Versions Compared

Key

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

...

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:

Eve posed a couple of questions before having to drop:

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:

...

Ishan's notes (thank you!):

Regarding client unawareness of scopes: In Siteminder, clients were not aware of scopes, enterprise use cases...and continue that pattern. UMA's proposed change does not preclude clients from being unaware of scopes Mike is interested down the road in how this will allow the development of smarter clients and authorization servers. We are adding back OAuth-like flows around scope that make it easier for development of resource servers/APIs. For enterprise use cases, an UMA gateway may be easier to retrofit on top of existing APIs minimizing development.

Regarding the open issue on registering multiple resource sets: What is the combination of scopes/format for each resource set to determine the scope math? We need to specify a way for allow multiple JSON objects at registration, to allow for backwards compatibility.

A request for discussing the MPD proposal for the next meeting:

  • How does the client get the token? ( RPT endpoint -> token endpoint)
  • Client can specify the set of scopes, and determine scope set math
  • Splitting the claims presentation options, non interactive; need to involve the RqP that tells the client to send them to an endpoint at the AS
  • Ticket rotation - handle to the next part of the transaction; one time use
  • Minor proposed syntax changes

In the next meeting, walk the through the MPD sequence diagram to compare/contrast the current UMA flow with the proposed one to eliminate future confusion. (Justin will not be available next week, and will join the call the following week)

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)

...