Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

UMA telecon 2016-06-16

Date and Time

Agenda

  • (Eve needs to leave a bit early)
  • Roll call
  • Approve minutes of UMA telecon 2016-06-02
  • MPD: Still working through the sequence diagram
    • Client awareness of scopes: replay/conclude discussion at CIS breakfast BOF and on the list; any negative impacts in the dev/business owner relationship?
    • Get-a-token loops
    • Next steps on spec text
  • AOB

Minutes

Roll call

Quorum was not reached.

Ishan will take notes after Eve drops.

Approve minutes

Approve minutes of UMA telecon 2016-06-02: Deferred.

MPD

We're looking at the set of scopes involved in step #4 from last meeting.

Note that a "client-to-AS-first" flow is not part of the MPD change proposals, so let's not discuss any of that now.

Take the scenario that the client attempts access with API call "foo", which could represent usage of scopes A, B, C, D, and E. Think of the example of OIDC, where accessing an email address potentially corresponds to the specific claim, "openid", "email", "address", and "profile". (Imagine that OIDC is UMA-protected in this instance.) Another example could be a photo service that allows viewing, printing, drawing a mustache, etc.

Do we want to mandate that the RS register a permission that is totally deterministic in terms of how many scopes it registers for the relevant resource set? Justin prefers that the spec give guidance to the RS to register the set of scopes that appear to correspond to the actual client access attempt. Suggested wording: "It is RECOMMENDED that the RS register a set of scopes with the permission ticket that would allow the client's request to succeed." This is close to our current wording, except that it's not a MUST, and would allow less scope than would suffice. 

What would the various rationales be for the RS registering more, less, or exactly the same as what the client attempted? We can't prescribe scope design, nor the relationship between the RS and client. Since we're planning to make it possible for the client to request more scopes, it should be possible for the RS to register fewer scopes.

Now, a philosophical question: Are we injecting into UMA something that's been seen as a detriment in plain OAuth? It's been seen as a business benefit that UMA up-levels to the business owner the semantics of scopes. Do our permission registration and RSR processes help with this?

Also, we have an open issue around registering multiple resource sets. How might we accommodate that? Can we just take it up later?

 

Swimlane edits needed:

  • tbs

Spec edits needed:

  • tbs

Attendees

As of 12 Jun 2016, quorum is 7 of 13. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah)

  1. Domenico
  2. Kathleen
  3. Sal
  4. Eve
  5. Mike
  6. Sarah

Non-voting participants:

  • Justin
  • Ishan
  • George
  • Adrian
  • James

 

  • No labels