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: 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.


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