size matters in matters of size

[b---c]

The DPoP proof JWT is relatively small (kinda) already but space can be at a premium in HTTP headers (especially, for example, when there might also be a JWT access token in the Authorization header). There are a few pieces of static content that could be tightened or removed to make the DPoP proof a bit more space efficient and maybe the bound access token a bit smaller too.

The core RFC 7519 claim names are all three characters so as to be "short because a core goal of JWTs is for the representation to be compact." DPoP could follow suit and use htu and htm rather than http_uri and http_method respectively to save 13 characters in the payload, which is ~18 characters in the encoded token. It could even go to two characters with hu and hm.

Given the claims content, how keys are used and communicated, and the general context of use, I cannot think of any reasonable way that a DPoP proof could be legitimately confused for a different meaningful and valid JWT in a different context. Or vice versa. As such, the "typ":"dpop+jwt", could be dropped to save 17 characters in the header, which is ~23 characters in the encoded token.

Using jkt#S256 for the confirmation member name was roughly following the convention from JOSE for the x5t and x5t#S256 headers where SHA1 was the hash alg for x5t and the #S256 part was added to indicate SHA256. The OAuth MTLS document went with "x5t#S256" for the confirmation method member name to try and be consistent with the JOSE headers and JWK parameters. But there's nothing preexisting for a JWK Thumbprint hashed with SHA1 and there's not going to be. So I think it'd be just fine for DPoP to use jkt for the SHA256 JWK Thumbprint confirmation method member name. That'd trim 5 characters from introspection responses and the body of JWT access tokens, which is ~7 characters of an encoded JWT access token.

[b---c]

I'm happy to do the work to make these changes BTW but I wanted to try and get some consensus from folks before making any changes.

[danielfett]

I would be fine with htu and htm and probably also with jkt.

I disagree on dropping typ, however. We do not know which kinds of JWTs are out there or will be in the future. From a protocol design standpoint, not having an identifier for the type of the message is really bad.

[b---c]

What you call "bad", I might call "pragmatic" :) But I suppose I can kinda see and will concede the point on typ. I think the others are worth doing and sooner rather than later. So I'll work on a PR.

[b---c]

pull request #53 does htu and htm and jkt

[danielfett]

Pull request is merged, closing this issue.