UMA telecon 2016-12-22

Owned by Eve Maler
Last updated: Dec 22, 2016
3 min read

UMA telecon 2016-12-22

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2016-12-01

  • Logistics

    • This is our last meeting of the year
    • Refer to telecon 2016-12-01 minutes to see how voting/balloting process goes

  • UMA V2.0 work

    • 2016 roadmap
    • Core is up to 09 and RReg is up to 02 (no changes from last meeting)
    • Dynamic swimlane
    • Complete set math decisions today: see email proposal
    • Proposal for "the rest of the issues to consider/take out of the backlog"; let's decide the final list by our first meeting in January and figure out our completion roadmap:
      • Use Cases for FHIR Security Authorization with Patient Consent ("cascading authorization servers")
      • Shoebox endpoint/"audit whether RS gave access per permissions" (issues 24, 224)
      • Hashed claims discovery (issue 254)
      • Issues that came up in editing:
        • What is the proper way to complete the specification of the UMA grant? e.g., how do the client's credentials actually get used in the flow?
        • 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?
        • What to do with the extensibility profiles?
        • Need to have IANA registry entries for both old uma-configuration and uma2-configuration?
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2016-12-01: tbs

Logistics

  • This is our last meeting of the year
  • Refer to telecon 2016-12-01 minutes to see how voting/balloting process goes

Regarding what to include in V2.0 work, Ishan brings up the RS's need to pass requirements for minimal authorization to the AS. This seems to be the only addition to Eve's proposed list so far for our final V2.0 work. There's support for seeking a set of WG drafts.

UMA V2.0 work

Set math: In the question of discretion applied by the RS during its permission request compared to discretion applied by the client during its initial access attempt: What's the motivation of the client? What's the motivation of the RS? Justin has proposed wording in the past that recommends requesting enough permissions for the request to succeed, which softens the previous requirement. Eve and Cigdem discussed the notion that this seems like "bad faith", since the (100% untrusted) client can only communicate one thing at this point: "I want resource X with Y scope" (or rather, some kind of resource among some set XX with YY scope). Eve notes that XACML expects the PEP to transmit a faithful representation of the application's access request to the PDP as an authorization request.

What are use cases for the RS to reduce the permission request vs. adding permissions and/or scopes? Should the RS be completely dumb and send no scopes at all when it requests permission? If it didn't do this, then suddenly the client's pre-registration for some scopes A, B, C and its potential dynamic addition of scopes X, Y at RPT request time become a lot more "normative".

Reminder: A "permission" is "Authorized access to a particular resource with one or more scopes." Now it's possible to request more than one permission on behalf of the client.

(The formal call ended and Robert and Eve continued discussing.)

Different APIs design their resource boundaries and scopes differently, so perhaps it's not a good idea to discriminate between what an RS can do with one vs. the other. Adrian had suggested earlier that it's good advice to say that the client should ask for as few scopes as possible, for least privilege reasons. The same is likely true for the RS requesting permissions. But is less than what the client asked for a case of least privilege?

Can we park the notion of changing things drastically for now (e.g. removing the RS's current capability of requesting scopes on permissions) and come back around to it?

What about this notion of equitable risk and responsibility distribution?

The client, representing some RqP, which are initially 100% untrusted and seek partial trust at maximum:

  • Can pre-register for scopes with the AS and can dynamically request scopes on every RPT request
  • Can attempt access differentially on tokenless attempt #1 and RPT-bearing attempt #2 at the RS

The RS, which outsources resource protection to the AS but has the right to apply "edge protection" (the "Adrian clause" but strengthened to apply to the beginning of the chain):

  • Is allowed to request permissions and scopes on behalf of the client that are smaller that would allow the initial access attempted by the client (Justin's proposal)
  • (This logic could be applied to allow "cascading authorization servers" to enable the RS's risk management vs. the RO's wishes)
  • ...

The AS, which is accountable to the resource owner and RS for resource protection:

  • Is allowed to reject or partially fulfill RPT requests

AI: Eve: Send out note with revised set math proposal.

AI: Eve: Publish rev 10 and rev 03 for people's holiday reading pleasure.

Attendees

As of 20 Dec 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Mike, Cigdem, Sarah)

  1. Domenico
  2. Robert
  3. Maciej
  4. Eve
  5. Mike
  6. Sarah

Non-voting participants:

  • Adrian
  • Ishan
  • Justin

Regrets:

  • Cigdem
  • James
  • Andi
  • Sal

Â