May 2016 - WG-UMA - mailman.kantarainitiative.org

Documenting UMA publication workflows
by Eve Maler 18 Jul '16

18 Jul '16

Hi folks-- Hope you are enjoying post-Christmas reentry or more holiday time, or whatever the case may be. Maciej and I are working on publishing the new Recommendations, and due to that, I unearthed the permanent/symbolic link information that I promised to Justin; we thought it would be a good idea to document the processes here -- and in the GitHub readme... It seems to work pretty well for now given that there isn't that much to the entire publishing process for our WG or others, but if you see ways to improve it for the future, let us know. After completing a draft spec revision cycle and getting it approved: 1. Edit the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources to change from Status #3 to #4 (see below), leaving the previous date in place. 2. Run the stylesheet over the XML sources to produce .html outputs, review the results as required, sync GitHub, and upload the last drafts by FTP (Eve and Oliver can do this). 3. Save the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with rec- instead. 4. Change the Status section of the new files from #4 to #5, the date, and any other metadata (some of this has to be done in the stylesheet, which is in the repo). 5. Update the two specs' References links to each other in the Reference section. 6. Run the stylesheet over the XML sources to produce HTML output with .html extensions, review the results as required, sync to GitHub, and FTP the HTML results to the website (Eve and Oliver can do this). 7. Get symbolic links created (see below) from the versioned rec- HTML links to generic links (Oliver can do this). After launching a new draft spec revision cycle: 1. Save the rec-uma-core-vn_n[_n] and rec-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with draft- and having the agreed new version numbers instead. 2. Edit the Status section from #5 to #1. 3. Proceed to edit the new drafts, and periodically produce HTML results that can be uploaded through FTP. 4. Get symbolic links created from the versioned draft- HTML links to generic links (Oliver can do this). Here are the stages of the Status section (embed links throughout as appropriate): 1. This document is a draft technical specification produced by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 2. This document is a Kantara Initiative Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 3. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. 4. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. The Ballot having passed, this document has been superseded by the Recommendation version of the document. 5. This document was developed by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and approved by the Membership of the Kantara Initiative <http://kantarainitiative.org/> as a Recommendation. Here is how the symbolic links work: https://docs.kantarainitiative.org/uma/rec-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-vn_n[_n].html - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-vn_n[_n].ht… - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/rec-uma-core.html - Symbolic link to latest Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html - Symbolic link to latest RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core.html - Symbolic link to latest Core draft https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html - Symbolic link to latest RSR draft *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Agenda for UMA telecon 2016-06-02
by Eve Maler 31 May '16

31 May '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02 Date and Time - *Thu Jun 2,* 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 - *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 Agenda - Roll call - Approve minutes of UMA telecon 2016-05-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-26> - MPD - Review sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and focus on the last bit, going more slowly through the flows this time - Any last-minute CIS plans/news - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Self Introduction
by Mohammad Chowdhury 29 May '16

29 May '16

Dear All, First of all, thank for allowing me to the group. I really appreciate Eve for her welcome note. I am Jabed, currently a PhD student at Swinburne University of Technology, Melbourne, Australia. My research interests are information security, Internet of things and cyber forensic. While I was working with my Phd research problem related to user based cross domain access control, I found Maciej's phd thesis. From his work, I learned about this working group. Our university research group is specialized in context-aware and adaptive computing. I am planning to extend UMA for context-awareness, specially for ubiquitous environment (pervasive and IoT enable). I am also interested to examine the privacy part of it. I have read about UMA from different available online documents. I have also downloaded and configured OpenUMA( from ForgeRock) to gain hands on experience. I am still learning about it. I hope to learn a lot from this group. I am also hopeful that I will get Eve and Maciej's expert guidance/feedback from time to time. Looking forward to collaborate. Best regards, Jabed

2 1

Slack team
by Eve Maler 27 May '16

27 May '16

