Business model telecon notes for 2019-05-07 - WG-UMA - mailman.kantarainitiative.org

newer
Fwd: Information about...

Business model telecon notes for 2019-05-07

older
Call for agenda items for tomorrow...

Eve Maler

7 May 2019 7 May '19

4:03 p.m.

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

Attachments:

attachment.html (text/html — 840 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Tim Reiniger

7 May 7 May

5:22 p.m.

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

Reply

Sign in to reply online Use email software

Andrew Hughes

5:44 p.m.

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 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 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

Reply

Sign in to reply online Use email software

Eve Maler

7:19 p.m.

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 https://en.wikipedia.org/wiki/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 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:

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 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 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

Reply

Sign in to reply online Use email software

Adrian Gropper

9:25 p.m.

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 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 https://en.wikipedia.org/wiki/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 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:

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 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 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

_______________________________________________ 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. DONATE: https://patientprivacyrights.org/donate-3/

Reply

Sign in to reply online Use email software

Lisa LeVasseur

9 May 9 May

3:09 p.m.

I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion). On Tue, May 7, 2019 at 12:19 PM Eve Maler 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 https://en.wikipedia.org/wiki/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 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:

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 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 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

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

Reply

Sign in to reply online Use email software

Eve Maler

10:13 p.m.

Hey all, trying to follow up on/mention a few things at once, maybe that's inadvisable, but... - IANAL, of course, but keep in mind that there's a difference between a "contract" and a "license" when it comes to legal devices. Tim put a lot of thought into recommending using licenses (with a substrate of contracts) in our first report https://kantarainitiative.org/file-downloads/uma-business-model-0-7e-2018-02... because of their properties and how they apply to UMA permissioning at the actual authorization granting stage. (See the "Licenses-*" edges vs. the other edges in our relationship model https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7..., and read the report for detail.) - Language: Smart contracting protocols, smart contracting, something along those lines... That helps! (Me, anyway.) - In terms of real-life use cases to build on: I agree being concrete is helpful! The deployed and on-the-way UMA systems I'm aware of use federated identity, not VCs. I'm hoping we can finally work on a "business model POC" shortly with one of them, btw. Adrian, can you help us understand what "contract interoperability" benefits would be gained by aligning with VCs? *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, May 9, 2019 at 10:09 AM Lisa LeVasseur wrote:

I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion).

On Tue, May 7, 2019 at 12:19 PM Eve Maler 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 https://en.wikipedia.org/wiki/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 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:

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 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 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

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

Reply

Sign in to reply online Use email software

Adrian Gropper

10 May 10 May

1:41 a.m.

The terms of a contract are potentially attributes or credentials signed by a party and held by another. The verifiable credentials work has been all about making the credentials machine-readable and signed using standard methods. This seems like the essence of interoperability. VCs do not specify a particular set of attributes or require federation but support a diversity of vocabulary strategies. Adrian On Thu, May 9, 2019 at 6:14 PM Eve Maler wrote:

Hey all, trying to follow up on/mention a few things at once, maybe that's inadvisable, but...

- IANAL, of course, but keep in mind that there's a difference between a "contract" and a "license" when it comes to legal devices. Tim put a lot of thought into recommending using licenses (with a substrate of contracts) in our first report https://kantarainitiative.org/file-downloads/uma-business-model-0-7e-2018-02... because of their properties and how they apply to UMA permissioning at the actual authorization granting stage. (See the "Licenses-*" edges vs. the other edges in our relationship model https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7..., and read the report for detail.)

- Language: Smart contracting protocols, smart contracting, something along those lines... That helps! (Me, anyway.)

- In terms of real-life use cases to build on: I agree being concrete is helpful! The deployed and on-the-way UMA systems I'm aware of use federated identity, not VCs. I'm hoping we can finally work on a "business model POC" shortly with one of them, btw. Adrian, can you help us understand what "contract interoperability" benefits would be gained by aligning with VCs?

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

On Thu, May 9, 2019 at 10:09 AM Lisa LeVasseur wrote:

...
I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion).

On Tue, May 7, 2019 at 12:19 PM Eve Maler 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 https://en.wikipedia.org/wiki/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:

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 https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g 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 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 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

_______________________________________________ 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. DONATE: https://patientprivacyrights.org/donate-3/

Reply

Sign in to reply online Use email software

Lisa LeVasseur

1:46 p.m.

