- WG-UMA - mailman.kantarainitiative.org

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 … [View More]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 [View Less]

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?) … [View More]

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 … [View More]

2 1

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, … [View More]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 [View Less]

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 … [View More]

1 0

FYI, new UMA draft profile for the UK DWP
by Eve Maler 05 Jan '17

05 Jan '17

The UK Department of Works and Pensions is working on an UMA profile <http://bit.ly/2iIVqoY>. The DWP Digital Group's Head of Secure Service Design Mike Pegman (mike.pegman(a)dwp.gsi.gov.uk) is the author; he's been getting some peer review from various folks in the linked doc. I've been asked to pass along this opportunity for y'all to take a look and provide feedback yourselves. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

05 Jan '17

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

1 1

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

05 Jan '17

Can’t make it today John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the … [View More]

1 0