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

UMA interfaces diagram
by Eve Maler 13 Oct '15

13 Oct '15

I’ve been working on a diagram that tries to describe how an UMA AS is also an OAuth AS and RS underneath, etc. This has been percolating in my brain for possibly YEARS. Please let me know if it’s useful, and if it could be improved. I often find myself having to point out that an UMA RS "acts in the role of an OAuth client” when it uses a PAT at the UMA AS, but this finally explains the rest of the story… :-) Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 6

REVIEW NOTICE: UMA Draft Specification Document and IPR Review
by Joni Brennan 07 Oct '15

07 Oct '15

Dear Kantara Initiative Members and Community: This is a formal notification that the UMA Work Group has approved the following documents as Working Group Draft Specifications for public comment and IPR Review: Title of Documents (click the titles to view the documents): - User-Managed Access (UMA) Profile of OAuth 2.0 V1.0.1 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html> - OAuth 2.0 Resource Set Registration V1.0.1 <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html> In accordance with the Katnara Initiative Operating Procedures, this email initiates a review and comment period of 45 days on these documents. Comment and IPR Review: - Opens: Today, Friday, 18 September 2015 - Closes: Monday, 2 November 2015, 23:59 Pacific Time To comment on these Draft Recommendations use one of the following options for participation: 1. Use the comment form: http://contact.kantarainitiative.org/comment/ 2. Send your comment via email to support @ kantarainitiative.org with the subject “UMA WG COMMENT SUBMISSION" NOTE: We are aware of the formatting issue resulting in some space characters showing up as question marks. We will solve this problem before final publication. IPR NOTICE: UMA WG Participants <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> are required to make claims to IPR regarding these technical documents. If you are not an UMA WG Participant you have no IPR licensing obligation to any of these documents. If you wish to submit an IPR claim please do the following: 1. IPR Claims may be sent to support @ kantarainitiative.org with the subject “UMA WG IPR CLAIM” Happy reviewing and best regards, Joni Brennan Kantara Initiative | Executive Director email: joni @ kantarainitiative.org Connecting Identity for a more trustworthy Internet - Overview <http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>

1 1

No WG meeting on Oct 1 or Oct 8
by Eve Maler 06 Oct '15

06 Oct '15

Hi folks— A few people have indicated they need a little more time to work on UIG action items, and we don’t have a lot of other really urgent business until the Public Review period end gets closer. (And I have conflicts. :-) If those with AIs can please work on them in the meantime, and if everyone (particularly voting participants) can also please be sure to mark your calendars for the Oct 22 and Nov 5 meetings so that we can make quorum to discuss Public Review comments and approve changes for the Draft Recommendations, I think we’ll be fine not meeting for the next two weeks. Let’s keep up with our legal subgroup meetings, though. And let’s hold the next APAC sync, which is scheduled for Oct 15. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

Recommendation from leadership team re IETF I-D situation
by Eve Maler 05 Oct '15

05 Oct '15

Since our previous WG discussion on this was inconclusive, Thomas, Maciej, and I discussed the question of whether we should let our current IETF Internet-Drafts expire without update vs. revise them preparatory to our original Informational RFC submission plan. Our consensus was to let them expire. https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 (exp Oct 6) https://tools.ietf.org/html/draft-hardjono-oauth-umacore-13 (exp Oct 6) https://tools.ietf.org/html/draft-maler-oauth-umatrust-03 (exp Oct 7) Rationales: Contributions there hadn’t stimulated any feedback or activity coming from the IETF quarter, and there is benefit in having a single canonical version of the specs to refer to. We found diminishing appetite to approach other forums. We’re due to consider a revision of our charter anyway, so let’s look at aligning it with the new plan in our Oct 22 call (assuming quorum), unless anyone would like to make a case for keeping the current plan (or some other third option). If you have questions or concerns, please float them in this thread. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 5

Notes from UMA legal subgroup telecon 2015-09-25
by Eve Maler 30 Sep '15