Adrian, What are the scopes of the "diversity of vocabulary strategies"? i.e. who determines them? They can be any agreed-upon and published vocabulary--is that correct? So there could be, for example, a published Patient Privacy Terms vocabulary? On Thu, May 9, 2019 at 6:41 PM Adrian Gropper wrote:

The terms of a contract are potentially attributes or credentials signed by a party and held by another. The verifiable credentials work has been all about making the credentials machine-readable and signed using standard methods. This seems like the essence of interoperability.

VCs do not specify a particular set of attributes or require federation but support a diversity of vocabulary strategies.

Adrian

On Thu, May 9, 2019 at 6:14 PM Eve Maler wrote:

...
Hey all, trying to follow up on/mention a few things at once, maybe that's inadvisable, but...

- IANAL, of course, but keep in mind that there's a difference between a "contract" and a "license" when it comes to legal devices. Tim put a lot of thought into recommending using licenses (with a substrate of contracts) in our first report https://kantarainitiative.org/file-downloads/uma-business-model-0-7e-2018-02... because of their properties and how they apply to UMA permissioning at the actual authorization granting stage. (See the "Licenses-*" edges vs. the other edges in our relationship model https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7..., and read the report for detail.)

- Language: Smart contracting protocols, smart contracting, something along those lines... That helps! (Me, anyway.)

- In terms of real-life use cases to build on: I agree being concrete is helpful! The deployed and on-the-way UMA systems I'm aware of use federated identity, not VCs. I'm hoping we can finally work on a "business model POC" shortly with one of them, btw. Adrian, can you help us understand what "contract interoperability" benefits would be gained by aligning with VCs?

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

On Thu, May 9, 2019 at 10:09 AM Lisa LeVasseur wrote:

...
I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion).

On Tue, May 7, 2019 at 12:19 PM Eve Maler 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 https://en.wikipedia.org/wiki/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:

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 https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g 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 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 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

_______________________________________________ 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. DONATE: https://patientprivacyrights.org/donate-3/

Reply

Sign in to reply online Use email software

Eve Maler

2 p.m.

Say, like this? :-) https://kantarainitiative.org/confluence/display/uma/Simple+Access+Authoriza... Eve Maler (sent from my iPad) | cell +1 425 345 6756

On May 10, 2019, at 8:46 AM, Lisa LeVasseur wrote:

Adrian, What are the scopes of the "diversity of vocabulary strategies"? i.e. who determines them? They can be any agreed-upon and published vocabulary--is that correct? So there could be, for example, a published Patient Privacy Terms vocabulary?

...
On Thu, May 9, 2019 at 6:41 PM Adrian Gropper wrote: The terms of a contract are potentially attributes or credentials signed by a party and held by another. The verifiable credentials work has been all about making the credentials machine-readable and signed using standard methods. This seems like the essence of interoperability.

VCs do not specify a particular set of attributes or require federation but support a diversity of vocabulary strategies.

Adrian

...
On Thu, May 9, 2019 at 6:14 PM Eve Maler wrote: Hey all, trying to follow up on/mention a few things at once, maybe that's inadvisable, but... IANAL, of course, but keep in mind that there's a difference between a "contract" and a "license" when it comes to legal devices. Tim put a lot of thought into recommending using licenses (with a substrate of contracts) in our first report because of their properties and how they apply to UMA permissioning at the actual authorization granting stage. (See the "Licenses-*" edges vs. the other edges in our relationship model, and read the report for detail.) Language: Smart contracting protocols, smart contracting, something along those lines... That helps! (Me, anyway.) In terms of real-life use cases to build on: I agree being concrete is helpful! The deployed and on-the-way UMA systems I'm aware of use federated identity, not VCs. I'm hoping we can finally work on a "business model POC" shortly with one of them, btw. Adrian, can you help us understand what "contract interoperability" benefits would be gained by aligning with VCs?

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

...
On Thu, May 9, 2019 at 10:09 AM Lisa LeVasseur wrote: I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion).

...
On Tue, May 7, 2019 at 12:19 PM Eve Maler 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 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: 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 Digital Identity | International Standards | Information Security

> On Tue, May 7, 2019 at 10:22 AM Tim Reiniger 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 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

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. DONATE: https://patientprivacyrights.org/donate-3/

Reply

Sign in to reply online Use email software

James Hazard

6:22 p.m.

