UMA telecon 2016-12-15

Owned by Eve Maler
Last updated: Dec 17, 2016
7 min read

UMA telecon 2016-12-15

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-12-01 
  • 5min: Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
    • Dec 16: Legal subgroup meets as usual
    • Dec 22: meet as usual; RSVP – Dec 23: no Legal subgroup meeting
    • FYI: End game for V2 specs looks like this:
      • Complete drafts ASAP in January
      • WG vote to publish Draft Recommendations (consider this an "implementers' draft"?)
      • 45-day Public Review
      • If no changes, LC votes to certify Draft Recommendations for All-Member Ballot
      • Ballot takes 14+ days
      • If no changes, Recommendations are prepared for publication and published
      • Total: if no changes, up to 90 days
  • Work on UMA.next issues – Core is up to 09 and RReg is up to 02 (no changes from last meeting)
    • Till bottom of the hour: Presentation of new use case/profile proposal: Use Cases for FHIR Security Authorization with Patient Consent (aka "cascading OAuth")
    • Set math (see active email threads)
    • Remove policy-specific resource/scope description properties from RReg and add as extensions in Core?
    • claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML?
    • uma_profiles_supported: What to do with the extensibility profiles?
    • Need to have IANA registry entries for both old uma-configuration and uma2-configuration?
    • Shoebox endpoint
    • Claims hashing
    • Other issue backlog review/cleanup
  • See the latest swimlane
  • AOB

Minutes

Roll call

Quorum was not reached.

Critical mass was reached.

Approve minutes

Approve minutes of UMA telecon 2016-12-01: Deferred.

Logistics

  • Dec 16: Legal subgroup meets as usual
  • Dec 22: meet as usual; RSVP – Dec 23: no Legal subgroup meeting

Who's not available for next Thursday? Andi, Cigdem, François.

Work on UMA.next issues

 Use Cases for FHIR Security Authorization with Patient Consent (aka "cascading OAuth"):

Mike Davis is the security architect for the Dept of Veterans Affairs. Kathleen, Mohammad, and Tony are on the security architecture team and have been working on enabling patient choice. What they'll show is what they've been working on for the HIMSS '17 conference. They've developed a profile that integrates patient and enterprise access control systems. Kathleen notes that Adrian has articulated the "multiple portals problem" in the past.

The Word document linked from above "cascades" authorization decisions. This version of the doc makes both parts OAuth-based, where the token expires within a period of time. They had demonstrated UMA in 2015. This next level is where there are multiple authorities governing access – different sources of policy.

The VA is a US federal agency. As such, it makes its IP available freely.

The notion is that there are at least two AS's. There is an external third-party authorization server connect to a consent directive management system. A "consent directive" is an authorization policy stored in a FHIR server in FHIR-dictated form. That's not UMA, but a FHIR server has the capability to query that in order to enforce a decision.

The flow starts with a client requesting some data. The client is redirected, or is hinted to go to the local AS, where it asks for an RPT. At this point, the overarching policies in the organization are checked. It's determined whether the patient's consent is needed. If so, a second hint is produced after the token is issued, and it proceeds to get a "patient consent token", which here is called an RPT. Verification and introspection later needs to take place, with each relevant AS. Data labeling and transformation subsequently takes place, which is not related to UMA.

They have a beta implementation of this right now.

Adrian: What is the resource that is being registered? There's the HEART profile, and the Argonaut profile. These talk about what you're supposed to register in terms of the permission structure. What goes into the scope portion is basically the security labels. If you're only supposed to have non-confidential data, that goes in. The resource ID portion, according to the spirit of HEART and other profiles, that gets registered is Alice/Medication, followed by the necessary clearances. It's a standard UMA server. What connects the AS's is the patient identity. This allows finding the relevant policies that the patient has filed.

Eve: If these are UMA AS's, are these all RPTs, and are the hints all need_info hints? This is still classic UMA, and this is all being done with permission registration (which would now be called requesting permissions on behalf of the client), only having a different party making the request. Eve suggests that a next step could be a detailed message flow for the swimlane and numbered list on pages 11-12 of the Word document.

Colin: Encourages looking at Consent Receipts as well.

Eve: Is this a way for an RS to constrain what an RO can share so as to control its liability in a technical, vs. just legal fashion? Kathleen: Yes, but it's also a way to ensure central patient policy information management of their own policies per se, not just have a central administration point.

Next steps: Decide if we want to make this a part of UMA2.

Set math:

