[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Comments on Tech Overview rev 03
I've started looking at this, not much time spent yet, but some things Eve didn't mention that jumped out: In 3.2 on Protocols, I would either reference the protocol message elements in all cases or none. For the Authn Request protocol, I'd reword to something like: "Defines a protocol by which a Service Provider or Principal can request assertions from an Identity Provider tailored to the requirements of a particular SAML profile, for example the Web Browser SSO Profile." The Artifact Protocol needs some corrections to reflect SAML 2.0. In particular, assertions don't factor into the definition anywhere. Something like: "Provides a mechanism by which protocol messages may be passed by reference using a small, fixed length value called an "artifact". The artifact receiver uses the Artifact Protocol to dereference the actual protocol message." For the Name Identifier Mapping protocol, I wouldn't refer to account linking there, but maybe something like: "Provides a mechanism to programmatically map one SAML NameIdentifier into another, subject to appropriate policy controls." Starting with line 237, Profiles, some suggested wording changes: Web browser SSO Profile: "Defines a mechanism for single sign-on by unmodified web browsers to multiple Service Providers using the Authentication Request protocol in combination with the HTTP Redirect, POST, and Artifact bindings." ECP Profile: "Defines a profile of the Authentication Request protocol in conjunction with the Reverse-SOAP and SOAP bindings suited to clients or gateway devices with knowledge of one or more Identity Providers." IdP Discovery Profile: "Defines one possible mechanism for a set of cooperating Identity and Service providers to obtain the Identity Providers used by a Principal." I haven't had time to go over the SSO meat in detail. Regarding section 6: Line 912, say rather "SAML V2.0 constitutes..." Line 915, change to "...are incompatible..." Line 936, there's now just a single Version atribute with the value "2.0". Line 949, "enclosed statements" rather than "inner". Line 951, <SubjectConfirmation> is now repeatable, with the formerly repeatable ConfirmationMethod element now an attribute within that element. Line 968, applies to both requests and responses Line 969, note that Issuer was added to requests and responses, as it did not appear there in SAML 1.1 Line 973, note that Status codes are now URIs instead of QNames Line 981, sec 6.8, this went back and forth, but SessionIndex only ended up on AuthnStatement. It's a new attribute, so I'd just say something like "The <AuthnStatement> element can contain a SessionIndex value in support of single logout and other session management requirements." Line 1007, clarify that this is about the use of KeyInfo within SubjectConfirmationData Other changes of note: A set of generic attributes in SubjectConfirmationData is defined for use in constraining the bearer method or other confirmation methods. Overall assertion validity is more flexible within profiles that use bearer as a result. The new BaseID extension point permits non-string identification of Subjects. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]