I’ll leap in. As the Kantara Smart Contract Blockchain group demonstrated, an effective transaction system can (must?) be based on a few notions: A record (in JSON, XML, Cmacc, SQL, graph, whatever (the “punctuation” (@xmlgrrl)) must be unimportant). Where each record is a list of attributes (key/values) and some links to other records. With prototype inheritance, the record inherits from i) the record stating the prior state, if any; ii) other “entities” (@xmlgrrl have I finally used the right word?) such as persons, places, things; iii) a paradigm of the step in the transaction (e.g. the consent form, the privacy rules, NDA, data sharing agreement). At CommonAccord.org http://commonaccord.org/, we demonstrate how this can render into full text documents, and also how collaboration can be done in an open system of repos on GitHub. This is applicable across all of legal transacting. The “Ricardian” notion is essentially params/code/prose. The “Wise Contracts” paper goes into depth. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2925871 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2925871 Some examples - including some playing with Kantara materials at various times commonaccord.org/index.php?action=list&file=G/#Kantara-ConsentReceipt-GDPR http://commonaccord.org/index.php?action=list&file=G/#Kantara-ConsentReceipt-GDPR

On May 10, 2019, at 7:00 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

Say, like this? :-)

https://kantarainitiative.org/confluence/display/uma/Simple+Access+Authoriza... https://kantarainitiative.org/confluence/display/uma/Simple+Access+Authoriza...

Eve Maler (sent from my iPad) | cell +1 425 345 6756

On May 10, 2019, at 8:46 AM, Lisa LeVasseur mailto:lalevasseur@ieee.org> wrote:

...
Adrian, What are the scopes of the "diversity of vocabulary strategies"? i.e. who determines them? They can be any agreed-upon and published vocabulary--is that correct? So there could be, for example, a published Patient Privacy Terms vocabulary?

On Thu, May 9, 2019 at 6:41 PM Adrian Gropper mailto:agropper@healthurl.com> wrote: The terms of a contract are potentially attributes or credentials signed by a party and held by another. The verifiable credentials work has been all about making the credentials machine-readable and signed using standard methods. This seems like the essence of interoperability.

VCs do not specify a particular set of attributes or require federation but support a diversity of vocabulary strategies.

Adrian

On Thu, May 9, 2019 at 6:14 PM Eve Maler mailto:eve@xmlgrrl.com> wrote: Hey all, trying to follow up on/mention a few things at once, maybe that's inadvisable, but... IANAL, of course, but keep in mind that there's a difference between a "contract" and a "license" when it comes to legal devices. Tim put a lot of thought into recommending using licenses (with a substrate of contracts) in our first report https://kantarainitiative.org/file-downloads/uma-business-model-0-7e-2018-02... because of their properties and how they apply to UMA permissioning at the actual authorization granting stage. (See the "Licenses-*" edges vs. the other edges in our relationship model https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7..., and read the report for detail.) Language: Smart contracting protocols, smart contracting, something along those lines... That helps! (Me, anyway.) In terms of real-life use cases to build on: I agree being concrete is helpful! The deployed and on-the-way UMA systems I'm aware of use federated identity, not VCs. I'm hoping we can finally work on a "business model POC" shortly with one of them, btw. Adrian, can you help us understand what "contract interoperability" benefits would be gained by aligning with VCs?

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

On Thu, May 9, 2019 at 10:09 AM Lisa LeVasseur mailto:lalevasseur@ieee.org> wrote: I like Ricardian Contract. I wan't part of the earlier discussions, but Smart Contract feels too specific. Another option is, "smart contracting protocols" (thanks to David Reed for that suggestion).

On Tue, May 7, 2019 at 12:19 PM Eve Maler mailto: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 https://en.wikipedia.org/wiki/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 mailto: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: https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J... https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J... with more text here: https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap... 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 https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g AndrewHughes3000@gmail.com mailto: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 mailto: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 mailto:eve@xmlgrrl.com> wrote:

...
They can be found here:

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 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 mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma

WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma 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. DONATE: https://patientprivacyrights.org/donate-3/ https://patientprivacyrights.org/donate-3/_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Cigdem Sengul

8 May 8 May

12:47 p.m.

Thank you, This is very useful information. I brought up consent receipt in the call because I am wondering whether it is possible to enhance offer-negotiate-accept terms-record flow for consent receipts. Namely, I’ve been thinking about whether consent receipt can act as a seed for creating a user policy and/or machine readable license which may be used to authorise future interactions of the user with the same service (which may be used by UMA AS). Thanks, --Cigdme From: WG-UMA on behalf of Andrew Hughes Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger Cc: "wg-uma@kantarainitiative.org WG" Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07 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.commailto: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 mailto: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 mailto:eve@xmlgrrl.com> 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.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Andrew Hughes