30 Sep '15

Fri Sep 25 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> Examine/confirm top meta-use cases RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved Discuss/prioritize business models Organizational consumer-facing access federation Industry access federation Free-love access federation Other Determine roughly what our outputs should look like Develop a list of unknowns without which we can’t finish our work Attending: Eve, Jon, Adrian, Jim, Thomas, Domenico, Dazza, Ann Meta-use cases: 1. RS-AS: RS is concerned about outsourcing protection functions to AS. 2. RO-RqP: RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved. Are these the top pairwise relationships to be concerned about? Adrian is concerned about the case where the technology that is executing the RO’s instructions is sovereign — that is, RO=AS. The analogy with SSO/authentication-as-a-service breaks down when we get to this point, because authentication is a kind of reputation service, authenticating the RO’s identity. It has to be a third party. By contrast, the AS can be wholly "first-party”. Should we add a third item about this? Yes: 3. RO-AS: RO is concerned that the AS fully represent her, and thus seeks to be able to build (vs. run or outsource) an AS so that it will never need to "have a privacy policy” because it’s hers. Business models: 1. Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS. 2. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.). 3. Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in. The reason it’s “BLT” is not just because, Bacon!!!, but because business comes first! The draft NIST Privacy Risk Management Framework notes, very sensibly, that you must start with a business goal. What business model do the HIEs of today represent? Are they focused on a single provider? They’re vertical-specific, regional, and voluntary on the part of the RS (hospital). They struggle mightily to get adoption and achieve a sustainability model. Under HIPAA, they decided to extend HIPAA to treat data aggregators (an HIE is one) as a business associate. This gives flexibility. There are about 80 HIEs around the country, and only NY (as far as we know) has enabled patient access. It’s the province of big hospitals. The HIE only stores identity information for patient matching. Data is exchanged through Direct messaging. An HIE registers encounters, and it manages consent. Eve suspects that HIEs anomalously reflect today’s US HIPAA regulations, and we’re building something specifically patient-centric. Further, that they are a special case of an industry access federation because they are exposing heterogeneous services. We explored the industry access federation example a bit more by looking at SmartHomeDB <http://www.smarthomedb.com/>. #1 means you’re “on the plantation”. #2 means the data never even enters the plantation; it stays in its native environment, the way data can stay on a phone. We agreed to focus first and foremost on #2 because it meets important UMA goals, requires legal support, and appears to be the critical model required for the IoT. What should our outputs be? Should we be developing sample pairwise agreements at the “client credentials issuance” stage because the terms and conditions at that stage are so important? There’s a B2B stage, and a B2C stage. The opportunity to issue those credentials always seems to come with a “gate” that has business agreements associated with it. AI: Dazza, with Eve as backup: Bring a source of contract terms for getting OAuth client credentials. AI: Jon: Bring preliminary thoughts on IoT liability tensions. AI: Jim: Pose an answer to the question “ What would a sane, brilliant, non-powerless consumer, with some bargaining power (or friends at the EFF and Justice Department) expect from an agreement?” AI: Dazza: Create a “business models page” on the wiki, numbering the business models. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 4

Some examples of terms of service for getting "social" OAuth client credentials [legal]
by Eve Maler 30 Sep '15

30 Sep '15

I started collecting a few of these here: https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Ter… Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

4 6

UMA for our VRM Robots
by Adrian Gropper 26 Sep '15

26 Sep '15

Apologies for cross-posting an article that could be a seed for discussion at IIW. (Apologies too, for having lost the source that pointed out this article to me.) http://idlewords.com/talks/what_happens_next_will_amaze_you.htm The UMA Authorization Server (or something very much like it) will be the link between our Vendors and our Things. The AS protocols and practices will become the essence of our robot's operation and enable VRM. Whether the robot belongs to me or to Them is central to "what happens next". See you at IIW. Adrian -- 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

