- WG-UMA - mailman.kantarainitiative.org

FutureCommerce Hackathon & Symposium Event at MIT
by Adrian Gropper 07 Nov '15

07 Nov '15

Previews and Live Discussion: Monday, November 9th at 2:00pm Eastern via this page: http://futurecommerce.civics.com/index.html#whats-next <http://futurecommerce.civics.com/index.html#whats-next>FutureCommerce Hackathon & Symposium November 20-22, 2015 Online and In-Person Open Event *by* MIT Connection Science @ The Media Lab ------------------------------ The FutureCommerce Hackathon and Symposium is a creative event for team-based generation of innovative commercial products, services, transactions, experiences, relationships and business models. Enroll and/or propose a project at http://futurecommerce.civics.com/index.html --- Shameless plug: I will be proposing a GitHub project to create an open source reference implementation of a _personal_ UMA Authorization Server. The goal is to accelerate adoption of standard APIs for controlled access to the personal information that service providers have about us. The project is called HIE of One. It's not healthcare specific. Attend the Nov 9 preview and/or just connect with me directly if you would like to know more. -- Adrian <http://patientprivacyrights.org/donate-2/> <http://patientprivacyrights.org/donate-2/>

1 0

UMA testing / SecurityLoft / Client calls API
by Mike Schwartz 06 Nov '15

06 Nov '15

UMA-tarians, We've been talking about interop / conformance testing for a long time, and I think we need to get this to the starting line. There are a lot of UMA use cases that we need to prove out. I think we all agree that in order to move forward, we should start small, and in each iteration, cover more cases. This past IIW, I broached the idea of forming a new volunteer organization called "SecurityLoft". I have been inspired by OWASP. To start, SecurityLoft would just be a website, and a cloud server somewhere. I spoke with Kelly Grizzle at Sailpoint about hosting SCIM conformance tests at SecurityLoft. Perhaps SecurityLoft could also host UMA tests. The specific use case I think we should start with is (drum roll please...): Client calls API on Resource Server To get this done, we'll need to make a policy that any client can call to test positive and negative results. To make it easy to start with, I suggest using a policy based on time. In order to get a successful request, the permission ticket must be registered in the first 15 seconds of the minute. Just an idea... I was also thinking perhaps the UMA client could send claims as a json payload. Modest start? Yes! But at least a start that shows something tangible! - Mike

2 1

Reminder: UMA legal subgroup telecon 2015-11-06
by Eve Maler 05 Nov '15

05 Nov '15

Fri Nov 6 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> Goal: start building a general "legal stack" for UMA-specific elements Learn more of Andrew H’s use case details Examine the sociotechnical norms for potentially useful concepts AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft minutes of UMA telecon 2015-11-05
by Eve Maler 05 Nov '15

05 Nov '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05 Minutes Roll call Quorum was reached. Next week's calls The WG call and the APAC sync are cancelled. The legal subgroup call will be run (and an agenda sent) by Adrian. Eve will "split the difference" with APAC-friendly calls and schedule one for two weeks from now vs. next week and three weeks from now. Public Review and WG approval for LC certification as Draft Recommendations so that All Member Ballot can begin Joni reports that we got a fair amount media attention, but no comments through the KI channel. We got a couple of pull requests for minor typos (thanks, Sarah!) and Eve reported a few minor editorial issues and subsequently incorporated fixes for all but one. Maciej has generated drafts with all of that incorporated. MOTION: Andi moves and Mike seconds: Approve the UMA Core V1.0.1 and OAuth RSR V1.0.1 specifications dated 5 Nov 2015, as amended with the agreed resolution to issue #229 and appropriate document metadata, for LC certification as Draft Recommendations so that All Member Ballot can begin. APPROVED by unanimous consent. The Status section should say, instead of "...for Public Review", should say "for LC certification as a Draft Recommendation". AI: Maciej: Edit the specs so we can turn them over to the LC to take up their e-ballot. AI: Eve: Edit the Release Notes slightly to indicate the status change of the specs. Independent Submission stance: any news/changes? The discussion to gather more information is still ongoing. Permission registration extension spec review We discussed the configuration data situation. Do we want to have an official UMA configuration data property that contains an array of profiles and extensions supported (by identifying URI)? Or instead – or in addition – does it make sense to have a property for each profile and extension (as this spec proposes) where the name is the identifying URI, and then you could provides all kinds of values, or even arrays etc., for finer-grained configuration of each profile and extension? George proposes something like this: "extensions_support is a JSON map where the key name is the extension URI and the value is a JSON object defined by the extension" This would ideally be something baked into the UMA spec. Does it make sense to do this in "the first extension produced by the UMA WG"? Also, the line between profiles and extensions is kind of thin. The spec, in Core Sec 1.4, explicitly stays out of the business of capturing profile or extension config data (at the end of the section). Should we get into the business? We're thinking maybe not. The mere presence of the key might normally indicate that the AS supports the extension. However, in an ecosystem where there are multiple AS's, and some do support the extension and some don't, a random RS might want all AS's to explicitly declare the situation. So that's where a key of "identifying_URI" and a value of something like a Boolean could be used. If the extension in question wants to have the AS provide a complex set of parameters whenever they do support the extension, it would be ideal to allow the parser to be able to stop the moment it knows that the AS doesn't support the extension, vs. parsing a whole object. (Think token introspection.) For our purposes here, we can keep it simple. Let's change to a Boolean for now. AI: George: Write up a short UIG section capturing the above discussion on profile/extension config data. (Eve will send links and instructions.) For the question about registration failure, George recommends for the AS to return an array of resource set IDs, each with a status, with an overall error. Are we sure we want to return a single ticket for the set of requested permissions? The RS has always had complete discretion about what to register. However, since resource sets may have scopes that are totally distinct from each other, it may be very important – party for interoperability's sake – to explicitly register requested permissions for each resource set. Note that the RS's registration of requested permissions is just about a bundling on behalf of the client. We don't get into authorization questions until the client actually conveys the ticket back to the AS to ask for authorization data at the RPT endpoint. So we're talking syntactic errors at this point. We're agreed that if there's an error in the request, the whole request should fail. We seem to need more discussion about multiple requested permissions vs. one returned ticket; we know there would have to be a lot more infrastructure invented if we returned multiple tickets. AI: Eve: Rev the permission registration extension spec. IIW 21 roundup Sorry there was no time to talk about IIW impressions! Do see the notes here <http://iiw.idcommons.net/IIW_21_Notes> (more still to come). There were lots of amazing discussions about UMA, and also consent receipts, and blockchain. (And don't miss Beyonce as a Service!) Previous AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Andi and Zhanna: Please look at the section on optional and extension properties to see what might need an update to account for V1.0.1. [DONE] AI: Maciej: Review and correct the Redirecting the Requesting Party to the Client After Claims Gathering section. AI: Maciej: Write up some recommendations for the RPT Refreshing section. AI: Maciej: Try to find Justin's old recommendations for the Permission Ticket Management section. Attendees As of 13 Oct 2015, quorum is 7 of 13. (François, Domenico, Sal, Thomas, Andi, Mary, Robert, Maciej, Eve, Sourav, Lisa, Arlene, Mike) Eve Andi Arlene Thomas Domenico Mike Maciej Non-voting participants: James Adrian Harvey Nusz - attended IIW 21 last week - IAM and now privacy Sarah Andrew J Katie George John W Jin Guests: Joni Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Agenda for UMA telecon 2015-11-04
by Eve Maler 04 Nov '15

