Assurance

[Paul Caskey <>]

It was the discovery use case I had in mind...


> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of David Walker
> Sent: Wednesday, May 04, 2016 11:25 AM
> To: 
> 
> Subject: Re: [Assurance] comments on draft MFA Interop WG documents
> 
> I'll take responsibility for putting the work "assurance" in the URI.  I 
> did it
> without much thought, and it certainly can be changed.  In fact, the plan 
> is to
> replace it with a URI in the REFEDS name space, anyway.
> 
> I agree with everyone that the MFA authentication context should be self-
> asserted.  I think the real question is whether IdPs that support the MFA
> profile should also be given a (presumably self asserted) entity category in
> metadata.  The current draft does not recommend an entity category, as the
> group didn't see use cases where it would help.  We have since, however,
> heard of SPs that would like to tailor their discovery interfaces to exclude
> non-MFA-supporting IdPs, and there are situations where an entity category
> can save an SP from issuing a second authentication request when it prefers
> MFA, but will accept anything else.
> 
> Do others have use cases for an IdP entity category that it supports the MFA
> profile?  It's certainly not too late to define one.
> 
> David
> 
> 
> On 05/04/2016 07:38 AM, Paul Caskey wrote:
> > +1 to all of that and yes, IMHO, we should not use the word 'assurance' to
> refer to this context.
> >
> >
> >
> >> -----Original Message-----
> >> From: 
> >> 
> >>  [
> >> ]
> >>  On Behalf Of Cantor, Scott
> >> Sent: Wednesday, May 04, 2016 8:48 AM
> >> To: 
> >> 
> >> Subject: RE: [Assurance] comments on draft MFA Interop WG documents
> >>
> >>> I hope we don't need to require an addendum for MFA...
> >>>
> >>> I think the intent was for self-assertion.
> >> I won't speak for the WG, but while working on the material, I had
> >> been operating under the assumption this was not an assurance
> >> category at all but a self-asserted AuthnContextClassRef (in SAML
> >> terms), just like many others defined in SAML already. Thus the idea
> >> of a self-asserted category to go with a self-asserted AuthnContext
> >> seemed redundant (but that may prove not to be the case for other
> reasons).
> >>
> >> I didn't actually notice the naming convention in the URI included
> >> the word assurance, and tend to think that may be confusing as a
> >> result and worth reconsidering before this finalizes. Sometimes the
> >> obvious doesn't hit you when you're staring at it closely.
> >>
> >> -- Scott
>