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

> 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

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

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