04 Nov '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05> Date and Time Thu Nov 5, 9-10am 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 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> Agenda Public Review closure and approving Draft Recommendations for progression to LC for approval to start the KI All Member Ballot process Independent Submission stance: any news/changes? Permission registration extension spec review How are we doing on other outstanding AIs? AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Fwd: [OAUTH-WG] Announcing new Identity Events Discussion List (id-event)
by Justin Richer 03 Nov '15

03 Nov '15

Apologies for cross-posting to multiple lists. A new mailing list is spinning up to discuss a potential abstraction that could include the “auditable transaction receipt” and “consent receipt” concepts in its milieu. This would be covering the technical aspects of the receipt construct, as well as potentially the delivery and notification aspects of these kinds of objects. If you’re interested in that conversation, please join the list. — Justin > Begin forwarded message: > > From: Phil Hunt <phil.hunt(a)oracle.com> > Subject: [OAUTH-WG] Announcing new Identity Events Discussion List (id-event) > Date: November 3, 2015 at 3:13:33 PM GMT+9 > To: SCIM WG <scim(a)ietf.org>, "<oauth(a)ietf.org>" <oauth(a)ietf.org> > Cc: <id-event(a)ietf.org> > > At IETF94, a number of us got together to discuss the emerging event work that is emerging in the Identity space: > > * OIDF RISC > * OIDC Logout > * SCIM Notify Events > * OAuth Token Revocations > * Consent Events > > The Id-Event discussion list is intended to begin discussion around developing new IDs (and potentially form a WG) for the purpose of defining a JWT message format for Identity Events and to define a possible approach for distribution. > > The list was formed after several participants noticed common event requirements that have emerged from SCIM provisioning, OIDC (eg. Logout), RISC Events (e.g. account suspension, reset, take-over), as well as OAuth2 (e.g. token revocations), and consent notification (e.g. consent from a distributes OAuth/UMA system). > > At this time, the process and route to standardization for identity events has not been determined. I expect that to be one of the discussions we will have on the list. > > The web page for the mailing list is: > > https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event> > > Regards, > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/>phil.hunt(a)oracle.com <mailto:phil.hunt@oracle.com> > _______________________________________________ > OAuth mailing list > OAuth(a)ietf.org > https://www.ietf.org/mailman/listinfo/oauth

1 0

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

Reminder: V1.0.1 45-day public review ends tomorrow (and some follow-on odds and ends)
by Eve Maler 01 Nov '15

01 Nov '15

As you should be well aware by now, WG members have special responsibilities when it comes to public review, IPR, how to report comments, etc. Details are here: http://kantarainitiative.org/pipermail/lc/2015-September/002762.html In preparation for next week’s meeting (VOTERS PLEASE ATTEND so we can make quorum), I’ve begun cleaning up minor editorial issues in the specs. See the seven commits made on Oct 28: https://github.com/KantaraInitiative/wg-uma/commits/master If you’ve been hanging onto additional clearly editorial issues (typos and such), please do report those ASAP, any way you like (even emailing me is fine). I’ve been considering issue #229 as an editorial clarification issue, since the truth of RPT-to-ticket relationship just is what it is. If I don’t hear from anyone else by public review close time, I’ll change the wording to “any RPT”: https://github.com/KantaraInitiative/wg-uma/issues/229 Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

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 30 Oct '15

30 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