January 2017 - WG-UMA - mailman.kantarainitiative.org

271: Add 'description' to scope document / 271: Add description to resource description
by Eve Maler 17 Jan '17

17 Jan '17

271 <https://github.com/KantaraInitiative/wg-uma/issues/271>: Add 'description' to scope document 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: Add description to resource description Mike suggests a definition of the property, in the scope case, could be something like this: description OPTIONAL A human-understandable explanation of what granting the scope means. So these would be the long-form explanation vs. the name. Often such fields are paired together. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

270: Resource Registration Document: 'uri' should be an array / examples
by Eve Maler 17 Jan '17

17 Jan '17

- 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>: Resource Registration Document: 'uri' should be an array / examples Please go and read, and comment on, this short but thought-provoking issue. FWIW, in some HEART-related discussions, the question of when, why, and how to register resources and the efficiency of doing so have been coming up, so I thought this was timely. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document"
by Eve Maler 17 Jan '17

17 Jan '17

- 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document" This is the first of a series of RReg issues I'll send in email, thanks to Mike S's reportage (thanks for that). Mike asks: "I was contemplating the above... and wondering what you mean by "resolve." If the URI is a URN, then you just mean it must be defined somewhere? And why can't the URI be a collision-resistant string?" Also: What if there is a scope description document, but the link fails, what happens? What if there's no document at all? What are the error conditions? What are the fallback mechanisms? Should this really be a MUST, after all? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

260: Cascading authorization servers: more detail
by Eve Maler 17 Jan '17

17 Jan '17

Here is the additional information I received about this proposal, captured as issue 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers. Please see both the description and the attached swimlane. ==== Please find attached a detailed sequence diagram for the cascaded authorization’s main flow —i.e. when both upstream and downstream ASs are involved. As for introspection, it is an interesting case. I think the downstream AS must be able to adapt/modify the upstream permissions (scopes) according to its overarching policies and combine its own permissions (scopes) with those received from the upstream AS using some kind of a configurable “introspection combining strategy.” Alternatively, it can be left to the implementers to simply decide what they want to do —although I think it must be noted in the specs as an important decision that the downstream AS must make. The decision on the validity of the RPTs is similar. I think the validity of the downstream RPT must not exceed the validity of the upstream RPT on which basis it is issued, but again, this is something that can be left to the implementers. In my current demo implementation, the downstream server simply passes on the same permissions (scopes) from the upstream server and the introspection results trickles down unmodified. But this is just a decision I made to keep things simple for this demo, while setting aside a module for “introspection combining” which currently is a simple identity function. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Set Math Discussion
by Justin Richer 17 Jan '17

17 Jan '17

