[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]