specified language for self-signed JWTs as subject_tokens

[tulshi]

Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.

On Fri, Apr 19, 2024, 6:30 AM Yaron Sheffer @.***> wrote:

@.**** commented on this pull request.

In draft-ietf-oauth-transaction-tokens.md https://github.com/oauth-wg/oauth-transaction-tokens/pull/90#discussion_r1572377478 :

-rfc9068 -: The subject_token is a JWT format OAuth 2.0 Access Token as defined in {{RFC9068}} +urn:ietf:params:txn-token:token-type:self-signed

I'm pretty sure you need an IANA section to register urn:ietf:params:txn-token.

Hint: https://www.iana.org/assignments/params/params.xhtml

— Reply to this email directly, view it on GitHub https://github.com/oauth-wg/oauth-transaction-tokens/pull/90#pullrequestreview-2011438609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB55UG5Q3BQQWGMFVDMGJUDY6EL6NAVCNFSM6AAAAABGEOTLE6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMJRGQZTQNRQHE . You are receiving this because you authored the thread.Message ID: @.***>

[obfuscoder]

@yaronf Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.

[yaronf]

@yaronf Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.

@obfuscoder My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.

[tulshi]

I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.

On Thu, Apr 25, 2024 at 6:55 AM Yaron Sheffer @.***> wrote:

@yaronf https://github.com/yaronf Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.

@obfuscoder https://github.com/obfuscoder My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.

— Reply to this email directly, view it on GitHub https://github.com/oauth-wg/oauth-transaction-tokens/pull/90#issuecomment-2077255417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB55UG3R5BUBBQW55C32VOLY7EDM3AVCNFSM6AAAAABGEOTLE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGI2TKNBRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[bc-pi]

Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.

[PieterKas]

Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security.

Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.

[bc-pi]

Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.

[PieterKas]

As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?

[tulshi]

TBH I think we took the wrong approach here. Instead of defining a new token type and having to ensure it cannot be abused for anything else, we could have had a simple JSON object containing the relevant claims. The object would be carried as a separate, optional parameter. This would be so much simpler for developers and would reduce the attack surface by a ton.

With that said, I can live with the current solution.

@yaronf On today's call we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.