I’ve been working on the set math problem and I’ve been trying to lay out scenarios using this spreadsheet to help me sort my thoughts: I’ve left a bit of space in the spreadsheet for additional combinations and use cases I might have missed, so please chime in and we can figure out an algorithm that we can all agree on. I can send out the .xlsx file if people care to play with it at home. So we’ve got six sets of scopes to deal with here, and they’re somewhat independent of each other. ClientReg - client registers for these scopes at the RS RSTicket - RS requests a ticket with these scopes ROPolicy - RO sets a policy with these scopes (and it’s fulfilled by the RqP for our purposes) ClientReq - client requests these scopes at the token endpoint RSReg - RS registers these scopes at RS setup time PrevRPT - client presents a previously-held RPT that’s got some other scopes on it and it’s trying to augment that with new scopes And finally what the token includes: RPTResult - the sets that the resulting token includes on output The one direct relationship seems to be that: ROPolicy = subset(RSReg) Because otherwise the RO could set scopes on a resource that the resource didn’t register, which doesn’t make sense to me. That’s the error in column “F” above. It’s clear to me that “ROPolicy” is a limiting set, in that if a scope is NOT in that set, then it is not in the result. In other words: RPTResult = subset(ROPolicy) That’s column D, and nearly any other combination without ROPolicy doesn’t let the scope go through, with one exception: if it’s in PrevRPT, it gets carried through no matter what. But in particular, that, I believe, is an AS decision on whether it wants to honor previous RPTs at all. That’s why I’ve coded those K, L in green. This also means that RSReg is also a limiting set, due to transitive subset operations: RPTResult = subset(RSReg) We have both the client and RS request scopes for the token at runtime in their parts, and it makes a lot of sense to combine them. So we get a working set of: Requested = union(ClientReq, RSTicket) We have an open question with what to do with column I: if a client hasn’t requested a scope, and a ticket didn’t request a scope, but the client registered for a scope, do we include it or not? We could choose to either ignore it and leave it out entirely; or add it in, and if it passes ROPolicy then we’ll pass it through to the token. These were the options we were discussing on the call on Thursday. Ignoring it here would effectively ignore the client’s registered scopes entirely, which is valid. The alternative would be coded something like: Requested = union(ClientReg, ClientReq, RSTicket) This could also be done conditionally, like the case where the client didn’t specifically request anything: if (empty(ClientReq)) { Requested = union(ClientReg, RSTicket) } Or if the client or ticket didn’t request anything: if (empty(ClientReq) && empty(RSTicket)) { Requested = ClientReg } So my proposed implementation would be something like this horrible pseudocode: if (ROPolicy is not subset(RSReg)) { throw error and fail <<sanity check>> } << the requested set is made up of the client’s request to the token endpoint and the RS’s request during the ticket issuance step>> Requested = union(ClientReq, RSTicket) << if nothing’s been requested, maybe the client’s registered for something we can default to >> if (empty(Requested)) { Requested = ClientReg } << finally, we take the requested scopes and filter out anything not in a matched policy, and add in anything from a previous RPT if it’s there >> RPTResult = union( intersection(Requested, ROPolicy), PrevRPT) I’ve tested a little bit of this with the following python truth table code: from truths import Truths print Truths(['ClientReg', 'RSTicket', 'ROPolicy', 'ClientReq', 'RSReg', 'PrevRPT'], ['(((ClientReq or RSTicket) if not (ClientReq or RSTicket) else ClientReg) and ROPolicy) or PrevRPT']) This seems to match up to expectations on a quick inspection, but I’m potentially missing something. Hopefully this makes sense, and this reflects my current thinking on this topic. I have almost certainly missed some use cases and might have some cases that don’t reflect reality. — Justin

1 0

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

