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: Comments on Tech Overview rev 03

Hi John-- Here are some comments on the Tech Overview.  As promised 
on this week's call, I'm sending them to the list.  I'm looking at 
this version:


I'm happy to try to incorporate my suggested changes wherever you 
think this would be appropriate, so let me know.

Section 1, Introduction:

Since this section delves into the IdP and SP concepts, I think it 
might be useful to go into the other various entities, roles, and 
relationships that SAML introduces, like asserting/relying parties, 
subjects/principals/users, etc.

We ensured in V2.0 that the core spec and other specs got a closer 
look to make sure we used all these terms appropriately, and this is 
the perfect document to expound on the distinctions.  There's a 
little wording now in the core spec that might provide "seeds" for 
this -- see, e.g., the intro to Core Section 2 -- and of course 
there's the glossary also.

In summaries of SAML, we keep running into the problem of describing 
the SAML piece-parts (assertions, protocols, bindings, profiles) but 
not having a formal place to talk about the actors that use them. 
This would solve that for the Tech Ovw, and also give an opportunity 
to refer readers to the Conformance doc to learn about operational 

If the fuller discussion of roles shouldn't go here, then maybe a 
new subsection of Section 3 (SAML Architecture) is needed, perhaps 
called "Entities".

Section 2, SAML Use Cases:

The first two paragraphs and block quote are repetitive and should 
be struck.  Here, I would dive right into the "drivers" (and remove 
the scare quotes from around that word!).

s/Most existing/Most pre-SAML/
s/Single-Sign On/Single Sign-On/
s/use browser cookies/used browser cookies/

On the SSO interoperability point, I would reverse the sense of the 
paragraph and state the interop benefits positively.

On the federation point, the description of federation as 
"consolidat[ing] many local identities into a single ... Federated 
Identity" seems wrong.  You federate *identities*, and in so doing 
you avoid centralizing into a single anything (other than a single 

Section 2.1, Single Sign-On Use Case:

s/SAML 1.0/SAML V1.0/g
s/SAML 1.1/SAML V1.1/g
s/Cross Domain/Cross-Domain/g

s/At some either/At some point either/

It doesn't seem obvious (nor typical) that AirlineInc.com in this 
example is the IdP but also, presumably, one of the services. 
Changing this assumption to use a more "neutral" IdP name would 
affect text and also diagrams throughout the document.  Should it be 

Figure 1 should be doublechecked against the similar (but not 
identical) diagram that appears in the Executive Overview.

Section 2.2, Federation Use Case:

s/one for car rentals/one for car rentals,/

Can it be stated here what the benefit is of linking the two 
accounts?  Personalized services, better access control, better 

Section 3, SAML Architecture:

See my note above under Section 1 about maybe having a subsection -- 
"Entities"? -- here.  Note that some of the first paragraph here 
already has to deal with principals and asserting parties, so a 
fuller explanation would certainly help here.

Also, should a subsection on Extensibility be added in Section 3, 
say, before 3.3?  It seems to me we should cover this in the Tech Ovw.

I would change the Attribute Profiles sentence to read "There are 
also Attribute Profiles (for example, LDAP and DCE profiles), which 
define how to interpret attribute information carried within an 
Assertion using common attribute/directory technologies."

s/how configuration information shared/how to express and share/
s/entities is defined and shared/entities/
s/DNS records/DNS records./

Insert "These" after the colons in the sub-list items under Assertions.

In the Protocols list item:
s/. The protocol is/which are/
s/defined are./defined are:/

In the sub-list of the Protocols list item, I like that the actual 
request and response elements are named in some cases.  Can they be 
added throughout?

In the Bindings list item:
PAOS sub-item: s/a HTTP/an HTTP/
Add periods to ends of Redirect and POST sub-items

I suggest the following description for the URI binding: "Defines a 
means for retrieving a SAML assertion by resolving a URI (uniform 
resource identifier)."

In the Profiles list item intro:
s/combined/combined for interoperability in particular usage scenarios/

Figure 3 needs to be revised to pluralize the word PROTOCOL.

Section 3.3.1, Assertions:

s/its more typical/it is more typical/

The intro to Figure 5 mentions highlighting of the authn statement, 
but I see none.  Beware that the PDF distillation process may do 
away with some bold and italic if it doesn't have the right font for 
these; maybe it would be a good idea to number the example lines and 
refer to them in the text as a backup.

s/In this case its/In this case it's/
Insert parens around "a number of predefined...and X.509 subject names".

I would strike the XML declaration from the first line of Figure 5, 
since more often a SAML assertion would be a fragment and not a 
whole XML document.

Should there be a bit more description about this first example, to 
set the stage?  E.g., remark on the validity period info vs. the 
issue instant?

Section 3.3.2, SOAP over HTTP Binding:

In Figure 7, if you want to have an XML declaration somewhere, this 
might be a good time to use it.

I stopped my review here; will continue as time permits!

Eve Maler                                      eve.maler @ sun.com
Sun Microsystems - Business Alliances     x40976 / +1 425 947 4522

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