- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2016-01-07
by Eve Maler 07 Jan '16

07 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-07 MinutesRoll call Quorum was reached. Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> MOTION: Andi moves, Thomas seconds: Approve minutes of UMA telecon 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17>. APPROVED by unanimous consent. Briefly review upcoming meeting schedule <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> The Jan 21 WG meeting is canceled. The APAC-friendly fortnightly sync meetings have been rescheduled, starting in the last week of January. The legal subgroup will be discussing tomorrow whether to restart weekly meetings. Recommendation ballot passed! Status of publication of Recommendations and IETF I-Ds: We got *about* 25 Yes votes and no No votes – a healthy response. We're still working on publishing the new Recommendations. Regarding the email about the workflow for creating new Recommendations and drafts, Maciej has a new suggestion: creating new GitHub branches. It's a relatively infrequent step, though, so it may be overkill. He'll write that suggestion up. *AI:* Andi: We should do a Kantara blog post about the new Recommendations and maybe share how many issues were closed, the number of votes, etc. *AI:* Thomas: Create two new I-Ds, changed to Informational, for UMA Core and OAuth RSR, that just have abstract, first intro paragraph, and second paragraph that normatively links to the respective final Kantara Recommendation. Discuss candidate charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts - See notes from UMA telecon 2015-12-17 and list discussions for proposed technical efforts – summarizing: - Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access (health context), wide ecosystems (health context), RO needs to ensure RS respects insufficient authorization data (health context/BLT dimensions) - Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, self-contained token validation (SCTV <https://en.wikipedia.org/wiki/Second_City_Television>!) - Also see issue backlog <https://github.com/KantaraInitiative/wg-uma/issues> - Proposed legal efforts are to be discussed more fully on Friday, but we can review Mike mentions token exchange of an RPT for an OIDC token. How do you bridge a client that has been granted access by an AS all the way to getting access to a UserInfo endpoint? The reason to do this is that the AS is in claims-gathering mode. This is the "wide ecosystem" use case/conundrum. Mike had started to sketch out a design for getting rid of permission tickets, and they may keep both, but he concluded "it's not UMA". :-) Other ideas that have come up in the consent receipt world: Extension endpoint for ingesting consent receipts (nicknamed "Shoebox" by Andrew Hughes). Adrian has advocated for an AS to add this type of endpoint. (It doesn't exist yet.) An exploration of UMA wrt blockchain could be worthwhile, for those who have an interest. (An early exploration happened here.) OTOH, it could be a distraction if we're not careful. Thomas points to this provenance-tracking work <https://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provena…> that he did with Jim H. This is a novel use of UMA combined with agreements and blockchain: UMA-protected agreement deltas that can then be put on the chain, which are thus nonrepudiable, and available for public inspection and third-party auditing (and mediation?) in case of dispute long after the negotiation stage (this is where chain vs. digital signatures are a win). AI: Eve: Present to the group next week a "matrix" that aligns use cases we've identified to date with technical "itches", for consideration as 2016 discussion topics for UMA post-V1.0.1 work. Don't tie us down to version numbers yet. We know we'll be working on the BLT spectrum. Attendees As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Domenico 3. Sal 4. Mike 5. Andi 6. Thomas 7. Maciej 8. François Non-voting participants: - Katie - Ishan - Jin - Jim Hazard *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Ideas for an UMA extension for shorter flow
by Mike Schwartz 06 Jan '16

06 Jan '16

Uma-tarians, Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow. We came up with three options: 1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied. 2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token). 3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient. #1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain. #2 has minimal overlap with UMA. #3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket). - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

4 9

Report from the legal "sub-sub-group" / Agenda for UMA legal subgroup telecon 2016-01-08 / request for feedback
by Eve Maler 06 Jan '16

06 Jan '16

