RE: [security-services] Comments on Tech Overview rev 03

["Scott Cantor" <cantor.2@osu.edu>]

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