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:
https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J...
with more text here:
https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap...
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
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
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
wrote: They can be found here:
https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note...
*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