Assurance

[David Walker <>]

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

Attachment: signature.asc
Description: OpenPGP digital signature