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] comments re sstc-saml-holder-of-key-browser-sso-draft-10

> How about this (intentionally verbose) text:

I suppose on the face of it, it reads ok to me. I don't know whether there
are other request elements that would fall under the domain of worrying
about whether the message was signed or not, and I think the original text
was left brief to avoid considering that question.

> > Or arguably you can satisfy the intent by saying "I trust anybody",
> > presumably by also including a user consent piece that makes it the
> > choice.
> Well, I wouldn't go so far in the HoK Web Browser SSO Profile since
> that seems to go against the intent or at least the spirit of the
> profile.

I'm not sure why there's a difference. I don't see this profile as doing
anything other than attempting to leverage SSL to provide a stronger
delivery binding. The SAML aspects seem fairly common to me.

> If the choice is arbitrary, then I see no point of allowing multiple
> elements to begin with.  Unless there is a possible use case, no
> matter how far fetched, I suggest we restrict ourselves to one and
> only one AuthnStatement.

I think the primary issue is that if you include multiple assertions that
relate to other profiles, some of them are likely to have authentication
statements (in most cases identical ones). I don't think you can have a rule
that says only one statement can appear across all of them.

-- Scott

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