Project Brandeis and Human-Data Interaction [legal]
by Eve Maler 25 Sep '15

25 Sep '15

I had an opportunity to have a very wide-ranging chat with David Bray, CIO of the FCC, yesterday, about data sharing, the IoT, UMA, and more. He subsequently pointed me to some resources about DARPA’s Project Brandeis, about which I’d heard, but I hadn’t really delved into it very far. It’s a new research project to come up with technology solutions for privacy related to (simplifying a bit) big data: http://www.darpa.mil/program/brandeis https://www.fbo.gov/index?s=opportunity&mode=form&id=806e298e3bda3a09fd13d4… https://defensesystems.com/articles/2015/08/25/darpa-sri-brandeis-data-priv… These led me to something called Human-Data Interaction: http://hdiresearch.org/ http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2508051 The paper will sound familiar to a lot of us who have been around VRM, PDS’s, and such for a long time. It’s good stuff, but not entirely new. In fact, they introduce a term, “data statement”, that sounds pretty close to consent receipts. :-) I put the [legal] tag on this note specifically because the paper has three themes — legibility, agency, and negotiability — that may *possibly* speak to our work. In any case, I thought I’d draw the attention of all of the “BL&T" participants to this stuff. Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Next steps [legal]: Homing in on concrete "business models" and deliverables
by Eve Maler 25 Sep '15

25 Sep '15

This is the message I promised legal subgroup folks last week, after gathering feedback from a few folks. I heard a couple of themes: Appetite to cut to the chase and discuss actual "business models” and concrete legal constructs (e.g., finally discussing licensing) Agnosticism about how we capture and store our results and deliverables (GitHub, Confluence, Word, whatever) These both make a lot of sense to me, particularly in the context of our tightening timeline. There’s always a danger of Zeno’s Paradox of Standards-Making: Before you can get halfway done, you have to get halfway to that intermediate point, and halfway to that second point, and so on, such that you can never finish. :-) So here are the tasks I recommend we undertake. 1. The meta-use cases — liability tensions, if you will — of most interest have been staring us in the face the whole time (they’re in our mission statement), and I suggest we focus on these two meta-use cases exclusively for the 2015 period: RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved If anyone has others they would like to make a case for, we can put them on the list and discuss (briefly) whether reprioritizing makes sense. 2. “Business model” is a term that I heard in the conversations. It’s in quotes because I don’t want to scare away anyone who would prefer to think of this in more Alice-friendly terms; it simply means is the nature of the ecosystem where the parties interact (I sometimes call this a “deployment ecosystem” or a “topology"). We need to prioritize the business models for which our subgroup needs to create outputs. Here are a few to consider, going from simpler/smaller to more complex/larger: Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS. Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.). Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in. If you have others in mind, or want to adjust these, great. 3. We need to determine roughly what our outputs should look like, so we know what we’re driving towards. Is it model clauses? Something different/more? Let’s just get an idea. 4. If we think about the two meta-use cases in light of each of the business models of interest, and in light of what we’re supposed to deliver, no doubt the experts in the room will notice all the things we’re missing! We need to develop a list of unknowns without which we can’t finish our work. I’m hearing that this could be anything from jurisdiction to “policy” (not authorization policy, something else? policy framework?) to use case specifics to whether we’re using a licensing model vs. a contract model! Please let me know what you think of this approach, on the list or separately. I’ll send an agenda with dial-in details as usual; the above may take us two meetings’ worth of time to go through…but maybe not, if we’re focused and try to do some homework ahead of time. Thanks! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 4

Reminder: UMA legal subgroup telecon 2015-09-25
by Eve Maler 24 Sep '15

24 Sep '15

Fri Sep 25 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> Examine/confirm top meta-use cases RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved Discuss/prioritize business models Organizational consumer-facing access federation Industry access federation Free-love access federation Other Determine roughly what our outputs should look like Develop a list of unknowns without which we can’t finish our work (Email troubles — sorry for the delayed agenda!) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0