13 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05>: APPROVED by unanimous consent. UMA V2.0 work *Set math:* Justin intended for ROPolicy to stand for the result of AS postprocessing of any policy conditions with which it has been configured. George intended for ROPolicy to stand for policy conditions prior to any AS processing. This may be moot for the math. Justin considered the math to be contextual to the resource set because of his implementation outlook, but George wants to ensure that, if the ROPolicy isn't sufficient to meet the requested policy, need_info (or "worse", definitive failure) is produced. Eve notes that "RO" policy is really a set of policy conditions that could have come from a collaboration between the RO and the AS; see, e.g., the TTL section <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html#rfc.section.…> . In George's example, Alice has policies that should result in *Bob* not getting access to *download* because he's not a family member. Let's think of *ROPolicy* instead as *PolicyResults*, (or even *AuthorizationProcessResults*?) and the value should be just *(view, share)* . Given Justin's interpretation that we're accepting, George's example set math stays the same, and the "determine which scopes are in play" section changes like this (*download* got removed, with no net change to the bottom line), and it should say "*...based on claims collected and the authorization assessment performed*": Scopes = intersection(Requested, ROPolicy) Scopes = intersection((view,share,print),(view,share)) Scopes = (view,share) James proposed ClientRegisteredDefaults vs. the original OAuth ClientReg as a convenience/clarification. George thinks we don't need this because it's more of a burden on the client. The client knows it's dealing with whatever API and its scopes. Registering ahead of time lets it reduce its interactions at access attempt time. If we drop ClientRegisteredDefaults, it's incumbent on the client to register ahead of time. Looking at the steps: 1. This now becomes: *Requested = union(intersection(ClientRegistered,ClientRequested), RSTicket)* If ClientRegistered OR ClientRequested is null, then RSTicket becomes all-important because the others won't get the client anywhere. If ClientRequested contains anything not previously in ClientRegistered, it gets dropped on the floor. 2. This is all part of the assessment process. Combine steps 2, 3, and 4 because they're all in this general area. 3. The pseudo-spec-text would change to say "*...scopes for which RqP (and client) has satisfied authorization requirements*" or something like that – with claims? figure out wording. We need a phrase that stands for the RqP-and-client. Would "requesting side" do? 4. This is the part of authorization assessment the AS would do if it's preparing to give a need_info error or maybe a request_submitted error (?). If it's preparing to give one of the other errors, it can dump out to those. 5. This would change to be* error*. 6. This would change to be *success*. This will need, in addition, the math that says what to do in the case that a previous RPT was supplied and was returned upgraded. We have consensus on all the set math modulo previous-RPT handling. Editing instructions: - Think up a phrase for "requesting side" and apply where necessary - Add spec text for everything but *previous-RPT set math*. - Implement the #264 decision where applicable. - Add to the extension grant type registry <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#par…> *AI:* Everyone: Read the new set math spec text carefully ASAP when it's available, and implement if you can. *264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details:* Justin ran through the swimlanes he provided in the issue thread: with a local user <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgVU1BIFN0ZXAgVX…> and with a remote IdP, using OIDC's auth code as example <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgVU1BIFN0ZXAgVX…>. George asked about registration. If the RqP doesn't yet have an account, they'd have to do that step, right? Yes. Mike's question in the thread had been about login. There's a distinction between the (UMA) client and the AS as a claims client/RP. Eve insists on getting it on the record [image: (smile)] that pushed claims with secondary audience fields using pre-established trust are a legitimate, on-label use of ID tokens. No disagreement, but also noted that doing a lot of hinting around what other claims to push is not likely to be used in such ecosystems. Using redirect_user immediately on failing a plain request for an RPT is likely for the case where the AS intends to handle all the claims collection. We have the UMA Implementers' Guide, where we could discuss things like achieving strong authentication. Or we could provide an example in the spec of profiling down to ACR values. *AI:* Eve: Ask Mike Pegman if he has the strong authentication use case. *(The official call ended and we continued for a short while.)* *Authorization interface and UMA grant:* The spec is currently schizophrenic. The whole authorization process is the UMA grant, not just the client's interaction with the token endpoint. This means Figure 1 is wrong and Sec 3.6 is right. The preconditions for starting with redirection are that the client needs a ticket and the AS has to have statically declared the claims interaction endpoint (plus all the other stuff for entering Sec 3.6, which is the generic stuff for starting with approaching the token endpoint). *AI:* Eve: Seek stylesheet help from Maciej/Oliver (and/or the xml2rfc list?). *254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery:* Eve is wondering whether, in certain ecosystems where pushed claims have been pre-negotiated a la SSO with attributes, hinting specifically about needed claims is being used/going to be used. We should ask around about whether this is being used. This bears on the question of hashed claims discovery as a feature for consideration, since it could be added as an extension or in a V2.1. As an in-band hint, it's there to be useful to wider ecosystems. And if the AS were to say redirect_user on failing client-provided hints, that would suggest that a really colossal closed-ecosystem failure could be mitigated by something kind of surprising on the AS's part. *AI:* Eve: Ask for instances of required_claims usage. *AI:* Eve: Send out some new cascading authorization server information from VA. AI: Eve: Send emails for the next issues to discuss. 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. Eve 4. Mike 5. Maciej 6. Sarah Non-voting participants: - George - Justin - JohnW - James - Colin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

No Legal subgroup telecon tomorrow
by Eve Maler 12 Jan '17

12 Jan '17

We've succeed in finding the expertise we were looking for to work on our precursor deliverables, in batches, so what I suggest is that we wait until we can take a look at batch #1 before meeting again. I'll keep an eye out for such news, and *each Thursday* I will either *announce the news in the form of an agenda* or *cancel the Friday call*. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-01-12 (note: new drafts are up)
by Eve Maler 11 Jan '17

11 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-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 2017-01-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05> - 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 11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html> and RReg is up to 04 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html> - Issues closed: 108 <https://github.com/KantaraInitiative/wg-uma/issues/108>, 234 <https://github.com/KantaraInitiative/wg-uma/issues/234>, 249 <https://github.com/KantaraInitiative/wg-uma/issues/249>, 261 <https://github.com/KantaraInitiative/wg-uma/issues/261>, 262 <https://github.com/KantaraInitiative/wg-uma/issues/262>, 268 <https://github.com/KantaraInitiative/wg-uma/issues/268> - Also tried out Justin's wording for how the AS and client handle invalidating/revoking an old RPT when the AS hands back a new RPT – see Core rev 11 Sec 3.6.6 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html#give-rpt> - *Please see new issues!* We'll discuss as necessary next week; please comment online: - 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>: Add 'description' to scope document - 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>: Resource Registration Document: 'uri' should be an array / examples - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document" - Issues to *discuss and close on this call*: - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (quick) - 254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery (quick) - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math (hopefully we'll have some spec-like wording to guide us further by tomorrow) - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically authorization interface vs. UMA grant concept - Issues to *discuss and hand out assignments for*: - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically a definition for and handling of the access token/claim token situation - 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: 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 - Easy issues to *close by Tue Jan 7 if no comment by then*: - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically whether to rename PCTs - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Proposing to pull in the timeline slightly on the "easy issues" (to next Tuesday instead of next Thursday)
by Eve Maler 11 Jan '17

