Attending
Notes
Recap from prior calls
What we’re looking for here is not an entitlement. It is not something that should be used for authorization purposes.
The primary use case that kicked this off: in the publisher use case, when a user comes to access content, they will verify that the user authenticate and that they have an entitlement to the data. That happens in real-time. Separate to that, there is a different set of people (e.g., the people who have purchased the access to the report) and they want to understand the use of that resource and classify that into buckets. That report is offered outside the authentication/authorization transaction and at a later date.
We are trying to define an opaque bucket for data to go into with a name that is interoperable. It is not appropriate, therefore, to get into defining the structure of the data for IdPs to implement. Implementation details will be abstracted out from the code.
Discussion
- eduPersonAnalytics draft
- Feedback received on list from Peter Schober expressing concerns about the delimiter and the abstraction of LDAP requirements out of the spec
Delimiter: changed to a pipe instead of a slash
Case sensitivity: noted that if the values are treated as case sensitive, that won’t hurt anything, but we should not that the reporting cannot count on that; the service should do whatever is most convenience.
Additional characters: Minimalistic is preferred to avoid encoding problems, and since it doesn’t matter what the values are, implementers should be able to work with this. Did go ahead and added underscore as an accepted value
Next steps
Request additional feedback from the mailing list; due by 11 September
Ask Schema Board to consider and determine if this is ready for formal consultation