Is the AAT unnecessary?

[jricher]

The Authorization API Access Token serves only to connect the requesting client to the authorization server over the specialty RPT endpoint (see #153). Why can't client credentials be used here instead, like at a normal token endpoint transaction?

Ostensibly, the authorization server could use the requesting party bound to the AAT to make its token issuance decision -- however, all guidance in the spec indicates that the decisions should be made on the basis of supplied claims which the requesting client has to either gather out of band or provide directly. As such, the AAT doesn't provide any additional value.

Furthermore, issuance of the AAT over a normal OAuth transaction is problematic as the requesting party, Bob, likely doesn't have an account on the authorization server. Supporting this would require the authorization server to either allow all external users to engage in OAuth transactions (unlikely) or to have a special-cased codepath for just the uma_authorization scope. (See mitreid-connect/OpenID-Connect-Java-Spring-Server#852 for an implementation-specific take.)

Suggested fix: remove the AAT alltogether and rely on client credentials and claims for issuing the RPT (as in #153), otherwise be very clearly explicit in the spec about the requirement the requesting party to be able to authorize tokens at the AS, which would likely limit UMA's usefulness to single security domains.

[gffletch]

The AAT isn't just about client credentials but also includes the requesting party (i.e. user). In some cases it might be only the client, but in many of the user-to-user sharing cases it requires the RqP. I suppose it might be possible to do this back-channel with client-credentials and an id_token the Client received when the user logged into the Client, but that is an optimization path that has yet to be explored.

[jricher]

That's my point though -- the claims required to be presented by the client already cover the RqP, so I'm not seeing that the AAT actually adds anything to the transaction in that case. You don't know that the RqP is present on the connection even if the AAT is valid, you just know that they did the introduction. But why limit client introduction if you're allowing dyanmic registration?

[gffletch]

But it isn't required that the claims required to be presented by the client include the RqP, so in that context the RqP in the AAT would be useful.

[jricher]

Perhaps, but to me that sounds like an optimization for a specific use case at the cost of the general mechanism.

[gffletch]

I believe the thinking was more the along the reverse position... since the RqP will likely be needed in most RPT requests, and the RqP is already part of the AAT, then why not just get the value from there rather than requiring it to be presented again in the "claims negotiation" phase. The case where the RqP is NOT required is the less likely case and that could be defined a slightly different flow.

[jricher]

But that case still requires that the RqP be able to mint tokens at the AS. This functionality is currently impossible in our own server unless everyone's in the same domain (ie: everyone has an account at the AS).

[gffletch]

Ahh... my expectation here is that an AS could allow a user to create an AAT without establishing an AS "account" by leveraging a external IdP the AS trusts to establish the RqP identity. This may be the important part of this thread.

How does an AS create an AAT with an RqP without requiring the RqP to create an AS "account/identity"?

[jricher]

You would need to enable an external identity like you said, but since our AS is also a general-purpose OAuth server, we don't want to allow all external users to mint all tokens. See mitreid-connect/OpenID-Connect-Java-Spring-Server#852 for details of where we're tracking it in our own project.

[xmlgrrl]

For reference: In Core Sec 1.3.2 (https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.1.3.2), the AAT represents the tuple AS-client-RqP. Specifically: "An AAT binds a requesting party, a client being used by that party, and an authorization server that protects resources this client is seeking access to on this requesting party's behalf. It is not specific to any resource server or resource owner. The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server. The authorization server is able to manage future processes of authorization and claims-caching efficiently for this client/requesting party pair across all resource servers they try to access; however, these management processes are outside the scope of this specification."

[xmlgrrl]

Regarding George's question, “How does an AS create an AAT with an RqP without requiring the RqP to create an AS "account/identity”?”:

An AAT is an OAuth token with a scope of uma_authorization, plain and simple, so if it’s “three-legged”, it reflects an authorization relationship that you pretty much assume is based on a user’s account/identity. For different deployment ecosystems, the source could differ. E.g., where RqPs are professionals (health trust frameworks?), maybe it’s from SAML-to-OAuth SSO bridges. The AS need not strictly do its own authentication.

I could imagine that a “dumb client” that is only ever capable of redirecting the RqP (rather than a "smart client" that can push claims), interacting with a type of AS that never caches claims (which means that RqP must be redirected afresh to supply them every time), could build a "two-legged" relationship (based on client credentials alone) and not require the RqP to consent to anything at all. We do already have the concept of an RqP-as-organization that uses a client credentials flow, though I believe this would be a novel application of the flow to the semantic. Not sure of all the implications (in terms of protecting the interests of the RqP or anything else).

[jricher]

I understand the intent, but having implemented this myself it's a very real problem. With the claims-based system, I don't think it's even necessary. A "dumb client" could easily present organization-based claims, which is an argument that I've heard for keeping the direct claims presentation system. It's only ever used for this one transaction, and I think that it can be removed without harm to the rest of the protocol.

[xmlgrrl]

After further research "back at the ranch" (customer use cases and dev team), here is further input from ForgeRock, offered with my participant hat on. Sorry for being prolix here -- just trying to run through the logic carefully.

Just as there is a variety of identity federation topologies possible, there is similarly a variety of access federation topologies possible, on a continuum. At one end ("widest ecosystem"), there are many entities of every type and services run in many domains; resource owners have full choice of which entities they use; and all relationships must be forged dynamically and in a user-directed fashion. At the other end ("narrowest ecosystem"), a single authorization server figures prominently as a trust anchor; relationships radiate from it; and relationships don't extend as far out into the world.

We are currently gaining experience with many use cases in the narrower-ecosystem range. This is not to deny the importance of the wider-ecosystem cases, it's just to establish the requirement. In these narrower cases, there is no question whether requesting parties have have a relationship with the authorization server: they do. The (three-legged) AAT does exactly what it was designed to do in this case: let the requesting party grant authorization for the client and authorization server to engage in using the authorization API. It can be silently granted where (as noted earlier in this thread) an employment relationship, or similar, carries their agreement ahead of them.

As noted in the initial issue report, there are costs in wider-ecosystem use cases to requiring requesting parties to have to authorize tokens at the AS. Effectively, a lot of RqPs will end up having to create some kind of local or federated (say, social) account at the resource owner's authorization server. RqPs could hate the proposition, the UX for them could be ugly, the scale implications could be ugly for the RO's AS, etc.

We agree it's important to offer an alternate option in the spec. The client credentials grant looks like a good possibility (and we note that it's already strictly allowed by the current spec, so it's not technically a breaking change to call this out). We would contribute the following discussion points:

• Is the client credentials grant typically used for clients that are operated by humans? Is this an acceptable use of this grant flow? http://tools.ietf.org/html/rfc6749#section-4.4 If for some reason it's not, what would an alternative be?
• In the case of no persistent RqP identity at the RO's AS, we'd expect the client to have to push all the information needed every time (or redirect the RqP), with no AS caching of anything interesting. We're okay with that.
• In the case of no AAT, there would be nothing on record anywhere of the RqP's consent or authorization to have any claims silently pushed about them. The closest analogue would probably be the client's unilateral (wrt the RqP) promises about its behavior by virtue of an agreement with the AS or membership in an access federation trust framework, probably as captured in issuance and use of client credentials. We would probably need to address this point somehow in the privacy considerations section.