*Hello to all our legal eagles!* As you may recall, we wrapped up our 2015 work season with several things: - A walkthrough of some early candidate model text - A promise from me to present a proposed mission statement for a next phase of work - A one-time meeting scheduled for this Friday, January 8, at 8-9am Pacific to discuss Jim Hazard and I kept up a steady pace this holiday season, through thick wifi and thin. :-) We accomplished three things. 1. Tomorrow we should be able to share a *new draft of the model text* that takes into account most or all of the feedback we got in the last meeting for your consideration. We may or may not have time to delve into all of it, however, depending how the following other discussion items go. 2. We hammered out a *high-level set of requirements* to better guide our model text design, as follows, and would like to walk through this and get feedback: - For efficiency, security, and transaction soundness, we want to enable the benefits of DRY [Don’t Repeat Yourself] and reusability as we develop UMA model text - We want the agreement builders of today not to be cut out of the loop in achieving the first requirement - For efficiency, we want to focus our model text efforts on UMA access federation enablement - We want to provide a user-friendly online environment for reusing UMA model text - We want users to be able to incorporate other text they are certain to need in their agreements that also include UMA model text - We want users to be able to choose their own formatting in reusing UMA model text, to the extent practical - We want users to be able to choose their own punctuation, grammar, and language paradigms in reusing our model text, to the extent practical 3. Most importantly, I can present to you a *candidate mission, six-month timeline, and process* that I hope you will feel makes good use of your time and expertise. Please take a look and let me know what you think. I will also be reaching out to you individually. - Retain the UMA legal subgroup as a cohesive subentity of the UMA WG - Next roadmap period to focus on: *January-June 2016* - Next goals to focus on: - Quickly publish the draft model text for external review (target #DPD16, which is January 28?) - Quickly gather requirements for development of the environment for using the model clauses - “Accordioned” until we know the final answer on our available budget - Oversee and “guinea-pig” the environment development work - Propose to continue the subgroup meeting series for this period - Because the right contributors to these activities will largely be SMEs -- those with legal knowledge and experience - Stick with existing time slot or identify new one? - Start outreach to external reviewer candidates immediately ==== 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 - Review proposed mission and timeline - Review high-level requirements - Review latest candidate model text *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2015-01-07
by Eve Maler 05 Jan '16

05 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-07 Date and Time - *Thu Jan 7,* 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 2015-09-24 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-09-24> , UMA telecon 2015-11-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-11-05>, and UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> if quorum - Briefly review upcoming meeting schedule - Recommendation ballot passed! - Status of publication of Recommendations and IETF I-Ds - Discuss candidate <http://kantarainitiative.org/confluence/display/uma/Charter> charter revisions and 2016 roadmap priorities based on proposed technical and legal efforts - See notes from UMA telecon 2015-12-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-12-17> and list discussions for proposed technical efforts – summarizing: - Use cases: IoT, API security (AS-RS tight), federated authorization (AS-RS loose), RS needs to apply mandatory access controls for higher "LOA", RO needs to preserve right of access, wide ecosystems, RO needs to ensure RS respects insufficient authorization data - Technical issues: AAT burden, multi-resource-set permission registration, client-to-AS-first efficiency, validation of self-contained tokens - Also see issue backlog <https://github.com/KantaraInitiative/wg-uma/issues> - Proposed legal efforts are to be discussed more fully on Friday, but we can review - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

APAC-friendly UMA sync meetings
by Eve Maler 05 Jan '16

05 Jan '16

Hi all, and welcome to 2016. :) I have just created a fortnightly event for the new series of "APAC-friendly" UMA sync meetings (starting on Wed Jan 28 US/Europe-side and Thu Jan 29 APAC-side), and added all the same people to the invitation who were on it before. Recognizing that some people who used to live in the APAC region no longer are, and that others who can't attend meetings regularly would like to take advantage of an occasional sync-up, wherever they live, I'm happy to adjust the invitations however you like. Just drop me a private note. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Can Web standards make mobile apps obsolete?
by Adrian Gropper 02 Jan '16

02 Jan '16

http://arstechnica.com/information-technology/2015/12/the-app-ocalypse-can-… It's fascinating to see how this well-done article completely ignores the privacy perspective. Happy New Year Adrian <http://patientprivacyrights.org/donate-2/>

