Audience, scope & purpose

[arndt-s]

From IETF chat: "Scope, audience and purpose claims all limit the transaction token but at different levels. I wonder if this can be simplified?"

Workload developers that validate transaction tokens currently would need to validate all 3 of these claims just for the sake of knowing if the transaction token is acceptable in their context. Authorization decisions based on azd and rctx then come on top of that.

[gffletch]

I'm a little confused regarding the inclusion of scope as 'scope' is only an input parameter to the Transaction Token Service and that parameter name is used because of the profiling of the Token Exchange spec.

The transaction token itself only has aud and purp and the point of using a different name than 'scope' for purp is that the semantics are slightly different. A transaction token should have a very fine-grained purpose and most scope values are not fine-grained.

A workload should only need to validate the aud field to know that the transaction token is part of it's trust domain and secondly the purp claim to evaluate if the stated purpose is something that the workload participates in. Not also, that a workload is not required to process the purp claim from an authorization point of view. I can depend on what the request is and risk, etc.

The intended authorization model is that the Transaction Token Service acts as a primary PDP when issuing the transaction token and then each workload can run it's own policy (if desired) to further evaluate the validity of the request.

[arndt-s]

You are right @gffletch, scope is not part of the transaction token and just a parameter of token exchange that results in the aud claim.

My thinking during the talk was whether aud is truly necessary. Once the signature check has passed (either based on issuer claim + metatabase + JWKS or trust bundle) the trust domain is implicit IMO. Also, what if the signature check passed but the audience does not match with the signing keys? Are workloads expected to check and deny then?

Related, do we expect workloads to just accept transaction tokens of a single trust domain or do we see use cases where incoming transaction tokens are part of different trust domains than the workload itself?

[gffletch]

So a couple of thoughts... I do think that aud is necessary as it's possible there could be multiple issuers that are all part of the single trust domain. For me, this makes the audience an easier way to determine the validity of the token to the workload.

As for transaction tokens that cross trust domain boundaries, I don't think we want to enable that. I'd prefer we leverage the cross domain OAuth work and the wimse token translation work to get a transaction token issued by the trust domain.

We may need to expand some thinking around authorization models and how they fit in with transaction tokens.

[obfuscoder]

Note: Although scope may not be part of the TraT definition, we decided to include the scope value in our implementation. For us, this value should at least be validated by workloads if there isn't a more specific purpose given in the TraT.

[gffletch]

@obfuscoder is there a reason you chose not to just set the purpose of the given TraT to the scope ? Semantic mismatch?

[obfuscoder]

@gffletch We had already an implementation of transaction tokens in place before we became aware of the transaction token draft. Our implementation was a bit more aligned with Token Exchange where the scope is copied (or narrowed down) to the internally used transaction token. So most deployments rely on having the scope in the "scope" claim. There is also pretty good library support for the scope claim already.

That said, it might not be an issue of semantics, but rather of ownership. At least in our implementation, scope values are defined (and owned) by the services which enforce the scope (also in internal calls using transaction tokens) when the internal microservice interface is called. Purpose, on the other hand, is more bound to the use case which needs to be fulfilled and the definition of those use cases will rather be done by the external endpoints (BFFs) and thus also owned by them. The internal microservices will then need to be configured to support purposes defined by several external endpoints. So it might still be worth, having the microservice check the scope it defined to be present when calling its API on top of validating the purpose.

[tulshi]

I've worked in environments earlier where the name "scope" in internal tokens caused enormous confusion with OAuth scopes from external systems.