- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2017-01-05
by Eve Maler 05 Jan '17

05 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01>: APPROVED by unanimous consent. Logistics - Hold WG votes on specs this month (as often as we like?), and add publicity - WG vote on proceeding to Public Review no later than Feb 9 (Feb 16 is RSAC; *no meeting*) - Refer to telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> minutes to see how voting/balloting process goes Eve, Andi, Sarah, and likely Sal among those who are attending today are going to RSA. Eve and Sarah <https://www.rsaconference.com/events/us17/agenda/sessions/4829-measuring-au…> are speaking. Eve's talk touches on UMA and consent receipts. Andi reminds everyone that the CIS CfP closes tomorrow. Justin has submitted a bunch of talks, including one about UMA2 changes and a wider view of "V2 standards". UMA V2.0 work *266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math:* The whole notion of a client registering at an AS for scopes is weird because it's not bound to resources. It's only later that the scopes get bound. *Option 1* is to completely ignore pre-registered scopes. *Option 2* is to add the pre-registered scopes to the requested scopes at the token endpoint and the scopes in the permission ticket carried there. *Option 3* is to limit the client to only the scopes pre-registered for, and not any additional scopes. Option 3 seems impractical because of the lack of resource context for scopes at that "OAuth-only" stage in the proceedings as well as limiting Bob's abilities to express his wants. George is looking to help make clients simpler through pre-registration, so that they don't have to "repeat themselves" asking for scopes dynamically every time and just assume it will be taken as read that scopes will be requested by virtue of pre-registration – so, option 2. Mike likes option 2 as well. At the time of doing matching, the AS needs to determine what the scopes are that match against resources. The AS unions the pre-registered and dynamically requested scopes (if any), and does a matching process of some kind (either "generous" for any resource ID in the ticket as possible or "stingy" somehow?), and issues an invalid_scope error if there's no matches at all. Our invalid_scope error probably needs to be revised to account for not just any (dynamically) requested scopes but also statically or dynamically pre-registered scopes. *AI:* Justin: Propose a concrete example for the AS scope-matching and resolution spec text by Jan 12. There's consensus that the RS can request permissions that cover less than what the client was trying to do, on "Adrian clause" thinking. Do we need to issue a warning or error somehow if the AS avails itself of the clause (that's always been in there) about "granting a subset of requested permissions" vs. "treating the result as an authorization failure"? George suggests an alternative: The AS is required to fail the client if it can't fulfill the entire permission ticket's worth of permissions with their scopes, but it can treat any additional request scopes with discretion. Let's decide this latter issue next week. *AI:* Eve: Spec out all the set math text that can be spec'd out modulo the remaining issues in rev 11. *264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details:* It would be desirable in a lot of cases to specify hints about things like a certain kind of hard token etc. Whereas before we had an error_details hint authentication_context, now the client would redirect the user to the AS, which would "communicate with itself" about all the needed context. But if the client were sending along an ID token previously, wouldn't hints about what to send be helpful? This is where Eve was suggesting in the issue text that an error_details extension might be necessary to think about. *AI:* Eve: Send email about issue 264 and the next few issues for discussion prior to next week. Attendees As of 22 Dec 2016 (post-meeting), quorum is 5 of 9. (Domenico, Sal, Nagesh, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Andi 4. Eve 5. Mike 6. Cigdem 7. Sarah Non-voting participants: - Justin - George - Adrian - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Regrets for today’s call
by John Wunderlich 05 Jan '17

05 Jan '17

Can’t make it today John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Potential privacy issue with PCT
by Justin Richer 05 Jan '17

05 Jan '17

I was running through our current protocol text and stumbled over what might be a privacy issue with regard to the PCT. Namely, a PCT is meant to represent a set of claims previously presented by the RqP. The question is, how do we store that information? If we store the claims themselves, then we’re potentially storing personal information about the RqP for the lifetime of the PCT. This may or may not be a problem, and perhaps it’s an implementation decision for the AS to decide how much data it wants to keep around to make things happen. My initial thought was that we could store the *results* of the PCT calculation, but the problem of that is that it only makes sense with regard to a given policy set. What if the policies change, should the PCT be re-run, revoked, or represent its initial calculation? What if the PCT is used against a different resource with different policies? A potential implementation solution would be to store hashes of the claims to use in the policy calculation instead of the claims themselves. The policy engine would of course need to account for this, but it would potentially solve the problem of storing sensitive data. We would need to be clear in Privacy Considerations what that would look like and what the tradeoffs would be. Note well: Before you call for the AAT’s return, I’d like to point out that it suffers from the same set of problems when applied to policy calculations in this way. — Justin

