How do internal services authorize the Transaction Tokens?

[appsdesh]

Can we clarify in the examples how do internal services authorize the Transaction tokens?

1. Are all the internal services bootstrapped with the token service public key?
2. How do internal services know the boundaries of the trust domain or whether is it part of it?

[tulshi]

You can use something like SPIFFE to establish internal trust between services. The public key for the TraT service can be delivered as a part of the trust bundle.

[gffletch]

So one though is that if the Transaction Token has an ‘iss’ claim then the public key should be discoverable. I don’t think that has to be the only way to obtain the public key but it is one way systems could do it. This obviously doesn’t need to be done on every request.

[PieterKas]

Proposal: make the iss claim mandatory and then reference existing mechanisms to discover public keys (maybe from jwks?). Also allow for other mechanisms to discover. General idea is to use the iss claim to discover the public key.

[obfuscoder]

I don't like to make iss claim mandatory. If all services operate within the same trust boundary, they already know their trusted authorization server and an iss claim would just add clutter and unnecessary data to the token. Also it would mean that one had to already trust some data within the transaction token before being able to validate its signature. This could lead to a rogue component to send requests to an internal service with carefully crafted transaction tokens with an iss pointing to another server the rogue component has control over. To prevent injecting rogue iss, the internal service would need to validate the provided iss value with a preconfigured list of allowed ones.

In our environment (trust boundary) where we are using internal tokens for transactions, the internal services have the authorization server's host name configured. Internal services can decide to pull (and cache) the jwks from the well-known url and validate the tokens locally or they can use the token introspection endpoint of the authorization server for validating the token. Validating the internal/transaction tokens with token introspection is useful for some sensitive operations and has the benefit that this validation can fail if for instance the access token the transaction token was derived from got revoked or the authentication context associated with the tokens got flagged.

[tulshi]

@obfuscoder 's point about all services in the same trust domain know the issuer and putting the iss field adds clutter is valid. We can make that field optional in the draft. I believe it is required right now. Section 5.2.1.

Even if we made this claim optional, we should still note the point about validating the iss claim so that it prevents external issuers from being trusted by internal services in the Security Considerations section.

[obfuscoder]

As the required iss claim is now replaced with the required aud claim, there should be some validation guidelines for this parameter.

In the absence of the iss claim, discovery is not available and either SPIFFE or preconfigured URLs of the TTS and/or its JWKS is possible.

[tulshi]

we have made iss optional now, after much discussion, so closing this issue.