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] Groups - sstc-saml-holder-of-key-browser-sso-draft-03.odt (sstc-saml-holder-of-key-browser-sso-draft-03.odt) uploaded


Some comments:

Sec 2.5.1: I don't think it's necessary to preclude a <saml:NameID> in the request, but you may want to include the guidance about not relying on the certificate name for that. At least one use case for including a NameID is orthogonal to this profile (those "remember me" checkboxes where the SP would essentially say "I think this should be John Doe").

Sec 2.5.2: I would reword "If the user agent fails to meet...". Maybe say "If the user agent cannot satisfy the..."

Sec 2.5.3: In the bullet on Single Logout, I think you should add <saml:NameID> to SessionIndex there. The original profile fails to note this, and it's come up a few times as to what the implications of not including a NameID are. (Or maybe you want to just preclude omitting NameID altogether, up to you.)

Sec 4, line 489: I think this is confusing in context because in fact as the profile is written, you're NOT issuing reusable assertions and they should still have short confirmation windows. In SSO now, the assertion *validity period* is independent of that anyway, even with bearer.

You *could* make the confirmation window longer, but why bother? The assertion is still targeted via audience at the SP, and it's an SP-driven profile, so I don't think this is really the right vehicle to be pushing reusable assertions.

-- Scott




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