Should the token-issuer-directory be JWK formatted and extend rfc7517?

[colinbendell]

Instead of introducing a new syntax for token-issuer-directories, should this instead extend rfc7517 to reduce devex friction?

The syntax would then be:

{
    "issuer-request-uri": "https://issuer.example.net/request",
    "keys": [
      {
        "kty": "EC",
        "crv": "P-384",
        "x": "MI...AB",
        "y": "MI...AB",
      },
      {
        "kty": "EC",
        "crv": "P-384",
        "x": "MI...AB",
        "y": "MI...AB",
      }
    ]
 }

(where the x and y coordinates are Base64Url encoded Nh long fields)

[chris-wood]

@colinbendell is the current syntax blocking implementations, or is this a nice-to-have request?

[colinbendell]

Nice-to-have.

It is confusing right now to have 3 almost similar formats. There is the token-issuer-directory (here), the key commitments for private-state-tokens and RFC7517 JWK Sets. JWKs have been around a lot longer and have existing tooling for JWKs (eg: vaulting, key rotation schedules, etc). Converging on existing specs, would allow the re-use of existing tools and enable clearer communications of expectations.

[chris-wood]

Thanks. So the origins are the ones that take this issuer configuration, extract the key(s), and then encode them in the token-key challenge parameter. They also consume the tokens themselves for the purposes of verifying tokens they get from the client.

On one hand, catering to clients that don't have or otherwise don't want to implement JWKs seems good (which is what we have now), and on the other hand catering to servers which can lean heavily on existing JWK support to parse these token keys also seems good.

What do you think about the following:

1. Keep the current token directory structure as-is, with the matching "application/token-issuer-directory" content type.
2. Define a separate content type, maybe "application/token-issuer-directory-jwk" or whatever, that carries the same content but with a different representation. (In this case, using JWK Sets instead of the existing format.)

Origins could then choose the format in which they want to consume the directory, assuming issuers implement both. Good idea? Bad idea? What do others think?

[colinbendell]

There really isn't much difference between a JWK and the issuer directory. The key details are:

• public key is encoded as a single field (token-key, Base64Url of the ASN.1 DER encoded form) vs two fields in a JWK (x and y scalars are broken out individually, base64url encoded)
• we would extend the JWK Set definition (cf: Section 5) for additional configuration fields like issuer-request-uri
• the token-type field is replaced with the more specific encryption fields
  • for VOPRF it would be {"kty": "EC", "crv": "P-384", "x":"...", "y":"..."}
  • for type 2 Blind RSA it would be {"kty":"RSA", "alg": "PS384", "mod":"...", "exp":"..."}

Generally, JWK is a bit more verbose and yet, ironically, uses terse keywords. So there isn't anything specific to JWK that an origin wouldn't need to implement if they are implementing the token-directory since it is a 1:1 mapping.

The one additional point I'll mention is that this isn't just Origin's consuming these keys. With Private-State-Tokens, the UA will likely also be consuming these public keys for the same purpose as the exchange with PAT.

All that to say, I'd bias toward just using JWK and deprecate the use of the token-issuer-directory to avoid confusion.

[chris-wood]

All that to say, I'd bias toward just using JWK and deprecate the use of the token-issuer-directory to avoid confusion.

That seems like what I suggested above, no? That is, we keep using what's in the draft now, specify the 1:1 JWK mapping (if someone has the energy or desire to do that), and then move to that new format as implementations gain support.

[colinbendell]

Ah, I misunderstood your comment about origins choosing which format to consume.

[chris-wood]

To try and further clarify, I don't think this would change the current document. Rather, I think it would be a new document that describes the new issuer directory format. Is that something you'd be interested in writing?

[colinbendell]

The one down side is the calculation of the token_key_id. For the origin it is convenient to simply take the der encoded field sha256() it, rather than having to constitute the der encded format. This could be overcome by providing the token_key_id in a precomputed form using the kid.

A quick POC to compare the differences (I've added a pre-calculated token_key_id in the jwks.json version):

• https://private-state-token.colinbendell.dev/.well-known/jwks.json
• https://private-state-token.colinbendell.dev/.well-known/key-commitment
• https://private-state-token.colinbendell.dev/.well-known/token-issuer-directory

[chris-wood]

Thanks @colinbendell. Can I ask that you take this issue to the mailing list so we can get more feedback? I appreciate the desire for convergence, but it's not clear to me JWK Sets are the right target for convergence.

[chris-wood]

I'm closing this issue with the proposed plan to produce a new document that describes a JWKS representation for keys.