Comment number | Comment | Author | Resolution | ||
---|---|---|---|---|---|
1 | The draft document as well as "Work Item 4" refered to an obsolete version of the subject-id spec, namely "Committee Draft 03": http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/csprd03/saml-subject-id-attr-v1.0-csprd03.pdf when a "Committee Specification 01" has been published in Jan 2019, even before this change request was brought to REFEDS, cf. https://wiki.oasis-open.org/security/SAMLSubjectIDAttr (As only the OpenDocument formats for OASIS standards are "authoritative" -- and the reference was to the PDF, so non-authoritative refs. seem to be fine I've now referenced the HTML version which is more suitable to and accessible for reading on the web.) | Peter Schober | Reference will be updated to point to https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html | ||
2 | The ChangeLog in the draft document still seems to be missing anything for 201911 (or rather '201910' as it calls itself) but had re-written the most previous changelog entry for 201602 which read: The following list shows changes in version (201910) relative to version (201310). which has now been changed back. | Peter Schober | A changelog will be updated, including an addition for 201911 changes. | ||
3 | Get rid of the manual TOC section and replace it with an auto-generated one (minlevel:3, maxlevel 5; maybe make individual attribute defs h5 if you want them to be included and clickable) | Peter Schober | Will fix as much as this wiki platform allows | ||
4 | "Unlink" the links in the change log: It's not clear to me what external document (and version thereof) these should point to -- the version the change was made? The current version/this document? – so just 'unlink' them. | Peter Schober | Will drop links | ||
5 | At UC, we’ve run into one case where the eduPersonAffiliation statuses don’t work for us. That is the concept of a “knowledge worker”. I don’t have a well-defined description of this yet, but basically it’s the need to capture the concept of an “employee-like member”. With existing affiliations, you can’t really distinguish “student-like members” from “employee-like members”. I grant you that even if one were defined, it wouldn’t be any more precise than the existing “employee”, “staff” and “faculty” values (can a knowledge worker contractor who’s not an employee be identified as an “employee”?) But it would allow UC to define standards for use of eduPersonAffiliation values without necessarily needing to define our own, distinct ucPersonAffiliation values. I can see this either way. This distinction is definitely more around business use than it is around research use of services, so may be better handled outside of eduPerson, eduPersonAffiliation has a long history of use and adding values now could break “stuff” out there, etc. So for now, just curious about your take on this. | Eric Goodman | This item is considered out of scope for this consultation, but will be brought up as a future work item. | ||
6 | In chapter 2.2.2 the link to http://shibboleth.internet2.edu/ could be replaced with an https link to
| Thomas Lenggenhager | Will change the link to https://www.shibboleth.net | ||
7 | The References section has no link link to RFC2798, that is still the source of several attributes. http://tools.ietf.org/html/rfc2798 | Thomas Lenggenhager | Will fix all references to the correct location for referencing RFCs. | ||
8 | In chapter 3.22. preferredLanguage I suggest to more precisely specify the 'permissible values' with a wording like this one: Permissible values ------------------ The syntax for preferredLanguage is derived from BCP47: langtag = language ["-" region] language = 2*3ALPHA ; shortest ISO 639 code region = 2ALPHA ; ISO 3166 code The language tag is composed of a primary language (two-letter ISO639 language code) and an optional region (two-letter ISO3166-1 country code). Additional References to add: [BCP47] https://tools.ietf.org/html/bcp47 [ISO639] https://en.wikipedia.org/wiki/ISO_639 [ISO3166-1] https://en.wikipedia.org/wiki/ISO_3166-1#Current_codes | Thomas Lenggenhager | Since we are not normative for the format here, we will include the appropriate references to RFC 2798 (preferred language) and RFC 2068 (form for the language specification). | ||
9 | I also wondered whether the copyright notice should still (only) call out Internet2 and (unnamed) authors: "Copyright © 2019 by Internet2 and/or the respective authors" | Peter Schober | Because the work was originally done by Internet2 and a host of individuals (some deceased), transferring the copyright is particularly complicated and difficult to transfer. Changes to the copyright will also result in potential changes to the other aspects of the IPR regime for eduPerson. This will require a separate work item to discuss; the Schema Board proposes to continue with this consultation with no resolution on this particular item. | ||
10 | I've a comment about "Work item 4": I found the original statement from Scott C. more clear in that it was explicitly citing the `<NameID> Format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"`. Would it possible to add back the reference to the <NameID>? | Davide Vaghetti | Protocol-specific references are being moved to a separate companion document in order to make eduPerson itself as protocol-agnostic as possible. | ||
11 | In Work Item 4, the proposed changes include a link to the SAML subject-id draft. This should be updated to point to the final approved Committee Specification (http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/) The link should really be to the CS01 version explicitly. Otherwise you're technically pointing to a moving link that could point to a later version (unlikely here, but it's the principle). | Scott Cantor | Duplicate; see item 1 | ||
12 | "Values of eduPersonPrincipalName are often, but not required to be, human-friendly, and may change as a result of various business processes. They may also be reassigned after a locally-defined period of dormancy. As a result, eduPersonPrincipalName is NOT RECOMMENDED for use by applications that provide separation between low-level identification and more presentation-oriented data such as name and email address."
| Alex Stuart | Sentence ("They may also be reassigned after a locally-defined period of dormancy.") will be revised to: "Possibilities of changes and reassignments make this identifier unsuitable for many purposes." | ||