Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added notes from committee review call


comment #Line/Reference #Proposed Change or QueryProposer / AffiliationAction / Decision (please leave blank)
1n/aI don’t like the attribute name - eduPersonAnalyticsID - its the ID part that worries me, its not an ‘Identity’ per se. I can foresee confusion and people sending almost or real PII in that ID value…. eduPersonAnalyticsTag or eduPersonAnalyticsValue ?Alan BuxeyThe committee agrees to changing this to eduPersonAnalyticsTag
2"represents the use of a service by a subject"The spec seems to allow for use as a targeted, privacy preserving identifier.  I don't have a strong opinion regarding the name, but as worded I think this attribute could be used to represent an identity.  If this is not the intent then use of the term 'subject' may need to be clarified.Mark Jones / UTHealthLanguage change: "aggregates the use of a service by a set of subjects"

From the definition I get the impression the identifier intents to identify a service from the perspective of the Institution.

Perhaps the name of the attribute should reflect that.

My initial association with Analytics is "learning analytics"

Niels van DijkWe believe this is addressed by the renaming of the attribute to eduPersonAnalytics Tag
424Might be worth clarifying whether it is expected that multiple subjects could have the same value, or giving an example. This paragraph is a little tricky to parse and fully understandHannah ShortWe will add a sentence to this effect; that combined with the language change described in comment 2 we believe addresses this issue.

This format would not allow URI's to be used as value, as neither semi-column colon not back-slash are allowed.

I think however the URL of the service, or a SAML entityID would actually make very good potential values?

Niels van DijkSAML entityID is not terribly useful to be reported in usage reporting systems as mostly all users from one institution will have the same. Also because this is for analytics purposes, I think values in the form of URIs may be more confusing than not. We will extend the example to offer some clarity on what to do when there are two values.
635For the purposes of the spec it would be better to be specific; either the values are case-sensitive, or they are not.Meshna KorenAgree; will make a change to be clear. We do not want people using values that differ by case.
741It should be possible for the home organization to correlate usage of various services. It will make analytics simpler if they don't have to decipher the meaning of different values.Meshna KorenThese aren't personal identifiers, so correlation between IdPs by the SPs isn't relevant. If an IdP does want to make sure this isn't possible, the IdP needs to be the ones that use different values for each SP. Will clarify the text.
8"It is RECOMMENDED, if stored in an LDAP or X.500 directory, ..."After reading "use of a service by a subject" at the beginning of the spec i was thinking about ePTID, and this paragraph suggests to me that the value would represent a unique subject and the service a unique SP. If that is not the intent then some clarification may be needed.Mark JonesWe will remove this text.
9"It is RECOMMENDED, if stored in an LDAP or X.500 directory, ..."

There are at least 100 potential ways this data could be stored.

Why a specific recommendation of 1 of these?

Niels van DijkWe will remove this text.
10"separated by a pipe (ASCII 124)"I believe this is generally called "vertical bar" outside of *nix shells.David WalkerOvertaken by events of removing the LDAP text.
11"FOOBAR_ZORKMID"Opaque?Niels van Dijkit is opaque in that it does not identify the individual. There is no reason it can't be human-readable.
12|Would recommending "|" create a limitation in the use of LDAP products (i.e. as it i used as internal seperator?)Niels van DijkOvertaken by events of removing the LDAP text.