[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: http://www.oasis-open.org/apps/org/workgroup/security/document.php?document_id=11512 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 modes. 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 "mapping"). 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 changed? 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 privacy... 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 -- 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]