[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 Fri, Nov 21, 2008 at 5:17 AM, Peter Sylvester <Peter.Sylvester@edelweb.fr> wrote: > Tom Scavo wrote: >> >> On Wed, Nov 19, 2008 at 12:46 PM, Peter Sylvester >> <Peter.Sylvester@edelweb.fr> wrote: >> >>> 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. > > Yes, but there seems to be texts with SHOULD NOT that addresses this > scenario, > if the point is out of scope, then there is no reason to discourage > something. I agree. I, myself, have made comments along these lines. >>> 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. > > First: I didn' gave a definition of 'global'. I don't mean a "unique" type > identifier > for everything, also entities can have all kinds of identifiers, and several > of > them. I just wanted to refer to 'non ambiguous'. I don't understand the point you're trying to make here. If you could provide some clarifying text, that might help. >>> 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. > > Transforming the various fields and extension values in an X509 into > attributes of an saml attribut assertion, e.g. an email, or a web server > name, > some permanent identifier, etc. even keyusage etc First of all, that's not what this profile is about, so I don't think we should go there. Secondly, if the RP wishes to parse the certificate, there's nothing stopping it from doing so. Why does the SAML issuer have to do the work for the RP? > Most of these things are attributs and not part of an 'identity' . In X509 > one should theoretically use attribute certficates, but this doesn't help > at all to create an assertion as in SAML. If there's an attribute certificate bound to the public key certificate, then sure, the RP can consume that if it chooses. The SAML issuer need not get involved, however. In fact, I would argue that the SAML issuer in general isn't concerned with the contents of the certificate, and shouldn't insert stuff from the certificate into the assertion. If the RP trusts the issuer of the certificate, the RP can parse it if it wishes. Tom
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]