Next in thread → Next in month →

Re: SAML V2.0 HoK Web Browser SSO Profile (draft-11)

From
Tom Scavo <>
Date
2009-01-13T04:24:54+00:00
ID
Thread
Re: SAML V2.0 HoK Web Browser SSO Profile (draft-11)
On Sun, Jan 11, 2009 at 8:15 PM, Tom Scavo <> wrote:
> Draft-11 of the SAML V2.0 HoK Web Browser SSO Profile has been
> uploaded to the document repository:
>
> http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile
>
> This draft of the SAML V2.0 Holder-of-Key Web Browser SSO Profile has
> been edited for clarity and preciseness.  The spirit and intent of
> Nate Klingenstein's original work has been mostly preserved in
> draft-11.  Since nearly every paragraph has been touched, in some
> cases totally rewritten, no diff has been provided.  However, I will
> summarize the changes made to the profile on next Tuesday's call.
>
> Tom Scavo
> NCSA

Here is a list of sections in the draft-11 where the language differs
significantly from that in draft-10:

- Section 1.5 (Conformance).  HTTP POST and HTTP Redirect are
mandatory to implement.  HTTP Artifact is OPTIONAL.

- Section 2.4 (TLS Usage) is completely new.  Paragraph at lines
334--340 is new, otherwise this section is a reformulation of the TLS
requirements previously scattered about (or implied).

- Section 2.5 (Choice of Binding) is completely new.  Suggests
SimpleSign may be used, otherwise there's nothing new here.

- Aside: Is SimpleSign allowed?  Does it make sense to use SimpleSign
in a profile meant to be "stronger" than ordinary Web Browser SSO?  If
SimpleSign is allowed, then language using the words "sign" or
"signing" needs to be loosened.

- Section 2.7.1 (<samlp:AuthnRequest> Usage).  The request may be
signed (period).  New requirements regarding the XML attributes on the
<samlp:AuthnRequest> element.  Removed the redundant requirement re
AllowCreate="true".

- Section 2.7.2 (<samlp:AuthnRequest> Message Processing Rules). New
rules in the case where the request is signed.  Clarification of
behavior if the XML attributes on the <samlp:AuthnRequest> element are
missing.

- Section 2.7.3 (<samlp:Response> Usage).  Clarification re strongly
matching subjects.  Additional language in the case where multiple
<saml:AuthnStatement> elements are issued (see lines 529--537).

- Section 2.7.4 (<samlp:Response> Message Processing Rules).  Behavior
in the case of multiple <saml:AuthnStatement> elements (basically, SP
behavior is unspecified).  Removed requirement: "SHOULD NOT rely on
any other data."
Next in thread → Next in month →