...
- Fridays, 8-9am PT
- Screenshare and audio: http://join.me/findthomas
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2017-09-08
Attending: Eve, Tim
We agreed that deliverable #3 is complete.
AI: Eve: Let Colin know about deliverable #3.
The Uniform Fiduciary Access to Digital Assets Act is already in effect in most US states and will require other states to take action quick. The Act calls for the use of an "online tool" – "an electronic service provided by a custodian that allows the user, in an agreement distinct from the terms-of-service agreement between the custodian and user, to provide directions for disclosure or nondisclosure of digital assets to a third person". That sounds exactly like an authorization server! Our legal framework and tools can help with providing that. The Uniform Law Commission has commissioners from every state. It seems they promoted the law pretty well, given the thorough coverage. There's' also the increasingly pressing requirements for PSD2 (January 2018) and GDPR (May 2018). There's also the DIACC Trust Framework effort.
Kantara can take directed funding for efforts to build specific tools, for example contract clauses (tools) for specific purposes. Would that make sense in the case of "directed" sets of contract language for jurisdiction-specific bodies of law covering specific use cases?
Is it time to go to the BL-FIDM list to get attention and review, and see if we can find "customers" for fleshing out the full framework and our first tools in Q4 2017? We think so.
AI: Tim: Draft message to BL-FIDM. Some goals: Ask for review of existing deliverables (some subset?) and slide artifacts (some subset?) to be determined, ask for use cases (and directed funding if needed to hire any further expertise?) for specific tool development, and ask really interested parties to join WG to develop tools actively in Q4 2017 and beyond.
AI: Eve: Cancel next week's Legal call.
AI: Eve: Revitalize our external reviewer list and think about who else to add from IAPP.
2017-08-18
Attending: Eve, Tim, Kathleen, Sal, Colin
...
- From resource server to resource server operator to resource controller to data controller????
...
2017-03-13
- Reviewing use cases doc
...
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
- Eve will try to press ahead with lots of editing AIs prior to the call
- Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review
Attending: Eve, Kathleen, Ann, John W, Mary, Jim
We did a ton of work in the document.
If you haven't seen it, the latest version of the slides with the "legal use cases" is here. Please feel free to share it.
See also Jim's CommonAccord capture of the GDPR.
2016-08-19
- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts
- We can make progress with the current scenario
Attending: Eve, Kathleen, Mary, Jeffrey, Jim, John W, Ann, Mark, Colin L.
NOTE: No meeting next week!
The "UMA technical" agenda is pressing ahead. Eve summarized our UMA legal status for the LC as "fits and starts but progressing" recently. The idea of changing or providing multiple scenarios is fine; doing that after we press ahead on the doc seems like it won't block our mapping work.
Jeffrey's Information Governance fact pattern includes Home Trunk Industries, which decided to be an aggregator. The challenge in applying this directly to the UMA scenario is that an aggregator usually gets full control of all that data. Are some "orchestrator" companies (service operators) able to use new consent strategies that defer to Alice the ability to control her data and even access to her physical stuff? Eve just had a Twitter conversation about car/plane co-leasing with maintenance taken care of through UMA, and we discussed drone and lawnmower control through smart contracts. John puts it this way: HTI would own the data (it's fungible), but Alice would own the information (it represents her).
We made lots of edits to the Introduction and nearly finished it.
...
- External review and reviewers of our work at the Q1 mark
- Action items for the model definition editors regarding last week's consensus definitions
- In-scope and out-of-scope trust relationships and their names (see this thread and below)
- Disentangling meanings of "delegation" – do we need a group norm about terminology?
- How do we square the "Requesting Party"/Grantee/Potential Grantee circle?
Attending: Eve, Kathleen, John W, Sal, Ann (regrets from Adrian, Mark)
AI: Eve, Jim: Revise our CmA model definitions with new consensus definitions.
Eve's premise was that anything with an UMA technical artifact really has to be in scope, and a direct relationship with any service operator with an UMA-specific purpose for existing (namely the AS operator) seems plausible to be in scope.
Would it be useful to write an explanatory document for reviewers about these relationships?
Should we be naming the agreements at all? There will be multiple actual agreements, for example, at different phases, or for whatever reason. And (channeling Jim) there are literally different agreement/contract workflow phases such as offer, acceptance, etc., and different sides of the equation might be offering or whatever. And given that English is only our first target language and not our only one, perhaps it should be a principle of ours that we should name as few things as we can get away with, so as not to have "language skew". Since our ultimate deliverables are at the size of "clauses", we need not care (for purposes of discussing trust relationships) about the larger combinatorial things into which they're mixed. Jim has put together quite a few assembled agreements, contracts, offers, etc., and we might do the same with our clauses as exemplars, but in the main we expect they'll be non-normative. So we've saved the candidate names, but kept them non-normative.
We have established to our satisfaction that there is complete separation between the legal and technical work of UMA by demonstrating that a technically conforming deployment of UMA services could be out of compliance with the data protection laws of some jurisdiction. Our "Russian example" is apt here: A Russian Grantor cannot legally allow a non-Russian "Requesting Party" access to their own data.
The clauses need to set up the correct preconditions for a deployment of UMA that encourages a "race to the top" in a greater alignment of incentives among the parties and in behavior that is compliant to relevant nonfunctional requirements (such as regulations).
John notes: "Makes me think that we need something like: Authorizing Server Operator - Regulating Body: Allowed-To-Release"
| Trust relationship | Dependencies on existing nonfunctional requirements | In scope for model text work? | (Candidate names of agreements formed out of our official clauses) | Technical artifact | Dependencies on existing technical artifacts | Discussion |
|---|---|---|---|---|---|---|
| Resource Subject - Grantor (if they are different) | n/a | No | n/a | n/a | n/a |
| RSO - ASO | n/a | Yes | Protection API client agreement | OAuth client credentials for RS | n/a |
| Grantor - ASO | n/a | Yes | Authorization services agreement | n/a | n/a | This has no technical artifact in UMA, and therefore no exact or obvious moment of appearing "on stage" for our work. Does this have an impact on whether it is in scope based on the rationale above? We agreed there are definitely reasons to have UMA-specific clauses, looking at our draft ones. |
| Grantor - RSO | RSO - ASO | Yes | Resource protection agreement | PAT | OAuth client credentials for RS | It's awkward to have a two-party agreement resting on a PAT. There are plenty of agreements where there are multiple Persons in one of the roles, but we're not so sure about true three-role agreements. |
| Client Operator - ASO | n/a | Yes | Authorization API client agreement | OAuth client credentials for Client | n/a | We have not scrutinized the definition of Client Operator. Let's put a pin in that to be sure it's okay. |
| "RqP" - Client Operator | n/a | No | n/a | n/a | n/a | We need to work on the term for "RqP". Let's put a pin in that. |
| "RqP" - ASO | Client Operator - ASO | Yes | Resource authorization agreement | AAT | OAuth client credentials for Client | The same discussion about n-party agreements above applies here. |
| Grantor - "RqP" | Resource Subject - Grantor, RSO - ASO, Grantor - ASO, Grantor - RSO, Client Operator - ASO, "RqP" - Client Operator, "RqP" - ASO, Grantor - "RqP" | Yes? | Resource sharing agreement Resource access agreement | Trust elevation mechanism and specifically claims subprotocol | OAuth client credentials for RS, PAT, OAuth client credentials for Client, AAT | Could be in the form of a consent receipt, sent to a notification endpoint. Is this trust relationship too "dependent" to be in scope, or does the calculus work? More discussion is needed. |
2016-03-11
- Do these terms work for us as model definitions?
- Resource Subject: Person to whom a digital data resource relates
- Grantor: Person who manages access to a resource, either as its Resource Subject or that Person's behalf
- Grantee: Person seeking access to a resource
- How to address the subject/grantor split in the tough use cases
- Tackling model clauses for RO/RSO
- Does the brute force method help?
- How can we address #RSctrl and #ROctrl needs – can we actually enumerate the exceptions?
Attending: Eve, Kathleen, Scott, Adrian, John W, Jim, Mary, Andrew, Thomas, Mark, Maciej
(As an aside, the fact that we're using Thomas's paid join.me account and had trouble reusing it because multiple people on the call have the app is an interesting "property rights" use case that is relevant to our problem! There's the potential for misuse of the paid account and the company often stomps on simultaneous use.)
Under consideration:
Resource Subject: The Person to whom a digital data resource relates
Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf
Grantee: The Person seeking access to a resource
Is Grantee too "final" (vs. Requesting Party) given that they haven't yet been given access/had trust elevated? Maybe we need to split the RqP language similarly into two, to capture the states of "authorization not granted" and "authorization granted". To take an extreme example, there could be a policy condition that Bob the RqP gets access to some resource only on even-number hours of the clock. In this case, the AS can manage the token time-to-live characteristics very dynamically, the RS can check all the token authorization data frequently, etc. – but Bob will go from being a "potential Grantee" to being an "actual Grantee" really frequently. So the former phase or state is the more persistent, and the latter is the more transient. Trust elevation and degradation in Bob can be quite dynamic. (Also note that the same is true for the client app Bob uses.)
Note that any trust relationship between the (requesting party bundle of concepts) and the Resource Server Operator is entirely invisible to UMA. According to our scoping of our work, it should likely be invisible to us too. ??
But the (requesting party bundle of concepts) and the Authorization Server Operator does have a trust relationship once the authorization API token is issued, so we need to take care of that set of obligations.
- RSO - ASO (client ID)
- RO (Subj/Grantor?) - RSO - ASO (PAT)
- C - ASO (client ID)
- RqP (trust elev/degr?: Grantee) - C - ASO (AAT)
- RqP (trust elev/degr?: Grantee) - RSO = no UMA relationship ???
The "Adrian clause" in the UMA Core spec is intended to reassure RSO's that they are free to elevate trust in the "requesting side" (that is, both the RqP and C) themselves. Note that the phrasing in the spec only allows further tightening; a clause a bit lower down makes clear that the intention is not for the RSO to enable loosening of access, although it's impossible in technical terms to prevent this. This is why we are working on how far we can take our model clauses to give RSOs the appropriate (and not inappropriate) flexibility to manage liability.
Eve suggests a group norm: Let's talk about "notice" and "consent" as consent life cycle words, and "notification" as what happens apart from that life cycle, so heads don't explode.
We agree on these model definitions for now:
Resource Subject: The Person to whom a digital data resource relates
Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf
We have discovered an important "phase split" in considering "Grantee", and can't really use it outright as a wholesale replacement for Requesting Party.
For the world of devices, client apps, and so on, should we introduce "Agent"/"Entity"/something? Eve is wary of Agent from our legal discussions, but Kathleen could submit ideas to the list.
Eve reviewed her "brute force version" of the "RO-RSO" trust relationship. Note that the last bullet is the only one that represents a break-glass scenario; the party seeking access never established a trust relationship with the ASO, never got into the position of being a RqP/Grantee/etc., and is unknown (at least as far as UMA is concerned) to the RO.
Adrian has introduced the term "resource registration agreement". Is this a good name for the overall agreement representing this trust relationship? ("Resource protection agreement"?) How do we square the circle of having two "three-party" trust relationships? How should we name each of the trust relationships? Let's try and bat this around on the list before the next meeting.
...