...
- 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.
2016-02-26
- Resource owners and those acting on their behalf: what language do we need to support the distinction? Any additional use cases? Any additional insight on technical design patterns?
- We said we'd try to conclude this decision-making process by this week, and then move on to the decisions about RS actions in contradiction.
Attending: Eve, Adrian, Ann, Andrew, Mark, Sal, Kathleen, John
Kathleen had summarized it in our WG call yesterday that this is an "owner" and an "on behalf of" problem. Adrian asks: Is it clear that there need to be separate credentials for these two roles (something like subject and custodian)? Kathleen's work at HL7 includes three roles: the subject of consent directive (of governed information), the grantor (the consentor who grants access), and the grantee (the one to whom access is delegated). Eve is familiar with a project where UMA is being contemplated where subject and delegate are the terms used, where she suspects (subject+grantor) and grantee map perfectly onto Kathleen's terms, and she knows they map exactly onto UMA's RO and RqP terms.
Let's put the "third term" aside since it seems there's no controversy about the mappings (for the moment), and concentrate on the "split RO" nature of the use cases in front of us.
Do we have to distinguish "who logs in to the AS" vs. "who logs in to the RS only"? Adrian asks: In our use cases from last week, are there separate credentials? We need to know the exact UMA design pattern we're looking at to know the answer, because otherwise the specific identity ecosystem in place is unknown. Andrew suggests: Is the question really about whether the RSO cares who the ASO is? Let's say a hospital IT department is the RSO and the healthcare insurer (Eve adds: or EHR SaaS vendor or government agency or whatever...) is the ASO.
Going back to the key issue: Adrian presumes that the AS presents a certificate and the RS gets to look at that certificate and see if it trusts it. But Eve points out this is off-track for the subject of this call. Any AS cert is for the whole AS. Let's return to (subject+grantor).
Regarding the terms coming from HL7, FHIR is taking this nomenclature work even farther. Eve wonders: Could subject and grantor suffice as terms for us, even if the subject isn't even literally the data/PII subject? Like, e.g., what if the "subject" created the digital artwork that is being sold and the grantor is managing access to the painting on behalf of the subject because they're no longer legally competent to be party to contracts? In health, a donor or cadaver might not be donating data, but body parts! (?)
The current theory/hope is that Subject could be a good new term for the "true resource owner" who might not be legally competent or might not be in a position to manage resource access at the AS. (Note that "control" is the verb we use on the UMA marvelous spiral architecture diagram to denote what the RO does at the AS.) If we need to get more specific in any of our model clauses regarding resources that truly contain PII, perhaps we need to clarify in the definition that UMA allows for resources not to contain PII, and then define a more specific term, Data Subject or PII Subject or Resource Subject (as discussed in notes below), specifically for resources that do contain it. (Do we also have to define the term Resource and/or Protected Resource in our model definitions?)
More current theory/hope: Grantor could be a good new term for the "guardian" of a legally incompetent Subject, or designated "proxy"/"agent" for a legally competent Subject, who exclusively manages resource access at the AS on their behalf. [Added after the call:] Eve's theory about the UMA design pattern in this case is this: The Grantor is the only one that interacts with the AS (e.g., logs in there, creates policies, etc.) If the Subject is capable of managing resources in an online fashion ("manage" is the verb we use on the UMA marvelous spiral architecture diagram to denote what the RO does at the RS, but also the verb we use to denote what the RqP does at the client), then in fact what could happen is that the Grantor sets up policies for the Subject to become an RqP to their own resources, accessing them through RS-that-is-also-a-C, and requiring that the Subject use the same AS as the Grantor to enable full Grantor oversight capabilities. (This is a known limitation due to #wideeco realities.)
More current theory/hope: We could replace Authorizing Party with Subject and Grantor.
More current theory/hope: Grantee could be a good new term for Requesting Party.
AI: Kathleen: Share HL7-based definitions of subject and grantor (and grantee) with UMA WG so we can try out definitions for our own purposes. (ISO standard basis for the definition – what is the ISO number? -- can't be shared because they're not free standards.)
AI: Adrian: Work with Kathleen to capture the "joint control" of painting resource example and share with the list.
AI: Eve: Add GitHub issues for the new model definition ideas.
...