Should the AM have a binding obligation not to issue itself permissions silently?

[xmlgrrl]

An AM has the power, if not the right, to issue an RPT and permissions to itself in order to get access to a host. Does it make sense to add a Binding Obligation for the AM not to use UMA protection mechanisms to access protected resources of an authorizing user without explicitly consulting and abiding by policies set by that user? (It would seem to go without saying, but the entire Binding Obligations spec is meant for saying things that should go without saying.)

[xmlgrrl]

From UMA telecon 2013-09-19 (http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2013-09-19): Mark's message of Aug 28 (https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/BRYhi46pCj8) was about AS=C. The goal is dashboard-like functions. The dashboard gives insight about what's going on with information. Instead of just being about access controls, it can be helpful to see the data being managed as part of access. So the AS needs to be a C for the purpose of representing that data. The naive answer is that the AS would have to issue a token to itself. This seems inefficient.

The AS could have a "dashboard app" that is strictly a C to itself. It would have to perform UMA flows explicitly in this case, which seems inefficient because it theoretically has optimization opportunities around self-communication without going over HTTP, getting client credentials, getting an AAT, getting an RPT, asking itself for permissions, etc. Commentary: It would be nice if the RS could treat the AS's requests for this data exactly as if it were any other C; when it gets an RPT that happens to be from the AS-as-C, it introspects it or whatever in the 100% normal UMA way. Only the AS might want to change for optimization reasons.

We had previously identified a threat around bad-actor AS's doing this silently, without user permission. But could we put this permission in the realm of normal (possibly explicit) RO policy and/or the overall binding obligations environment in which the AS is operating?

Is the dashboard functionality such central functionality for an AS that we want to privilege somehow, possibly even going to the extent of putting some actual syntactic sugar in the protocol for this use case? It's a little bit like considering an AS-as-Disco-Service. Then again, we've previously resisted literally expanding the AS's scope. Should we continue to keep the scope of what an AS does "clean"?

Because complex analytics could be done by an AS, it could do important information management jobs if it had access to RS data. So access to this data isn't necessarily just about dashboard UX functionality. So we shouldn't limited the scope of what it could do with the data – it has a right to be a client doing "whatever" with the data is possible, just as much as any client!

The solution could be in the form of spec changes, best practices, profiling, binding obligations clauses, or "other".