Versions Compared

Old Version 3

changes.mady.by.user Heather Flanagan

Saved on

compared with

New Version Current

changes.mady.by.user Peter Brand

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: DRAFT


Comment numberCommentAuthorResolution
1The 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 SchoberReference 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).
   1. Section 2.2.14 "eduPersonOrcid"added

which has now been changed back.

Peter SchoberA changelog will be updated, including an addition for 201911 changes.
3Get 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 SchoberWill 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 SchoberWill 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 GoodmanThis 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
https://www.internet2.edu/products-services/trust-identity/shibboleth/

Info

"I think that comment is a little dated at this point and probably should be removed altogether, but link to https://www.shibboleth.net/ if anywhere." – Scott Cantor


Thomas LenggenhagerWill change the link to https://www.shibboleth.net
7The References section has no link link to RFC2798, that is still the source of several attributes.
http://tools.ietf.org/html/rfc2798		Thomas LenggenhagerWill fix all references to the correct location for referencing RFCs.
8In 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 LenggenhagerSince 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).
9I 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 SchoberBecause 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.
10I'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 VaghettiProtocol-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).

It would have the advantage though of potentially auto-pointing to a final Standard version if we get it to that point, as that's probably the most likely "new" version to appear at that URL.

Scott CantorDuplicate; 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."

Is the third sentence saying the ePPN is only an identifier & shouldn't be displayed alongside presentation-oriented data in case it gets mistaken for an email address?


Info

"It's saying that if an application already has the ability to leverage attributes designed to be displayed or used for human-facing purposes like email or search, you shouldn't display EPPN when it's never explicitly been meant for that purpose.

"But I suppose such an application has no reason to be using EPPN in the first place, other than history, and that sentence may be more confusing than helpful.

"I haven't done any formal review yet, but I think that's probably one worth making in the wiki. I'd probably strike it." – Scott Cantor


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."