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

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

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, 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

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 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

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 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