James P has offered to create a Slack team for our WG for better between-meeting communication and work. Thanks, James! (The UMA Dev WG is planning to do the same thing.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Notes from UMA legal telecon 2016-05-27
by Eve Maler 27 May '16

27 May '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-05-27 - Review Digital Contracts event - DG - CommonAccord directions - Legal POC appetite - ... - IDE directions - Model definitions: next steps Attending: Eve, John W, Adrian, Ann, Jon N (Andrew regrets) Adrian is on the FHIR group, along with Kathleen. The conversation at that table around "policies on the wire" is very live there. The motivation to source policies from multiple places in the FHIR conversation seems to be internal to a single domain. Given our capturing of notes last week, we'd like to write a short document for a nontechnical, legally inclined, even regulatorily inclined audience. John has stuck his hand up to outline such a doc, and he and Eve can review the results together at Privacy@Scale <http://privacyatscale.com/> (run by FB) next Tuesday. (Microsoft is running a similar event the next day(s), NIST is running a Named Data Networking <http://www.nist.gov/itl/antd/named-data-networking.cfm> event on May 31-Jun 1, and there's a Health Privacy Summit <https://patientprivacyrights.org/2016-health-privacy-summit/> at Georgetown Law June 7-8, and it will be streamed.) Looking at it from a business/strategic point of view, the benefits are privacy-preserving because no authorization/permission policy transmission is needed, and the AS is not a data controller, and individual/patient/consumer/citizen-centric because the AS exists to enable that party's wishes (their "agent" in some fashion). Looking at it from a legal point of view, we are working on a system of model text to protect the interests of all the parties engaging with each other. (As we said last week, if an institution running that domain wants to federate policies in some fashion a la the methods that XACML <https://en.wikipedia.org/wiki/XACML> makes available, they're free to, behind the "UMA façade" of the standardized APIs of AS. If it turns out to be valuable to develop a companion technical paper that answers questions that technical people have about the architecture that supports our contentions, we could write that afterwards.) It seems like we really need a proper use case document now too, identifying why and how the parties might be equivalent or not equivalent (note that in UC4, "offlice Alice/gov agency", the Grantor happens to be the ASO, but in UC1-3, it's not). We need more use cases showing how the Grantor could equal the Grantee, the Grantee could not equal the human end user that is acting on behalf of the Grantee (like Dr. Bob working for the hospital that wants access), etc. Once we have a full, non-repeating set of use cases, we'll know we're close to being done with the model term definitions. [image: (smile)] Eve's interested to coauthor; John W's tentatively interested to coauthor; Jon N's interested to review. There's a new Kantara Blockchain and Smart Contracts Discussion Group <http://kantarainitiative.org/confluence/display/BSC/Home> – feel free to join! Note that the actual original EU Model Clauses are under threat <http://www.blplaw.com/expert-legal-insights/articles/model-clauses-under-th…>. But we seem to be happy with the lowercase phrase for our work, still. We should have a CHEDDAR rundown on a future call. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA Legal telecon 2016-05-27
by Eve Maler 26 May '16

26 May '16

We will continue the threads begun last week. Please forgive the lack of a formal agenda, and see the link below for all details: http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Draft minutes of UMA telecon 2016-05-26
by Eve Maler 26 May '16

26 May '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-26 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecons 2016-04-14 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-04-14> and 2016-05-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-19>: So approved. Review of MPD We're looking at the swimlane. The first batch of changes in MPD is around discovery. These are backwards-incompatible, but not particularly invasive. Justin and Sarah note that the discovery document (currently known as AS configuration data) is relevant to both the RS and the client, and thus it isn't specific to what UMA calls Phase 1. The alignment done here is to OIDC; OAuth is undergoing its own alignment to OIDC as well. Do we want to align with the other specs in terms of terminology: discovery document vs. configuration data? We have consensus to do this. Justin suggests an editorial comment in the spec commenting that it's a good idea to use an interactive grant flow when, as is typically the case, an individual end-user is a resource owner. This gives the developer the clearest guidance as to which grant to choose. This would be paired with stronger normative text that identifies the RS as an OAuth client. The editorial comment could then also briefly mention the converse case of an organization ("legal person") using the client credentials grant (and point off to the UIG if warranted). If there's a discovery document at .well-known, is it ever a good idea to rely on discovery some other way? Should we make discovery by that means optional? We're covered on this by saying "as needed" already. The UMA client now needs client credentials, not because it needs an AAT (one of the reasons before), but because it would need it for the exact role that an OAuth client would normally need it – and now, Bob the RqP would be the end-user who is using that client at the AS (specifically, the *token*endpoint that the AS already has, and has had all this time, along with a newly conceived *claims* endpoint). The loop in the swimlane involves trading a ticket for a token – repeatedly, until success. This is very analogous to an authorization code flow. Per OAuth, OIDC, and our recent security work, tickets are now one-time-use only. Note that the "claims" process treats what was previously a separate flow – step-up authentication – as subsumed into the same flow. It's possible for the client to send claims directly to the token endpoint directly. One question to discuss on the next call: Is there an in-band mechanism by which the RqP can authorize that flow? The claims endpoint can be treated as a "dispatch" endpoint. Swimlane tasks: - We should take out the Phase 1 label from the swimlane. Spec tasks: - Align the terminology and syntax of the discovery document format. - Insert the editorial comment about which grants are appropriate and normative text about the RS being an OAuth client. (Also consider a figure about the protection API being protected by OAuth.) - Implement the change for issue #155. - Where the protocol flow currently casually uses declarative text, switch to using normative RFC 2119 text. Attendees As of 15 Apr 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Nagesh 3. Andi 4. Robert 5. Eve 6. Mike 7. Sarah Non-voting participants: - Justin - Adrian - Colin - Jin - John - James Regrets: - Maciej - Sal? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-05-26
by Eve Maler 25 May '16

25 May '16

Date and Time - *Thu May 26,* 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 - *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 Agenda - Roll call - Approve minutes of UMA telecons 2016-04-14 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-04-14> and 2016-05-19 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-19> - MPD - Review new sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> - Discuss affordances and implications - Discuss - News from Digital Contracts event - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-05-19
by Eve Maler 19 May '16

19 May '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-19 MinutesRoll call Quorum was reached. Approve minutes tbs CIS prep Don't forget about Cloud Identity Summit <https://www.cloudidentitysummit.com/en/index.html>. It's not too late to register (contact Andi Hindle for assistance, wink wink). There's a Kantara Summit, an UMA talk, an UMA MasterClass, a HEART talk, and a privacy track, all relevant to what we do here. (And: BLOCKCHAIN!!!!) Eve, Colin, Andi, George, Maciej, Sarah, Justin, and Ishan are all attending – and speaking. Nagesh *may* attend. Meeting schedule Let's put next week's meeting back on the calendar. Huzzah. We'll have a good long stretch of meetings through June and July. Any huge absences? Please let Eve know. IIW and EIC recaps At IIW, beyond the "MPD" discussion: - Adrian convened a session where we discussed blockchain/smart contract implications for UMA. Think "escrow" where payment for access to a resource could be worked out, or proving certain elements of identity in a wide ecosystem. - Eve created a diagram describing different kinds of delegation: RO-to-AS (as an "agent" for executing to Alice's wishes), RO-to-RqP (delegating access to resources), and Resource Subject-to-Grantor (offline wrt the protocol, but an important business/legal relationship). - Adrian brought up ten kinds of "self-sovereign technology", different from self-sovereign identity". Think about a "personal" type of UMA authorization service. Contact Adrian for more information. At EIC: - Eve gave a keynote <https://www.kuppingercole.com/watch/eic16_keynote_maler> that centered on UMA (and a HEART use case). Lots of discussion. - Ian gave a keynote where he called for an identity p - rofessional association; Kantara put up a pledge signup site <https://kantarainitiative.org/digital_identity_professional/>! Justin's change proposals For reference: The wide ecosystem challenge analysis <https://docs.google.com/document/d/1lJXDFzlq8j-m0f8mELjqYcX6PPcYSjOuxiGHzwU…> document. The challenges came from two sources: the identity protocols used to convey identity/claims require pre-established trust, and UMA itself requires a pre-established AAT. Justin's proposals eliminate the AAT (much as a very old version of UMA had only two tokens) and do a bunch of other cleanup, which tackles not only #wideeco but also #simplify. We walked through the bullets in Justin's original email. *Changes include:* *- Removal of the RPT endpoint, in favor of using the token endpoint and a new grant type (#153)* *- Removal of the AAT (#154)* *- Removal of extraneous bits of the resource set registration URL pattern (#155)* *- Alignment of the discovery document with OIDC discovery (#157)* *- Removal of “version” field in discovery document, instead document is published under new .well-known URL pattern (#159)* *- Change use of “scopes” name in responses to something more explicit (#158)* *- Ability of client to specify scopes in token request (#165)* *- Addition of the claims-gathering URL to the need_info response, removal of “redirect_user” as redundant in this case (#167)* *- Simplification of the “need_info” response structure, removal of extraneous object layers (#237)* *- Rotation of ticket values on all requests to token endpoint or claims endpoint to mitigate session fixation and related attacks (#239, #205)* Discussion about "Ability of client to specify scopes in token request": In UMA V1.x, the flow is client-to-RS-first. The client is entirely "dumb" with respect to what scopes are available, and can only attempt access using one scope at a time, and the RS is entirely in control about how many scopes to register: one (stingy), or more than one (generous). Sarah suggests that Justin's motivation is privacy preservation: The client could essentially do a downscoping by requesting fewer scopes than the RS would have requested. But is this the motivation? Are both motivations relevant (downscoping and upscoping)? Also, does Justin's change enable an additional client-to-AS-first flow or is it still client-to-RS-first alone? If the client approaches the AS, how does the client indicate the specific RO and resource needed – does it need to know the *rsid*? On balance, might there be privacy-destructive aspects if Alice ends up sharing more access? Eve had pointed out at IIW that the asynchronous nature of the RO's control means that the client shouldn't really get to say what scopes it requests anyway. George thinks it's more of a negotiation. And maybe negotiation among RS, C, and RO isn't entirely bad? To be discussed on the legal subgroup call. [image: (smile)] It will be key to have accurate swimlanes and hopefully some spec text to stare at during next week's call. Attendees As of 15 Apr 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Kathleen 3. Nagesh - Accenture and JPMorgan Chase experience in IAM - now at Optiv and working at home with schedule flexibility! 4. Andi 5. Robert 6. Eve 7. Sarah Non-voting participants: - Adrian - John W - Jin - Ishan - George - Colin - Scott Regrets: - Sal - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA legal telecon 2016-05-20
by Eve Maler 18 May '16

18 May '16

Our legal subgroup is another meeting series that's been quiet for a little while -- but we'll meet again on Friday! http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date and Time - *Fridays,* 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 2016-05-20 - Review IIW and EIC discussions – progress around RSO-ASO as an "agent" - Upcoming Digital Contracts conference with opportunity to gather requirements for CommonAccord IDE and feedback on our work - Reality check on model clause process – definitions seem a lot easier, vs. clauses without a "live" agreement to work towards Attending: ... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0