- WG-UMA - mailman.kantarainitiative.org

The idea of deferring big issues and focusing on actual bugs in the patch release
by Eve Maler 12 Aug '15

12 Aug '15

This topic is on the agenda for discussion tomorrow. In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?). Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy. If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks, Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 3

Agenda for UMA telecon 2015-08-13
by Eve Maler 11 Aug '15

11 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-13 Date and Time Thu Aug 13 8:30-10am PT (we start 30 minutes earlier and meet for 90 minutes in August) 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 <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 <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Roll call Minutes approval Sample motion: Approve the minutes of UMA telecon 2015-08-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06>. Issue resolution work (issues on GitHub <https://github.com/xmlgrrl/UMA-Specifications/issues>) (UMA V1.0.1 issue nominations spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…>) ("sprint" document <https://docs.google.com/document/d/1c50top8X6Aqw3CEVeX_SD2THqO508ihs14QwLem…>) Are we definitely interested in putting significant breaking "upgrades" onto a major/minor release train? E.g., issue 153/154 What would be a reasonable schedule for such an effort? What type of release is it looking like? (SemVer <http://semver.org/> says breaking = major...) Now let's take a fresh look at the patch release Can we tackle a few patch release issues today? AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Draft minutes of UMA telecon 2015-08-06
by Eve Maler 11 Aug '15

11 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06 Minutes Roll call Quorum was reached. Minutes approval MOTION: Approve the amended minutes of UMA telecon 2015-07-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-07-30>. APPROVED by unanimous consent. APAC-friendly sync update This sync schedule is working really well. Spec versioning process update No update. Eve hasn't moved the repo over. Issue resolution work Goal is to discuss and resolve issues 165/153/154 (all ranked #1) – please review! Issues on GitHub <https://github.com/xmlgrrl/UMA-Specifications/issues> UMA V1.0.1 issue nominations spreadsheet <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> Issues 153 and 154 Not meaning to guess Justin's exact thought process in any way... Observation #1: AS has a special "RPT endpoint", making up the entirety of the special "UMA authorization API", at which the UMA client asks for a special UMA "RPT" with authorization data on Bob's behalf, that acts suspiciously just like an ordinary OAuth token endpoint. If it were more like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved. Observation #2: The UMA "authorization API token" (AAT) is an extra layer and hindrance to the entire OAuth-friendly cycle in this case, particularly because it appears to require that Bob have a login at the AS. Discussion: Isn't the last bit, about the login, just an implementation decision? He has to either be SSO'd into the AS, or have a local login at the AS, or be offered a federated ("NASCAR-like" or whatever) login option at the AS. More accurately stated, he has to be able to establish an authenticated relationship with Alice's AS. Observation #3: If the AAT flow were entirely removed and the RPT endpoint were turned into a ordinary token endpoint, then Bob's client would approach it to ask for "an access token" (perhaps of some UMA-flavored type?). Discussion: Eve contends that, since we are trying to keep everything as much the same as possible, then this new "UMA-flavored grant flow" would still (so far) have the the client approach the RS, fail, get a ticket, go to the AS's (now) token endpoint, ask for a token, and engage in the trust elevation flow we have already designed. Observation #4: Instead of using an AAT in the header of the token request, it would use its client credentials to identify itself, basically using its own recognizance. Discussion: Where else is the AAT required in headers? Is it required in the redirect of Bob for claims-gathering? No, there are other security measures imposed. What about in the case of an autonomous web service client? We think that this could use pushed claims to the token endpoint as well. More discussion: The AAT isn't very high-value! So a kind of "merge" to elevate what was the AAT flow up into what was the RPT flow to become an analog of a typical OAuth flow looks attractive. That means the claims flow would be the very first thing Bob does – no AAT step before. That seems kind of clean as a UX, if we're not missing anything like Bob's consent. And we don't think we're missing that, because that's what the OAuth flow is designed to do. The RPT represents everything the AAT did, but more. Why didn't we consider this before? In fact, we did <https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3>. More discussion: In both the authorization API circumstances and the newly imagined grant flow circumstances, how does Bob know exactly what claims the client is pushing? Observation #5: UMA is still OAuth++ or value-add or something, in that the protection API that makes the AS and RS loosely coupled and makes possible trust establishment between them (using OAuth) is added on top, and in that Bob is a completely autonomous actor wrt Alice (which is why the grant flow we're considering has trust elevation as a key part of it), and in that the grant flow we're considering has asynchronicity as a key part of it. All the value-add still seems to adhere even if the AAT isn't part of the picture. Discussion: Regarding the Privacy concerns: if the Client does a POST on the RPT to get the AuthzData added to it, the AS can still decide to return a new RPT to the Client (if the presented RPT had AuthzData for another RS attached to it). So that could be a AS-privacy setting? According to the APAC discussion yesterday, the answer appears to be yes. We can use a MUST to force the AS to mint a new token per RS. (Justin also noted in email that if the client tries to present a token from RS1 for upgrading with authorization data for RS2, the AS should not allow that.) Discussion: Is UMA all pseudonymity-based? The AS knows Alice by AliceID(AS). The AS knows Bob through some set of claims, potentially. Each RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous federated ID by which both the AS and that RS know Alice. Each client has a set of access tokens (in the putative new solution) with a set of permissions, but not identifiers. Discussion: How would the client manage multiple access tokens? All it knows is that it's trying to access a resource. How would it know that the token it has been given is new for this RS? What if the spec said this (bold is new)? "If the client did not present a token in the request for authorization data, the authorization server creates and returns a new token. If the client did present a token in the request, the authorization server returns the token with which it associated the requested authorization data, which MAY be either the token that was in the request or a new one. In any case, the authorization server MUST return a new token when the client presents a token that is associated with a different resource server." Summarizing our sense: Generally positive about most aspects, but there is a concern about how clients handle the token situation, and some uncertainty about ensuring that the requesting party really has a chance to authorize the interaction. Next steps: AI: Eve: Develop swimlanes (web sequence diagrams) of the putative new flows, along with pros and cons, and share with the group by Monday. Let's TRY and have an active discussion, drawing in Nat, about the client concerns, before next Thursday. Let's TRY and conclude issues 153 and 154 in the early part of next Thursday's meeting. If we have a specific proposal in front of us for issue 165, we'll consider it, otherwise not. We'll also take up 160, 161, 162, and 168 next time. Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. Ooh, next week is going to be tough for quorum, so everyone else please try and attend if they can! AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Andi Irwin Domenico Maciej Robert Mike Arlene François Non-voting participants: Adrian James Rene Mark Ishan Allan Jin Regrets: Thomas Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 6

Completing my action item on issues 153 and 154 (RPT->token and AAT->nothing)
by Eve Maler 10 Aug '15

10 Aug '15

I created a (really huge) swimlane and a pro/con list, and a bit more... I ended up writing a recommendation. You can find the whole thing linked from here: https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h… Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 1

Fwd: Draft minutes of UMA telecon 2015-08-06
by Maciej Machulak 07 Aug '15

07 Aug '15

---------- Forwarded message --------- From: Maciej Machulak <maciej.machulak(a)gmail.com> Date: Thu, 6 Aug 2015 19:44 Subject: Re: [WG-UMA] Draft minutes of UMA telecon 2015-08-06 To: Allan Foster <allan.foster(a)forgerock.com> Allan, My 2 cents: 1) There is a proposal considered not to use this endpoint but just token endpoint (it's not fully accurate but good enough - the user endpoint can still be used in trust elevation) 2) Bob is not asked for consent to allow the client to provide specific claims to AS. It was just uma_authz scope. Maciej On Thu, 6 Aug 2015 19:29 Allan Foster <allan.foster(a)forgerock.com> wrote: > In the discussion there was talk of the new flow, and how we get Bob's > consent. > > It came to me that we are only talking about using the token endpoint, at > the moment. In order to collect claims about Bob, wouldn't we need to use > the User Endpoint? > > If so, this should happen early in the flow, and is where the actual > consent can be captured > > > Allan > > > > > On 8/7/15 1:05 AM, Eve Maler wrote: > > http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06 > Minutes Roll call > > Quorum was reached. > Minutes approval > > *MOTION:* Approve the amended minutes of UMA telecon 2015-07-30 > <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-07-30>. > APPROVED by unanimous consent. > APAC-friendly sync update > > This sync schedule is working really well. > Spec versioning process update > > No update. Eve hasn't moved the repo over. > Issue resolution work > > - Goal is to discuss and resolve issues 165/153/154 (all ranked #1) – > please review! > - Issues on GitHub > <https://github.com/xmlgrrl/UMA-Specifications/issues> > - UMA V1.0.1 issue nominations spreadsheet > <https://docs.google.com/spreadsheets/d/1s27E3JsHdvl_UzhGkQ8ZWP2dnyAXQAj5sxE…> > > Issues 153 and 154 > > Not meaning to guess Justin's exact thought process in any way... > > Observation #1: AS has a special "RPT endpoint", making up the entirety of > the special "UMA authorization API", at which the UMA client asks for a > special UMA "RPT" with authorization data on Bob's behalf, that acts > suspiciously just like an ordinary OAuth token endpoint. If it were more > like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved. > > Observation #2: The UMA "authorization API token" (AAT) is an extra layer > and hindrance to the entire OAuth-friendly cycle in this case, particularly > because it appears to require that Bob have a login at the AS. > > Discussion: Isn't the last bit, about the login, just an implementation > decision? He has to either be SSO'd into the AS, or have a local login at > the AS, or be offered a federated ("NASCAR-like" or whatever) login option > at the AS. More accurately stated, he has to be able to establish an > authenticated relationship with *Alice's* AS. > > Observation #3: If the AAT flow were entirely removed and the RPT endpoint > were turned into a ordinary token endpoint, then Bob's client would > approach it to ask for "an access token" (perhaps of some UMA-flavored > type?). > > Discussion: Eve contends that, since we are trying to keep everything as > much the same as possible, then this new "UMA-flavored grant flow" would > still (so far) have the the client approach the RS, fail, get a ticket, go > to the AS's (now) token endpoint, ask for a token, and engage in the trust > elevation flow we have already designed. > > Observation #4: Instead of using an AAT in the header of the token > request, it would use its client credentials to identify itself, basically > using its own recognizance. > > Discussion: Where else is the AAT required in headers? Is it required in > the redirect of Bob for claims-gathering? No, there are other security > measures imposed. What about in the case of an autonomous web service > client? We think that this could use pushed claims to the token endpoint as > well. > > More discussion: The AAT isn't very high-value! So a kind of "merge" to > elevate what was the AAT flow up into what was the RPT flow to become an > analog of a typical OAuth flow looks attractive. That means the claims flow > would be the very first thing Bob does – no AAT step before. That seems > kind of clean as a UX, if we're not missing anything like Bob's consent. > And we don't think we're missing that, because that's what the OAuth flow > is designed to do. The RPT represents everything the AAT did, but more. Why > didn't we consider this before? In fact, we did > <https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3>. > > More discussion: In both the authorization API circumstances and the newly > imagined grant flow circumstances, how does Bob know exactly what claims > the client is pushing? > > Observation #5: UMA is still OAuth++ or value-add or something, in that > the protection API that makes the AS and RS loosely coupled and makes > possible trust establishment between them (using OAuth) is added on top, > and in that Bob is a completely autonomous actor wrt Alice (which is why > the grant flow we're considering has trust elevation as a key part of it), > and in that the grant flow we're considering has asynchronicity as a key > part of it. All the value-add still seems to adhere even if the AAT isn't > part of the picture. > > Discussion: Regarding the Privacy concerns: if the Client does a POST on > the RPT to get the AuthzData added to it, the AS can still decide to return > a new RPT to the Client (if the presented RPT had AuthzData for another RS > attached to it). So that could be a AS-privacy setting? According to the > APAC discussion yesterday, the answer appears to be yes. We can use a MUST > to force the AS to mint a new token per RS. (Justin also noted in email > that if the client tries to present a token from RS1 for upgrading with > authorization data for RS2, the AS should not allow that.) > > Discussion: Is UMA all pseudonymity-based? The AS knows Alice by > AliceID(AS). The AS knows Bob through some set of claims, potentially. Each > RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous > federated ID by which both the AS and that RS know Alice. Each client has a > set of access tokens (in the putative new solution) with a set of > permissions, but not identifiers. > > Discussion: How would the client manage multiple access tokens? All it > knows is that it's trying to access a resource. How would it know that the > token it has been given is new for this RS? What if the spec said this > (bold is new)? > > "If the client did not present *a token* in the request for authorization > data, the authorization server creates and returns a new *token*. If the > client did present *a token* in the request, the authorization server > returns the *token* with which it associated the requested authorization > data, which MAY be either the *token* that was in the request or a new > one. *In any case, the authorization server MUST return a new token when > the client presents a token that is associated with a different resource > server.*" > > Summarizing our sense: Generally positive about most aspects, but there is > a concern about how clients handle the token situation, and some > uncertainty about ensuring that the requesting party really has a chance to > authorize the interaction. > > Next steps: > > - AI: Eve: Develop swimlanes (web sequence diagrams) of the putative > new flows, along with pros and cons, and share with the group by Monday. > - Let's TRY and have an active discussion, drawing in Nat, about the > client concerns, before next Thursday. > - Let's TRY and conclude issues 153 and 154 in the early part of next > Thursday's meeting. If we have a specific proposal in front of us for issue > 165, we'll consider it, otherwise not. We'll also take up 160, 161, 162, > and 168 next time. > > Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. > Ooh, next week is going to be tough for quorum, so everyone else please try > and attend if they can! > AI status > > - AI: Thomas: Review the charter for potential revisions in this > annual cycle. > - AI: Sal: Investigate IP implications of formal liaison activities > with other Kantara groups with the LC, and ultimately draft an LC Note as > warranted. > - AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve > to add to the FAQ, pointing everyone to the UIG. > - AI: Sal: Fill out IDESG form to have UMA adopted as a recommended > standard for use in the IDESG framework. > - AI: Mike: Write SCIM protection case study to highlight client > claims-based use case. > - AI: Maciej: Write as many sections for the UIG as he can. > - AI: Justin: Write a UIG section on default-deny and race conditions. > > Attendees > > As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, > Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) > > 1. Eve > 2. Andi > 3. Irwin > 4. Domenico > 5. Maciej > 6. Robert > 7. Mike > 8. Arlene > 9. François > > > Non-voting participants: > > - Adrian > - James > - Rene > - Mark > - Ishan > - Allan > - Jin > > Regrets: > > - Thomas > > > > Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | > Calendar: xmlgrrl(a)gmail.com > > > > _______________________________________________ > WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma >

3 3

Notes from UMA legal subgroup telecon 2015-08-07
by Eve Maler 07 Aug '15

07 Aug '15

Attending: Eve, Scott, Adrian, Dazza, Jon, Mark, Jim, Thomas, Tim Our schedule and deadline are meant to be a forcing function to align with UMA V1.0’s and V1.0.1’s needs. Eve read the draft mission statement in italic: Develop recommendations about resource owner-and-requesting party [Alice-and-Bob], resource server-and-authorization server [service-and-hub], and any other transactional relationships in the UMA environment, keeping in mind international jurisdictional friendliness; applicability to many different vertical and horizontal use cases, including health; and support of higher-level access federation trust frameworks and similar efforts. What does “transactional” mean here? It’s probably not a term of art, just a word. Scott could see substituting “interaction”, but it’s not strictly necessary. Transactions imply some formalism. When you have intermediation without being able to monitor the transaction fully, you have a problem. He has seen problems in supply chains where there are no measurements the middle. Reliability is a goal. The parties and intermediations need to be listed and understood. Eve described the overall goal of the exercise, from her perspective, is giving comfort to those interested in deploying UMA — in any size of “cloud” — that any sets of parties involved who have misaligned interests can nonetheless have enforceable and predictable ways to do it. Adrian’s take is a little different, but related: For those parties in a potential ecosystem who are *not* interested, he wants to create some kind of “safe harbor” that shifts liability appropriately away so that they will be willing to play along. He thinks these will be the resource servers in healthcare. Scott says this is two ways of expressing the same thing. Liability is just cost. Standardization of result, such as standard contracts, is one of the ways, to reduce such costs. Accelerate adoption! Reduce inhibitors! Dazza notes that the UETA, with the essential notion of actors and actions, is relevant. At the end of the day, you may have hundreds of intermediaries. A good place to start is the use cases, such as those Adrian sent. The selection of use cases inherently surfaces the parties of interest to us, and sets the prevailing context. Enumerating the transactional relationships is something we’ll have to do. What would deliverables look like to meet these goals, in order to be most effective? It may be too early for this. What makes a good use case? Generic UMA use cases count, as well as “things going wrong” use cases. These are like the “negative tests” in software testing. And we need success and failure conditions. In fact, all of the warnings you see on consumer goods are the result of something having gone wrong. (“Do not use this toaster while sleeping.” Samples: http://idiot-dog.com/disclaimer.html :-) Mark notes that the MVCR (Consent Receipt) work is getting to V0.7. There are some strong relationships here. Consent receipts are a species of transaction receipt, and since UMA is bristling with transactions, there are a lot of opportunities for receipts. If you add consent (a consent record) to a transaction, you can bind them. Adrian connects this to his use case that mentions “accounting for disclosures”, which Alice would want to hang onto for dear life, since it’s the only evidence that her data was shared — similarly to a confirmation number received when travel plans are changed. The correspondence to the logs of the servers where their own liability gets protected is a key element. Mark remarks that different UMA scenarios along the lines of “who owns the data” (at the resource server) may be an important dividing line. Adrian dislikes “data ownership”, other than RTBF. Scott thinks “data ownership” is a nonstarter, but “data rights ownership” could be workable. Next steps: - Anoint Dazza our GitHub wiki master — thank you, Dazza! - Begin use case collection and label them on wiki with “legal-*” labels for emergent categorization . AI: Eve, Adrian, and Mark especially: Contribute starter use cases . AI: Dazza: Explain in email how we engage on the wiki - Agenda for next time: . Remedial UMA flow explanation . Use case discussion and logging/receipts and data rights ownership . Licensure vs. contract Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: UMA legal subgroup telecon 2015-08-07
by Eve Maler 06 Aug '15

06 Aug '15

Fri Aug 7 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 <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 <http://kantarainitiative.org/confluence/display/uma/Calendar> We’ll get to know each other and mission-bash (see the previous message on that here <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/missio…>). Looking forward! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Reminder: 90min WG August meetings start a half-hour early...like 20 minutes from now
by Eve Maler 06 Aug '15

06 Aug '15

If you have a Skype handle, aren’t yet in our UMA Chat thread, and want to be there for meeting start reminders, ping me at “xmlgrrl” and I’ll add you. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from APAC-friendly UMA WG sync 2015-08-06
by Eve Maler 06 Aug '15

06 Aug '15

Attending: Eve, Allan, Colin, Paul, Gil, Nat The NZ POC is proceeding, and “going better and better”. ==== Looking at issues 153 and 154: The two-token idea seems attractive. One subtle change is that the old RPT contains permissions for, at most, that RqP, that client, that AS, a single RS, and all the ROs at that RS, whereas the new access token would contain permissions for, at most, that RqP, that client, that AS, all the RS’s connected to that AS, and all the RO’s using the AS that the RS’s are connected to. So the new element is the multiple RS’s. Right! If the RS introspects the access token, it’s inappropriate for it to get back any portion of the token that is targeted at other RS’s. It turns out we had to go back to UMA Core rev 03, not rev 05, to find the old two-token “HAT/RAT” model that did this: https://tools.ietf.org/html/draft-hardjono-oauth-umacore-03#section-3.3 “The AM returns the token's status in an HTTP response using the 200 OK status code, containing a JSON document supplying the token status description. The token status description either contains all of the permissions that are currently valid for this requester access token at the host in question (and thus for the requesting party on whose behalf it is acting), or indicates that the token is invalid (see Section 1.4).” It seems to break the claims/JWT model somewhat to have to filter the results of token introspection. Is there an elegant way to solve it? Allan suggests a potentially elegant way. Could the AS only ever hand out (or upgrade) access tokens per RS? We already do have language in Core that has the “feel” of what we want to achieve: https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.4 “If the client did not present an RPT in the request for authorization data, the authorization server creates and returns a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the requested authorization data, which MAY be either the RPT that was in the request or a new one.” We could use this style of spec language to mandate that the authorization server MUST (or, as a privacy consideration, SHOULD?) issue new RPTs/access tokens. SHOULD seems way too weak. Nat points out that it’s a security leak as well, since it’s a bearer token. Nat observes that in OIDC, you have the same kind of constraint, so this seems like a reasonable way to handle the constraint. Naturally, we noted, whatever token profile you define, it has to be opaque to the client. ==== Looking at issue 165: We poked around at the various disconnects here: RS’s don’t know anything about clients, by design. On the other hand, clients are operated by parties who aren’t the resource owner, and are generally expected to “take what they get”. On the third hand, clients might be capable of working with only some subset of scopes, and know better than AS’s what they can handle. The requested-permission-and-ticket flow is a natural place that suggests itself for extension, either for client hints to the RS or client requests to the AS. Another possibility, suggests Allan, is for the client to have a completely new and additional way to construct tickets (or, said another way, to request permissions?) of its own directly. We didn’t take this too far — just “woke up the topic” a little. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 3

Issues to be discussed in APAC-friendly sync and regular WG call: please read up
by Eve Maler 05 Aug '15

05 Aug '15

There’s a lively discussion going on in the GitHub issues. If everyone attending these meetings (and even *not* able to attend them) can please read up on issues 153, 154, and 165 at a minimum, and think, research, and comment as they see fit, we will be much better prepared to take action on resolutions. If you want to read ahead, issue 160 is also sitting there waiting for you. :-) https://github.com/xmlgrrl/UMA-Specifications/issues Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0