Transaction Tokens for S2S calls

[dteleguin]

Cryptographically protected Txn-Tokens ensure that downstream workloads cannot make unauthorized modifications to such information, and cannot make spurious calls without the presence of an external trigger.

What about legitimate (non-spurious) calls without the presence of an external trigger?

A transaction might be initiated by an internal component (e.g. triggered by a scheduler). In this case, there will be no external context (req_ctx) and no user (human) identity. However, transaction details (purp and azd) might still be relevant.

Can TX Tokens cover this use case as well? The benefits will be unified token issuance and verification process for both external- and internal-initiated transactions. The only alternative in the OAuth world I could think of is the Client Credentials Grant, but it doesn't specify how to push transaction-specific data. Also, the result will be an Access Token and not a Txn-Token, which assumes that downstream workloads must be able to understand both.

Maybe slightly unrelated, but it is also a bit unclear how should we communicate the desired azd and purp to the Txn-Token Service? Or is it assumed that everything should be derived from the external token + rctx?

[gffletch]

Transaction Tokens can definitely be used with legitimate calls that don't have an external trigger. The key element from an authorization perspective, is "who is allowed to request an transaction token" and "for what purpose(s)". If any service can request a transaction token, then it's important to limit the scope of how that transaction token can be used. In other words, we wouldn't want the logging service to be able to request a transaction service for the purpose of transferring crypto from a user's account.

I would argue that there is still a req_ctx in this case, it may just contain different claims. I would expect downstream systems to want to know the originating workload that requested the transaction token.

As for azd, I agree that there are use cases where that needs to be specified to the Transaction Token service.

Great points on areas where we need to enhance the specification.

[obfuscoder]

Reviewing this issue, I can see a relation with #62. As it has been established that requesting Txn-Tokens without an external trigger is needed. however, the current spec requires an Access token to be presented in the subject_token parameter and the question is, how an internal batch process would obtain this. @dteguin (and me in the related issue #62) mentioned Client credentials grant for obtaining the AT. However, client credentials grant based ATs may not be related to users referred to with the sub claim, so it may be a challenge to issue Txn-Tokens with a user-related sub when the client credentials grant based AT does not contain one.

In #62 I gave an example where a batch processor might be able to present an expired Txn-Token, but there are still scenarios where no AT can be presented in the subject_token parameter or where the presented subject_token does not contain the information necessary to fill and issue the Txn-Token. This information needs to be provided somehow to the TTS. If this information must be part of the subject_token or somehow be obtainable by the TTS via parts of the subject_token content, it should at least be mentioned in the spec.

Personally, I'd like to see an option where the TTS can be called without a subject_token as input and instead providing the necessary information via additional parameters (e.g. sub within the req_ctx). It goes without saying, that this type of Token issuance should only be allowed to a very limited set of authenticated clients which have a special trust relationship with the TTS.

[tulshi]

I agree that the subject_token can be an optional field in the TraT request. We should update the spec to say so. We can discuss this issue on Friday 2/2

[dteleguin]

As per RFC 8639, subject_token and subject_token_type are required. Do you think we can "override" that in this spec @tulshi ?

[tulshi]

We could agree on some placeholder to avoid being non-compliant with the RFC8693 (in the event that there is no input token)

[obfuscoder]

There is this "N_A" which could be reused here?

[gffletch]

I'm still wondering if we'd want to send in a subject_token all the time rather than have this spec override the Token Exchange spec. We need a 'sub' as part of the TraT so why not use the subject_type to provide it. The subject_token value could be something simple like a String and then the subject_token_type could be urn:...:workload_id

[gffletch]

Are the updates to draft 01 sufficient to close this issue? or do we need additional text?

[obfuscoder]

@gffletch The current draft mentions that the subject_token represents the subject and it could either be a token or simple string. However, the current draft does not say, what should be the subject_token_type if the subject_token contains a simple string. My suggestion would be to register a URN at IANA for this and name it urn:ietf:params:oauth:token-type:subject

[gffletch]

@obfuscoder My original intent was to make this out of scope for the specification as the only entity that needs to understand a subject_token_type value is the Transaction Token Service. If the deployment wants to define a urn:x-example:params:oauth:token-type:email to identify a subject_token value of "foo@bar.com" then that is totally fine. I don't think this is an area where specification is required.

I'm open to options and ways to better support use cases where transaction tokens are needing to be "minted" without any existing "access token".

One such use case could be a service that uses mTLS to unique identify a user (e.g. per user certificate) and then wants to specify that user as the subject of the transaction token. How does the requesting workload specify the "subject" (CN of the certificate?) to the Transaction Token Service?

[tulshi]

I think the self-signed token addition to the draft addresses this issue. Please reopen if not addressed fully.