11 Jan '17

If we went all the way to next Thursday, I couldn't incorporate any relevant changes into the next spec rev for consideration. So let's please make the deadline next Tuesday, January 10 vs. next Thursday, January 12. That will allow me to assess whether to put anything on the agenda, change what goes into the spec, etc. As a reminder, this week's agenda listed these as what I'm calling "easy issues": - 261 <https://github.com/KantaraInitiative/wg-uma/issues/261>: Caching token inspection results (take the action recommended) - 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? (take no action) - 108 <https://github.com/KantaraInitiative/wg-uma/issues/108>: Protection and authorization scopes implicit/recommended vs. MUST? (take no action) And I've just put up a fourth one that falls into this category as well: - 268 <https://github.com/KantaraInitiative/wg-uma/issues/268>: Fix cascading error around client authentication (take the action recommended) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Scopes and Resource Owner policy at the AS
by George Fletcher 10 Jan '17

10 Jan '17

Hi, I wanted to start a different thread that relates to the "set math" discussion but is more focused on the relationship between resource registered scopes and resource owner policy (ROPolicy). Please correct any incorrect thinking that follows:) In order for a RO to define policy for a given resource, the RS must first register that resource set with the AS. When the RS registers the resource set with the AS, the RS defines what scopes are allowed for that specific resource set. The RO can then go to the AS and find the resource set and define policies that link to the scopes associated with the resource set. Following on my example from the "set math" thread, lets say my photo service registers two resources: rsid_1: photos/gff/landscape scopes: view, link, download rsid_2: photos/gff/family scopes: view, link, download, print When I (as the RO) go to the AS, I'm assuming that I get to define the policy for each of the scopes associated with each of the registered resource sets. Now in practice, I suspect that as the RO, I want an AS that allows me to define sets of claims and then map those to the scopes associated with the different resource sets. Lets assume I've defined the following policy claim sets at the AS. family -- list of individuals that are part of my family photo_viewer -- promises to not download/sell/market any photo I then map the above policies to the resource sets and scopes as follows... rsid_1: view, link -- photo_viewer download -- family rsid_2: view, link, download, print -- family Now, when the client tries to access photos/gff/landscape the RS registers a permissions ticket with scopes for "view" and "link" but not download. The client then presents the permissions ticket to the AS and the AS determines which claims the RqP needs to meet in order to be authorized for those scopes. In this case, both scopes require the same claims (photo_viewer). Now, if the client requested the "download" scope in addition to the scopes in the permissions ticket, then the RqP must meet the family claims in order to get access to that scope. I'm assuming we are leaving it up to the AS to determine whether to fail the RPT request if the RqP can NOT meet the family claim, or return "view" and "link" but NOT "download". The latter feels more like OAuth2 though I'm guessing in more complicated cases this could get dicey:) So RPT request processing at the AS should, I think, be determined by the intersection of the set of scopes defined for the resources set and the set of scopes requested. Simplifying slightly from Justin's set math... scopesToProcess = intersection(Requested, RSReg) The AS then needs to iterate through the "scopes to process" to determine the claims the RqP needs to meet in order to grant an RPT with that set of scopes. for each scope in scopesToProcess { claimsRequired += claims(rsid, scope) } normalize/merge claimsRequired Once the required set of claims is defined, the RqP/client can go through claims negotiation. Depending on which claims are met, the associated authorized scopes can be determined. claims met == promise to not download/sell/market scopes authorized based on claims met view, link If the set of authorized scopes is NOT a super set of the scopes requested in the permissions ticket, the RPT request fails. Otherwise, return the scopes authorized. In this context, I don't think the PrevRPT provides much value, however, a token defining previously satisfied claims provides a lot of value. Does that resonate with how others envision the logic and flow working? Thanks, George -- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544

1 0