Business model telecon notes for 2019-05-07
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
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+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
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 <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+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
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 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 <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+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
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 <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 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 <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+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/
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 <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 <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 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 <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+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
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-01-pdf/> 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/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7wSfzDjU/edit?usp=sharing>, 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 <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 <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 <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 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 <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+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
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 <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-01-pdf/> 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/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7wSfzDjU/edit?usp=sharing>, 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 <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 <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 < 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 <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+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/
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 <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 <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-01-pdf/> 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/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7wSfzDjU/edit?usp=sharing>, 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 <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 <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 < 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 <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+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/
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 <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 <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 <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 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 <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 <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: 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 <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+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/
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 <eve@xmlgrrl.com <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+Authorization+Claims>
Eve Maler (sent from my iPad) | cell +1 425 345 6756
On May 10, 2019, at 8:46 AM, Lisa LeVasseur <lalevasseur@ieee.org <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 <agropper@healthurl.com <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 <eve@xmlgrrl.com <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-01-pdf/> 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/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7wSfzDjU/edit?usp=sharing>, 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 <lalevasseur@ieee.org <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 <eve@xmlgrrl.com <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 <andrewhughes3000@gmail.com <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/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J0PS> with more text here: https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap... <https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap+for+Kantara+%27User+agreement%27+Receipt+Concept>
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 <tsreiniger@gmail.com <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 <eve@xmlgrrl.com <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+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 <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>
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 <wg-uma-bounces@kantarainitiative.org> on behalf of Andrew Hughes <andrewhughes3000@gmail.com> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger <tsreiniger@gmail.com> Cc: "wg-uma@kantarainitiative.org WG" <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.com<mailto: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<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 <eve@xmlgrrl.com<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.org<mailto:WG-UMA@kantarainitiative.org> 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
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 <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 <wg-uma-bounces@kantarainitiative.org> on behalf of Andrew Hughes <andrewhughes3000@gmail.com> *Date: *Tuesday, 7 May 2019 at 18:45 *To: *Tim Reiniger <tsreiniger@gmail.com> *Cc: *"wg-uma@kantarainitiative.org WG" <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.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 <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+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
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 <andrewhughes3000@gmail.com> Date: Wednesday, 8 May 2019 at 14:27 To: Cigdem Sengul <Cigdem.Sengul@nominet.uk> Cc: Tim Reiniger <tsreiniger@gmail.com>, "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org> 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.com<mailto: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 <Cigdem.Sengul@nominet.uk<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 <wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Andrew Hughes <andrewhughes3000@gmail.com<mailto:andrewhughes3000@gmail.com>> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger <tsreiniger@gmail.com<mailto:tsreiniger@gmail.com>> Cc: "wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> WG" <wg-uma@kantarainitiative.org<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.com<mailto: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<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 <eve@xmlgrrl.com<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.org<mailto:WG-UMA@kantarainitiative.org> 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
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 <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 <wg-uma-bounces@kantarainitiative.org> on behalf of Andrew Hughes <andrewhughes3000@gmail.com> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger <tsreiniger@gmail.com> Cc: "wg-uma@kantarainitiative.org WG" <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... <https://share.mindmanager.com/#publish/NEsOqlqyWZ2buLfRgPdytSBf9KO1pQpZZMM4J0PS> with more text here: https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap... <https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap+for+Kantara+%27User+agreement%27+Receipt+Concept>
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 <tsreiniger@gmail.com <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 <eve@xmlgrrl.com <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+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 <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
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" <mark@openconsent.com> Date: Wednesday, 8 May 2019 at 16:01 To: Cigdem Sengul <Cigdem.Sengul@nominet.uk> Cc: Andrew Hughes <andrewhughes3000@gmail.com>, Tim Reiniger <tsreiniger@gmail.com>, "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org> 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 <Cigdem.Sengul@nominet.uk<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 <wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org>> on behalf of Andrew Hughes <andrewhughes3000@gmail.com<mailto:andrewhughes3000@gmail.com>> Date: Tuesday, 7 May 2019 at 18:45 To: Tim Reiniger <tsreiniger@gmail.com<mailto:tsreiniger@gmail.com>> Cc: "wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> WG" <wg-uma@kantarainitiative.org<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.com<mailto: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<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 <eve@xmlgrrl.com<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.org<mailto:WG-UMA@kantarainitiative.org> 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 _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/wg-uma
participants (8)
-
Adrian Gropper -
Andrew Hughes -
Cigdem Sengul -
Eve Maler -
James Hazard -
Lisa LeVasseur -
Mark ＠ OC -
Tim Reiniger