3 4

Happy Holidays and Happy New Year!
by Eve Maler 25 Dec '15

25 Dec '15

A very quick update... Just wanted to let you know that our All-Member Ballot for the V1.0.01 specs passed with 25 Yes votes and no No votes. We required at least 10 votes total, with 8 of them being positive. Great show of support, and great GOTV effort; thanks to you, to Jane and the rest of the Kantara staff, and to the Kantara community at large! Talk to you all on the flip side :-), Eve *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Thoughts on Obligations
by Allan Foster 23 Dec '15

23 Dec '15

Folks, I am concerned about putting specific obligations on the RS and thus subjagating it to the AS. Specifically to allow for Enterprise MAC with UMA participation, where the End user is a participant in the access control decision, but not the only participant. 1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>-Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>: Delegate-Protection* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> and Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> have mutually agreed to serve in these respective roles for each other, theResource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> gains an obligation to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> to delegate protection services to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> for the set of protectable resources for which it represents this capability to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>, and to respect the authorization data that the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> has associated with an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> when the Resource Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> subsequently allows or disallows access by the Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> that presented that RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>. My concern here is that it delegates "Protection services" to the AS, and this feels a little like an all or nothing. This might not be true in the case where the RO is only one party in the Access control decision. 3. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>-Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…>: Respect-Permissions* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> and Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> have mutually agreed to serve in these respective roles for each other, the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> gains an obligation to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> to disallow access by a Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> presenting an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> in all cases where the authorization data associated by the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiati…> is insufficient for the access attempt.. The RS is obligated to dissallow access in the AS cannot provide sufficient rights - in all cases. This has several implications. If the RS has additional business rules whereby a party might get access even tho they are not UMA authorized, (break glass?) (Admin or Help Desk) The RS HAS to determine if a user is a special user BEFORE making the request to the AS. Since once it has an answer, it is obligated to deny. This implies that the RS cannot opt out once the request to the AS is made. It feels a little bit like don't ask don't tell! My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions. Allan -- Simplify Email: Email Charter <http://emailcharter.org/> ForgeRock Logo *Allan Foster - ForgeRock * /VP Strategic Partner Enablement/ *Location:*San Francisco *p:* +1.214.755.9218 *email:* allan.foster(a)forgerock.com <mailto:allan.foster@forgerock.com> *blogs:* blogs.forgerock.com/GuruAllan <http://blogs.forgerock.com/GuruAllan> *Skype:* Call GuruAllan <http://is.gd/lWVfMG> *www:* www.forgerock.com <http://www.forgerock.com/> *www:* www.forgerock.org <http://www.forgerock.org/>

5 8

Two thoughts for UMA enhancments
by Mike Schwartz 23 Dec '15

23 Dec '15

UMA-tarians, Can we discuss two ideas for enhancments: 1) UMA sans permission ticket Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets. We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures? 2) UMA without the AAT Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional? - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike(a)gluu.org

7 20

Notes from UMA legal subgroup telecon 2015-12-18
by Eve Maler 22 Dec '15

22 Dec '15

