- WG-UMA - mailman.kantarainitiative.org

Section 7 - Security considerations - bearer tokens
by Cigdem Sengul 22 Oct '16

22 Oct '16

Hello, Eve suggested that I start the discussion about this in the list. Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens. In addition, RFC 6750 recommendations may also be referred to in the draft. Thanks, --Cigdem

4 7

Notes from UMA telecon 2016-10-21
by Eve Maler 21 Oct '16

21 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-21 MinutesRoll call Quorum was not reached. Logistics *Next week: no meeting because of IIW!* Have a great time if you're going. Please don't forget to send George comments on his deck, and soon. Approve minutes Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13>: Deferred. Work on UMA.next issues *Requesting party claims endpoint:* Eve's proposal for the AS *declaring a requesting party claims endpoint* to the client was that we should pick option 2: both static (in the config data) and dynamic (in the response to the client) methods, with MAY, and with dynamic overriding static if it's present, providing the rationale that static pattern enables the RqP to authorize client pushing of claims and the dynamic pattern enables variable URLs according to the AS's management of its API. Mike notes that OIDC just had a thread <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20161010/0063…> about a similar matter, regarding scopes. Eve guesses that this specific thread may not be related because it's about a required registration and the interaction between two specs. Is there another thread? Eve proposes spec'ing the text, and if anyone can identify a concern that seems more related, do it by the time rev 06 is out. Eve proposes that the definition of "authorization process" should require that "request_submitted" be more formally defined to have the AS emit a 403, and say that "The authorization server responds with the HTTP 403 (Forbidden) status code.", and the client is free to start another authorization process at a later time. Similarly the other 400s require starting new authorization processes. This makes clear what "persistence" means for a PCT. Mike and Cigdem are supportive. *Authorization interface and UMA grant:* We looked at Dom's first diagram. We requested: - Adding "natural person" and "legal person" icons to both the RO and RqP blocks - Some way of ensuring that inside the AS block: - The protection API concept is associated with the RO-RS-AS tuple - The authorization interface concept is associated with the C-RqP-AS tuple - The UMA grant concept is associated with the C-AS tuple - The PCT is shown as being optional in a nice-looking way - The second canvas with the life cycle should use initial capitals in the text - Attempt resource access - Register requested permission - Authorization process - Authorization assessment - It should also have a small "start" arrow to show that the client attempts access to the resource - The life cycle circle should be a bit smaller to make sure all the outer text shows - Overlay the RPT so that it shows "through" the life cycle (maybe make the circle translucent?) - Keep up the flowcharts according to the swimlane; do as you wish with the life cycle color coding Instructions: - Spec requesting party claims endpoint declaration as indicated above - Spec authorization process definition as indicated above - Create a draft ASCII diagram for the first canvas - Update swimlane *Bearer RPT and PoP tokens:* We didn't get to this, so please weigh in on the list. Eve is happy to try out spec text (and also removing spec text!) in 06 if we hurry on that. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Eve 3. Mike 4. Cigdem Non-voting participants: - John Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA Legal telecon 2016-10-21
by Eve Maler 21 Oct '16

