[GNAP] GNAP Architecture and the role of the AS

[Justin Richer <[e-mail]>]

As discussed at the IETF meeting, the editors proposed that one of our next big topic areas was going to be the nature of the AS role within the GNAP protocol, especially how it relates to the device-driven use cases that have been brought up. Apologies in advance for the long post, but there are a lot of parts to this discussion that I’m hoping we can kick off here.

My core proposal is that we see the AS as the component that has the following properties:
 - receives delegation requests from the client instance for access to an RS via access tokens, and for access to subject information returned directly to the client instance
 - collects consent and authorization from the RO for the delegation
 - issues access tokens that its downstream RS’s can interpret (and validate/accept)
 - issues subject information asserted by the AS 

This framing of the parties is really important in making a consistent understanding of how the protocol works, and a consistent understanding is vital if we’re going to function as a working group in both discussing the problem space and executing the solution space. For a historical example, a naive approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to declare that the resource server is the thing the user is logging in to. This seems reasonable at first (and some people tried doing this) but it violates all kinds of trust boundaries and puts new expectations on the different parties that do not make sense. It stops looking anything like OAuth very quickly and turns into another protocol. If instead we say the user is logging in to the client, things suddenly make a lot more sense and we can do a lot more with it. (See this blog post from 2013 for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ <https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/>)

I think we’ve got a similar situation here when we start to talk about the user bringing their own AS with them. I think this is a reasonable-seeming assumption but it’s based on a false premise that the RO has to log into the AS to approve the request, and the AS has full control and view over everything in the network. While OAuth doesn’t require this, it’s largely assumed that’s how it works. After all, all of the early OAuth deployments worked exactly this way: the user logs in and clicks the “OK” button. However, cloud deployments have shown us that it’s perfectly reasonable for an OAuth AS to take in its consent and user information from an external trusted source, and so this model is not even accurate in OAuth.

In short, I think we can do a better job here of defining things in terms that both accept the reality we face and enable new ideas in ways that make sense. It’s my stance that the user shouldn’t need to bring the AS with them in order to have the kind of input and control of the system that people are asking for. Instead, the AS should be able to take inputs from things that the user controls in order for the AS to do its job.

People have discussed privacy concerns with the AS knowing “too much”, but in many of those discussions the knowledge is simply pushed to the RS instead. What I’m observing here is really just pushing portions of the AS role into the “RS” deployment. This doesn’t make it less of an “AS” role, it’s just being fulfilled closely to where the RS role is fulfilled. As such, my proposal is really not that different in practice, but the labels are different and better aligned with the capabilities of the protocol. 

We’ve previously talked about separating the user-facing portions of the AS into another component, and I think now might be the time to do that. This is a very flammable strawman proposal, but what if we had the AS defined, as above, and the “consent and authorization” gathering portion is augmented by another named component. Here let’s call it an Interaction Component. This can take several forms based on the kind of interaction mode in use:

 - Hosted at a URL the user is redirected to; it can then make the user log in, consent, and whatever else they need to do
 - Hosted at a URL the user will load separately and enter in an access code
 - An app on the user’s device that the user interacts with directly and which sends information back to the AS
 - An app reachable by a messaging endpoint that the AS sends and receives structured information from
 - The client itself that is given an indication as to what information the AS needs in order to fulfill the request; this could be MFA challenge/response, user credentials, signed claims, etc.

It’s the AS’s job to accept any and all of these that it supports and churn those into an access token. 

The AS itself doesn’t ever need to have the user log in. The AS doesn’t necessarily need to even know who the user is in any way. The AS just needs to know from a trusted source that the request is approved.

From a practical standpoint, I think this will have some small changes in how we talk about the components and how we talk about the interaction phase of the grant negotiation process. Everything I’m laying out here is currently allowed by the spec, but I think we’ve carried through the same assumptions from OAuth 2 about deployment that are both inaccurate and confusing. 

 — Justin