1:27 p.m.

Hi Cigdem - it's possible, but please be cautious with extending the concept of 'receipt' I'm trying to reinforce a clear functional role for the 'receipt' concept so that everyone that encounters it can start from the same mental model. In its simplest form, the 'consent receipt' should be a direct analog to a 'sales slip' or 'sales receipt' for small purchases. For the most part, a receipt has transaction-event data (timestamp, identifiers, locations, service identifier) plus pointers to other data lookups (stock number, item name, policies, tax number) and 'terms of service' data (in the special case of data-related transactions: a Privacy Notice pointer, critical details from the Privacy Notice, the Data Processing Purpose, etc). It's the record-keeping of the event that is kept by the person, separately from the 'vendor' record-keeping. If the content of the receipt for UMA use cases includes token representations, URLs of authorization things, license representations, excellent. Like maybe some way to reference the Persisted Claims Token to bootstrap the future interactions part. During the preparation phase for the v2 receipt spec project, I'll be writing up some diagrams showing this framing of the receipt concept. We will be adding the capability of the receipt to include use case specific data - so that perhaps if there's an UMA profile of the receipt spec, it can include authorization/license specific data. We are starting the prep phase now - collecting use cases and enhancement requests - I'll coordinate with Eve to ensure that we have UMA-specific use cases and requirements to throw into the mix. 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 Wed, May 8, 2019 at 5:47 AM Cigdem Sengul wrote:

Thank you,

This is very useful information.

I brought up consent receipt in the call because I am wondering whether it is possible to enhance offer-negotiate-accept terms-record flow for consent receipts.

Namely, I’ve been thinking about whether consent receipt can act as a seed for creating a user policy and/or machine readable license which may be used to authorise future interactions of the user with the same service (which may be used by UMA AS).

Thanks,

--Cigdme

*From: *WG-UMA on behalf of Andrew Hughes *Date: *Tuesday, 7 May 2019 at 18:45 *To: *Tim Reiniger *Cc: *"wg-uma@kantarainitiative.org WG" *Subject: *Re: [WG-UMA] Business model telecon notes for 2019-05-07

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 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 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

Reply

Sign in to reply online Use email software

Cigdem Sengul

3:03 p.m.

Thanks Andrew. Yes, sure. My curiosity is that there are several “tools” out there and I am trying to see how they come together. I realize I muddied the waters by saying extend. I think it is more important to focus on how things work together (or not) rather than extending one piece or another. Definitely a lot more to think about here. Thanks again – this is really interesting discussion. --Cigdem From: Andrew Hughes Date: Wednesday, 8 May 2019 at 14:27 To: Cigdem Sengul Cc: Tim Reiniger , "wg-uma@kantarainitiative.org WG" Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07 Hi Cigdem - it's possible, but please be cautious with extending the concept of 'receipt' I'm trying to reinforce a clear functional role for the 'receipt' concept so that everyone that encounters it can start from the same mental model. In its simplest form, the 'consent receipt' should be a direct analog to a 'sales slip' or 'sales receipt' for small purchases. For the most part, a receipt has transaction-event data (timestamp, identifiers, locations, service identifier) plus pointers to other data lookups (stock number, item name, policies, tax number) and 'terms of service' data (in the special case of data-related transactions: a Privacy Notice pointer, critical details from the Privacy Notice, the Data Processing Purpose, etc). It's the record-keeping of the event that is kept by the person, separately from the 'vendor' record-keeping. If the content of the receipt for UMA use cases includes token representations, URLs of authorization things, license representations, excellent. Like maybe some way to reference the Persisted Claims Token to bootstrap the future interactions part. During the preparation phase for the v2 receipt spec project, I'll be writing up some diagrams showing this framing of the receipt concept. We will be adding the capability of the receipt to include use case specific data - so that perhaps if there's an UMA profile of the receipt spec, it can include authorization/license specific data. We are starting the prep phase now - collecting use cases and enhancement requests - I'll coordinate with Eve to ensure that we have UMA-specific use cases and requirements to throw into the mix. 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.commailto:AndrewHughes3000@gmail.com https://www.linkedin.com/in/andrew-hughes-682058a Digital Identity | International Standards | Information Security On Wed, May 8, 2019 at 5:47 AM Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote: Thank you, This is very useful information. I brought up consent receipt in the call because I am wondering whether it is possible to enhance offer-negotiate-accept terms-record flow for consent receipts. Namely, I’ve been thinking about whether consent receipt can act as a seed for creating a user policy and/or machine readable license which may be used to authorise future interactions of the user with the same service (which may be used by UMA AS). Thanks, --Cigdme From: WG-UMA mailto:wg-uma-bounces@kantarainitiative.org> on behalf of Andrew Hughes mailto:andrewhughes3000@gmail.com> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger mailto:tsreiniger@gmail.com> Cc: "wg-uma@kantarainitiative.orgmailto:wg-uma@kantarainitiative.org WG" mailto:wg-uma@kantarainitiative.org> Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07 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.commailto: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 mailto: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 mailto:eve@xmlgrrl.com> 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.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Mark ＠ OC

