Notes from UMA legal subgroup telecon 2015-10-30
Fri Oct 30 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Report from IIW Eve will post John Wunderlich’s Consent Receipt demo video before the meeting There was a lot more relevant discussion too Input from Andrew Hughes — is he ready yet? Walk through Binding Obs to look for fodder What can we draw from all of this to shape our next outputs? AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. API.ConsentReceipts.org This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at CR.org is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Very good to see the consent receipt work covered in UMA. In regards to the consent receipt API demonstrator - the version that represents the v0.7 specification can be found at http://mvcr.herokuapp.com/ <http://mvcr.herokuapp.com/> The version currently up at api.consentreceipt.org <http://api.consentreceipt.org/> is the original straw man which Justin and Sarah started. We need to update this current version to api.consentreceipt.org <http://api.consentreceipt.org/> but haven’t had a moment. - Mark
On 30 Oct 2015, at 16:06, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Fri Oct 30 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Report from IIW Eve will post John Wunderlich’s Consent Receipt demo video before the meeting There was a lot more relevant discussion too Input from Andrew Hughes — is he ready yet? Walk through Binding Obs to look for fodder What can we draw from all of this to shape our next outputs? AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
Blockchains
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
BLT
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
PTP
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
API.ConsentReceipts.org <http://api.consentreceipts.org/>
This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
HIE of One
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
Binding Obligations review
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
Next steps
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
This email is an awesome font of information. Thanks. One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc. Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities. One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain? David David Kelts Director of Product Architecture Phone: 978-215-2573 Mobile: 508-633-1133 Fax: 978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com<mailto:dkelts@MorphoTrust.com> www.MorphoTrust.com<http://www.morphotrust.com/> [cid:image003.jpg@01D11325.155A6B60] Follow @IdentoGO<https://twitter.com/identogo> on Twitter and IdentoGO<http://www.linkedin.com/company/identogo> on LinkedIn. Like IdentoGO<https://www.facebook.com/identogo> on Facebook. From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: wg-uma@kantarainitiative.org WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 · Fri Oct 30 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines<https://www.turbobridge.com/join.html>), room code 178-2540# · Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me<http://join.me> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar * Report from IIW * Eve will post John Wunderlich’s Consent Receipt demo video before the meeting * There was a lot more relevant discussion too * Input from Andrew Hughes — is he ready yet? * Walk through Binding Obs to look for fodder * What can we draw from all of this to shape our next outputs? * AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the notes page<http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular session<http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins<https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the session<http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article<http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. API.ConsentReceipts.org<http://api.consentreceipts.org> This API<http://api.consentreceipt.org> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at CR.org<http://cr.org> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org<http://coloredchains.org>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the Binding Obs spec<https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> ________________________________ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
Hi David, Yes, blockchain is a technology, which was brought to world attention by Bitcoin, but is independent of Bitcoin. And it can indeed be run as you suggest. They can also be made to have a much higher degree of functionality. It is feasible to do as you say, though probably simpler to have a single organization carry the "cost." I put that in quotes, because the cost is very small if you don't have to use "proof of work" (an intentionally expensive approach) to incentivize maintenance of truth. MIT recently announced a similar thing for digital diplomas. As for the difficulties of figuring out the current state of someone's authorizations, it is possible to keep a record of the current state of a fixed (even large) number of parameters, and to reference where the sources of that truth are stored. This points out, however, an issue of architecture. It seems to me (I say this without deep technical understanding) that there are very good reasons of efficiency and security to have many, many independent channels (blockchain or other) instead of just one (as with Bitcoin). An institution or company shouldn't put internal communications on a public chain if it doesn't have to. If my pacemaker talks to my phone, it shouldn't broadcast stuff, and has to be able to do that independently, without an external internet connection. There can be many channels of communication, which feed each peer's data store. The glue can be the format of the records. Jim On Fri, Oct 30, 2015 at 8:10 PM, Kelts, David <DKelts@morphotrust.com> wrote:
This email is an awesome font of information. Thanks.
One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc.
Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities.
One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain?
David
*David Kelts*
*Director of Product Architecture*
*Phone: *978-215-2573
*Mobile: *508-633-1133
*Fax: *978-215-2500
296 Concord Ave, Suite 300
Billerica, MA, 01821 USA
dkelts@MorphoTrust.com
www.MorphoTrust.com <http://www.morphotrust.com/>
*Follow **@IdentoGO* <https://twitter.com/identogo>* on Twitter and * *IdentoGO* <http://www.linkedin.com/company/identogo>* on LinkedIn. Like * *IdentoGO* <https://www.facebook.com/identogo>* on Facebook. *
*From:* wg-uma-bounces@kantarainitiative.org [mailto: wg-uma-bounces@kantarainitiative.org] *On Behalf Of *Eve Maler *Sent:* Friday, October 30, 2015 12:07 PM *To:* wg-uma@kantarainitiative.org WG *Subject:* [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
· *Fri Oct 30* 8-9am PT
· Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540#
· Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
· UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
- Report from IIW
- Eve will post John Wunderlich’s Consent Receipt demo video before the meeting - There was a lot more relevant discussion too
- Input from Andrew Hughes — is he ready yet? - Walk through Binding Obs to look for fodder - What can we draw from all of this to shape our next outputs? - AOB
Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
*Blockchains*
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
*BLT*
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
*PTP*
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
*API.ConsentReceipts.org <http://api.consentreceipts.org>*
This API <http://api.consentreceipt.org> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
*HIE of One*
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
*Binding Obligations review*
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
*Next steps*
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
------------------------------
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
David, Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com) that I can open link to with say MyBirthID.com? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will. If not, please leave your sales pitch at the door! Tim From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Kelts, David Sent: Friday, October 30, 2015 2:10 PM To: Eve Maler; wg-uma@kantarainitiative.org WG Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 This email is an awesome font of information. Thanks. One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc. Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities. One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain? David David Kelts Director of Product Architecture Phone: 978-215-2573 Mobile: 508-633-1133 Fax: 978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com <http://www.morphotrust.com/> www.MorphoTrust.com Follow <https://twitter.com/identogo> @IdentoGO on Twitter and <http://www.linkedin.com/company/identogo> IdentoGO on LinkedIn. Like <https://www.facebook.com/identogo> IdentoGO on Facebook. From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: wg-uma@kantarainitiative.org WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 · Fri Oct 30 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 ( <https://www.turbobridge.com/join.html> international dial-in lines), room code 178-2540# · Screen sharing: <http://join.me/findthomas> http://join.me/findthomas - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar * Report from IIW * Eve will post John Wunderlich’s Consent Receipt demo video before the meeting * There was a lot more relevant discussion too * Input from Andrew Hughes — is he ready yet? * Walk through Binding Obs to look for fodder * What can we draw from all of this to shape our next outputs? * AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the <http://iiw.idcommons.net/IIW_21_Notes> notes page generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> session focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with <https://en.bitcoin.it/wiki/Colored_Coins> colored coins. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the <http://iiw.idcommons.net/Consent_Receipts_in_UMA> session where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> article he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. API.ConsentReceipts.org This <http://api.consentreceipt.org> API from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at CR.org is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> Binding Obs spec is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com _____ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be. On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com<mailto:tim@bridgeidentity.com>> wrote: David, Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com<http://mymorphoid.com/>) that I can open link to with say MyBirthID.com<http://mybirthid.com/>? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will. If not, please leave your sales pitch at the door! Tim From: wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Kelts, David Sent: Friday, October 30, 2015 2:10 PM To: Eve Maler; wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> WG Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 This email is an awesome font of information. Thanks. One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org<http://consentreceipts.org/>, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc. Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities. One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain? David David Kelts Director of Product Architecture Phone: 978-215-2573 Mobile: 508-633-1133 Fax: 978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com<mailto:dkelts@MorphoTrust.com> www.MorphoTrust.com<http://www.morphotrust.com/> <image001.jpg> Follow @IdentoGO<https://twitter.com/identogo> on Twitter and IdentoGO<http://www.linkedin.com/company/identogo> on LinkedIn. Like IdentoGO<https://www.facebook.com/identogo> on Facebook. From: wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 • Fri Oct 30 8-9am PT • Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines<https://www.turbobridge.com/join.html>), room code 178-2540# • Screen sharing: http://join.me/findthomas - NOTE: IGNORE the join.me<http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) • UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar * Report from IIW * Eve will post John Wunderlich’s Consent Receipt demo video before the meeting * There was a lot more relevant discussion too * Input from Andrew Hughes — is he ready yet? * Walk through Binding Obs to look for fodder * What can we draw from all of this to shape our next outputs? * AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the notes page<http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular session<http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins<https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the session<http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article<http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. API.ConsentReceipts.org<http://api.consentreceipts.org/> This API<http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at CR.org<http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org<http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the Binding Obs spec<https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com<mailto:xmlgrrl@gmail.com> ________________________________ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
Eve, Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com> wrote:
My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be.
On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com <tim@bridgeidentity.com>> wrote:
David,
Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com <http://mymorphoid.com/>) that I can open link to with say MyBirthID.com <http://mybirthid.com/>? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will.
If not, please leave your sales pitch at the door!
Tim
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Kelts, David *Sent:* Friday, October 30, 2015 2:10 PM *To:* Eve Maler; wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
This email is an awesome font of information. Thanks.
One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org <http://consentreceipts.org/>, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc.
Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities.
One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain?
David
*David Kelts* *Director of Product Architecture* *Phone: *978-215-2573 *Mobile: *508-633-1133 *Fax: *978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com www.MorphoTrust.com <http://www.morphotrust.com/>
<image001.jpg>
*Follow **@IdentoGO* <https://twitter.com/identogo>* on Twitter and * *IdentoGO* <http://www.linkedin.com/company/identogo>* on LinkedIn. Like * *IdentoGO* <https://www.facebook.com/identogo>* on Facebook. *
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Eve Maler *Sent:* Friday, October 30, 2015 12:07 PM *To:* wg-uma@kantarainitiative.org WG *Subject:* [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
· *Fri Oct 30* 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# · Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
- Report from IIW
- Eve will post John Wunderlich’s Consent Receipt demo video before the meeting - There was a lot more relevant discussion too
- Input from Andrew Hughes — is he ready yet? - Walk through Binding Obs to look for fodder - What can we draw from all of this to shape our next outputs? - AOB
Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
*Blockchains*
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
*BLT*
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
*PTP*
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
*API.ConsentReceipts.org <http://api.consentreceipts.org/>*
This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
*HIE of One*
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
*Binding Obligations review*
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
*Next steps*
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
------------------------------
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Might be a way to address audit in uma.. From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of j stollman Sent: Saturday, October 31, 2015 10:27 AM To: Kelts, David Cc: wg-uma@kantarainitiative.org Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 Eve, Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com> wrote: My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be. On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com> wrote: David, Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. <http://mymorphoid.com/> MyMorphoID.com) that I can open link to with say <http://mybirthid.com/> MyBirthID.com? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will. If not, please leave your sales pitch at the door! Tim From: <mailto:wg-uma-bounces@kantarainitiative.org> wg-uma-bounces@kantarainitiative.org [ <mailto:wg-uma-bounces@kantarainitiative.org> mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Kelts, David Sent: Friday, October 30, 2015 2:10 PM To: Eve Maler; <mailto:wg-uma@kantarainitiative.org> wg-uma@kantarainitiative.org WG Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 This email is an awesome font of information. Thanks. One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and <http://consentreceipts.org/> ConsentReceipts.org, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc. Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities. One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain? David David Kelts Director of Product Architecture Phone: 978-215-2573 Mobile: 508-633-1133 Fax: 978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA <mailto:dkelts@MorphoTrust.com> dkelts@MorphoTrust.com <http://www.morphotrust.com/> www.MorphoTrust.com <image001.jpg> Follow <https://twitter.com/identogo> @IdentoGO on Twitter and <http://www.linkedin.com/company/identogo> IdentoGO on LinkedIn. Like <https://www.facebook.com/identogo> IdentoGO on Facebook. From: <mailto:wg-uma-bounces@kantarainitiative.org> wg-uma-bounces@kantarainitiative.org [ <mailto:wg-uma-bounces@kantarainitiative.org> mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: <mailto:wg-uma@kantarainitiative.org> wg-uma@kantarainitiative.org WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 · Fri Oct 30 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 <tel:%2B1-805-309-2350> ( <https://www.turbobridge.com/join.html> international dial-in lines), room code 178-2540# · Screen sharing: <http://join.me/findthomas> http://join.me/findthomas - NOTE: IGNORE the <http://join.me/> join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: <http://kantarainitiative.org/confluence/display/uma/Calendar> http://kantarainitiative.org/confluence/display/uma/Calendar * Report from IIW * Eve will post John Wunderlich’s Consent Receipt demo video before the meeting * There was a lot more relevant discussion too * Input from Andrew Hughes — is he ready yet? * Walk through Binding Obs to look for fodder * What can we draw from all of this to shape our next outputs? * AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the <http://iiw.idcommons.net/IIW_21_Notes> notes page generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> session focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with <https://en.bitcoin.it/wiki/Colored_Coins> colored coins. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the <http://iiw.idcommons.net/Consent_Receipts_in_UMA> session where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> article he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. <http://api.consentreceipts.org/> API.ConsentReceipts.org This <http://api.consentreceipt.org/> API from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at <http://cr.org/> CR.org is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of <http://coloredchains.org/> ColoredChains.org, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> Binding Obs spec is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: <mailto:xmlgrrl@gmail.com> xmlgrrl@gmail.com _____ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately. _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
This was a contribution from Thomas, and it’s MIT Media Lab that’s doing a lot of work to mitigate both business and technical risks. I may have captured the concern incorrectly. Thomas, can you describe the concern more accurately? Eve
On 31 Oct 2015, at 7:26 AM, j stollman <stollman.j@gmail.com> wrote:
Eve,
Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place.
Jeff
--------------------------------- Jeff Stollman stollman.j@gmail.com <mailto:stollman.j@gmail.com> 1 202.683.8699
Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck
On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com <mailto:DKelts@morphotrust.com>> wrote: My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be.
On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com <mailto:tim@bridgeidentity.com>> wrote:
David,
Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com <http://mymorphoid.com/>) that I can open link to with say MyBirthID.com <http://mybirthid.com/>? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will.
If not, please leave your sales pitch at the door!
Tim
From: wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>] On Behalf Of Kelts, David Sent: Friday, October 30, 2015 2:10 PM To: Eve Maler; wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> WG Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
This email is an awesome font of information. Thanks.
One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org <http://consentreceipts.org/>, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc.
Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities.
One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain?
David
David Kelts Director of Product Architecture Phone: 978-215-2573 <tel:978-215-2573> Mobile: 508-633-1133 <tel:508-633-1133> Fax: 978-215-2500 <tel:978-215-2500> 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com <mailto:dkelts@MorphoTrust.com> www.MorphoTrust.com <http://www.morphotrust.com/>
<image001.jpg>
Follow @IdentoGO <https://twitter.com/identogo> on Twitter and IdentoGO <http://www.linkedin.com/company/identogo> on LinkedIn. Like IdentoGO <https://www.facebook.com/identogo> on Facebook.
From: wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org <mailto:wg-uma-bounces@kantarainitiative.org>] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
· Fri Oct 30 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 <tel:%2B1-805-309-2350> (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# · Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Report from IIW Eve will post John Wunderlich’s Consent Receipt demo video before the meeting There was a lot more relevant discussion too Input from Andrew Hughes — is he ready yet? Walk through Binding Obs to look for fodder What can we draw from all of this to shape our next outputs? AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
Blockchains
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
BLT
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
PTP
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
API.ConsentReceipts.org <http://api.consentreceipts.org/>
This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
HIE of One
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
Binding Obligations review
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
Next steps
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com <mailto:xmlgrrl@gmail.com>
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Very sorry to have missed the meeting. With your time change, we are now back on the usual difference. This all looks very promising. Blockchain opens new technical possibilities and has put people on the hunt for open source approaches. I've been asked to make a short presentation to the Global Alliance for Genomics and Health (GA4GH) on "smart contracts" and machine readable consent at their meeting in Paris, November 10. The context is patient consent to use of genetic information, a complex and touchy area, involving extensive personal data, great regulatory scrutiny, and international interoperability. My approach is to focus on the what (nouns) rather than how (verbs). What is needed is records. Records of the consent, of the preliminaries to the consent, of events afterwards (e.g., accesses, disposal, revocation), etc. These records should have a common format to allow them to work together. The focus of CommonAccord has been to demonstrate that complex textual relationships can be expressed like source code, simple enough that even lawyers can feel comfortable with it. Hashing, used on blockchain (and IPFS, git, maybe BitTorrent and other systems - beyond my domain of competence) allows great reduction in the number of copies of a record that a system needs to have. Often a single original with a backup or two. Use can be by interrogating an original (smart contract or conventional automation), or making a copy and disposing of it after use. There will still be good reasons to keep copies of many kinds of records, but it becomes much easier for the system to run nearly dry. Like a good software program, viewed across the whole of all users and uses. To demonstrate this, I'm putting together an "object model" for consents obtained in connection with genomics research. An object model would start with the actual consent, and work backwards and forwards. Backwards would be paperwork in creating the consent - the model of the consent, the adaptations for a particular country or research institute, the requirements of funders, the identification of the researcher, study, institution, funder, regulator, etc. Forwards would be notices of use, notice of destruction, revocation, further permission, etc. Ideally each thing would be stated once. Obviously, I can't expect to build a whole system between now and the 10th, but I do hope to sketch in something that could be iterated. With Primavera last year, and a translation by an Austrian researcher, we did a rough object model demonstrating the GA4GH Model Consent including objects for the persons, the study, the form of consent and three languages. http://www.commonaccord.org/index.php?action=list&file=Wx/org/genomicsandhealth/REWG/Demo/ The MVCR seems a useful object to integrate into a solution. I'll try to get a brief demo of http://mvcr.herokuapp.org/ going soon at - http://www.commonaccord.org/index.php?action=source&file=Wx/org/consentreceipt/api/Form/Doc_v0.md I invite anyone who is interested to let me know. I can use help, and correction, on almost everything. A stub of a resource for the presentation is at http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/2015-11-Paris/SmartContracts/Form/Presentation_v0.md Jim On Sun, Nov 1, 2015 at 8:46 AM, Eve Maler <eve@xmlgrrl.com> wrote:
This was a contribution from Thomas, and it’s MIT Media Lab that’s doing a lot of work to mitigate both business and technical risks. I may have captured the concern incorrectly. Thomas, can you describe the concern more accurately?
Eve
On 31 Oct 2015, at 7:26 AM, j stollman <stollman.j@gmail.com> wrote:
Eve,
Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place.
Jeff
--------------------------------- Jeff Stollman stollman.j@gmail.com 1 202.683.8699
Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck
On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com> wrote:
My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be.
On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com <tim@bridgeidentity.com>> wrote:
David,
Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com <http://mymorphoid.com/>) that I can open link to with say MyBirthID.com <http://mybirthid.com/>? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will.
If not, please leave your sales pitch at the door!
Tim
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Kelts, David *Sent:* Friday, October 30, 2015 2:10 PM *To:* Eve Maler; wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
This email is an awesome font of information. Thanks.
One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org <http://consentreceipts.org/>, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc.
Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities.
One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain?
David
*David Kelts* *Director of Product Architecture* *Phone: *978-215-2573 *Mobile: *508-633-1133 *Fax: *978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA dkelts@MorphoTrust.com www.MorphoTrust.com <http://www.morphotrust.com/>
<image001.jpg>
*Follow **@IdentoGO* <https://twitter.com/identogo>* on Twitter and * *IdentoGO* <http://www.linkedin.com/company/identogo>* on LinkedIn. Like **IdentoGO* <https://www.facebook.com/identogo>* on Facebook. *
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Eve Maler *Sent:* Friday, October 30, 2015 12:07 PM *To:* wg-uma@kantarainitiative.org WG *Subject:* [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
· *Fri Oct 30* 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# · Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
- Report from IIW
- Eve will post John Wunderlich’s Consent Receipt demo video before the meeting - There was a lot more relevant discussion too
- Input from Andrew Hughes — is he ready yet? - Walk through Binding Obs to look for fodder - What can we draw from all of this to shape our next outputs? - AOB
Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
*Blockchains*
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
*BLT*
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
*PTP*
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
*API.ConsentReceipts.org <http://api.consentreceipts.org/>*
This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
*HIE of One*
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
*Binding Obligations review*
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
*Next steps*
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
------------------------------
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Jim, I missed the meeting too, but here is a link to a healthcare cluster diagram I did that may shed some light on the healthcare identities. I also opened a link to a smart contract vehicle warranty architect using smart contract, tuples, and a graph database. Beta outline, but does open some insight to most of the identities one would need to relate to. UMA would attach to the API and Protocol nodes and not effect identities in this program. Let me know your thoughts and if you can understand it or not. http://www.bridgeidentity.com/index.php/sidechaincluster-healthcare http://www.bridgeidentity.com/index.php/sample-smart-contract-vehicle-warran... Tim From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of James Hazard Sent: Sunday, November 01, 2015 3:40 AM To: Eve Maler Cc: wg-uma@kantarainitiative.org Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 Very sorry to have missed the meeting. With your time change, we are now back on the usual difference. This all looks very promising. Blockchain opens new technical possibilities and has put people on the hunt for open source approaches. I've been asked to make a short presentation to the Global Alliance for Genomics and Health (GA4GH) on "smart contracts" and machine readable consent at their meeting in Paris, November 10. The context is patient consent to use of genetic information, a complex and touchy area, involving extensive personal data, great regulatory scrutiny, and international interoperability. My approach is to focus on the what (nouns) rather than how (verbs). What is needed is records. Records of the consent, of the preliminaries to the consent, of events afterwards (e.g., accesses, disposal, revocation), etc. These records should have a common format to allow them to work together. The focus of CommonAccord has been to demonstrate that complex textual relationships can be expressed like source code, simple enough that even lawyers can feel comfortable with it. Hashing, used on blockchain (and IPFS, git, maybe BitTorrent and other systems - beyond my domain of competence) allows great reduction in the number of copies of a record that a system needs to have. Often a single original with a backup or two. Use can be by interrogating an original (smart contract or conventional automation), or making a copy and disposing of it after use. There will still be good reasons to keep copies of many kinds of records, but it becomes much easier for the system to run nearly dry. Like a good software program, viewed across the whole of all users and uses. To demonstrate this, I'm putting together an "object model" for consents obtained in connection with genomics research. An object model would start with the actual consent, and work backwards and forwards. Backwards would be paperwork in creating the consent - the model of the consent, the adaptations for a particular country or research institute, the requirements of funders, the identification of the researcher, study, institution, funder, regulator, etc. Forwards would be notices of use, notice of destruction, revocation, further permission, etc. Ideally each thing would be stated once. Obviously, I can't expect to build a whole system between now and the 10th, but I do hope to sketch in something that could be iterated. With Primavera last year, and a translation by an Austrian researcher, we did a rough object model demonstrating the GA4GH Model Consent including objects for the persons, the study, the form of consent and three languages. http://www.commonaccord.org/index.php?action=list <http://www.commonaccord.org/index.php?action=list&file=Wx/org/genomicsandhealth/REWG/Demo/> &file=Wx/org/genomicsandhealth/REWG/Demo/ The MVCR seems a useful object to integrate into a solution. I'll try to get a brief demo of http://mvcr.herokuapp.org/ going soon at - http://www.commonaccord.org/index.php?action=source <http://www.commonaccord.org/index.php?action=source&file=Wx/org/consentreceipt/api/Form/Doc_v0.md> &file=Wx/org/consentreceipt/api/Form/Doc_v0.md I invite anyone who is interested to let me know. I can use help, and correction, on almost everything. A stub of a resource for the presentation is at http://www.commonaccord.org/index.php?action=doc <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/2015-11-Paris/SmartContracts/Form/Presentation_v0.md> &file=Wx/org/genomicsandhealth/REWG/2015-11-Paris/SmartContracts/Form/Presentation_v0.md Jim On Sun, Nov 1, 2015 at 8:46 AM, Eve Maler <eve@xmlgrrl.com> wrote: This was a contribution from Thomas, and it’s MIT Media Lab that’s doing a lot of work to mitigate both business and technical risks. I may have captured the concern incorrectly. Thomas, can you describe the concern more accurately? Eve On 31 Oct 2015, at 7:26 AM, j stollman <stollman.j@gmail.com> wrote: Eve, Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 <tel:1%20202.683.8699> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com> wrote: My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be. On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com> wrote: David, Ouch!!!! You hit this on the nail. First off, MIT is awesome and I am loving their work every day. Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol. Public and private mining pools will develop to support every application we can conceive for good and bad reasons. UMA, that matters! Is Morpho willing to create their own open blockchain (i.e. <http://mymorphoid.com/> MyMorphoID.com) that I can open link to with say <http://mybirthid.com/> MyBirthID.com? Let me know as I am all ears. It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will. If not, please leave your sales pitch at the door! Tim From: <mailto:wg-uma-bounces@kantarainitiative.org> wg-uma-bounces@kantarainitiative.org [ <mailto:wg-uma-bounces@kantarainitiative.org> mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Kelts, David Sent: Friday, October 30, 2015 2:10 PM To: Eve Maler; <mailto:wg-uma@kantarainitiative.org> wg-uma@kantarainitiative.org WG Subject: Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 This email is an awesome font of information. Thanks. One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and <http://consentreceipts.org/> ConsentReceipts.org, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc. Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities. One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain? David David Kelts Director of Product Architecture Phone: 978-215-2573 Mobile: 508-633-1133 Fax: 978-215-2500 296 Concord Ave, Suite 300 Billerica, MA, 01821 USA <mailto:dkelts@MorphoTrust.com> dkelts@MorphoTrust.com <http://www.morphotrust.com/> www.MorphoTrust.com <image001.jpg> Follow <https://twitter.com/identogo> @IdentoGO on Twitter and <http://www.linkedin.com/company/identogo> IdentoGO on LinkedIn. Like <https://www.facebook.com/identogo> IdentoGO on Facebook. From: <mailto:wg-uma-bounces@kantarainitiative.org> wg-uma-bounces@kantarainitiative.org [ <mailto:wg-uma-bounces@kantarainitiative.org> mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Friday, October 30, 2015 12:07 PM To: <mailto:wg-uma@kantarainitiative.org> wg-uma@kantarainitiative.org WG Subject: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30 · Fri Oct 30 8-9am PT · Voice: Skype: +99051000000481 or US +1-805-309-2350 <tel:%2B1-805-309-2350> ( <https://www.turbobridge.com/join.html> international dial-in lines), room code 178-2540# · Screen sharing: <http://join.me/findthomas> http://join.me/findthomas - NOTE: IGNORE the <http://join.me/> join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) · UMA calendar: <http://kantarainitiative.org/confluence/display/uma/Calendar> http://kantarainitiative.org/confluence/display/uma/Calendar * Report from IIW * Eve will post John Wunderlich’s Consent Receipt demo video before the meeting * There was a lot more relevant discussion too * Input from Andrew Hughes — is he ready yet? * Walk through Binding Obs to look for fodder * What can we draw from all of this to shape our next outputs? * AOB Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark Blockchains These were big at IIW 21! Take a look at the <http://iiw.idcommons.net/IIW_21_Notes> notes page generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger. Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities. One particular <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> session focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with <https://en.bitcoin.it/wiki/Colored_Coins> colored coins. The costs are latency (hour->day) and monetary costs ($.01 per transaction). In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion. BLT It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail! PTP This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource. Consent Receipts vs. Auditable Transaction Receipts Consent Receipts in UMA is the <http://iiw.idcommons.net/Consent_Receipts_in_UMA> session where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-) Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> article he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability. <http://api.consentreceipts.org/> API.ConsentReceipts.org This <http://api.consentreceipt.org/> API from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon). It appears that UX for the policy generator at <http://cr.org/> CR.org is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is. When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of <http://coloredchains.org/> ColoredChains.org, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces. HIE of One Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.” Binding Obligations review Eve reviewed very briefly how the <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> Binding Obs spec is supposed to work. Andrew is working on doing the same approach for other identity-related protocols. Next steps If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define. One question: Are we interested to use the “sociotechnical systems” language? Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: <mailto:xmlgrrl@gmail.com> xmlgrrl@gmail.com _____ This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately. _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Sorry for the slow response, I looked, wondered, slept. I'm all ears on "tuples and graphs", which is also the "Cmacc" data model (that enables CommonAccord). I was not able to connect your materials to my view of the world or CommonAccord, but I'm sure this is just a matter of building another bridge (or edge). On Sun, Nov 1, 2015 at 8:11 PM, BridgeIDentity <tim@bridgeidentity.com> wrote:
Jim,
I missed the meeting too, but here is a link to a healthcare cluster diagram I did that may shed some light on the healthcare identities.
I also opened a link to a smart contract vehicle warranty architect using smart contract, tuples, and a graph database.
Beta outline, but does open some insight to most of the identities one would need to relate to.
UMA would attach to the API and Protocol nodes and not effect identities in this program.
Let me know your thoughts and if you can understand it or not.
http://www.bridgeidentity.com/index.php/sidechaincluster-healthcare
http://www.bridgeidentity.com/index.php/sample-smart-contract-vehicle-warran...
Tim
*From:* wg-uma-bounces@kantarainitiative.org [mailto: wg-uma-bounces@kantarainitiative.org] *On Behalf Of *James Hazard *Sent:* Sunday, November 01, 2015 3:40 AM *To:* Eve Maler *Cc:* wg-uma@kantarainitiative.org
*Subject:* Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
Very sorry to have missed the meeting. With your time change, we are now back on the usual difference.
This all looks very promising. Blockchain opens new technical possibilities and has put people on the hunt for open source approaches.
I've been asked to make a short presentation to the Global Alliance for Genomics and Health (GA4GH) on "smart contracts" and machine readable consent at their meeting in Paris, November 10. The context is patient consent to use of genetic information, a complex and touchy area, involving extensive personal data, great regulatory scrutiny, and international interoperability.
My approach is to focus on the what (nouns) rather than how (verbs). What is needed is records. Records of the consent, of the preliminaries to the consent, of events afterwards (e.g., accesses, disposal, revocation), etc. These records should have a common format to allow them to work together. The focus of CommonAccord has been to demonstrate that complex textual relationships can be expressed like source code, simple enough that even lawyers can feel comfortable with it.
Hashing, used on blockchain (and IPFS, git, maybe BitTorrent and other systems - beyond my domain of competence) allows great reduction in the number of copies of a record that a system needs to have. Often a single original with a backup or two. Use can be by interrogating an original (smart contract or conventional automation), or making a copy and disposing of it after use. There will still be good reasons to keep copies of many kinds of records, but it becomes much easier for the system to run nearly dry. Like a good software program, viewed across the whole of all users and uses.
To demonstrate this, I'm putting together an "object model" for consents obtained in connection with genomics research. An object model would start with the actual consent, and work backwards and forwards. Backwards would be paperwork in creating the consent - the model of the consent, the adaptations for a particular country or research institute, the requirements of funders, the identification of the researcher, study, institution, funder, regulator, etc. Forwards would be notices of use, notice of destruction, revocation, further permission, etc. Ideally each thing would be stated once.
Obviously, I can't expect to build a whole system between now and the 10th, but I do hope to sketch in something that could be iterated. With Primavera last year, and a translation by an Austrian researcher, we did a rough object model demonstrating the GA4GH Model Consent including objects for the persons, the study, the form of consent and three languages. http://www.commonaccord.org/index.php?action=list&file=Wx/org/genomicsandhealth/REWG/Demo/
The MVCR seems a useful object to integrate into a solution. I'll try to get a brief demo of http://mvcr.herokuapp.org/ going soon at - http://www.commonaccord.org/index.php?action=source&file=Wx/org/consentreceipt/api/Form/Doc_v0.md
I invite anyone who is interested to let me know. I can use help, and correction, on almost everything. A stub of a resource for the presentation is at http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/2015-11-Paris/SmartContracts/Form/Presentation_v0.md
Jim
On Sun, Nov 1, 2015 at 8:46 AM, Eve Maler <eve@xmlgrrl.com> wrote:
This was a contribution from Thomas, and it’s MIT Media Lab that’s doing a lot of work to mitigate both business and technical risks. I may have captured the concern incorrectly. Thomas, can you describe the concern more accurately?
Eve
On 31 Oct 2015, at 7:26 AM, j stollman <stollman.j@gmail.com> wrote:
Eve,
Allow me to correct as mis-statement. One of the benefits of the blockchain is that it creates a transparent, non-reputiatable, transaction log. Claiming to have "lost my key" would not prevent the counterparty from decrypting the transaction as evidence that it took place.
Jeff
---------------------------------
Jeff Stollman stollman.j@gmail.com 1 202.683.8699
Truth never triumphs — its opponents just die out.
Science advances one funeral at a time.
Max Planck
On Sat, Oct 31, 2015 at 7:14 AM, Kelts, David <DKelts@morphotrust.com> wrote:
My apologies to the group if I came off salesy. I grabbed an example off the top of my head that made mental sense - all organizations I respect and think people trust - to make a point. Having understood this version of blockchain usage anew, yes I am going to take action to see what my company’s directions will be.
On Oct 30, 2015, at 8:01 PM, BridgeIDentity <tim@BridgeIDentity.com <tim@bridgeidentity.com>> wrote:
David,
Ouch!!!! You hit this on the nail.
First off, MIT is awesome and I am loving their work every day.
Keep in mind that “the Ledger” you reference is not a ledger. There are multiple ledgers using the base protocol.
Public and private mining pools will develop to support every application we can conceive for good and bad reasons.
UMA, that matters!
Is Morpho willing to create their own open blockchain (i.e. MyMorphoID.com <http://mymorphoid.com/>) that I can open link to with say MyBirthID.com <http://mybirthid.com/>? Let me know as I am all ears.
It really all comes down to silo and gov protectionism when really it is the UMA focus here. Figure it out or someone else will.
If not, please leave your sales pitch at the door!
Tim
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Kelts, David *Sent:* Friday, October 30, 2015 2:10 PM *To:* Eve Maler; wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
This email is an awesome font of information. Thanks.
One of the things I learned at IIW (which, of course, could be refutable because it was I who learned it…) is that there are models where you could separate Bitcoins from the Blockchain algorithm and the Distributed Ledger. Bitcoin is an incentive mechanism for miners to solve crypto problems for the right to earn the transaction fees and write the next transaction block to the Ledger. Other models, where, for instance, ‘n’ entities could round robin the writing of the transaction blocks would be less processor intensive and still maintain a perfectly good Distributed Ledger for public use. As a more specific hypothetical example, if MIT and EFF and NIST and ConsentReceipts.org <http://consentreceipts.org/>, etc. formed a legal agreement to maintain a Blockchain for public use of consent receipts including the cost impact of the storage space for the ledger, an API could be made available with free and always available public verification. The difficulty would be the legal and cost agreements plus getting a large enough number of trustworthy volunteer block writers, but it would save the expenditure of Bitcoins. Alternatively, the UN or government entities could share Ledger costs. Worldwide birth certificate registry maintained by all countries, etc.
Feel free to either refute or laugh at the altruism this would take to implement… but there is some sense behind it and maybe some realistic possibilities.
One other question for the consent receipts usage. Since you only append to the chain, wouldn’t the revocation of consent mean that a “get me current state” algorithm for one consumer have to traverse the entire chain?
David
*David Kelts*
*Director of Product Architecture*
*Phone: *978-215-2573
*Mobile: *508-633-1133
*Fax: *978-215-2500
296 Concord Ave, Suite 300
Billerica, MA, 01821 USA
dkelts@MorphoTrust.com
www.MorphoTrust.com <http://www.morphotrust.com/>
<image001.jpg>
*Follow **@IdentoGO* <https://twitter.com/identogo>* on Twitter and * *IdentoGO* <http://www.linkedin.com/company/identogo>* on LinkedIn. Like * *IdentoGO* <https://www.facebook.com/identogo>* on Facebook. *
*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org>] *On Behalf Of *Eve Maler *Sent:* Friday, October 30, 2015 12:07 PM *To:* wg-uma@kantarainitiative.org WG *Subject:* [WG-UMA] Notes from UMA legal subgroup telecon 2015-10-30
· *Fri Oct 30* 8-9am PT
· Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540#
· Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
· UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
- Report from IIW
- Eve will post John Wunderlich’s Consent Receipt demo video before the meeting - There was a lot more relevant discussion too
- Input from Andrew Hughes — is he ready yet? - Walk through Binding Obs to look for fodder - What can we draw from all of this to shape our next outputs? - AOB
Attending: Eve, Jon, Adrian, Ann, Steve, Thomas, Andrew H, Joni, Mark
*Blockchains*
These were big at IIW 21! Take a look at the notes page <http://iiw.idcommons.net/IIW_21_Notes> generally, compared to six months ago, when there was one session. A blockchain is a distributed ledger.
Our our call today, Thomas, Adrian, and Steve “speak blockchain” pretty well. Thomas noted that MIT Media Labs has a full-time digital currency initiative to combat some of the key (perceived or real) vulnerabilities.
One particular session <http://iiw.idcommons.net/BlockChain_&_UMA_%E2%80%93_Two_Great_Tastes%E2%80%A6_Do_They_Go_Together?> focused on blockchain wrt UMA. The session participants came up with four ideas for potential synergies. The most attractive was using a blockchain for receipts. The newer implementations give the features you’d need for this with colored coins <https://en.bitcoin.it/wiki/Colored_Coins>. The costs are latency (hour->day) and monetary costs ($.01 per transaction).
In the case of using this technology for contracts, the incentives may be perverse regarding revocation: You typically want each party to protect their private key with their lives. But for contracts, one party may want to go to the judge and say “Sorry, I lost my key, so in fact I can’t prove and you can’t prove I took part in these transactions!” That sounds pretty bad. Then you’re back to key escrow. How much does that solve vs. “centralized” mechanisms? The data is still stored in a decentralized fashion.
*BLT*
It’s not just a sandwich anymore. There’s a bourbon, lemon, and tonic cocktail!
*PTP*
This is the Pumpkin Theater Protocol. Sarah had a consent receipts session act out the UMA protocol with receipts added, protecting a little autumn pumpkin as the resource.
Consent Receipts vs. Auditable Transaction Receipts
Consent Receipts in UMA is the session <http://iiw.idcommons.net/Consent_Receipts_in_UMA> where Sarah came up with the PTP. We liked the idea of defining a little spec for what Adrian calls a “notice endpoint”. UMA could choose to add this optionally to the protection and authorization APIs, for resource owners and requesting parties, at the authorization server if it wants to. This could make the AS one hub of receipt storage. Andrew notes it could be called the “shoebox endpoint”! :-)
Adrian suspects that this could do away with the notion of “informed consent” completely. Wow. This is similar to an article <http://www.nejm.org/doi/full/10.1056/NEJMp1512205?query=TOC> he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
*API.ConsentReceipts.org <http://api.consentreceipts.org/>*
This API <http://api.consentreceipt.org/> from the CISWG illustrates how they are going about defining the “minimum viable consent receipt” spec. We showed how it produces (supposedly) human-readable receipts; the JSON output seemed not to be working for the moment but Eve saw it in John Wunderlich’s demo this week (for which she will hopefully be posting video soon).
It appears that UX for the policy generator at CR.org <http://cr.org/> is a new substitute for “markdown editing” (or whatever it is) presented in CommonAccord, and the “legal stack” that you can get out of CommonAccord as a template generator could be managed, versioned, and then hashed as a representation of what your contract is.
When you put something onto the blockchain, the way the storage works, you only have a tiny amount of space into the scripting area. In the case of ColoredChains.org <http://coloredchains.org/>, they put the distributed hash table key into BitTorrent. You might have a much larger document with megabytes of data that you want to claim and provide a verifiable token for. The blockchain gives you the verifiability you need. A “colored coin” is just the hash piece. BitTorrent uses SHA-1, which isn’t considered secure anymore. So you use SHA-256, use three address slots, and use the second two for a SHA-256 hash broken into two pieces.
*HIE of One*
Dazza is running Future of Commerce on Nov 20-22, and Adrian will be launching HIE of One here, which is meant to be the “simplest practical UMA use case”. HIE of One’s project goal is to "provide a standards-based platform for durable relationship between customers and vendors. Our approach lowers the barrier to adoption by the vendors by (i) not introducing a new party to their base customer relationship, (ii) allowing the vendor the option to authenticate any requesting party, just like they do already, and (iii) offering an accessible reference implementation for both the vendor and any requesting party client to test against. The benefit of this approach to both the customer and the vendor is trust, in that valuable behavioral data does not leak to intermediary brokers. We will use UMA 1.0.1 as the core standard and suggest changes for UMA 2.0 as gaps are identified. OpenID Connect, CommonAccord, and MVCR will be referenced as appropriate.”
*Binding Obligations review*
Eve reviewed very briefly how the Binding Obs spec <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> is supposed to work. Andrew is working on doing the same approach for other identity-related protocols.
*Next steps*
If Andrew can provide us with his requirements by next time, it appears we’ll be very well positioned to start filling in at least some UMA-specific and non-UMA-specific clauses and deciding what technical approach to use and what “legal stacks” to define.
One question: Are we interested to use the “sociotechnical systems” language?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
------------------------------
This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, LLC. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (7)
-
BridgeIDentity -
Eve Maler -
j stollman -
James Hazard -
Kelts, David -
Mark Lizar -
Salvatore D'Agostino