21 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-21 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Working through use cases per party in the transaction Attending: Eve, John W, Ann What is the scope of our work (in this subgroup)? The technical layer may or may not change, while the contractual and regulatory layers above may change surrounding it. Our effort to gather use cases is an attempt to literally scope our work for now. Think of this as a "V1" effort of the "UMA legal subgroup" (which perhaps needs a new name because "legal" is too specific?). The use cases are driven by business and influenced by the regulatory environment, and could be implemented with UMA *and*other technologies – e.g., consent receipts, user-submitted terms, JLINC's stuff, etc. Eve's theory: We wanted to do draft model text by 1Q2016. [image: (smile)] But the need for some visible progress by 4Q2016 is getting acute. Evidence: The use case of "delegation of access rights" (think "power of attorney", or positive acceptance of access on behalf of the resource owner, or "I am accepting that you gave me rights to drive this connected car", or "this is a payment API and Alice gives Bob the right to spend money out of her account") keeps coming up. UMA the technical solution says nothing about the API semantics, but the contractual and maybe the regulatory layer (think Open Banking API and PSD2) may say a lot about this. Also, there are some complementary technologies such as Token Exchange <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05>, which has an "act_as" semantic, which may have a role at the technical layer. Once upon a time, we had innovated the "Binding Obligations" approach, which enabled a mapping of the non-technical layers to the technical layer where there was a state change so that it's possible to capture that change as part of the chain of evidence (hey, with blockchain/DLT involved??). Sometimes there is no technical state change at the UMA level, but sometimes there is, e.g., a token expires or gets issued or something. And we can start to be more and more clever about that. Keep in mind that "getting access" could mean getting a value of data, or getting access to a stream of data (e.g. Websocket), or getting access so as to insert or delete data. In the world that used to be, only control of "disclosure" mattered. But now, with UMA anyway, API publishers (RS's) are authoritative for what grain of access is possible, and ROs can control what scopes are handed out. What are the constraints on Bob's behavior once he gets access as a "first-party" RqP? 1. Bob is a completely free agent to use the access as he sees fit. 2. Bob is legally or contractually constrained in how he uses the access. 3. Bob is technically constrained in how he uses the access. Eve attempts to make the case that there are fine gradations (referencing her as-yet unpublished permission model taxonomy!) among "ways he uses the access", e.g. onward sharing with third-party grantees such as Charlie, and using it for marketing purposes vs. essential business purposes. She owes the group/the world her taxonomy writeup already. Look at last week's notes for the description of how UMA and a combination of other technologies could address the onward sharing proposition. The "*delegation of access rights*" use case seems to be such a popular one that maybe we should highlight it in our interim publications. What are the realistic options for Bob's use or disclosure of Alice's data he's been exposed to (in this specific case, vs. onward sharing)? "Information wants to be free", generally. To the extent that data is volatile, it loses value over time. To the extent that data is nonvolatile and valuable, helping Alice not to overshare will help, and leveraging wider ecosystems where the business model favors Alice's interests. Beyond that, only nontechnical methods of enforcement will need to be exploited to keep the Bobs in line. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-10-21 (special Friday meeting, just after Legal call)
by Eve Maler 20 Oct '16

20 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-21 Date and Time - *Special Friday meeting,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Logistics for upcoming meetings - Next week: no meeting because of IIW - Approve minutes of UMA telecon 2016-10-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13> - Work on UMA.next issues – Core is up to 05 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html> - Requesting party claims endpoint: static declaration, dynamic declaration in response to client, or both? - The authorization interface and the UMA grant - Domenico's latest diagrams - Set math: See 9-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> and 10-6 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06> - RPTs, the bearer token profile, and PoP tokens - George thoughts on leveraging UMA error description/URL for more info on specific resource set IDs/scopes at fault in registering a permission? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

No WG meeting today (Thursday) -- we meet tomorrow (Friday) instead
by Eve Maler 20 Oct '16

20 Oct '16

Please be prepared to weigh in on all the current discussions and text! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] Pre-registration of the client's callback claims_redirect_uri: comment requested
by Justin Richer 18 Oct '16

18 Oct '16

