Page Comparison

• Review IIW and EIC discussions – progress around RSO-ASO as an "agent"
• Upcoming Digital Contracts conference with opportunity to gather requirements for CommonAccord IDE and feedback on our work
• Reality check on model clause process – definitions seem a lot easier, vs. clauses without a "live" agreement to work towards
• Discuss: What about the Grantor keeping policies secret?

Attending: Eve, Adrian, John W, Ann, Mark, Kathleen, Jim, Colin

At IIW, we reviewed the model definition work to date, and discussed the use cases for splitting the Grantor and Resource Subject. We discussed how the ASO is an "agent" of the RO/Grantor/Resource/Subject. In the "J-LINC - Signed Contracts on a Blockchain" session, we discussed the three different kinds of delegation. See yesterday's WG notes for more on this: we said there are different kinds of delegation:

• RO-to-RqP (delegating access to resources – the problem that the UMA protocol "solves")
• RO-to-AS (the architecture that the UMA protocol invented to solve the problem, which makes the ASO an "agent" for executing Alice's wishes)
• Resource Subject-to-Grantor (offline wrt the protocol, but an important business/legal relationship where the Grantor assists the Resource Subject in controlling access by RqPs)
• Authority-Override (offline wrt the protocol, but reflects jurisdictional overrides to ASO or RSO or CO actions and conditions in the business/legal space)

In the regulations generally, there's a notion of a data subject, a data controller, and a data processor. But there's not a notion of another player: a service, which UMA calls an Authorization Server – and an operator of that service, an Authorization Service Operator -- that executes the wishes of the data subject. And at the legal level, UMA has observed that there may also be a Grantor who assists a Resource Subject in controlling access.

When we say "offline wrt the protocol", it's offline wrt UMA itself, but there's the possibility of a notification pattern that could be implemented in a technical solution. Right now that's not quite on the table for UMA, though the CISWG is discussing this somewhat. There are six ways in GDPR that an entity could collect personal information, and only one is through consent. Proof of consent is required, though not to be presented to the individual – rather by the org to authorities. Other open principles, however, do require presenting such proof to the individual. Canada in some cases does require proof to be presented to the individual depending on information sensitivity.

Let's stick strictly to a RACI model (responsible - accountable - consulted - informed). Is it possible to assign static RACI roles to ASO, RsS, and G, or not? If "little 1yo Johnny" is a RsS but not a G, he can't be responsible, only informed, right? Every consent has to be scoped appropriately, and it has to be dynamic.

The RSO is most clearly a data controller. The biggest conundrum wrt regulations such as the GDPR is that the ASO isn't a "data anything". It holds policies, which are metadata, which don't necessary have to travel anywhere, and – in UMA flows, anyway – don't travel. Kathleen has brought up previously how you can have "federated" flows behind the UMA scenes where policies can be sourced from multiple places to make an authorization decision at the UMA AS, and technically, the UMA AS could have gotten the token that it handed to the RS from another place entirely. In other words, the job that the AS does could be entirely virtual. In the main, we might guess that an AS is "monolithic", but what if the job that an AS does is through an API facade, and is really done by a bunch of microservices run by lots of different companies on the back end?

Netting this out: UMA uses the OAuth architecture, which only puts calculated entitlements on the wire, not policies, which seems to be a privacy benefit (vs. an XACML-type architecture, which designed a way for policies to go onto the wire, and also requires the "RS" – the PEP – to ask the "AS" – the PDP – for the policy decision, vs. making the "client" – the application ask for it).

So where we are is that the AS has a strength in not being a DS/DC/DP. It is a helper service; an enabler of the Grantor; a technical device for connecting services and data stores; a data sharing and control mechanism available to the data subject. It's a tool to enable Alice to control who has access to her data. The AS is the linchpin of the UMA protocol; the service at the center of the marvelous spiral.

How can we make progress on real live model clauses for real live agreements? Eve might have someone interested in a "legal POC". Let's ask people next week at the Digital Contracts event too. Mark has someone in mind too. Adrian suggests that a MITREid Connect/HIPAA context project could be a good case. Have contacts reach out and we can discuss starting "legal POCs"!