2:59 p.m.

HI Cigdem, This has been a topic of interest for some time now. Eve/Tim, if I recall, have you both done a lot of work in terms of consent directives? (I have been out of the loop for awhile) Would anyone happen to have a pointer to the use cases for digital death scenario's or for when a person becomes an adult and wants to take over their own consent ? (Personally, Its a great idea to update a profile with consent scopes and to link this to resource) Perhaps we can discuss via EIC ? Mark

On 8 May 2019, at 13:47, Cigdem Sengul wrote:

Thank you, This is very useful information.

I brought up consent receipt in the call because I am wondering whether it is possible to enhance offer-negotiate-accept terms-record flow for consent receipts.

Namely, I’ve been thinking about whether consent receipt can act as a seed for creating a user policy and/or machine readable license which may be used to authorise future interactions of the user with the same service (which may be used by UMA AS).

Thanks, --Cigdme

From: WG-UMA on behalf of Andrew Hughes Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger Cc: "wg-uma@kantarainitiative.org WG" Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07

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... https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J... with more text here: https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap... 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 mailto: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 mailto: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 mailto:eve@xmlgrrl.com> wrote:

They can be found here:

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 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 mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma https://kantarainitiative.org/mailman/listinfo/wg-uma_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Cigdem Sengul

3:11 p.m.

Responding to Mark and Lisa, Lisa, Thanks for the pointer I will take a deeper look, I did not have the chance to do a deep dive in this area. Mark, It is great to hear that this is of interest to you too. Let’s see how the discussion shapes up around this. We had discussions around the use-cases you mentioned, but cannot seem to find the pointers to them. --Cigdem From: "Mark @ OC" Date: Wednesday, 8 May 2019 at 16:01 To: Cigdem Sengul Cc: Andrew Hughes , Tim Reiniger , "wg-uma@kantarainitiative.org WG" Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07 HI Cigdem, This has been a topic of interest for some time now. Eve/Tim, if I recall, have you both done a lot of work in terms of consent directives? (I have been out of the loop for awhile) Would anyone happen to have a pointer to the use cases for digital death scenario's or for when a person becomes an adult and wants to take over their own consent ? (Personally, Its a great idea to update a profile with consent scopes and to link this to resource) Perhaps we can discuss via EIC ? Mark On 8 May 2019, at 13:47, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote: Thank you, This is very useful information. I brought up consent receipt in the call because I am wondering whether it is possible to enhance offer-negotiate-accept terms-record flow for consent receipts. Namely, I’ve been thinking about whether consent receipt can act as a seed for creating a user policy and/or machine readable license which may be used to authorise future interactions of the user with the same service (which may be used by UMA AS). Thanks, --Cigdme From: WG-UMA mailto:wg-uma-bounces@kantarainitiative.org> on behalf of Andrew Hughes mailto:andrewhughes3000@gmail.com> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger mailto:tsreiniger@gmail.com> Cc: "wg-uma@kantarainitiative.orgmailto:wg-uma@kantarainitiative.org WG" mailto:wg-uma@kantarainitiative.org> Subject: Re: [WG-UMA] Business model telecon notes for 2019-05-07 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.commailto: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 mailto: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 mailto:eve@xmlgrrl.com> 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.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

1956

Age (days ago)

1959

Last active (days ago)

Download

15 comments

8 participants

tags

participants (8)

Adrian Gropper
Andrew Hughes
Cigdem Sengul
Eve Maler
James Hazard
Lisa LeVasseur
Mark ＠ OC
Tim Reiniger