Public Comments

The following documents underwent Public Review between 23 Apr 2018 and 7 May 2018:

See 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 <shibmd:Scope> 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 preclude regular expression use if we choose.
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.

PublicComments20180423-20180507 (last edited 2018-07-12 17:39:24 by cantor.2)