OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] AI #88 - AuthnContext clarification




>-----Original Message-----
>From: Scott Cantor [mailto:cantor.2@osu.edu]
>Sent: Monday, January 12, 2004 6:35 PM
>To: 'Paul Madsen'; 'SAML'
>Subject: RE: [security-services] AI #88 - AuthnContext clarification
>
>
>> When embedded in metadata (and it could be done through any 
>of the three
>> mechanisms you identity below) the authentication context would be a
>logical
>> boast by the IDP along the lines of 'I can do this'. When 
>embedded within
>a
>> particular assertion, its 'I did this'.
>
>But am I correct that the metadata schema in ID-FF doesn't 
>include this? Or
>did I just overlook it?

You are correct

>
>> Actually, some classes are more specific. For instance the 
>Password class
>> requires that the password be 3 characters or greater.
>
>Ah, I missed that, thanks.
>
>> Additionally, context classes, although lablelled by their 
>authentication
>> mechanisms, do specify information beyond that listed in SAML's
>> AuthenticationMethod.
>
>Yes, but what I meant by that comment was that in general a 
>SAML Auth Method
>seems to just say "this is a broad label for the kind of stuff 
>we did" and
>that seems to match what the classes say, kind of. Maybe it's 
>a stretch.

I agree that SAML's AuthenticationMethod attribute hides alot of detail, but
I don't believe that the detail being hidden is anything other than info
about how the Principal authenticated.

For instance, for an IDP to assert saml:AuthenticationMethod="Password" it
is making no commitment wrt how the Principal was originally identified or
to the processes it follows in securing its infrastructure.

On the other hand, in principle, when an IDP asserts a particular
<lib:AuthnContextClassRef>, it is committing to more than simply how the
Principal authenticated. In practice, for the classes that Liberty defined,
it is only the 4 mobile classes that take advantage of this extra
functionality.


>
>> I think of the class ref as a ahorthand for the actual 
>context statement,
>if
>> both are included the IDP is saying 'here are the details if you're
>> interested, if not, here is the reader's digest version.
>
>Except that the class ref is a fixed URI that won't vary based 
>on the actual
>statement's contents, right? So it's not really a condensed 
>version but more
>like a signal that the statement itself is condensed from the 
>full syntax
>possible.

True, the context classes are schemas derived by restriction from the base
schema. An AuthnContextClassRef URI is a boast/promise/commitment by the IDP
that the XML authentication context statement (real or otherwise), in
addition to validting against the base schema, would also validate against
the class schema corresponding to that URI.

>
>-- Scott
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]