[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on sstc-saml-core-2.0-draft-17.pdf ( long)
Below are some comments on the current last call draft available at [1], including some proposed text changes. Cheers, - JohnK Line number references are to the above-named draft document accessed at [1]: 212-220 Given that we have several more protocols than previously, and that not all of these protocols are directly involved in transmitting or requesting assertions, I think the introduction should be broadened a little - something along the lines of: "The Security Assertion Markup Language (SAML) defines the syntax and processing semantics of assertions made about a subject by a system entity. In the course of making, or relying upon such assertions, SAML system entities may use other protocols to communicate aspects either regarding an assertion itself, or the subject of an assertion. This specification defines both the structure of a SAML assertion, and the associated set of protocols, in addition to the processing rules involved in managing a SAML system." I suggest replacing the sentence starting on 212, ending on 213, with the above. 216-217 We now have both bindings and profiles. I think we need to briefly discuss the relationship between the two (enough for an implementer to be able to know roughly how to proceed), and then lead the reader to [SAML-TechOvw] for more info. 309-320 Although "subject-less" assertions are not currently defined by SSTC, we offer the capability for those extending the SAML assertion schema to make use of the optionality of the <Subject> element now defined in the assertion itself. I think we should note a) roughly on line 318, that "SAML assertions are usually made about a <emphasis>Subject</emphasis> (see [SAML-Gloss]). However, the <Subject> element of the assertion is optional, and other specifications may utilize the structure of the SAML assertion to make similar statements without specifying a subject." and b) we should define "subject" in the glossary, if we don't already, and reference that from here. 351-352 I think we need to say a bit more about Name Identifiers, by way of explanation. I think there's quite a lot of good stuff in the section at the end of the document where the various formats are defined, but it references some things that should probably also be up front here. I recommend something like the following be inserted at line 352: "Given that the SAML protocol enables third-party authentication of a subject, in addition to a number of other circumstances where two system entities (where one entity may even be acting on behalf of an <emphasis>affiliation</emphasis> (see [SAML-Gloss], [SAML-TechOvw]) may communicate regarding a third party, it is useful to establish a means by which parties may be associated with identifiers that are meaningful to each of the parties. In some cases, it will be necessary to limit the scope within which an identifier is used to a small set of system entities (to preserve the privacy of a so-named subject, for example). Similar identifiers may also be used to refer to the issuer of a SAML protocol message or assertion. It is possible that two or more system entities may define the same name identifier to refer to different identities. Thus, each entity may have a different understanding of that same name. SAML provides a <emphasis> name qualifier</emphasis> to disambiguate the name identifier by effectively placing it in a <emphasis>namespace</emphasis> (perhaps we need to define 'namespace' separately from XML namespace???) related to that qualifier. Name identifiers may be encrypted to further improve their privacy-preserving characteristics, particularly in cases where the identifier may be transmitted via some intermediary." Note that I mention "affiliation" in there - I don't see any mention of that concept in [SAML-Core] until we get to the section on NI formats, so I just want to make sure that the glossary and tech overview have something about affiliations in there. I don't really see such a great place to talk specifically about it in [SAML-Core] but that's probably OK if we have reference to the relevant places. 501-502 Regarding the subject-less assertions - SAML defines assertions that *may* have no subject, but does not define any semantics around those - should we not just say that more explicitly to prevent confusion? It seems to me that SAML doesn't (currently) have a profile where subject is omitted - other specifications either as a future piece of SAML, or outside of SSTC may exist that create such a profile, but that is outside the scope of this specification - so I would suggest stronger language here to note that there are currently no semantics in SAML for this, unless you really wish to leave it ambiguous (which I'm not against BTW if that's what you intend?) 658 - If one can only ever supply one OneTimeUse element, why is this restricted in prose instead of schema? Should we not explain that reasoning? BTW - line 772 duplicates the MUST 663 - same comment as above, and MUST is also duplicated at line 803 774 and 805 - I am not sure what these sentences actually mean - "for the purposes of determining the validity of the <Conditions> element, the XXXX is considered to always be valid" - are you really saying that the system entity evaluating the <Conditions> need not take these conditions into account when determining overall validity of the <Conditions> element? 863-870 I notice that the encrypted assertion type looks a lot like the encrypted NameID type. I was wondering whether these could be derived similarly - ie. define a BaseEncryptableType, and put the EncryptedData, EncryptedKey into it. Then one could derive both the BaseID (or just the EncryptedNameID I guess) and EncryptedAssertion from the same base type. Not only that, it would possibly allow others to encrypt other things. I guess I'm not totally sure how to model multiple inheritance or interfaces in XML... 874 - I think that the abstract statement type is used not only by "other assertion-based applications" but also by SAML statements. Not wanting to confuse the reader, I think we should say so, and note that "other specifications may create assertion-based frameworks by extending the StatementAbstractType" or something similar. 898 - SubjectLocality - presumably this should refer to the subject specified at the assertion-level? Should we say that? 906 - Speaking of which, this sentence is indented, which made it hard for me to see that we do in fact make the Subject required in the assertion contains an AuthnStatement. We might want to remove the indentation at least, but I think this sentence should actually move up to the introductory paragraph - roughly line 886 seems like a good place. 965 - 980 The authentication context content model allows one to basically put nothing inside an instance of the element - is that desirable? Should we make a top-level <choice> group that allows multiples of the decl/class/refs with a minOccurs = 1 (ie. no point in including an AuthnContext if you don't make at least one (and as many as you want) statement(s)). 1097-1102 - same comments about creating a BaseEncryptableType and having the EncryptedAttribute element derive from that.... 1232-1239 - again, no discussion of what profiles do, or of [SAMLProf] generally 1318 - 1320 (also applies to 1382) - lines are indented where they probably shouldn't be. Also, this sentence makes me ask the question - "What should I do if there's no signature present?" Can I also not rely on the request? [1] http://www.oasis-open.org/committees/download.php/7737/sstc-saml-core-2.0-draft-17.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]