Decision 1: What to do when the client has pre-registered parsimoniously but the rest of the scope ecosystem has been more generous?

  1. Client pre-registers for scopes at the AS (dynamically, or out of band, or updates a previous registration, etc.)
  2. Client attempts access, nominally "using some scope" by virtue of making an API call
  3. RS requests one or more permissions on the client's behalf
  4. Client requests an RPT, possibly explicitly requesting one or more scopes
  5. (At some point) RO configures the AS with some policy conditions, which would ultimately grant the client (on the RqP's behalf) some permissions with some scopes
  6. AS grants the client (on the RqP's behalf) permissions with some scopes

1a. What if, in #1, client registers for only A, B, C, but in #3 and/or #5, the AS gets the idea that it's supposed to grant a permission that involves scope X?

1b. What if (given the RO/RS context above), in #4, client requests X even though it only registered for A, B, C?

Note that there is no requirement that a client has to pre-register for scopes. And there's no hard semantic for scope pre-registration, so the act doesn't necessarily mean "I can handle only these scopes". And we can fast see the day coming where scope pre-registration becomes so awkward because of its implicit association with only some resources in many OAuth-protected APIs that resource pre-registration will become available (scopes are explicitly associated with specific resources in UMA already).

Eve had tried a "least privilege" strawman in email was to mask out scope X from any client that didn't pre-register for it. But we can't seem to think of a reason to deny granting that permission. Mike S could imagine a really paranoid trust model that would have the AS deny granting it, though.

So do we want to be deterministic, or continue to allow the AS to use discretion? E.g., see the wording in Core V1.0.1 Sec 3.5.2 about partial fulfillment of scopes vs. rejection. Ishan: At least coming up with a maximal list of scopes and saying it's okay to mask it or not would be more deterministic. If an UMA AS is also an OIDC OP, would conflicts arise? We don't want that.

(The WG call officially ended, and Eve and Cigdem continued.)

1c. What discretion or determinism should there be around #3?

In Core V1.0.1 Sec 3.2, we currently say that the RS has to request a permission that at least suffices for what the client attempted. Of course, there is even some discretion in figuring this out. But it still seems practical to continue requiring the RS to request something minimally sufficing, and then – because it alone is authoritative for resource boundary management and complexity – enabling requesting of multiple permissions (that is, multiple resources) as required or desired, along with multiple scopes on those resources, based on its judgment as we have been saying all along. It's a matter not only of resource boundary management but also of stinginess/permissiveness.

Client pre-registration of scopes seems so discretionary and so unclear as to its purpose that we think it shouldn't  be relied on as any guidance towards UMA normative text. Maybe in future, it might be more meaningful if an RS could register its resources for protection in a way that allows clients to pre-register for resources with scopes (generically, outside of an RO context). But for now, this isn't possible. At that later time, we could extend UMA to allow clients to request specific resources when asking for an RPT in #4. We're not willing to define this mechanism as an extension to dynamic client registration, or as an OOB mechanism.

(Or are we? A way to do it either dynamically or OOB would be to use something like the optional RReg type property (see RSR V1.01. Sec 2.2.1), or an extension scopetype property or whatever, to convey the generic resource type you mean. From there, you could drill down on the scopes you mean, with an array. Etc. A client could use an object that leverages all this stuff to pre-register in some fashion for the specific scopes it can handle. Probably way too ambitious for UMA2, but there's an obvious path for how to extend it if someone wants to do this.)

The way we're heading in our logic, #4 – the client requesting scopes – is something that's kind of unattractive because of this scope/resource skew. However, we had made this decision to add it because OAuth allows it, and because of the presumption that the client "knows its own mind", has to know the API, and therefore has to code to the scopes. Should we consider the above analysis to be sufficient new information to make us reconsider the new functionality we've added (client requesting scopes at the token endpoint, and the associated invalid_scope error)? Or should we consider it directly relevant to the AS's calculation, as in 1b above? It's a kind of dynamic addition to whatever is in the permission ticket. 

The client – presumably acting on behalf of the RqP no matter whether the RqP is human or enterprise – has two opportunities to express the latter's wishes, or perhaps three. In #1, pre-registration for scopes is an act that takes place outside of any RqP's context, so that has nothing to do with the RqP, so let's not count that. In #2, the client actually attempts access, so that's a direct expression of a wish for access of a particular kind to something, directly at the RS itself. So we should take that very seriously (and do, according to the discussion above). In #4, the client currently has the ability to request scopes, a la OAuth, though we haven't been super-clear about the semantic of such a request: is it on the RqP's behalf, or is it on the client's own behalf, or what? Our previous discussion leading to this decision leans more on the side of the client's own behalf, connected somewhat to things like pre-registration. So, how much do we actually care – in set math reality – what the client requests at token-endpoint run time? Is it more important than pre-registration for scopes, and if so, by how much?

AI: Eve and Cigdem: Draft sample spec text for "set math", with a choice point between client scope request effect options.

Attendees

As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)

  1. Andi
  2. Eve
  3. Mike S
  4. Cigdem
  5. Sarah

Non-voting participants:

  • Andrew
  • Ishan
  • Adrian
  • François
  • Kathleen
  • Scott F
  • Mike Davis
  • Jin

Guests:

  • Tony Mallia
  • Colin Lurking
  • Mohammad Jafari

Regrets:

  • Sal
  • James
  • Domenico

Â