UMA telecon 2016-11-18

Owned by Eve Maler
Last updated: Nov 18, 2016
4 min read

UMA telecon 2016-11-18

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-11-10 
  • Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
    • Next week: no WG or legal meeting due to US holiday
    • Week after: normal WG meeting on Dec 1
    • Week after that: Eve unavailable on Thu/Fri...
  • Work on UMA.next issues – Core is up to 08 and RReg is up to 01 – please review changes ahead of time if possible
    • Besides agreed and expected changes, main changes are:
      • Removed pat_grant_types_supported per proposal
      • "protection API token" --> "protection API access token"
      • "permission registration --> "permission request" (rhetorical and syntax)
      • "permission_scopes" --> "resource_scopes"
      • "resource set reg" --> "resource reg" (rhetorical and syntax) in RReg spec
      • Introduction text in Core (incomplete) – please especially review
    • To discuss specifically this time:
      • Briefly review Introduction and plan to include high-level diagram
      • Discuss "token profiling" proposal to:
        • Make token introspection permissions structure optional
        • Require its array to contain one or more values
        • Require AS to support token introspection
        • Require AS to support permissions structure
        • Recommend development of extensions for alternative introspection structures
      • Even if token introspection isn’t used, can/should we require the ability for a locally validatable RPT to operate at a “permissions” grain somehow?

      • Need to say something about RReg taking place in the context of a resource owner? Is it always done in that context? Doesn't it depend on the RReg security mechanism used?

      • Set math: See 9-29 and 10-6, and the email thread – including...
        • What scopes should the client ask for, and why? (E.g., least-privilege rationale.) What should the mechanism be for asking for scopes for specific protected resources?
        • What permissions should the RS request on behalf of the client, and why?
      • claim_token_profiles_supported: My proposal was to keep this profiling mechanism, but clean it up and provide two actual profiles or at least credible examples, say, for OIDC ID tokens and SAML assertions. Discussion?
      • uma_profiles_supported: My proposal was to keep this profiling mechanism, but figure out seriously if the extensibility profiles are doing the right job, and include credible examples of extensions and not just extensibility profiles. Discussion?
      • Is step-up auth the way it was conceived in UMA1 hunky dory according to the claims collection mechanism in UMA2?
      • Need to have IANA registry entries for both old uma-configuration and uma2-configuration?
      • Shoebox endpoint
      • Claims hashing
  • See the latest swimlane
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2016-11-10: Deferred.

Logistics

The agenda is starting to include even the minutiae of the issue backlog and the roadmap. It looks long, but is designed to keep us honest in gaining consensus on discussion topics. If people show up to meetings and review spec drafts, we'll push through everything on a good schedule.

No meetings next week.

Work on UMA.next issues

The RReg definition of a protected resource goes too far because it presumes an RO. If we soften it to mention just an AS, then we think that the RReg spec is generic enough to serve OAuth needs along with UMA etc. needs. Let's try that.

Eve asked an aesthetic question about the sample endpoints in the config response. If anyone would like to see them looking different send mail with your preference.

The entire abstract and Introduction are new (and is awaiting a new ASCII diagram). PLEASE review and comment.

Discussion of Eve's strawman proposal: James likes the idea because, what if you want to mix UMA and OAuth scopes? You can't expect a client to maintain multiple access tokens where there are AS's supporting multiple grant types that deal with incompatible tokens. This is where getting Implementer's Drafts out there would be really useful. You could include OAuth scopes in an RPT now with no UMA permissions, but the permissions property would still have to appear with nothing in the array; that's ugly.

If the AS gives the RS a locally validatable RPT, normally the format of the token would be considered in the realm of a "private communication" between them, and it would be considered a burden to impose constraints on that. In the interest of making possible the new Intro text's promise that "The token introspection extension lets the resource owner increase and decrease grants at a grain finer than a whole access token.", do we want to say that the AS MUST/SHOULD/MAY package up locally validatable RPTs as signed versions of the token introspection object? Maybe we just point this out; it's the obvious object to sign if you want that functionality.

AI: James: Send a note to the list about the question of a locally validatable RPT and whether to recommend something about its format.

What scopes should the client ask for, and why? The client knows nothing about resource IDs and in particular nothing about any of the resource IDs associated with the permission ticket it just brought to the AS, only about the API and presumably about the scopes possible on the HTTP resource to which it just attempted access. This client-AS request is the first step in the UMA grant, and we can tell because the client is coming to the token endpoint with a permission ticket. Let's say the ticket has R1, R2, and R3. They all have "view" available, and R2 and R3 have "print" available. There are OAuth-protected resources at the same RS that have scopes that overlap. Is it possible to have a hybrid client-AS request at this stage? Is it possible to be executing two OAuth grants at the same time? Eve hasn't heard of this before, and we do already have an invalid_scope error in place to protect against scope clashes of the sort imagined. This may mean that our hybrid UMA-OAuth scenario above wouldn't work anyway.

AI: Eve: Send a note to the list laying out the current situation wrt scopes.

Instructions:

  • RReg 02: Soften "protected resource" definition and any similar passages to remove the insistence that an RO is required for protection to obtain over a resource.
  • Implement the token introspection proposal.
  • Sketch a Sec 1 Intro diagram.
  • Revise the Sec 3 intro and sketch an ASCII diagram for it.

Attendees

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

  1. Eve
  2. Maciej
  3. Sarah

Non-voting participants:

  • James
  • Arlene
  • Kathleen

Regrets:

  • John W
  • Sal