Separate transaction tokens from JWT

[jricher]

To me, the real value here is the semantics around the payload, and less directly tied to the JWT format as its container. In particular, it seems like the payload could benefit from some of the disclosure capabilities of things like SD-JWT to allow the system to mask certain values from some parties within the trust domain.

Consequently, perhaps the document should focus on the payload and semantics, or explicitly show ties to both JWT and SD-JWT (and maybe CWT and others?) from the payload definition.

[gffletch]

That is an interesting restructuring to the doc. Basically a conceptual section and then bindings to particular formats allowing for profiles to other encodings? Is that the general idea?

[obfuscoder]

Are we considering opaque token formats as an alternative as well? Those formats could not be verified (e.g. signature check) by the workloads locally, but would require incorporating Token Introspection to get the data. For performance reasons, the format should at least be defined as self contained and verifiable locally. CWT as well as (SD-)JWT would have these properties. In the IETF meeting protobuf was mentioned. As far as I know, protobuf does not have this property, so I don't see it as a fitting candidate.

We also need to consider interoperability. If the spec allowed for multiple formats (or even leaves the format out of the specification), generic libraries/frameworks to implement the protocol would need to support not just one but a lot of formats or even make the format (serialization/deserialization) pluggable. Although this might be a good idea anyway, it tends to be more complex.

In regards to selective disclosure: The purpose of the transaction token is to pass it along the transaction call chain. So if there is specific data of the original presented Access Token not to be disclosed in the transaction token, the TTS would simply not add it in the transaction token when issuing it. Although a workload can choose to exchange the transaction token for another one, the purpose was to narrow the scope to further limit the access which the new transaction token could be used for. At this point the new transaction token could contain even less information than the original transaction token. I don't think that there should be more information disclosed at this point. That's why I don't think that SD-JWTs would have an application here.

On the other hand, I do see an application for a transaction token which contains specific information for specific workloads along the call chain. I can see some similarities to Rich Authorization Requests (RAR) where there can be PII/resource identifiers in the transaction token which should only be visible to some workloads even if the transaction token is passed along through all participating workloads.