March 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

Draft minutes of UMA telecon 2016-03-31
by Eve Maler 31 Mar '16

31 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-31 MinutesRoll call Quorum was reached. AI: Eve: Check the rolls and reach out to Ran at a minimum. Approve minutes tbs Publication of new spec The extension spec is here <https://docs.kantarainitiative.org/uma/draft-uma-claims-sec-ext-v1_0.html> (versioned) and here <https://docs.kantarainitiative.org/uma/draft-uma-claims-sec-ext.html> (symbolic link to "latest draft"). Wide ecosystem analyses and solution proposals Let's try and analyze the problem space thoroughly enough to collect solutions and match them all up. Eve presented a new document, UMA wide ecosystem challenge analysis <https://docs.google.com/document/d/1lJXDFzlq8j-m0f8mELjqYcX6PPcYSjOuxiGHzwU…>, that walks through thoughts on how trust elevation will likely be done in narrow, medium, and wide ecosystems and what the practical challenges are with the latter. We looked at Domenico's excellent diagram (produced in 2011!). We worked on "trusted claims" a lot in the past; it falls in an area that could be broader than UMA's scope, meaning that others might find it interesting to work on and use as well, so we had put it aside. The diagram shows, roughly, a kind of "UMA-protected requesting party claims" picture. Mike observes that having the "OpenID Connect AS" entity request a token from the "resource owner's AS" might be another solution. Adrian asks: Is a certificate helpful for solving this problem? A policy condition could require Bob to authenticate strongly in a certificate-based way. We're not sure this particular type of policy is relevant to the wide ecosystem question. Mike notes: "Not to be overly negative... but the wide ecosystem use case is really a long shot for adoption. Its really hard to get network economies of scale." Adrian has previously talked about how an AS could usefully accept federated logins by its ROs from an RS. The medium ecosystem diagram shows a similar example, only on the client side – the AS accepts federated logins from the identity ecosystem of the service that the client participates in. Justin describes FHIR as a common/universal API that should be heading to universal acceptability, and thus ultimately totally open acceptability for, say, every conforming client. The current world is more like static onboarding, a la Microsoft HealthVault <https://account.healthvault.com/us/en-US/Directory> with its ~400 clients. Adrian says the Mass. Medical Society is looking at such a thing, but there's no evidence of any move to support the wide ecosystem approach yet, despite a strong wish by some for this type of disintermediation. The example of a Volvo app that unlocks the engine shows that you may also want to grant access to a friend or family member. This is a valet key for real. [image: (smile)] Attendees As of 20 Feb 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah, Ran) 1. Domenico 2. Kathleen 3. Andi 4. Maciej 5. Eve 6. Mike 7. Sarah Non-voting participants: - Mary - Jin - Mark - Adrian - James - Scott - Justin Regrets: - Sal - Robert *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-03-31
by Eve Maler 31 Mar '16

31 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-31 Date and Time - *Thu Mar 31,* 9-10am PT (*N.B.:* SUMMERTIME SKEW IS REALLY OVER THIS TIME) - 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 - Publication of new spec - Approve minutes of UMA telecon 2016-03-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24> - Wide ecosystem analyses and solution proposals - Roadmap checkin - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Oauth2 to UMA material
by Arlene Mordeno 28 Mar '16

28 Mar '16

Hello, Would anyone have any material on how an enterprise can transition from using Oauth into UMA, say a year from now? I am looking for infrastructure considerations when doing an enterprise IAM strategy. Thanks, Arlene

3 3

Notes from UMA legal telecon 2016-03-25
by Eve Maler 26 Mar '16

26 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-03-25 - Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review Attending: Eve, Paul, Kathleen, Adrian, Jon N, Ann, Jim We reviewed our model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> with model definitions <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/…>, with recent changes. What's the deal with the "D word" – delegation? If we qualify "delegation of *what*", then we can observe that there are several types, and we can map them to different trust relationships we have identified: - Resource Subject - Grantor (not in scope): This enables a "resource owner" to find someone else to actively manage resource access for them at an AS. - Grantor - ASO: This enables an always-on AS to be available to execute the wishes (policy conditions) of the Grantor. - RqP - Client Operator (not in scope; also not previously discussed as a model definition...) - Grantor - RqP Discussion about Grantor - RqP: Adrian doesn't think this is an appropriate use of the word "delegation". Eve believes "that train has sailed". [image: (smile)] See, e.g., the NZ POC <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Man…> . Regarding Adrian likes the distinction of "If you have a privacy policy, then there's an Operator involved; if you don't have a privacy policy, then you own it/wrote it." (It's personal to you and there's a 1:1 relationship between you and the software/service.) We have a new party with responsibilities now in scope! It's the Client Operator. Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases. Which trust relationship should we dig into first? For reasons of our #RSctrl/#ROctrl use case <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> tension, and because it's the most "upstream" (no dependencies) trust relationship, let's start from RSO - ASO (see the clauses that start ASO... here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> and the clause that starts with RSO here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> – however, these are old and almost certainly don't reflect our latest discussion). There's a use case that could help us interestingly when we get to working on Resource Subject- and Grantor-involved model clauses, but will need to take into account some out-of-band machinations because it engages precisely the Resource Subject - Grantor relationship: a "digital death" use case. Alice (as her own Grantor) shares some digital data resources with Bob. She wants to arrange for her lawyer to become her Grantor when she dies, so that Bob can continue to get access to those resources. In practice, because of what are known (really) as "time-to-live" strategies around credentials, tokens, and permissions inside tokens, the access that Bob enjoys to those resources is certain to get cut off at some point after Alice dies. Using a combination of business, legal, and (non-UMA – including digital contract) technical approaches, Alice's lawyer can replace Alice as the owner of those resources and ensure through the AS that Bob's access can continue or be restarted. *AI:* Jim and Eve: Extract the two-party reworkings of the old model clauses for at least RSO - ASO and prepare for group review next week. *AI:* Everyone: Think about and approach candidate external reviewers by next week. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 2

