NOTE: This is a snapshot of the wiki page https://wiki.oasis-open.org/security/PublicComments20171113-20171212 on 16 April 2018. = Public Comments = The following documents underwent Public Review between 13 Nov 2017 and 12 Dec 2017: * [[SAMLSubjectIDAttr|SAML V2.0 Subject Identifier Attributes Profile Version 1.0]] See the [[https://lists.oasis-open.org/archives/security-services-comment/201711/msg00000.html|OASIS official announcement]] for details about this Public Review. The comments received during the Public Review period are itemized below. == SAML V2.0 Subject Identifier Attributes Profile Version 1.0 == === Comment 1 === Reference:: https://lists.oasis-open.org/archives/security-services-comment/201711/msg00001.html Submitted By:: Tom Scavo Comment:: Minor Typos and Suggestions Disposition:: Most of these were accepted as is, with some exceptions noted below. ----- Comment:: [lines 145, 148, 183, 186] s/should not/SHOULD NOT/ Disposition:: The editor feels these are generally untestable guidance that aren't suitable for normative language. ----- Comment:: [line 202] s/reproducible values/values/ Disposition:: The editor feels it's important to emphasize that computed values be reproducible. ----- Comment:: [section 3] Suggestion: For clarity, group all processing requirements (for the relying party) in a single subsection (or at least in contiguous paragraphs). Disposition:: The editor does not believe that clarity will be significantly improved by reordering material that was deliberately written to build on the material before it. For example, discussing case sensitivity is more confusing when placed before an explanation of the syntax rules. If text isn't needed, it should be removed rather than moved below other material. The editor also believes strongly that clarity is improved by separate syntax and semantics material. ----- Comment:: [line 86] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles Disposition:: Accepted ----- Comment:: [lines 98--101] The word “entityID” implies the use of metadata and therefore the use of that word in these definitions is problematic. I suggest you eliminate the use of this word altogether. AFAICT, it’s not needed in this spec. Disposition:: The editor believes that "entityID" is essentially interchangeable with the more abstract term "entity identifier" that is used in Core, but since it is true that the abbreviated form never appears in Core, it's better to spell it out. The concept underlying the term is definitely needed in this spec to explain scoping. ----- Comment:: [line 102] The term “Service Provider” is undefined. Comment:: [line 104] The term “Identity Provider” is undefined. Comment:: [line 191] The term “Identity Provider” is undefined. Comment:: [line 192] The term “Service Provider” is undefined. Disposition:: The terms are used throughout the SAML standard already. ----- Comment:: [section 3.3] Suggestion: Add an explicit example of a element to the latter part of this section. Comment:: [section 3.4] Add an explicit example of a element to this section. Disposition:: Accepted ----- Comment:: [line 107] The term “Standard Subject Identifier” does not adequately describe the identifier being defined in this section. Both of the identifiers defined in sections 3.3 and 3.4 are “standard.” Disposition:: The heading was changed to "General Purpose". There is no great term to use because nobody in the group who crafted this material was happy with "non-pairwise" or "non-directed" as a way of defining the opposite kind of identifier. ----- Comment:: [line 109] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles:attribute Comment:: [line 161] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles:attribute Disposition:: We will not change the names. The original standard used that, but subsequent documents have used the shorter form in some cases, and these names are absolutely set in stone at this stage of the process without an actual technical reason for changing them. ----- Comment:: [line 109] The suffix “subject-id” is suboptimal for two reasons: 1) the suffix clashes with the suffix of the identifier on line 86, and 2) the identifier defined in section 3.4 is also a subject identifier. Disposition:: We will not change it. All possible values considered have been suboptimal for various reasons, and these names are absolutely set in stone at this stage of the process without an actual technical reason for changing them. ----- Comment:: [lines 109--110] What is the FriendlyName of this Attribute? (Deployers will invent a FriendlyName if you don’t.) Comment:: [lines 161--162] What is the FriendlyName of this Attribute? (Deployers will invent a FriendlyName if you don’t.) Disposition:: FriendlyName is non-normative and deployers are free to make up any name they like for that purpose as with any other SAML Attribute. ----- Comment:: [lines 114--116] This is a binding rule, not a syntax rule. This requirement is out of place. Disposition:: It was poorly worded given that this Attribute is solely defined as being expressed using that XML syntax, so the sentence was altered to simply state outright what the syntax is. There's no "binding" needed because it has no abstract representation apart from SAML. Anybody wishing to define such would need to do so outside of this document. That's the main reason we didn't use an OID to name them. ----- Comment:: [lines 114--116] Add a binding rule that begins with the following text: “This Attribute, when appearing as a element...” Disposition:: This document very deliberately does not define such a syntax. We seek to end non-transient use of the NameID element. ----- Comment:: [line 117] Define “whitespace.” What characters exactly should be stripped? Disposition:: Clarified this is referring to XML's definition of whitespace. ----- Comment:: [lines 117--118] More importantly, what is the corresponding binding rule for the asserting party? Disposition:: The editor was not clear on the meaning of that comment. ----- Comment:: [line 128] A normative reference for “ABNF grammar” is needed. As it is, the primitives ALPHA and DIGIT are undefined. Disposition:: Added reference to RFC2234. ----- Comment:: [lines 132--134] The importance of this requirement is underemphasized. In the following subsection, the word “value” really means “equivalence class of values.” All values in an equivalence class are bound to at most one subject. The following paragraph attempts to make this precise: Disposition:: Under consideration. ----- Comment:: [lines 157--158] Convert this sentence into a normative requirement for asserting parties. Disposition:: Unchanged. It isn't describing an additional requirement, it's describing a possibly non-intuitive implication of the previous requirement about identical values always referring to the same subject. ----- Comment:: [lines 181--182] The word “reversible” implicitly refers to a hashed value. As you know, not all pairwise identifiers are hashed values, but for the sake of discussion, let’s assume it is. Is the use of SHA-1 allowed? Disposition:: The point of that sentence is not specific to hashed/computed identifiers, so the word was changed to "mappable". It has more to do with precluding the use of a username as a pairwise identifier. ----- Comment:: [lines 210--211] If a relying party requests a long-lived, non-reassigned identifier from an asserting party (by whatever means), but the asserting party asserts the legacy SAML V2.0 Persistent Identifier in lieu of the subject identifiers defined in this specification, is the asserting party conforming to this specification? Disposition:: There is no way to request that in SAML, and use of anything but the Attributes defined in this specification would be out of scope. ----- Comment:: [section 3.5.1] The requirements in this section say nothing about the relevant role descriptor(s) in metadata. I assume an SPSSODescriptor is required, but in that case, what if there are multiple AttributeConsumingService elements in that role descriptor? Speaking of which, the AttributeConsumingService construct was invented exactly for this purpose, so I’m not sure why you’ve profiled the use of an entity attribute? Disposition:: EntityAttributes do not appear at the role level, so it unnecessary to discuss that. Any role could be present if the role in question was one that was relevant to the consumption of attributes. This signaling mechanism has nothing to say about the mechanism you're asking about because it does not have sufficient expressiveness to deal with the simple requirement of "I must have this or that", which is something this mechanism has to be able to express. The "any" value is impossible to express using that mechanism, so it was simply ignored in favor of a mechanism that can be defined more freely. ----- Comment:: Suppose a relying party issues an AuthnRequest containing a extension element. How does the relying party signal its identifier requirements in the AuthnRequest? Disposition:: We are not trying to define such a mechanism, but if the relying party requires a specific type of identifier, then it would be straightforward to do so. If it requires one of the two types, but doesn't care which type, then it is impossible to do so with that syntax, which is why we chose not to use it. ----- Comment:: Similarly, suppose a relying party issues an AttributeQuery containing one or more elements. How does the relying party signal its identifier requirements in the AttributeQuery? Disposition:: Same answer. You can ask for one or both of these Attributes, but you can't ask for "one of them", and we are not attempting to fix that. ----- Comment:: The signaling mechanism profiled in section 3.5.1 does not address these questions. It seems we need a general-purpose signaling mechanism that satisfies all of these use cases. Disposition:: The editor has proposed a mechanism that meets the needs that have been identified and does not believe that it is necessary to support additional use cases at this time. If it were necessary, none of the machinery originally defined in SAML would be sufficient to do so. The specific question of whether to leverage the RequestedAttribute construct was considered and rejected deliberately, as it cannot meet the requirements. ----- Comment:: [lines 248--251] If the Attribute is carried in a element, is the asserting party conforming to this specification? (I assume that it is, but in any case, the spec should be explicit so that conformance is understood, one way or the other.) Disposition:: It is absolutely non-conformant to do so, and language has been added to that section to clarify that any such usage is not within the scope of this specification. ----- Comment:: [lines 252--252] It looks like [SAML2Prof] is normative. (It is listed as a non-normative reference on page 6.) Disposition:: Accepted ----- Comment:: [lines 258--259] It never occurred to me I was reading an implementation profile until I got to this page. Instead of defining conformance in terms of the implementation, I’ll suggest that conformance align with the semantics of the following metadata elements: Disposition:: The editor isn't comfortable expressing conformance in terms of an optional and unused portion of the metadata, but the conformance idea with attribute definitions can be a bit hard to express. Because the requirement for conformance clauses is an OASIS one, the editor simply prefers to leave it alone as it has no real impact on use of the specification. Also, in the unlikely event that this were to try to become an OASIS Standard, the only way that would be possible is for *implementations* to claim conformance, so it's best stated in those terms. As far as the metadata is concerned, it is inherently true that one can assert those elements in the manner suggested, and this specification doesn't need to explicitly point that out. Nobody uses them anyway, as EntityAttribute tags have replaced all of those approaches. ----- Comment:: [lines 264--265] This requirement focuses on just one of three possible use cases (listed above). I believe a more general signaling mechanism is needed. Disposition:: This specification does not preclude people with such use cases from defining additional signaling mechanisms, but the editor does not believe one is needed or will be used, and so has no mandate to define anything more than what was already defined. === Comment 2 === Reference:: https://lists.oasis-open.org/archives/security-services-comment/201711/msg00002.html Submitted By:: Tom Scavo Comment:: Proposal to implement the specification using a single attribute a different signaling mechanism. Disposition:: The editor produced a specification that approaches the problem based on a set of decisions that were made by an InCommon working group and that group debated all of these questions (1 attribute or two, the naming, the use of RequestedAttribute for signaling) and came to the conclusions reflected in the current specification. The editor in particular believes that the single attribute approach is flawed and would lead to confusion for deployers. The most important dimension of the proposal is the ability to know that one has received a non-pairwise identifier without any additional context or assumptions. Using one attribute would make that impossible since there would have to be assumptions made about what the source system provided and that it was following the rules expressed in some other layer of policy. The question of supporting RequestedAttribute is of course related since the use of two attributes is one of the major factors that make that approach unworkable in practice, but since that mechanism lacks widespread support in software, there has been no strong advocacy for its use (but there has been some, and if that's really a need, it can be met later). Support for Affiliations was also debated, and the total lack of use to date made it a feature deemed unnecessary to support initially and even allowing for it would complicate the proposal in ways that wouldn't benefit its adoption.