2 3

Agenda for UMA telecon 2016-01-05
by Eve Maler 05 Jan '17

05 Jan '17

Date and Time - *Thursdays,* 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 - Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> - Logistics - Hold WG votes on specs this month (as often as we like?), and add publicity - WG vote on proceeding to Public Review no later than Feb 9 (Feb 16 is RSAC; no meeting) - Refer to telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> minutes to see how voting/balloting process goes - UMA V2.0 work - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 10 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html> and RReg is up to 03 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-03.html> - Issues to *discuss in the telecon*: - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details - 254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery - 263 <https://github.com/KantaraInitiative/wg-uma/issues/263>: Claim token profiling / 119 <https://github.com/KantaraInitiative/wg-uma/issues/119>: Create an IANA registry for URIs that stand for claim token formats - Shoebox (stretch goal; let's *make assignments for proposals for next week*): - 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior / 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>: Location Constraints / 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>: RS Notifies AS or RO of Access / 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>: Audit logs to support legal enforceability / 24 <https://github.com/KantaraInitiative/wg-uma/issues/24>: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM? - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers (stretch goal; let's plan to study this and decide whether it's in the WG's scope by *next week*) - Issues that will *close with no action* if no one brings them up for discussion by *next week*: - 261 <https://github.com/KantaraInitiative/wg-uma/issues/261>: Caching token inspection results - 249 <https://github.com/KantaraInitiative/wg-uma/issues/249>: Is there a way to elevate trust in Client Operators further, with a claims-like mechanism? - 108 <https://github.com/KantaraInitiative/wg-uma/issues/108>: Protection and authorization scopes implicit/recommended vs. MUST? - AOB - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: WG telecom tomorrow
by Eve Maler 04 Jan '17

04 Jan '17

I'm working on the agenda, which will include a series of concrete issues to work through, mostly not huge and some from email (e.g. the latest from the set math thread). For now, if you haven't yet familiarized yourself with rev 10, please do. https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html Also, please make a note to do your best to attend all meetings through Feb 9. Here's the key part of the newly changed TOC; it could yet be changed further and I've already collected some good feedback: 1. Introduction 1.1 Roles and High-Level Communications 1.2 Notational Conventions 1.3 Federated Authorization 1.3.1 HTTP Usage 1.3.2 Resource and Scope Interpretation 1.4 Protocol Flow Summary 1.4.1 Protection API and Related Resource Owner Actions 1.4.2 Authorization Interface and Related Authorization Server and Requesting Party Actions 1.4.3 Protected Resource Interface and Related Resource Server Actions 1.5 Time-to-Live Considerations 2. Authorization Server Configuration 2.1 Configuration Properties 2.2 Configuration Document 2.3 Requests to Authorization Server for Configuration Document 2.4 Authorization Server Response Containing Configuration Document 3. Protocol Flow Details 3.1 Resource Server Obtains PAT 3.2 Resource Server Registers Resources for Protection 3.3 Client Attempts Access to Protected Resource With No Token 3.4 Resource Server Requests Permissions on Client's Behalf With Authorization Server 3.4.1 Resource Server Request to Permission Endpoint 3.4.2 Permission Ticket Creation and Management 3.4.3 Authorization Server Response to Resource Server on Permission Request Success 3.4.4 Authorization Server Response to Resource Server on Permission Request Failure 3.5 Resource Server Responds to Client's Tokenless Access Attempt 3.5.1 Resource Server Response to Client on Permission Request Success 3.5.2 Resource Server Response to Client on Permission Request Failure 3.6 Authorization Process: The UMA Grant 3.6.1 Client Request to Authorization Server for RPT 3.6.2 Client Request to Authorization Server for RPT With Pushed Claims 3.6.3 Client Redirect of User Agent to Authorization Server for Interactive Claims-Gathering 3.6.4 Authorization Server Redirect of User Agent Back to Client After Interactive Claims-Gathering 3.6.5 Authorization Assessment 3.6.6 Authorization Server Response to Client on Authorization Success 3.6.7 Authorization Server Response to Client on Authorization Success With PCT 3.6.8 Authorization Server Response to Client on Authorization Failure 3.7 Client Attempts Access to Protected Resource With RPT 3.8 Resource Server Determines RPT Status 3.8.1 Resource Server Request to Token Introspection Endpoint 3.8.2 Authorization Server Response to Resource Server on Token Introspection Success 3.9 Resource Server Responds to Client’s Access Attempt With RPT 3.9.1 Permissions Assessment 3.9.2 Resource Server Response to Client on Sufficiency of Authorization 3.9.3 Resource Server Response to Client on Insufficiency of Authorization Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

