October 2015 - WG-UMA - mailman.kantarainitiative.org

Notes from UMA legal subgroup telecon 2015-10-30
by Eve Maler 02 Nov '15

02 Nov '15

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%…> 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(a)gmail.com

7 11

Discussing issue #229: RPT/ticket security language in Core Sec 3.2.2
by Eve Maler 30 Oct '15

30 Oct '15

Since we didn’t get to meet last week, we didn’t have a chance to discuss this issue synchronously as I’d hoped. James had brought this up to me: https://github.com/KantaraInitiative/wg-uma/issues/229 In Core Sec 3.2.2 in draft V1.0.1... https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#ticket-ma… ...it says... "If the authorization server observes that a permission ticket is used by multiple different clients, it SHOULD attempt to revoke all RPTs already granted based on the compromised permission ticket." However, wouldn't "all RPTs" amount to precisely a single RPT, if one was granted? If so, then it should simply say: "If the authorization server observes that a permission ticket is used by multiple different clients, it SHOULD attempt to revoke any RPT already granted based on the compromised permission ticket.” ==== Do we count even RPTs issued when an RPT is turned in by the client and a new one is minted by the AS in response as all being “granted based on the compromised permission ticket”? I’m not sure that would make sense for the attack, though, since the multiple different clients would have actually USED the same ticket in that case. So it seems to me that replacing “all RPTs” with “any RPT” would still be accurate and also less confusing. Thoughts? Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 3

Fwd: NIST Seeks Comments on New Project Aimed at Protecting Privacy Online
by Andrew Hughes 29 Oct '15

29 Oct '15

Hi UMAnitarians - not sure if you've seen this notice yet I'm vice-chair of IAWG & we are probably going to assemble comments on this. "Privacy-Enhanced Identity Brokers" Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE Due 18 December http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000(a)gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

9 13

Re: [WG-UMA] [WG-InfoSharing] consent receipt decks
by Mark Lizar 29 Oct '15

29 Oct '15

Great stuff, EXCELLENT presentation explaining the receipt! I think i may have contributed to a mistake on one side an suggest only one slight revision. Changing: "Consent and Information Sharing Work Group has created an MVP standard as part of its work at the Kantara Initiative.” I would change this to, we are on our way to creating a specification, for core consent and notice profile, or minimum viable consent receipt. ( We are at v0.7.2 at the moment.) We are at a point in the specification development which really needs implementation and feed back. S _Mark PS. that is a nudge for anyone interested in implementing consent receipts to get in touch. > On 29 Oct 2015, at 14:13, John Wunderlich <john(a)wunderlich.ca> wrote: > > FYI: > > Here's the links to the consent receipt decks I used at IIW: > > Introduction to the MVCR: > Introduction to the MVCR.pdf <https://drive.google.com/a/wunderlich.ca/file/d/0B-W7F5c-RcqEbHJXMUxqaHc4dk…> > Introduction to the MVCR.pptx <https://drive.google.com/a/wunderlich.ca/file/d/0B-W7F5c-RcqEQmpCUGxJcXh0WE…> > Speed Demo: > > IIW_MVCR_Demo.pdf <https://drive.google.com/a/wunderlich.ca/file/d/0B-W7F5c-RcqEb3FVSWt1d05mRj…> > IIW_MVCR_Demo.pptx <https://drive.google.com/a/wunderlich.ca/file/d/0B-W7F5c-RcqEbnBOaWM5S3dZem…> > > Sincerely, > John Wunderlich > @PrivacyCDN > > Call: +1 (647) 669-4749 > eMail: john(a)wunderlich.ca <mailto:john@wunderlich.ca> > > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > WG-InfoSharing mailing list > WG-InfoSharing(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-infosharing

1 0

Reminder: UMA legal subgroup telecon 2015-10-30 (but no WG meeting tomorrow)
by Eve Maler 29 Oct '15

29 Oct '15

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 Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft of permission registration extension spec
by Eve Maler 29 Oct '15

29 Oct '15

This is sort of an “editor’s draft”. Thanks to Roland et al. for early feedback! Does the group want to consider this ready enough for discussion as a group work product? In which case I can put it in GitHub etc… Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

You're invited: tweet chat on #ConsentFutures
by Eve Maler 25 Oct '15

25 Oct '15

Hi folks— As noted in the legal subgroup minutes already: Please join my upcoming Twitter chat Tue Nov 3 9am PT <https://www.forgerock.com/blog/twitter-chat-with-xmlgrrl-eve-maler-consentf…>! The hashtag is #ConsentFutures. The full title is Safe Harbor and the Future of Consent. I think I just discovered that our listed times are slightly incorrect because “summertime skew” will be over by Nov 3, so the UK time should be 5pm and the CET time should be 6pm. I’m sorry for any inconvenience! Please spread the word… If you let me know you’re attending, I’ll give you a shoutout in Twitter. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Re: [WG-UMA] [projectvrm] Consent Receipts: Safe Harbour through Personal Data Control
by Adrian Gropper 23 Oct '15

