...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-04-28
- Reviewing draft deliverable #3
- "Resource Regulator" role
Attending: Eve, John, Adrian, Kathleen, Tim, Mark, Bjorn
Review of Move Fast and Break Things, recommended by John. (We were talking about turpentine and the importance of something stinging in order to tell that it's working – also "if it hurt, do it more often" from Agile.)
Resource Regulator role:
How would we include Resource Regulator in any charts, if we did? A regulator constrains, by law, what some of the other parties do, in a context of enabling others. In other words, it sets rights and responsibilities. And we can't change these. These are jurisdictional. So a regulator is a sort of "god". It's out of band of the UMA protocol and Eve suggests it's also "out of band" of UMA legal because we can't affect regulatory/public law on any reasonable time scale.
Here's what we're doing in this subgroup:
- Building a legal framework...
- So that we can next build "toolkits" that are friction-reducing building blocks for various contractual mechanisms ("private law")...
- So that third parties can deploy UMA-enabled service systems in a manner consistent with protecting privacy rights using those contractual mechanisms that adhere to the laws and regulations ("public law") of their jurisdictions
Kathleen points out that in the case of HIEs, e.g. in Michigan, there's a kind of blending of private and public law – there's a contract made among HIE participants that includes 42 CFR Part 2 by value. But that was their choice; by-reference would have probably been better. (Hey, CommonAccord would have helped. 
)
Eve's proposal: We can influence interpretation of regulations (especially now when a lot of GDPR etc. guidance is being written), but let's keep "regulator" lowercase since we can't influence written regulations and laws directly. Consensus not to uppercase the Resource Regulator party role.
Roles and splitting:
We have roles that mostly stick to the existing UMA technical roles, with the exception of splitting Resource Subject and Resource Owner for now. Once we have some model contracts, we can add nuance in splitting roles. Our previous "party" terms of Authorization Server Operator, Resource Server Operator, and Client Operator weren't about splitting but just about acknowledging the different between "software entity" terms and "party to a contract" terms.
Trust frameworks and access federation:
The only ones we are familiar with that exist (that could potentially accommodate UMA-style – party-to-party – user-centric authorization and "consent directives", vs. just opt-in consent) already are trust frameworks for identity federations, except for the emerging Pan-Canadian Trust Framework and the very new health trust framework efforts that Kathleen has mentioned in the BSC context. The latter work puts the data under the patient's control under the "patient's right of access". There are liability shifts which would result in the motivation becoming stronger for appealing to individuals to ask for data for secondary-use purposes.
Interesting situation: For a genome, there's more than just one data subject for the same data set!
(Should we be talking about reducing friction in "federating access" in UMA-enabled contracts and not yet talk about automation of true "access federations" a la Shibboleth-like automated onboarding of IdPs/RPs?)
Licensing as our legal model:
We need to use some well-understood legal model in our "private law" tools. Effectively there has to be some sort of cascade of rights that the RO gets. As Kathleen points out, the RS will only expose licensing rights that meet their business model. We hope that reducing friction to "doing the right thing".
Tokens:
There are three tokens that come into play:
- Requesting party token (RPT) - required
- The RqP is able to revoke this through the OAuth token revocation mechanism.
- Protection API access token - required
- The RO is able to revoke this through the OAuth token revocation mechanism.
- Persisted claims token (PCT) - optional
- The RqP is able to revoke this through the OAuth token revocation mechanism.
2017-04-21
- Reviewing draft deliverable #2
...