AS flexibility around access token management: simplify?
by Eve Maler 02 Jan '17

02 Jan '17

Cigdem asked some good questions in a series of comments she sent me: Core Section 3.5.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#give-rpt> (rev 09) has a Note that explains: "The authorization server is free to choose to return either the same RPT that appeared in the request or a new RPT, and it is also free to choose to *invalidate or retain the validity* of the original RPT or any permission that was previously added to that RPT." Cigdem's questions were (slightly edited): *If the original RPT was valid, wouldn't the client have gotten access to the resource at the resource server? Would the client ever ask for another RPT with a valid original RPT? Does it describe the case where the RPT was for one resource/scope and not expired, but the client tried to use it to access another resource/scope and failed?* What we were trying to say was that: 1. *(Client can bring no RPT and ask for one -- not a concern)* 1. *(AS can issue a new RPT A -- not a concern)* 2. Client can bring RPT A that doesn't have a permission for what it wants to do and ask for an RPT that works for what it wants to do 1. AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it 2. AS can issue a new RPT B (different RPT string), having added the relevant permissions to it 1. AS can invalidate the old RPT A that the client brought it upon this action 2. AS can retain the validity of the old RPT A that the client brought it and any of its permission(s) -- presumably ones that are still good and that the client didn't just try to exercise but found wanting The question is, do all these options truly make sense? Is it, for example, such a common pattern for an AS to invalidate all previous tokens and stuff all current permissions into the latest and greatest access token (which equates to list item 2.2.1 above) that doing anything else is insanity? Any other option would leave the client juggling multiple tokens, and having to guess which ones unlock which resources. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

New drafts, finally: Core rev 10 and RReg rev 03
by Eve Maler 02 Jan '17

02 Jan '17

So, uh, happy new year. :-) https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-03.html I've been working on great detailed comments from Cigdem and Mike (thanks!) and other mostly editorial stuff, and managed to implement 98% of the big section refactoring I've been talking about for a while (flatten-consolidate-shorten). Please try and give these a read-through. Questions: - I'm starting to believe that the "*authorization interface*" is actually properly the "*UMA grant*", tip to toe. In one place I actually did call it that. True? - I added a precondition/assumption that the client needs to use the *client credentials grant* to get an access token to use in the header when it makes a call to the token endpoint to get an RPT. Is my understanding correct? We didn't say anything about this before. - We have "five definitive errors" that *end the authorization process*. But is there anything that should happen to make this truly definitive? Should permission tickets expire, or what? - I've got a couple of other *Table of Contents nerd questions* that I'd love to pore over with others similarly inclined in a quick session before our Thursday session. Self-identify and I'll find you. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Step 3 to Step 4 (client approaches RS with no token) wording
by Eve Maler 30 Dec '16

30 Dec '16

(Edited the subject line and will break up this thread into two for clarity...) Excellent point about "single authorization server", thanks, Justin! The other thing I was wondering about was: Everyone okay if we excise the other *n* instances of this explanation in the next section? As noted during our last call, now that the "normative commentary" about interfaces has largely moved to Section 1, I'd like to ensure that the messaging specifics are cleanly spelled out in the next section, with no holes and no "digressions" -- only xrefs back if we really want them. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer <jricher(a)mit.edu> wrote: > For my action item from Eve’s post, I would suggest this wording: > > Note: In step 3, the client attempts access to a protected resource with > no token, and in step 4, the resource server requests permissions on behalf > of that client at the authorization server. In order for the resource > server to know which authorization server to approach and which PAT > (representing a resource owner) and resource identifier to supply in that > request, the API being accessed by the client needs be structured in such a > way that the resource server can derive this information from the client's > token-free access attempt. Commonly, this information can be passed through > the URI, headers, or body of the client's request. Alternatively, the > entire interface could be dedicated to the use of a single resource owner > and protected by a single authorization server. > > > > > — Justin > >