That's fine. Seems odd to call it "regular" but I see what you're getting at. I don't have a better suggestion at the moment. --Justin Sent from my phone -------- Original message --------From: Eve Maler <eve(a)xmlgrrl.com> Date: 10/17/16 12:40 PM (GMT-05:00) To: Justin Richer <jricher(a)mit.edu> Cc: "wg-uma(a)kantarainitiative.org UMA" <wg-uma(a)kantarainitiative.org> Subject: Re: [WG-UMA] Pre-registration of the client's callback claims_redirect_uri: comment requested After James pinged me with some comments suggesting more normative-ness in a specific direction, I thought I'd try out this variant: "Note that claims redirection URIs are different from regular OAuth redirection URIs in that they are intended for the exclusive use of requesting parties and not resource owners. Therefore, authorization servers MUST NOT redirect requesting parties to regular pre-registered OAuth redirection URIs unless such URIs are also pre-registered as claims redirection URIs." Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Oct 17, 2016 at 1:51 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: In that case, wouldn't the following be sufficient? "Note that claims redirection URIs are distinct from regular OAuth redirection URIs; they are intended for the exclusive use of requesting parties and not resource owners." Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Oct 17, 2016 at 1:02 PM, Justin Richer <jricher(a)mit.edu> wrote: No, that’s too proscriptive. If the client wants to use the same URI to do both, it should be allowed to. The important thing is that it’s two different values from the perspective of the AS. Thus two different field names in the client data model. The AS should never compare them to each other nor be given a hint that it should (as the text below suggests). — Justin On Oct 17, 2016, at 4:18 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: Ah, okay. The rationale got lost in the shuffle. The original is in the right direction, but needs more explanation and disambiguation, I think: "Because the claims redirection URIs of a client are intended for the exclusive use of requesting parties and not resource owners, if a client pre-registers redirection URIs at all, any claims redirection URIs must be different from any other redirection URIs to be used by the authorization endpoint during redirect-based OAuth flows." Is this accurate? Eve Maler (sent from my iPad) | cell +1 425 345 6756 On Oct 17, 2016, at 2:03 AM, Justin Richer <jricher(a)mit.edu> wrote: Yes, the separation is still very much necessary. Remember, we’re folding together the *back* channel and not the *front* channel, because the parties are different on the front channel in UMA vs. OAuth (namely, RqP vs. RO). The claims_redirect_uri and redirect_uri are all about returning data from the front channel. We’ve gotten rid of the rpt_endpoint because that was a special back channel endpoint that’s no longer necessary. If we were using the authorization endpoint then we could use the same redirect_uri as in OAuth, but we’re not. Why aren’t we? Because then the RqP would need to be treated much like a RO at the resource server — which is to say, Bob needs to be treated like Alice. But it’s not Bob’s server and we can’t (and shouldn’t) assume that he’ll be treated the same as she will. Recall that this mistaken assumption is at the core of deployment issues with the AAT for anything beyond a very narrow ecosystem where everyone is using the same AS. — Justin On Oct 16, 2016, at 2:17 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: Cigdem did a close reading of the spec draft, for which I'm grateful. In addition to finding an error in the config data example that I was able to fix in the forthcoming rev 05), she also noticed some ambiguous language here: Sec 3.6.2 rev 04:"claims_redirect_uriOPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an application/x-www-form-urlencoded-formatted query parameter component that MUST be retained when adding additional parameters, and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint (either using a static process or throughRFC7591 (at line 1749) or [OIDCDynClientReg]). The claims redirection URIs of a client MUST be registered distinct from the client's redirection URIs as used at the authorization endpoint during redirect-based OAuth flows. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (at line 1756) (Simple String Comparison)." She commented: "Section 3.6.2, in the “claims_redirect_uri” description, I was a bit confused about what is a MUST and what is a should? Is it a MUST that the client pre-registers the claims_redirect_uri? Then the sentence, “If the URI is pre-registered” should not have an If?" First, we could improve the language generally to do away with the passive and ambiguity (some of which came from the original OAuth passage). But second, is it still necessary for us to be segregating UMA client redirect callback URIs from OAuth client callback URIs? With an UMA client adhering to a formal UMA extension grant of OAuth soon enough, will it be a distinction without a difference? Here's a revision that attempts to fix the former problem and also keep the original semantic, in case we need it. Changes bolded. The sentence in bold red could be removed if we think it's pointless now. "claims_redirect_uriOPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute; MAY contain an application/x-www-form-urlencoded-formatted query parameter component that the authorization server MUST retain when redirecting the requesting party back, whether or not it adds any other parameters; and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint (either using a static process or through RFC7591 or [OIDCDynClientReg]). If the authorization server does require clients to register redirection endpoints, it MUST require clients using UMA grants to register claims redirection URIs distinct from clients using other OAuth grants. If a client has pre-registered a URI, then the URI it supplies here MUST exactly match one of its pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (Simple String Comparison)." Discussion and comment welcome, especially prior to next Friday's call so that we can take care of this issue expeditiously. Thanks! Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl _______________________________________________ WG-UMA mailing list WG-UMA(a)kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

