- WG-UMA - mailman.kantarainitiative.org

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 1

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

Calling for comment on 254: Hashed claims discovery
by Eve Maler 08 Jan '17

08 Jan '17

We haven't discussed this one yet, but 254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery is a proposal from Justin (and Sarah, I believe) for communicating to a client enough information about the desired claim value(s) so that it can supply the right claim(s) the AS is looking for, without exposing too much of the RO's policies, and without the client pushing too many of the RqP's claims to the AS. So the idea is for it to be mutually (well-roundedly?) privacy protective in the context of a hinted pushed-claims scenario. The issue thread includes a use case. This one needs some discussion about the why and the privacy considerations along with the how (which may be straightforward but hasn't been spelled out yet). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4

Regarding resource Server permission request
by Cigdem Sengul 08 Jan '17

08 Jan '17

Thanks, it was an interesting discussion. Regarding “ The resource server has discretion over the extent of access covered by the request (see Sec 3.3.3); … even a lesser extent. “ Is the following scenario possible? - Client asked resource 1, scope A, B, C. - RS registered a lesser extent, due to edge protection, i.e., resource 1, scope A and B. - RO has a policy that allows A, B and C for this resource for this client With the ticket, the client approaches to RS, and asks for scopes A, B, C in its request. This would generate an invalid_scope error as the requested scopes do not match the ones in in the ticket. I believe this is what was discussed in the call: giving the client a clue about what scopes have been registered in the permission ticket. In this case, client got an error. If it did not include any scopes in its request, it would still not get scope C. RO cannot do anything about it. Does this mean - RS and RO need to resolve this offline? - RO is trying to give a scope on a resource that is not under its authority? Or The RO would never be able to give a permission that allow C on resource 1, in the first place? Thanks, Cigdem Sengul, PhD Senior Researcher [cid:image001.png@01D26780.DAFB68F0] Website<http://www.nominet.uk/> | Twitter<https://twitter.com/Nominet> | Facebook<https://www.facebook.com/nominet/> DD: +44 (0)1865 332256 E: cigdem.sengul(a)nominet.uk Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom Nominet UK. Registered in England and Wales No. 3203859 This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. --Cigdem

3 2

Calling for comment on 264: Authentication-related error details and 263: Claim token profiling
by Eve Maler 06 Jan '17

06 Jan '17

Bunch of discussion going on in issue 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>. Issue 263 <https://github.com/KantaraInitiative/wg-uma/issues/263> is somewhat related though it's seen no discussion yet, so I'll take the opportunity to mention it here. I think we can figure out both of these by next week (said the optimist). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Caching, OAuth, UMA, and security considerations
by Eve Maler 06 Jan '17

06 Jan '17

In our 2016-11-10 telecon <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10?…>, we said: *"Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already.* - *Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher."* So I poked around the OAuth spec to see if there's similar wording I could align with, and discovered this in Sec 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>: *"The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"."* So...I believe this means the client isn't allowed to cache tokens given to it by the AS, and maybe the RS isn't allowed to cache token introspection responses given to it if the token introspection spec follows along in this pattern. But the RS is allowed to cache tokens that the client brings to it because this isn't an AS response, but rather a client request. And if it has locally validated those tokens, it can hang onto the results as long as it wants as well. I looked a little further, at the OAuth Threat Model spec, and there's potentially some broadly suggestive text in Sec 4.6.6 <https://tools.ietf.org/html/rfc6819#section-4.6.6> about both clients and RS's using Cache-Control: private to protect against leakage through HTTP proxies, but nothing more directly relevant. Some specific questions for people to react to: - Is my interpretation above about the RS's abilities correct? With an analysis of who can cache what completed, would anyone agree it might be helpful to put the result into the spec as a "Note" observation so others don't have to repeat the exercise and possibly get it wrong? - Our spec says it "mainly relies on OAuth" for security considerations. Does this mean we must pick up on the prohibition against the AS letting the recipient cache things? I don't think so because it's in the main body of the spec. - Do we therefore want to *add* similar wording for the same security reasons OAuth itself has that wording? - What exactly should our security consideration about TTL of permissions and RPTs say? I think it should cover the circumstances of both local validation and caching. I could use wording similar to what our telecon notes say, but the trick is that the RS doesn't have access to the policy conditions. However, it does have "Adrian clause" rights it may want to apply, so we could mention that. - In fact, I'm starting to think that a more extended discussion in the Federated Authorization section about this concept -- the fact that the RS retains "edge (local?) authorization" rights -- would be useful to point to from more than one other location in the spec, including this new Security Considerations section. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

5 7

No UMA legal call tomorrow (Friday)
by Eve Maler 06 Jan '17

06 Jan '17

Sorry for doing this at (sort of) the last minute, but since I'm working things on the back channel with Colin and don't have news yet, let's not hold the UMA legal call tomorrow. I'll remove it from the calendar now. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Proposal: Schedule WG calls for 8:30-10am on Thursdays through Feb 9
by Eve Maler 05 Jan '17

05 Jan '17

In the last year we've pretty much avoided extending our calls as we traditionally used to do during crunch times. But it occurs to me that to get through our issue list, including some potential new design questions, it would be awfully useful to extend our calls during this period. Please respond in this thread if you can generally attend if we extend the calls in this way (tacking 30 minutes onto the beginning). I would count the first 30 minutes as more "ad hoc" than "quorate" if really necessary, but think it would help tremendously if we could get enough people on to continue working through and discussing issues and lining up propositions for the top of the "first real hour". *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0