Attendees:
Non-voting participants:
Main simplification assumptions are:
Maciej explains what scope registration means - Host communicates to the AM all the resources that they are managing that need protection. Scope defines the resource, describes the things you can do to a bunch of stuff e.g. from OAuth. (JB says it's claims based access, others says it's groups) Scope also refers to AM resources access as opposed to Host-based access. This prompts Maciej to provide an overview.
John Bradley digs into understanding the scope and registration issues - asks if it makes sense to exchange the keys and the (? - missing) in the initial OAuth flow.
Maciej describes the UMA flows and presents an introduction to UMA. JB asks about dynamic PEP/PDP and remote validation. JB asks about opaque tokens so the host knows which AM to talk to. Maciej says that this can be a problem. JB says that making the assumption that the host knows is a bad design choice.
JB brings up a great point: if the requester is talking to a non-human requester vs. a human requester.
Rainer brings up an enterprise use case - where the administrator sets the policy, and the user executes the policy. Herve explains that there is a use case for this and that this is baked into UMA. JB reiterates this in an enterprise context and discuss that this can be done through claims. Herve explains that you look at claims as if they are protected resources. JB another way to look at this can be like a Secure Token Service (STS).
JB points out that UMA is just one way to transform one type of token into another.