3 3

Pre-registration of the client's callback claims_redirect_uri: comment requested
by Eve Maler 17 Oct '16

17 Oct '16

Cigdem did a close reading of the spec draft, for which I'm grateful. In addition to finding an error in the config data example that I was able to fix in the forthcoming rev 05), she also noticed some ambiguous language here: Sec 3.6.2 rev 04 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-04.html#rfc.section.…> : "*claims_redirect_uri* OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an application/x-www-form-urlencoded-formatted query parameter component that MUST be retained when adding additional parameters, and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint (either using a static process or throughRFC7591 (at line 1749) or [OIDCDynClientReg]). The claims redirection URIs of a client MUST be registered distinct from the client's redirection URIs as used at the authorization endpoint during redirect-based OAuth flows. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (at line 1756) (Simple String Comparison)." She commented: *"Section 3.6.2, in the “claims_redirect_uri” description, I was a bit confused about what is a MUST and what is a should? Is it a MUST that the client pre-registers the claims_redirect_uri? Then the sentence, “If the URI is pre-registered” should not have an If?"* First, we could improve the language generally to do away with the passive and ambiguity (some of which came from the original OAuth passage <https://tools.ietf.org/html/rfc6749#section-3.1.2>). But second, is it still necessary for us to be segregating UMA client redirect callback URIs from OAuth client callback URIs? With an UMA client adhering to a formal UMA extension grant of OAuth soon enough, will it be a distinction without a difference? Here's a revision that attempts to fix the former problem and also keep the original semantic, in case we need it. Changes *bolded*. The sentence in *bold red* could be removed if we think it's pointless now. "*claims_redirect_uri* OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute; MAY contain an application/x-www-form-urlencoded-formatted query parameter component that *the authorization server MUST retain when redirecting the requesting party back, whether or not it adds any other parameters*; and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint (either using a static process or through RFC7591 or [OIDCDynClientReg]). *If the authorization server does require clients to register redirection endpoints, it MUST require clients using UMA grants to register claims redirection URIs distinct from clients using other OAuth grants.* *If a client has pre-registered a URI, then the URI it supplies here *MUST exactly match one of its pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (Simple String Comparison)." Discussion and comment welcome, especially prior to next Friday's call so that we can take care of this issue expeditiously. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 5

New spec and graphical representations
by Eve Maler 16 Oct '16

16 Oct '16

Hi folks-- A bunch of things to share with you today for your review. - Domenico has developed some revisions of the diagrams and flowcharts he's been working on, and they're attached here. - Here is a link to a new swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> I just created. It will update as I revise it; it's meant to capture our current draft 2.0 flows, and to mark "SYNTAX CHANGES" and "ADDED OPTIONS". Dom's flowchart is meant to be a higher-level version of the swimlane, so we can decide what we'd like to put in the spec around the notion of an authorization interface and authorization process (conceptual? very technical?). - Finally, draft 05 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html> is up! Everything interesting (and some boring stuff) is in one commit <https://github.com/KantaraInitiative/wg-uma/commit/a973ea594169a359133cddf7…> . - Don't forget about George's deck <http://www.slideshare.net/CloudIDSummit/cis-2015-user-managed-access> for IIW as well! I'll try and review that in the next couple of days. Please review and comment! And please don't forget about the email threads already begun. :-) Talk to y'all Friday. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal telecon 2016-10-14
by Eve Maler 14 Oct '16

