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 - saml-session-token-v1.0-wd03.pdfuploaded


Comments on wd-03:

(Please turn line numbering on in the PDF for the next drafts, makes
review much easier.)

Section 1, elsewhere, should http be more formally referenced as HTTP with
appropriate reference to 2616?

Normative References: the SAML spec references need to be cleaned up, or
they'll get caught during QA by tc-admin. You can find the proper syntax
from some of the recent SAML spec drafts.

Why is section 3 ultimately non-normative? Couldn't this be written as a
SAML assertion profile regarding what the content should be and what
MUST/SHOULD/MAY be evaluated? I guess I'd find it more intuitive to see 3
and 4 combined in that manner.

SAML element references should be in Courier, and namespace-qualified
(<saml:Conditions>).

Section 4: does this NameID have a connection to a NameID in a SAML SSO
context? I assume not, but I also wonder why it would be required, since
SAML SSO doesn't always include a NameID. Also, why would we make special
note of profiling it?...use of the NameID attributes should be governed by
the NameID Format, as with any other usage.

Why does subject confirmation have to be bearer? Couldn't one use client
TLS in, say, the HoK profile, and use this to create a session that binds
all the activity to the client key?

Are Conditions allowed, or just times? If not, we should say that.

Sec 4.4:

Are these intended to be "basic" attribute names? I'm strongly against any
use of SAML attributes in which the NameFormat is left unspecified.
Certainly in a formal SAML document, anyway. I would prefer we use URI
naming if at all possible, but I'm assuming maybe you're trying to save
space. But I think any practical use of an assertion in a cookie will be
compressed anyway.

Why is SessionStart needed if it's guaranteed to match AuthnInstant anyway?

What's the purpose of AuthenticationStrength?

Sec 5: Says the cookie name can be specified metadata, but I don't see any
profile for that here. Is compression allowed? Shouldn't it be?

Sec 6: Why base 64 the parameter only? That's technically not part of the
URI binding syntax you're reusing here, so I'd suggest that URL-encoding
the whole URI and leave it at that.

Sec 7: seems superfluous

-- Scott



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