I have three real-world use-cases and suggest we align with the W3C Verifiable Credentials (VC )model for the "contract" aspects. In this context, the VC pertains to a Subject, is issued (signed) by the Issuer, held and presented by the Subject, and relied-on by the Verifier. The nice thing about the VC model is that years of work have gone into making the "contract" clear and interoperable. Both JWT and JSON-LD are supported. There are no smart contracts involved.

The three use-cases I'm involved in are out there for open discussion which means the business and legal issues are pretty clear. I suggest we begin UMA business activity on real-world examples with named actors rather than trying to boil the ocean of hypothetical legal and business situations. They are:

A - Medicare wants to add Dynamic Client Registration to their production OAuth API.
B - ONC wants (in the 21st C Cures regulations) to enable Alice-to-Bob API access and to solve the multiple portals problem for Alice
C - Microsoft Azure wants to introduce personal "Identity Hubs" that would outsource personal data storage and access permissions management relative to a typical service provider. This is happening via the Decentralized Identity Foundation (DIF).

All three of these use-cases could be Alice-to-Alice or Alice-to-Bob. The more general case is obviously Alice-to-Bob. 

A signed contract that binds the Resource Server to the Authorization Server could be a VC with the AS as Issuer, Alice as Subject, and the RS as Verifier. 

Another signed contract binds Bob's Client to Alice's AS and the RS could also be a VC. In this case, Bob is the Issuer, the Client is the Subject, and the AS and RS are Verifiers. The law (HIPAA) may actually require two VC with the Client as Subject. The first one is issued by Bob, who takes responsibility for the policies of their Client. The second VC is issued by Alice (via her AS) and takes responsibility for Bob and his Client.

In all three use-cases, the business case is simple: As long as the RS trusts either Alice or Alice's AS then the RS has a safe harbor from data breaches.

Adrian





On Tue, May 7, 2019 at 3:19 PM Eve Maler <eve@xmlgrrl.com> wrote:
Just a note about smart contracts: In the past, we've discussed this, and felt that this is a leap that a lot of people won't be willing to make, since it implies a pretty huge and consequential (blockchain-based) technology stack that most aren't using (yet?). Pointing to a legal device from a technology artifact (or doing the reverse) in order to cement the linkage is fair game, though, as in the "Ricardian contract" sense Jim Hazard has introduced.

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl



On Tue, May 7, 2019 at 12:45 PM Andrew Hughes <andrewhughes3000@gmail.com> wrote:
The conceptual model that we have introduced in the Consent & Information Sharing WG is a simplistic version of concepts of contract/agreement law.

a) A 'vendor' makes a 'service' available
b) A 'person' discovers the 'service' and wishes to try it
c) The 'vendor' offers terms which describes the exchange of 'valuable consideration' i.e. services for money; product for goodwill; whatever for whatever...
d) The 'person' reviews and accepts or rejects the terms
e) Both parties have a 'meeting of the minds' and form an intent to make an agreement, then enter into that agreement 
f) Record keeping happens
g) The 'valuable consideration' is exchanged
h) The agreement ends at some future time for one of many possible reasons (completion of service or time are very common)

Clearly the exact sequence is case-specific. Also, there are many variations around offer-negotiate-accept terms - for user-centric and VRM-type flows, the first offer might be from the person rather than from the vendor. And so on.
The Personal Data Receipt (a.k.a. "Consent Receipt") arises at f). 'Vendors' keep records of agreements and interactions for operational and potentially regulatory reasons. Individuals are never offered a 'receipt' unless the interaction is a sales transaction (and even then, not always). The Personal Data Receipt is intended to be the person-side record that, once enough are accumulated in the person's vault/wallet, can be analyzed in the same way that Quicken or Mint analyses and manages financial statements and receipts.

An imperfect flow diagram of the above is here: 
with more text here:

On first glance, the "machine readable licence" shows up in c), d) and f). The specific form of the license is secondary to my mind - as long as it identifies the parties, describes the terms, describes the restrictions, and is tamper-evident - there are a few other properties...

So the 'consent receipt' is definitely not the same thing as the 'machine readable license' - but they probably occupy the same place in the 'agreement flow concept'.

CIS WG is creating v2 of the receipt spec - and it will be a generalized data receipt. It should be possible to create some kind of profile of the eventual v2 that accommodates the UMA license use case (or not - we can discuss)

andrew.

Andrew Hughes CISM CISSP 
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road, Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com 
https://www.linkedin.com/in/andrew-hughes-682058a
Digital Identity | International Standards | Information Security 



On Tue, May 7, 2019 at 10:22 AM Tim Reiniger <tsreiniger@gmail.com> wrote:
Looks like we need to solidify/formalize the “machine readable license” concept. Perhaps the easiest approach is to treat it as one type/application of a “smart contract” unless anyone has an objection.

Tim

Sent from my iPhone

On May 7, 2019, at 11:03 AM, Eve Maler <eve@xmlgrrl.com> wrote:

They can be found here:

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2019-05-07

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma


--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.