On 9 Jul 2015, at 10:05 AM, Eve Maler <eve@xmlgrrl.com> wrote:http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-07-09_______________________________________________Minutes
Roll call
Quorum was reached.
Minutes approval
MOTION: Robert moves and Sal seconds: Approve the minutes of UMA telecon 2015-06-25 and read into today's minutes the notes of UMA telecon 2015-07-01. APPROVED by unanimous consent.
Call logistics
Let's stick with our Skype-providing option and Eve will try and remember (everyone please help her) to put something in the join.me chat at the beginning of every call to remind join.me joiners to use the alternate dial-in, not the join.me dial. DONE!
Obligations
UMA trust, obligations, commitments, transactions, receipts, contracts, licenses...
- Most important use cases
- Prepare thoughts and questions for the meeting with Prof. Singh et al. the following day
The question arose: How to bind UMA to existing legal structures. "Licensing" is the dominant approach used by lawyers. Does it work in UMA? Prof. Singh introduced some alternate terminology. DRM approaches are another approach.
authorization (could be can or can't?)
commitment (UMA obligation)
prohibition
sanction (like a fine)
power
Eve propose that a "license" model within UMA could look like this:
- (With some preconditions having been satisfied, such as client credentials being issued, etc.)
- RO authorizes RqP to access Resource Set(s) to use Scope(s) by adding authorization data to RqP’s Client’s RPT
- RqP exercises license by having Client access Resource Set(s) using Scope(s)
- RO is able to withdraw the license by revoking the authorization
A challenge with the license model is active revocation. If it appears to be a license for five days, but then the RO revokes the license after two days, what happens? There are technical implications around caching vs. token introspection, checking of expiration periods, and so on (time-to-live management), and also business implications of RqP and client expectations. It could be the case that an access federation trust framework specifies both levels of expectations. If the RO suspects malfeasance, maybe all bets are off and then can revoke immediately.
Tim has sent a document called "The New Ontologies - The Effect of Copyright Protection on Public Scientific Data Sharing Using Semantic Web Ontologies" to the list. The attraction here was the notion of machine-readable license language.
By contrast, if Alice presents Bob with terms he has to agree to, she could point him to machine-readable terms (which could be the ontology content above), and a "contract" model could look like this:
- AS, on behalf of RO, offers RqP valuable (this is important) access under terms expressed by policy (the terms are going to result in, e.g., authentication, claims, and any other trust elevation parameters able to be supplied by the RqP)
- RqP accepts RO’s terms by conveying trust elevation parameters that meet policy — environmental, contextual, and heuristic factors are insufficient to indicate acceptance, while AAT acceptance may be a good indicator of pre-willingness to accept terms later on even when supplying claims implicitly through a client that pushes them silently
- AS, on behalf of RO, provides consideration by adding authorization data to RqP’s Client’s RPT
If you standardize the claims, e.g. for the HIPAA-type "purpose of use", and especially if you standards resource types, the terms would be pretty clear in this case. But it's definitely a more complicated model.
If you throw events that are machine-readable during the course of the protocol running, that starts to look like "consent receipts" or similar.
Who's interested to meet with the researchers tomorrow? Eve will add Robert to the invite.
AI status
- AI: Thomas: Review the charter for potential revisions in this annual cycle.
- AI: Eve: Review Marcelo Wikipedia comments and take next actions.
- AI: Tim: Expound on the licensing idea in email.
- AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. Let's discuss this at the next LC call.
- AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
- AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. PROGRESSING. There are multiple steps. He has gone through the process with OAuth and OIDC already.
- AI: Mike: Rework UIG section on organizations as ROs and RqPs.
- AI: Eve: Update GitHub.
- AI: Maciej: Write as many sections for the UIG as he can.
- AI: Justin: Write a UIG section on default-deny and race conditions.
Attendees
As of 1 Jul 2015 (pre-meeting), quorum is 7 of 13. (François, Domenico, Sal, Mark, Thomas, Andi, Ishan, Robert, Maciej, Eve, Arlene, Mike, Jin)
- Eve
- Arlene
- Robert
- Mike
- Sal
- George
- Jin
Non-voting participants:
- Adrian
- Sarah
- Scott Fehrman – ForgeRock – pre-sales, former Oracle, former Sun – in identity for 10-12 years
- Abhi
Regrets:
- Maciej
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma