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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

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

Subject: Re: [security-services-comment] Re: http://saml.xml.org/news/holder-of-key-web-browser-sso-profile

On Wed, Nov 19, 2008 at 12:46 PM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
> The usage of SAML assertions allows to disconnect some  'primary' identity
> which
> is available in an X.509  from some 'secondary' identity which is
> established in
> whatever way and which  may be totally unrelated to the identities which are
> present
> in the X.509.

The identifiers in the certificate do not matter with respect to SAML
Web Browser SSO (unless of course the SAML issuer decides otherwise).
The only identifiers that matter are the Subject/NameID and any global
identifiers that happen to be asserted as attributes in an
AttributeStatement.  In particular, the stuff in SubjectConfirmation
are not identifiers for the user.

> The identities present in the X.509 certificate  may be
> totally ignored by
> a service provider and the identity provider after initial registration.

Yes, and we anticipate this to be the typical case.

> Furthermore, the SAML assertion is established for each act and normally
> has a lifetime much shorter than the lifetime of a certificate.


> Nevertheless, the specification do not prohibit to use identities present
> in the X.509 certificate in closed environments.

But this is totally out of scope with respect to HoK Web Browser SSO.

> The introduction could mention something about that an X.509 cert has two
> purpuses:
> - The usage of the key (respond to some authentication challenge)
> - The link to some "global" identity.
> The specification treats a case where the second part may or is not
> used, i.e. a service provider only used the first part to
> verify whether the saml assertion is presented by the holder
> of the key and present whatever identity it is configured to present.

This is how it should be, I think.  We can note the possible uses of
the certificate in the profile (and I think we've tried to do this)
but that text should not be in the normative parts of the document
lest the reader misunderstand the intent.

> There is a use that would like to use whatever is in a certificate
> in more or less diffcult ways for an application, but easier
> for a "centralised" function or id server.

I'm not sure what that means.

> My initial question was for a feature to return additional
> identifier of the "subject" for example in the way outlined below.

But what you are proposing is an inappropriate use of
SubjectConfirmation, I believe.  That's not what SubjectConfirmation
is for.


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