Heather, David, Chris, Meshna, Michael, Peter, Benn
Jiri, Ralph
1 - Administrivia
Officially official - Schema Board subcommittee - making this an official subcommittee is currently in an e-vote with the Schema Board. Having it as an official subcommittee will make actual adoption (if that’s what we decide to do) easier in terms of process
FIM4R and FIM4L have been told about this.
FIM4L - how is this different than COUNTER?
FIM4R - no obvious use cases reported
2 - Review of use case and draft
https://docs.google.com/document/d/1HGmz39bVMOq5VU74bhCd1Uu0nV_Tq9JaPBU98Zm-Fe0/edit#heading=h.j6288fhwkrg0
The idea of having a whole new attribute instead of eduPersonEntitlement results from the fact it has an entirely different semantic purpose. Still a question as to whether this should be held under eduPersonEntitlement, which was not originally restricted to authorization (as its commonly understood today)
Clarifying a use case: 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 .
eduPersonEntitlement states that it "indicates a set of rights to specific resources.” The idea we’re discussing has nothing at all to do with such rights.
As long as it is generic, that it isn’t a reporting code, and if an SP uses it for reporting, then that’s there is support for going forward with this new thing. We should not define something that is only for this use case.
We need to take into account that there may be other use cases, so that we don’t have to do this again for other use cases
Is this actually a generalizable use case at all?
Another possibility is to report back on HPC usage. If the SP is enforcing a restriction, then that is an entitlement. But if it’s just related to reporting, then this idea could fulfill that use case.
In other reporting schemas, this would be called a segment ID
Or, “values in this attribute could be segment IDs"
This is not necessarily a purely bilateral piece of information.
Does the entityID need to be in the value, or should that be handled externally. The eduPerson schema is implemented in LDAP directories; what do the LDAP implementations need to look like? If you have it as part of the data in LDAP, then the IdP will a simpler operation in deciding what value goes to which SP. eduPerson is both a storage and a transport, so it is very difficult to split the two. There is no value in sending the SP string to the SP as part of the transport, but there is value to the IdP to have that in the storage.
3 - AOB
Next call:
Discuss the semantics of what should be stored on the IdP and what should be sent to the SP
Consider if there are any other use cases where this code might be used
Figure out a better name