[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: comments: sstc-saml-holder-of-key-browser-sso-draft-02
I was a bit hasty with some of my comments, so let me try to clarify below. On Sun, May 4, 2008 at 4:05 PM, Tom Scavo <trscavo@gmail.com> wrote: > > - [lines 343--344] Alternatively, why can't the Response be signed? On second thought, I agree the <saml:Assertion> element MUST be signed and I think this requirement should hold regardless of binding. > - [lines 404--408] This is too vague. Can you elaborate on the > choices and perhaps be specific about the content of the > <saml:SubjectConfirmationData> element? Actually, let me put a stake in the ground. The IdP MUST bind the complete certificate to the holder-of-key assertion. The reason is that I can imagine situations where the name is more important than the key. > - [lines 445--446] Can the <samlp:Response? be signed instead? (Yes.) No, you're right, the <saml:Assertion> element MUST be signed (regardless of binding). > - [lines 463--468] This paragraph assumes the use of a long-lived > X.509 certificate. This should be made explicit (since a short-lived, > opaque certificate won't have any of these limitations). In general, the lifetime of the certificate has no bearing on its privacy characteristics, so let me rephrase this. Unless X.509 client authn is used, the certificate may as well be self-signed (which of course can be constructed to be opaque). Moreover, the fact that "the public key is a de-facto persistent ID" is an advantage of this profile, not a disadvantage, since it precludes the need for the IdP to issue and maintain a persistent identifier for the user. Tom
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]