Attending
Notes
V/C Info
Topic: eduPerson Analytics Code (was Reporting Code)
Time: Sep 2, 2020 11:00 AM Pacific Time (US and Canada)
Join Zoom Meeting
https://us02web.zoom.us/j/88475830909?pwd=VXN0YmExejlkVWFiVldadTk2djFRUT09
Meeting ID: 884 7583 0909
Passcode: 684028
One tap mobile
+12532158782,,88475830909#,,,,,,0#,,684028# US (Tacoma)
+16699006833,,88475830909#,,,,,,0#,,684028# US (San Jose)
Dial by your location
+1 253 215 8782 US (Tacoma)
+1 669 900 6833 US (San Jose)
+1 346 248 7799 US (Houston)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
Meeting ID: 884 7583 0909
Passcode: 684028
Find your local number: https://us02web.zoom.us/u/kcNFK6IjGg
Join by Skype for Business
https://us02web.zoom.us/skype/88475830909
Agenda
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