On Fri, Aug 17, 2018 at 4:54 PM, Adrian Gropper <agropper@healthurl.com> wrote:

On Fri, Aug 17, 2018 at 8:46 AM, Pedro Igor Silva <psilva@redhat.com> wrote:

On Fri, Aug 17, 2018 at 1:34 AM, Eve Maler <eve@xmlgrrl.com> wrote:

<SNIP>

Fourth, Adrian, you bring up the challenges of client app trust, particularly in the context of a loosely coupled AS and RS (which UMA has done a lot of deep work around, but which is starting to creep into the OAuth WG's thinking a bit now too). If there were outputs from the meeting in DC that describe the requirements around warnings, can we take a look? It's a bit odd to say that it's the RS that doesn't trust the client app, given that the RS doesn't really have a relationship with the client; the AS does. (The AS is what issues and checks client credentials.)

Don't know about the requirements, but yeah, we can take a look :)

Agree that AS is the main authority. But I think RS can also decide whether or not a client is trustworthy. Even if backed by information from AS. For instance, what if RS only allow access from Client X if authentication level is Y ?

I see this as out-of-scope for UMA. UMA is a delegation protocol. The RS is free to implement any set of protocols including authentication of the requesting party but I cant't see how UMA can possibly cover the range of business and jurisdictional mandates that could impact an RS decision to override an authorization. That is a very deep ocean. I'm not sure UMA even covers the protocol for the RS to notify the AS that it has been overruled regardless of why.

I agree, Adrian. I'm mainly considering "enterprise UMA" use cases.

 

Adrian