2 8

Spec proposal for protected resource and scope communications and mappings ("set math")
by Eve Maler 29 Dec '16

29 Dec '16

Cigdem and I continued meeting for a bit after Thursday's call officially drew to a close. This allowed us to explore a couple of the outstanding "set math" questions in greater detail, which in turn allowed me to form a concrete proposal. After trying it out on Cigdem -- thanks a million! -- in email (see our *italic commentary* in sub-bullets), I wanted to share it with the WG to try and collect discussion before this Thursday. If possible, *let's see if we can get quorum/critical mass this Thursday* to decide these matters. The following is written as a summary that would go somewhere in Section 1, with plentiful cross-references to later sections (currently mentioning the relevant sections in rev 09 <http://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html>) where full normative text either currently appears or would need to be added. ==== At several junctures in the authorization process and the surrounding flow, the actors communicate and perform internal mappings regarding relevant protected resources and their scopes, as follows. - Based on the client's initial attempt to access a protected resource (see Sec 3.1.1), the resource server, which is responsible for managing any internal resource complexity (see Sec 1.4.3), maps the access attempt to a resource identifier and scope that would suffice for successful access and then requests one or more permissions on the client's behalf that include at least that resource identifier and scope (see Sec 3.2). The authorization server issues a permission ticket that represents exactly the permissions the resource server requested (see Sec 3.2.2). - *In 3.1.1: Add explanation that the client's access attempt implicitly indicates some set of resource identifier possibilities, and cross-ref to 1.4.3 and 3.2* - *1.4.3 has the text it needs already (modulo an editing tweak)* - *In 3.2: Add explanation about interpreting the client's access attempt and mapping to one of the resource identifiers and scopes that suffices* - *3.2.2 has the text it needs already* - Anytime the client approaches the authorization server with a permission ticket to request an RPT (see Sec 3.5.1), if the client requests scopes not already included on operative resource identifiers associated with the permission ticket, the authorization server dynamically extends the requested permissions associated with the permission ticket by mapping each of the requested scopes to any of the resource identifiers that have that scope. It does this regardless of any scopes for which the client has pre-registered (see Sec 3.5). - *Because of new clarity around this whole resource/scope ecosystem, we found ourselves kind of uncomfortable with the newly added scope-requesting feature; discuss whether dynamic additions of scopes by the client makes sense given that the RO can "dynamically reduce" again through policy and the AS can "dynamically reduce" through the partial fulfillment/rejection option? (see below)* - *Assuming the feature is kept: In 3.5.1: Add explanation of how scopes are matched; use exact match a la this <https://xml2rfc.tools.ietf.org/public/rfc/html/rfc3986.html#comparison-stri…>?* - *3.5 has the text it needs already* - After the authorization server performs authorization assessment (see Sec 3.5.2) against the requested permissions associated with the permission ticket and policy conditions, if only a subset of policy conditions is met allowing a subset of the resource identifiers and/or their scopes among the requested permissions, it is free to grant the entire subset of requested permissions or to treat the result as an authorization failure. - *3.5.2 currently words this more softly, whereas it's stated as a binary choice above; since policy conditions are out of band, it's currently impossible to enforce it as a binary; what wording makes sense?* - When the client attempts to access a protected resource with an RPT (see Sec 3.1.2), the resource server determines the RPT status (see Sec 3.4), maps the access attempt to a resource identifier and scope that would suffice for success access, and compares the result to the RPT status (see Sec ?) as part of considering whether to give access. - *In 3.1.2: We should note that the client could actually attempt to access a different resource, or the same resource with a different scope, than originally when it had no token; there's no way to stop it, and it doesn't harm anything wrt access control.* - *3.4 has the text it needs already, modulo breaking out some of the text to form a new section that focuses on the (RS-internal) RPT assessment process* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Book Review
by John Wunderlich 23 Dec '16

23 Dec '16

For your holiday reading pleasure. This might be of interest to the Legal UMA group and some on the BSC DG. It's a review <http://www.rogerwhitson.net/?p=3501>of Benjamin Bratton’s The Stack: On Software and Sovereignty <https://www.amazon.ca/Stack-Software-Sovereignty-Studies-ebook/dp/B01D1Q44HE> John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0