23 Oct '15

John, I think we're talking past each other. You're talking about the content, and I'm talking about the context. A stable consent receipt ecosystem will evolve from the desire of both customers and vendors to engage in somewhat durable relationships. The Wired article <http://www.wired.co.uk/magazine/archive/2015/11/features/inside-facebook-me…> about Facebook Messenger gets this. Relationships and business imperatives will drive the receipt content standard. Adrian On Fri, Oct 23, 2015 at 12:38 PM, John Wunderlich <john(a)wunderlich.ca> wrote: > Adrian; > > Isn't it the case that notice requires a recipient. The actual address to > which this is delivered can be transient, anonymous, or permanent. From my > point of view the consent receipt will deliver a record of what information > was collected, by whom, and for what purposes. The presence of a GUID on > the receipt means that the transaction can be both anonymous and verifiable > after the fact - if both parties keep a copy of the receipt. And it is > certainly the case that the consent receipt format can be used to deliver a > notice - i.e. "Here is the receipt you will get if you register with our > site. Should we proceed, or should we delete your information and end the > transaction?" > > So to your question about where to work this out, I would suggest that > there is no normative or canonical answer to this question. If and when the > notion of a receipt for the collection of personal information becomes > normalized, then there will be many contextual choices. Hopefully most of > them will meet the spec we are building - but that spec has to do with the > information IN the receipt, not how it is transmitted. > > Adoption will be driven by the ability of providers to use the API we are > devloping in multiple contexts, to meet their own and their customers needs > - while providing evidence to regulators where needed. > > > Sincerely, > John Wunderlich > @PrivacyCDN > > Call: +1 (647) 669-4749 > eMail: john(a)wunderlich.ca > > On 23 October 2015 at 10:07, Adrian Gropper <agropper(a)healthurl.com> > wrote: > >> Apologies for continuing this valuable cross-posting. >> >> Notice, first and foremost, requires a destination address. This address >> can be either: >> >> - arbitrarily specified by the subject of the PII (the principal) >> - specified by the vendor or service provider >> - chosen, NASCAR-style, from a list of well-known intermediaries >> - sent to a public ledger like a blockchain >> >> Where do we work out which of these meets our intent and drives adoption? >> >> Adrian >> >> On Fri, Oct 23, 2015 at 8:11 AM, Mark Lizar <info(a)smartspecies.com> >> wrote: >> >>> Some background on the thinking that has gone into the design of a >>> consent receipt specific to safe harbour. >>> >>> One of the biggest issues with moving data across jurisdictions is the >>> different laws. This is in addition to the complexity of difference >>> cultures and different contexts that create expectations of data use. This >>> is why data protection and privacy in the context of cross border data >>> transfers is so difficult. >>> >>> A preferred way to expedite data transfers is for people to control >>> their own data and to consent to its access, rather than only its transfer. >>> (A new and developing layer of technical capability affectionately called >>> Consent 2.0) >>> >>> A consent receipt is like a reverse (VRM) cookie, its a record that >>> people get to track organisations and what they share about them. It >>> collects the identity attributes that are provided, the purpose they are >>> provided for and who they are shared with. The Consent Receipt can also >>> carry assurances, trust marks, security promises and even reputations. >>> >>> Combined with UMA, a consent receipt is a tool to show how personal >>> control over data means that it can stay in a jurisdiction, and be shared >>> with others. In essence people can control access to data and create their >>> own safe harbour to transfer data across borders. >>> >>> Regardless of who the data controller is, a key benefit of a consent >>> receipt for organisations is the ability to add, record and provide >>> jurisdictionally based notice requirements to a consent notice. >>> Demonstrating compliance (or not) by the notices provided with the privacy >>> policy for sharing and data use. Combined with model contract clauses, >>> which are used to assure liability and define data controls, consent >>> receipts address Privacy Policies while model contracts address Terms of >>> Use policies. >>> >>> In the EU, notice and consent is required for all personal data >>> collection and sharing. In the US, explicit notices are required for >>> consent for sensitive data. Data covered by federal laws like COPPA, GBLA, >>> HIPPA, and the like. >>> >>> In every jurisdiction sensitive data comes with specific, legally >>> defined, notice requirements, that are localised. All sensitive personal >>> data transfer requires explicit consent and notice that are intended to >>> assure informed consent. It is for this reason that a consent receipt has >>> been designed to highlight sensitive data, both what an individual >>> considers sensitive and what the law considers sensitive, so that PII can >>> be shared. >>> >>> If an organisation doesn’t meet legal notice requirements across >>> jurisdictions, then it doesn’t matter what model contract clauses are used, >>> the consent is not informed and compliant for sensitive data collection and >>> sharing. In fact, model clauses can become a source of toxic liability and >>> can be used to hold the data controller or processors liable. (which builds >>> trust) >>> >>> Posted on consentreceipt.org >>> <http://consentreceipt.org/consent-receipts-safe-harbour-through-personal-da…> >>> >>> >> >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! >> HELP us fight for the right to control personal health data. >> DONATE: http://patientprivacyrights.org/donate-2/ >> > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Notes from UMA legal subgroup telecon 2015-10-23
by Eve Maler 23 Oct '15