- Review the first draft deliverable <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative…> and its model clauses and definitions - How to take our work forward? Continue our subgroup meetings? - AOB Attending: Eve, Andrew H, Steve, Adrian, John W, Mark, Ann, Jon N, Jim, Scott, Dazza *How to take our work forward? Continue our subgroup meetings?* What is the interest in continuing the subgroup meeting series into 2016? Andrew is interested in a capped-length subgroup meeting series, e.g. six months tied to outcomes, but is wary of scope drift. Adrian would like to see an implementation group continue, but he's wondering where the academic focus went. Eve described the 2015 mission <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative…> as relentlessly practical. Mark noted that with the consent receipt work pushing forward, the direction of this work and further collaboration seem very important. Eve will propose a fresh, limited draft charter for the subgroup. Eve will schedule a meeting on Friday January 8 for us to review where we are for the first half of 2016. *Review the first draft deliverable and its model clauses and definitions* *Intro first para:* We suggest Jim and Scott follow up to switch to "represent" language vs. declaration and conformance (only "operators" can conform, vs. "users"). *Does the color marking system work?* Andrew suggests that color coding doesn't help for tokens. But for defined terms and abbreviations, it does, and probably for the persons/parties. *Idea for the UX:* It would be cool if clicking on a term/abbreviation would take the reader to the definition. *What to do about Individual/NPE/Subject?* In the era of IoT, we have to get this very right. The alternative that would be both legal- and technical-friendly would be *Individual *(?)*/Legal Person/* Device/Application/etc.*/Person*. Note that Subject in a legal sense is much more than "subject" in a technical sense; the former is the "subject of someone's gaze" (think data subject) and the latter, at least in security and identity is the subject of authentication. Also, we'll need conversion tables into other natural languages. Can we define the terms as bounded by US law until we can vet that it works cross-jurisdictionally, or provide sets of terms that are compatible with different jurisdictions? If we're targeting Canada as a first "customer", how should we handle this? Maybe we can put a note into the relevant definitions, we can put in notes about these being derived from US law. Can we borrow/steal from some existing federation language to support our UMA-specific needs? The UETA may have everything we need to support both "bags of protoplasm" and "organizations" running "server-side services" and "client-side apps". Jim will propose a change to this set of terms, with Legal Person (without an abbreviation). We may someday use NPE for equipment. *Two-party or three-party relationships?* We can see three-party relationships we clustering of two-party relationships, where a condition precedent to one two-party relationship is the formation of a prior two-party relationship. We can state any condition precedent and/or condition subsequent in terms of UMA roles (and leave holes for non-UMA conditions). AI: Jim/Eve: We'll have to be sure to do that in our clause reusability structuring. Scott notes that there's an RNA analogy. And Dazza notes that the Carat Guidelines from the '90s (here <http://civics.typepad.com/files/carat_final_011400-1.pdf>) said that there should be a limited number of roles, functions are allocated to roles, and when there are permutations and functions are allocated to more than one legal party, it should be clear what rights and obligations are delegated to them and which are delegable and non-delegable. Maybe we can include some of that language! *Adrian's earlier comments:* In email, Adrian sent comments that pointed out a typo we will fix. *Analyzing the very first clause:* "When the Client successfully gains access from a Resource Server to a protected resource by wielding a valid "bearer" RPT associated with at least one currently valid permission for the type of access sought, the Requesting Party using that Client gains an obligation to the Authorizing Party to adhere to any terms it agreed to in order to gain the permission." We drilled down into the specific Adhere-to-Terms clause source <http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiat…>, which has "comments" and "issues" that don't show up in the main document rendering. Eve observes that: - A LOT of conditions precedent seem to be buried in that one condition! - We probably need to get into the weeds of the Client Operator in a way we haven't previously. - We haven't said that the Requesting Party actually supplied claims, and maybe this Duty should only depend on a Condition of having supplied claims; the Issue mentions that the Condition perhaps be at the juncture of supplying the claim. - And oh, by the way, this clause is just stating the "blinding flash of the obvious" about what the protocol messages *exist to mean*. SAML the protocol never ever stated this: An IdP never promises to mean that it authenticated somebody at time *x* using method *y*. Scott observes that: - Right. Sit down in the chair -- get a haircut -- you have to pay for it. :-) Dazza observes that: - We have to get into "all applicable laws need to be followed". - We can start to have everyone propose clauses for our "clause bank", now that we are hammering out the canonical form. Jim observes that: - We can actually have a series of "Duty" phrases that can appear as alternatives and/or can aggregate. This would be a different reusability logic vs. the Adhere-to-Terms unique naming of each Duty, and would depend on whether the Condition is unique per set of Duty phrases. Jim and Eve: Propose a fresh clause skeleton <http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiat…> . *Thanks to all, with especial thanks to Jim and Mark! See you on the other side!* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 7