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] Groups - SAML shared credential (draft-saml-shared-credential-discussion-01.doc)uploaded

Scott, to your point regarding authentication context classes as a 
solution for the use case, I can well imagine a conversation along the 
lines of

1) IDP->SP: here is X and the AC class is 'urn:SAML:ac:classes:shared'
2) SP->IDP: I need an AC class of 'urn:SAML:ac:password'
3) IDP->SP: here is Y and the AC  class is  'urn:SAML:ac:password'

It would be from the specified AC class of  #1 that the SP would infer 
that  the  identifier was shared (if it wasn't able to determine that 
from how that id mapped into its local identifiers).

The IDP would recognize that it would be unable to satisfy the requested 
AC class of #2 without authenticating the user in a different way.

So, yes I think this could work.

But, I have trouble understanding how it would fit with existing AC classes.

As modelled above, the 'shared' URI above doesn't allow the IDP to 
express other aspects of the authentication, e.g. that it was a mobile 
phone, or a kiosk. This info could be relevant for the SP.

But, if the above URI instead looked like 
'urn:SAML:ac:classes:shared:mobile' (or 
'urn:SAML:ac:classes:mobile:shared"), giving the SP this info, the 
implication appears that we need to extend all existing classes.

'Shared' (or collective or composite)  feels like a 'meta' attribute 
that could be relevant across all existing classes (maybe not biometric).

If the AuthnStatement allowed multiple AuthnContext elements (like the 
AuthnRequest does for RequestedAuthnContext) this wouldn't be an issue I 


Scott Cantor wrote:
>> I feel strongly that that this property of being or not being an
>> accountable identity is an abstract property of the identity and is not
>> related to an authentication act. Naturally the Issuing Party will use a
>> policy for distributing passwords or keys that corresponds to its notion
>> of the type of identity in question. In short, I see this property as
>> just another attribute of the subject.
> I think anything can be turned into attributes of the subject, including
> Authentication Context information, which is where I think this kind of
> "meta-information" about the account's essential nature belongs. It also has
> the advantage of solving this particular use case, at least.
>> This brings me to my proposed approach. Why not use an attribute
>> statement to indicate the Issuing Party's belief about the type of
>> identity it is?
> This wouldn't be a problem, except...
>> Then we should be able to use existing
>> machinery, such as an attribute query to say, I need the accountable
>> identity that is associated with this request, here is the composite
>> identity.
> There's no way to use a query for this use case. If the user starts out
> authenticating under an account that doesn't possess the attribute, a web
> site couldn't use a query to get the IdP to interact with the user so that
> the attribute could be obtained. Not by itself anyway, since the query is a
> back-channel.
> Instead, you'd probably use metadata to identify the attribute/value needed
> and reauthenticate with a new AuthnRequest that had a different
> AttributeConsumingServiceIndex in it. The IdP would have to figure out the
> implications of the attribute value the SP wanted and extrapolate from it
> that a new authentication approach was needed.
> I don't see the inherent advantage of that over and above using AuthnContext
> by defining deployment-specific classes to distinguish it.
> -- Scott
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Paul Madsen                        e:paulmadsen @ ntt-at.com
NTT                                p:613-482-0432

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