Agenda for UMA legal telecon 2016-03-25
by Eve Maler 24 Mar '16

24 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-03-25 - Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Draft minutes of UMA telecon 2016-03-24
by Eve Maler 24 Mar '16

24 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-03-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17>: APPROVED. Issue 239 materials We agreed to remove "as the sole means of trust elevation" because SHOULD is the operative instruction regardless. Discussion of the new security considerations: We're not allowing both endpoints because it's a big mess to have to deal with "old" clients along with "new" clients. You'd have to flag clients in some fashion. So this section is something of a rationale for the endpoint swap. Eve suggested a slight wording change to give it this flavor. *MOTION:* Moved by Sarah. Seconded by Sal: Approve the "UMA Claims-Gathering Extension for Enhanced Security" specification, as to be amended, as a draft Technical Specification. APPROVED by unanimous consent. *AI:* Maciej and Eve (with Oliver): Publish the new extension spec. What to do with "progressing" this spec? Let's let it lie for now, and think about changes in "batch" with other 2016 roadmap work on the other specs. What sort of publicity should we do around this? Mention on wiki, on FB, etc. Talk about it at an UMA Update session at IIW? *AI:* Eve: Create an issue for the next minor rev of UMA (if there is one) to point back to the extension spec in some fashion and either deprecate it or absorb it, whatever is appropriate. Wide ecosystem We reviewed some previously discussed topics about wide ecosystem challenges. What value does the AAT bring? Based on current implementation and usage, it seems valuable for at least narrow and medium ecosystems, but in Justin's experimental work for wide ecosystem purposes he has done away with it entirely. Does a wide ecosystem actually require removing it if it turns out to be valuable for others? Sal points out that some IoT use cases also bring in special circumstances such as disconnection from the network. *AI:* Eve: Send wide ecosystem doc and graphics. Attendees As of 20 Feb 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah, Ran) 1. Domenico 2. Kathleen 3. Sal 4. Thomas 5. Maciej 6. Eve 7. Mike 8. Sarah Non-voting participants: - Adrian - Justin - Arlene - Jin - John *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

What should the parallel requesting party claims endpoint in the extension spec be called in the config data?
by Eve Maler 24 Mar '16

24 Mar '16

Recall that we're likely to supplant the original endpoint (called requesting_party_claims_endpoint) with the enhanced-security one at the first opportunity, i.e. when we "open up" UMA Core for backwards-incompatible changes. Should we pick a name that's just descriptive for now like security_enhanced_claims_endpoint (what's in the current draft) and align to the original name when we open up the spec? Should we pick a wholly new name now and switch to that for "backwards compatibility" with what people are likely to be using in their implementations? If the latter, what should that name be? Please see today's meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17> for some suggestions and discussion. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Fwd: Diagram
by Maciej Machulak 24 Mar '16

24 Mar '16

---------- Forwarded message --------- From: Maciej Machulak <maciej.machulak(a)gmail.com> Date: Thu, 18 Feb 2016 18:55 Subject: Diagram To: Eve Maler <eve(a)xmlgrrl.com> [image: Inline images 1] -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) -- Maciej Machulak (sent from mobile)

1 0

Please review the extension spec and non-normative doc before tomorrow's WG call
by Eve Maler 24 Mar '16

24 Mar '16

Hi folks-- Please review the current review drafts (these are also linked in our agenda <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-24> ): - Spec <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/b…> - Doc <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Sessi…> We know there are a few editorial tweaks that need to be made to the spec, so please make sure to review substantive stuff. We'll be looking to do a WG vote on whether this represents a draft Technical Specification (official WG output, not just an editors' draft) that we can publish on docs.ki.org. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1