= Public Comments = The following documents underwent Public Review between 23 Apr 2018 and 7 May 2018: * SAML V2.0 Subject Identifier Attributes Profile Version 1.0 CSD02 See https://lists.oasis-open.org/archives/security-services-comment/201804/msg00000.html (the 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 CSD 02 == === Comment 1 === Reference:: https://lists.oasis-open.org/archives/security-services-comment/201804/msg00001.html Submitted By:: Paul Knight Comment:: In publishing the files for csprd02, we noted a typo: "Tthis" at the beginning of the last sentence of Section 3.5.2 (before Section 4). Disposition:: Corrected typo. === Comment 2 === Reference:: http://lists.oasis-open.org/archives/security-services-comment/201805/msg00000.html Submitted By:: Tom Scavo * Comment:: This profile includes an excellent summary of lessons learned (lines 37–47) but it lacks a candid discussion of the potential pitfalls associated with scoped identifiers. Disposition:: The editor agrees and has drafted non-normative guidance drawing on some of the suggested additions. * Comment:: This profile intentionally overlooks the use of scoped identifiers in conjunction with the NameID element. While this may be good advice in general, I don’t think this profile is the right place to discourage the use of the NameID element. Disposition:: No change. The editor disagrees profoundly and this document's main purpose is in fact to preclude them. * Comment:: (Ignoring the use of NameIDs) renders scoped identifiers irrelevant for those SAML implementations that lack the ability to produce or consume SAML Attributes. Disposition:: No change. The editor actively seeks to deprecate the usage of such implementations and the document's purpose would be fatally undermined by any compromise around their usage. Very few, if any, actual SAML implementations have this limitation. It's a deployment problem, not an implementer problem. * Comment:: If you want this specification to be relevant outside of higher education, you need to standardize the metadata extension. Diposition:: The response from OASIS when asked was that it is possible when justified to standardize a namespace owned by a third party, so given some legwork on the IPR issues, this appears to be doable and the document will be revised to include this material. Note that it can't be rendered incompatible, but we can normatively discourage regular expression use and certainly allow implementations to omit it. * Comment:: Line 93. “This profile defines a pair of SAML Attributes...” Some SAML relying parties require the SAML NameID element to hold a long-lived identifier. Presumably those relying party implementations do not have the ability to consume arbitrary SAML Attributes. Disposition:: No change. There is no real evidence that this ability is missing, it's simply a choice by deployers. This document seeks to provide an interoperable solution that has to cover not just what the data is, but where it goes and what it's called. Generality is how we got here. * Comment:: Line 60. s/factually untrue, assumption/factually untrue assumption/ Disposition:: The comma is paired with an earlier one that introduces an intentonal pause so this was left alone. * Comment:: Line 124. s/1 to 127 characters, all either alphanumeric or the equals sign (ASCII 61) or hypen (ASCII 45)/1 to 127 ASCII characters, each of which is either an alphanumeric ASCII character, an equals sign (ASCII 61), or a hyphen (ASCII 45)/ Disposition:: Accepted. * Comment:: Line 126. s/1 to 127 alphanumeric, hyphen (ASCII 45), or period (ASCII 46) characters/1 to 127 ASCII characters, each of which is either an alphanumeric ASCII character, a hyphen (ASCII 45), or a period (ASCII 46)/ Disposition:: Accepted. * Comment:: Line 247. s/a relying party MUST express/a relying party implementation MUST be able to express/ Disposition:: Left alone. The editor prefers the original wording, it expresses a more active intent that the RP must actually do something in its metadata. * Comment:: Line 280. s/Tthis/This/ Disposition:: Duplicate of comment from Paul, accepted. * Comment:: Lines 285–286 s/configured to produce the two identifier Attributes/configured to produce both identifier Attributes/ Disposition:: Accepted. * Comment:: Lines 288–289. s/configured to consume neither, either, and both/configured to consume either or both/ Disposition:: Left alone. This is about implementation conformance by software, which means the full generality must be possible. All of the possible options must be supported by software to allow deployments to choose the right one.