Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UMA telecon 2017-02-02

...

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-01-26 

  • Logistics:
    • Next week is our last scheduled 90-minute meeting; extend?
    • No meeting Feb 16 because of RSAC

  • UMA V2.0 work

    • 2016 roadmap / GitHub issues for V2.0 (all issues to be kept here for the duration!) / dynamic swimlane
    • Core is up to 13 (no change) and RReg is up to 05 (no change); expect Core 14 before the call
    • 266: Set math / resource and scope ecosystem
    • Discuss and clear the RReg issues
    • 260: Cascading authorization servers
      • Discuss Mohammed's input
      • Decide next steps
    • Claim token profiling: 263: Claim token profiling / 119: Create an IANA registry for URIs that stand for claim token formats
  • AOB

Minutes

Roll call

Quorum was not? reached.

Approve minutes

Approve minutes of UMA telecon 2017-01-26: tbsDeferred.

Logistics

  • Next week is our last scheduled 90-minute meeting; extend?
  • No meeting Feb 16 because of RSAC

tbsCurrently our Core spec is inconsistent; we can't publish a WG draft for Last Call in this state.

UMA V2.0 work

266: Set math / resource and scope ecosystem:

What is the deal with the Protected Resource Metadata spec? Eve wondered if it has a hint of something in it that would be valuable for our current discussion. Just relates the history: Mike J created a "throwaway draft" just to save the idea somewhere on the Internet. The notion is to prevent a client from sending a token to a rogue endpoint. In the AOL case, if the Mail team creates a new endpoint, it's a way to have loose coupling and dynamic discovery of endpoints. But George agrees that the OAuth WG is not taking this up as a work item.

Eve's specific idea about the usefulness of the static declaration approach vs. the active registration approach was that, if OAuth is chosen as the security mechanism for the RReg endpoint (and OAuth is an awesome security mechanism), that choice requires a binding of whoever/whatever the resource owner is – natural or legal person (individual or enterprise) – to the resources. Static declaration allows the resource to be generic, without any RO context.

Proposal: Instead of having the RReg spec with a resource description document that passes the resource description by value and the scope description by reference (or a simple scope string), we develop a OAuth protected resource metadata spec that suffices for our needs, and then incorporate the RReg API into the UMA spec such that the RReg process simply binds a generic resource and its possible scopes together in an RO context with the PAT. Could this be achieved by simply extending Swagger?

But then the client, in order to request scopes, would need to know about resource IDs as well. But that was why Eve went in this direction; a smarter client should be this smart. Eve's fear is that our design where clients only know about scopes will incentivize design of APIs and scopes in the exact same direction that OAuth does now:

tbs

Spec instructions:

...

pushing APIs to put all the "juice" into scopes, the way Salesforce does, so that a client with only id scope can ask for chatter_api scope. In FHIR, if you have read scope and ask for write scope, you might get it added to the three resources you already had in your RPT, but you can never request access to other resources you didn't already have access to except by attempting access to them, thus hinting to the RS that you want them. Eve's proposal using the "scenario 3" approach in the WSD is akin to the direction Phil had sketched where the token is bound specifically to resources (actually, the RPT already is, but the client doesn't know it).

In scenario 2, if we have a case of CandidateGrantedScopes that's partial, and the AS got a previous RPT, 

Discussion: Are we clear about not choosing scenario 3, "super-smart client"? Ishan: The client would have to know the RO in some fashion. Yes, presumably OOB. Agreed. Kathleen: The RO might have set policy that requires the client (and presumably the RqP) to meet various clearances; that's all still true. Yes. Summary by George: What we'd "lose" if we don't go this route is to potentially access a new resource without first attempting access to it. Eve adds: Whatever existing encouragement there is in the current OAuth design center for scopes to have a lot of power, there still is, but there isn't any further power in that direction. Mike: We could have potentially avoided some round trips in the messaging, but our spec schedule would take a hit. George: But we can extend the token introspection endpoint, maybe add a hint, to improve the current messaging.

We have consensus not to go the super-smart client route for now.

Justin notes, as the token introspection spec editor, that the notion of the hint was yanked. But you can add parameters on the request. Adding the permission ticket seems unreasonable since it's meant to be ephemeral.

We have a couple of big decisions to make right now, then:

  • Efficiency of the RS permission request / response to client loop
    • We seem to have two loops where we have optimization opportunities:
      • James's:

        • 10 RS requests resourceA(scope1, scope2)
          20 AS issues RPT resourceA(scope1)
          30 RS introspects RPT, finds insufficient scope for request, GOTO 10

      • George's:
        • The normal flow is client access attempt on R1, get ticket, go to AS, get RPT valid for R1; go to R2, get ticket, go to AS, get RPT valid for R2. We could say: On the R2 pass, we could say that the AS should check the previous RPT to see if it works for R2 already before going through the existing assessment logic. It would be on a different endpoint, not baked into the existing assessment logic flow.
        • Ishan observes that there's no harm in having the AS do this, as it's internal logic.
  • Effect of PreviousRPT on authorization assessment

Open questions:

How does the AS deal with partial results? Specifically, is PermissionTicket inviolable?

How does the RS deal with rejected requests? Specifically how can it optimize? (James)

How does the PreviousRPT affect set math?

(optional) Can the AS optimize dealing with a previous RPT prior to engaging in assessment logic?

Publishing UMA endpoints in Swagger/OpenAPIs: Does anyone want to research this? Justin speaks against; some others may be interested. Mike will look into it. OpenAPIs.org. IPR compatibility is a question.

Ad hoc meeting on Tuesday during the same 90-minute period as today: George, James, Eve, Domenico, Kathleen?, Cigdem?, and Mike can attend.

Attendees

As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)

  1. tbsDomenico
  2. Eve
  3. Mike
  4. Cigdem
  5. Sarah

Non-voting participants:

  • Justin
  • George
  • Adrian
  • James
  • Kathleen
  • Ishan

Regrets:

  • tbsMaciej