23 Oct '15

Attending: Eve, Adrian, Ann, Andrew H, Jeff, Mark, Tim, Jim, Domenico, Dazza Regrets: Jon, Steve Mark L’s very interesting new blog post <http://consentreceipt.org/blog/> is a positive innovation-centric view of consent and what may come after the “easy path” is denied to organizations. On that note, please join Eve’s Twitter chat Tue Nov 3 9am PT <https://www.forgerock.com/blog/twitter-chat-with-xmlgrrl-eve-maler-consentf…>! The hashtag is #ConsentFutures. Two tasks we can do today: Jim’s “stack dance” and a walkthrough of Binding Obs to get inspired about UMA-specific model clauses. Andrew H is working on a project right now that involves something very much like Binding Obs. They’re currently calling them “commitments”. Some RS’s are independently operated, and they’re trying to persuade them, partly through contracts, to play ball. The technical layer is easy: “Follow the spec.” But at the business program level, they have to care, and at the legal contract level, it’s obviously relevant. (B&L are the challenge, not T.) Adrian points to this Wired article <http://www.wired.co.uk/magazine/archive/2015/11/features/inside-facebook-me…> about FB Messenger having a leg up over other apps/platforms because of its identity footprint. He sees UMA having an opportunity to provide an alternative. Eve wonders if this is relevant to his point about making the RS more comfortable with the UMA proposition by enabling RqP authentication (and maybe even claims-gathering?) through the RS. This is additionally to letting the RS continue to vet the RqP. Andrew thinks some of these could work on a B level and will provide feedback. Regarding who logs in to whom, this is a government sector project, and there are certain cultural identity practices, resulting in unique tensions and also degrees of trust. Andrew’s new term for trust frameworks is “faith frameworks”. :-) This reminds Eve of Prof. Munindar Singh’s work on “sociotechnical systems”, where “commitments is the formal name for what we’ve called obligations. Here are the references we previously shared with the WG: Readings sent by Prof. Munindar Singh: [Basic: if you have time for one paper] Norms as a Basis for Governing Sociotechnical Systems <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/IJCAI-15-TIST.pdf>. This is a five-page extended abstract of a longer journal article. [Computational mapping to data stores; short but somewhat technical] Cupid: Commitments in Relational Algebra <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/AAAI-15-Cupid.pdf>. [More on the conception of commitments; easy read] Commitments in Multiagent Systems: Some History, Some Confusions, Some Controversies, Some Prospects <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/Commitments-for-MAS.pdf>. Model clauses are now a very popular notion for starting to solve our problems. The head of Microsoft Legal was talking about this in a blog post recently. A “legal stack” in CommonAccord means that a single outline can be built, and then the EU model clauses in each language can be mapped to the singular outline in turn. A contract outline has been put together that uses Dazza’s BLT ordering. This is why you can see {Business.Sec}, {Legal.Sec}, and then {Technical.Sec} as the sections in the outline. Andrew asks for great sources of Safe Harbor news. Here are some: Jon’s blog: DataLaw.net <http://datalaw.net/> Jon’s Twitter feed: @jonneiditz <https://twitter.com/jonneiditz> Jim’s Twitter feed: @CommonAccord <https://twitter.com/commonaccord> How does someone create their own documents/legal stacks/contracts? One can fork the code, or create pull requests, or… Jim has created some “pretend namespaces” at CommonAccord, such as “GHx” to represent the CommonAccord mirroring of GitHub repos living elsewhere, and “W” for the WWW generally, and “TW” for Twitter accounts. He also has “at” is for locations. Someday the app could go client-side so it could be everywhere. Ideally it should be understood as a file system by those who use it. The link at the top of the “Source” pages could then go and fetch the content live. The terms on the left of a stack, such as “DEO” for data-exporting organization, are just made up by the author. There’s no magic in it. It’s just a string that’s the name of a constant. Eventually the software will want to be able to handle some simple match, searches, etc. Andrew needs to have a well-described approach by mid-November. By late spring, they are looking to have the “commitments” and even some contracts settled. Can Andrew start to list the documents needed? We can start to put together draft versions, and assemble a stack. Andrew is currently trying to identify all the parties and transactions involved. He can share all that in a week or two. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 1

Why HybridIDToken ?
by Roland Hedberg 23 Oct '15

23 Oct '15

In the examples in 3.5.4 and 3.6.2 ”http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken” is given as an example of claim_token_format/format. I can’t see that Hybrid Flow ID Token provides the AS with any extra information compared to a ’normal’ ID Token that the AS can have any use of. Since the AS will most probably not have access to the code or the access_token value. Or am I missing something ? So, why choose it as an example. — Roland 'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett

2 1