14 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-14 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Working through use cases per party in the transaction – see last week's notes for the pattern Attending: Eve, John W, Adrian, Kathleen, Mark, Mary, Sal Adrian points to this fascinating article introducing the notion of an "information fiduciary <http://www.theatlantic.com/technology/archive/2016/10/information-fiduciary…>". We discussed the merits of this phrase vs. "agent"; in the past, we've had feedback that "agent" is an accurate legal concept, but too academic. Mark concurs. Some give feedback that "fiduciary" may be helpful has a concept. It does have a connotation of totality of trust. This is sitting pretty well with quite a few use cases. What if our model text, if adopted as a whole by an ecosystem, would confer a kind of "safe harbor" (see the reference to this concept in the article) that lets the various service roles declare that they are "fiduciaries" of specific kinds on behalf of the resource owner/Resource Subject. At the least, we could advocate for this to be a standard interpretation among the Pan-Canadian Trust Framework developers, the GDPR regulators, etc. We're thinking that the budget we have available to use – and must be used by end of year – would best be used in a completion of this analysis. In fact, do we want to take BCRs and turn them into our text, or go in the other direction, or what? We have defined *Resource Subject* with our eyes open to the analogy with Data Subject. Does it make sense to have *Resource Controller* instead of Resource Server Operator? This seems relatively close, by analogy to Data Controller. But then again, from a rights-granting perspective (where the DS is the rights-holder on whatever basis and the DC works under constraints set by the DS) and what we've done with the design of UMA, we have perhaps split out the Data Controller role into two with our RS and AS. This is part of the innovation of UMA. And then what about *Resource Processor*, analogously to Data Processor, for the Client Operator? Is disclosure of data always for some purpose that is "on the DS's behalf", or is it sometimes for the autonomous use of the access recipient? Eve wonders if the "behalf" distinction is just a way of saying that liability, or responsibility, or accountability, is really strong or has a lot of components to it. As long as the regulatory/contractual layer above the technical UMA layer can capture the subtleties of the liability (such as "you can only share this data after a certain time") or even the technical layer can capture some constraints (such as "sharing will end at this time" or "you cannot write data back to the server, only read it from the server"), then the entire requesting side – both client and requesting party (however each ultimately get split out in "party" terms) – could constitute the Data Processor. What about the challenge of "on-sharing", or re-sharing, or downstream sharing constraints? Here are some thoughts: - If there is a narrow ecosystem where all users are using the *same* AS, it's very easy to manage this, because the (singular) AS can keep track, and then you (the RS that publishes APIs) could theoretically invent something like a "no re-sharing" scope on your APIs and then let people set this when they share. (Think of Google Apps's similar "Advanced" feature.) Such a scope, if that's the right place to put it, maybe could be a standard "best practice" scope in various APIs. - In a medium or wide ecosystem, where everyone uses (say) a different AS, John points out that Alice could at least monitor sharing through a ledger mechanism (he can send the diagram to the group), but you'd need something like encryption or DRM technology above UMA to actually control the re-sharing. John mentions J-LINC and Sal mentions COALA <http://coala.global/working-groups/>. *AI:* Eve: If feasible, approach Scott D about the possibility of more focused work to complete our use cases and terminology and analysis around DS/DP/DC. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Options for declaring the requesting party claims endpoint
by Eve Maler 14 Oct '16

14 Oct '16

Regarding the three options for declaring the requesting party claims endpoint that we discussed today: 1. Keep static declaration of requesting party claims endpoint in config data document and don't add to AS need_info response to client (status quo) 2. Keep static declaration and ADD to AS response 3. DROP static declaration and ADD to AS response Would static declarations be the only way to have a pattern of Bob authorizing claim-pushing ahead of time (a la AATs)? That may be a good rationale for keeping them, because they'd give feature parity with original UMA. And we already identified a rationale (or several) for dynamically adding the endpoint to the AS response. Does this argue for option 1? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3