- 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 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 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.
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 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 he’s seen making the case that deidentification no longer puts you into a Safe Harbor by avoiding authorization and accountability.
This 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 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?