- WG-UMA - mailman.kantarainitiative.org

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 04 Jan '17

04 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 04 Jan '17

04 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

Draft minutes of UMA telecon 2016-12-22
by Eve Maler 22 Dec '16

22 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-22 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01>: tbs Logistics - This is our last meeting of the year - 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 Regarding what to include in V2.0 work, Ishan brings up the RS's need to pass requirements for minimal authorization to the AS. This seems to be the only addition to Eve's proposed list so far for our final V2.0 work. There's support for seeking a set of WG drafts. UMA V2.0 work *Set math:* In the question of discretion applied by the RS during its permission request compared to discretion applied by the client during its initial access attempt: What's the motivation of the client? What's the motivation of the RS? Justin has proposed wording in the past that recommends requesting enough permissions for the request to succeed, which softens the previous requirement. Eve and Cigdem discussed the notion that this seems like "bad faith", since the (100% untrusted) client can only communicate one thing at this point: "I want resource X with Y scope" (or rather, some kind of resource among some set XX with YY scope). Eve notes that XACML expects the PEP to transmit a faithful representation of the application's access request to the PDP as an authorization request. What are use cases for the RS to reduce the permission request vs. adding permissions and/or scopes? Should the RS be completely dumb and send no scopes at all when it requests permission? If it didn't do this, then suddenly the client's pre-registration for some scopes A, B, C and its potential dynamic addition of scopes X, Y at RPT request time become a lot more "normative". Reminder: A "permission" is "Authorized access to a particular resource with one or more scopes." Now it's possible to request more than one permission on behalf of the client. (The formal call ended and Robert and Eve continued discussing.) Different APIs design their resource boundaries and scopes differently, so perhaps it's not a good idea to discriminate between what an RS can do with one vs. the other. Adrian had suggested earlier that it's good advice to say that the client should ask for as few scopes as possible, for least privilege reasons. The same is likely true for the RS requesting permissions. But is *less than* what the client asked for a case of least privilege? Can we park the notion of changing things drastically for now (e.g. removing the RS's current capability of requesting scopes on permissions) and come back around to it? What about this notion of equitable risk and responsibility distribution? The client, representing some RqP, which are initially 100% untrusted and seek partial trust at maximum: - Can pre-register for scopes with the AS and can dynamically request scopes on every RPT request - Can attempt access differentially on tokenless attempt #1 and RPT-bearing attempt #2 at the RS The RS, which outsources resource protection to the AS but has the right to apply "edge protection" (the "Adrian clause" but strengthened to apply to the beginning of the chain): - Is allowed to request permissions and scopes on behalf of the client that are smaller that would allow the initial access attempted by the client (Justin's proposal) - (This logic could be applied to allow "cascading authorization servers" to enable the RS's risk management vs. the RO's wishes) - ... The AS, which is accountable to the resource owner and RS for resource protection: - Is allowed to reject or partially fulfill RPT requests *AI:* Eve: Send out note with revised set math proposal. *AI:* Eve: Publish rev 10 and rev 03 for people's holiday reading pleasure. Attendees As of 20 Dec 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Robert 3. Maciej 4. Eve 5. Mike 6. Sarah Non-voting participants: - Adrian - Ishan - Justin Regrets: - Cigdem - James - Andi - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0