Key format

[martinthomson]

Pick one please. The idea that you might have multiple key formats in order to support different use cases is cute, but it doesn't foster interoperability. The lessons of the Tower of Babel apply. The JWKS format seems tolerable.

[thibmeu]

Just to confirm: are you discussing key format (as in the response that the verifier gets) or the type? type carries both a format and validation method.

directory and jwks_uri share the same format already (as you observed in #116, and mentioned in Section 5.5): JWKS. CIMD is a format that requires one more resolution step (first the document, then the jwks_uri or inline jwks). I believe that moving its declaration to the registry draft, where it is actually used, makes more sense, and we can provide a uniform format this way (relates to #110).

As for validation, if we were to keep jwks_uri only (as it's more generic), the verifier would have to infer it based on the shape of the URI . When fetching /.well-known/http-message-signatures-directory, the verifier knows that there are certain validations to be made, and that's something the client controls. If the verifier receives an arbitrary path, it's automatically a JWKS URI.

The downside is that the well-known then has to be short, because it's included in every request (which goes into #116), and that the client has to infer validation based on pattern matching the URI instead of having a clear type.

[martinthomson]

I refer to both. The type parameter indicates that the resource has multiple potential formats. That leads to verifiers having to implement ALL of those formats if they want to be interoperable, which isn't particularly friendly in terms of getting interoperability. It makes implementation a bigger ask of verifiers.

Not sure what you are saying about what verifiers infer. That's a separable issue, but the concern I continue to have with "http-message-signatures-directory" (aside from its length, #116) is that it doesn't convey semantics. The name says that this conveys a directory of signatures, but what you really want is a name that says what this is: a directory of keys for agents that are identifying themselves with a signature.

[thibmeu]

Let's imagine we only keep jwks_uri. The point about inferring is that when presented with the two URLs

A: https://example.com/.well-known/jwks.json
B: https://example.com/.well-known/http-message-signatures-directory

The first one fetches the JWKS resource, and that's it.
The second one is recognisable as a registered well-known. The verifier can therefore perform a domain binding by validating the directory response accordingly.

The property would therefore be inferred from the URL shape rather than from a specific type.

Note: i agree that having a clearer name for the endpoint could help to be more descriptive

One point if we remove type: that's a breaking change for Signature-Agent (we have done that with structured field directory, so it's doable, but worth noting)

[martinthomson]

Understand that my tolerance for pushback on the basis that something was shipped is very low. I suspect others will vary, but my general feedback is that if you ship something prior to having these sorts of discussions, expect that changes will need to follow. (A new name is always a choice that is available.)

[thibmeu]

Totally get that. The note was mostly that when we address the issue, the braking change should be clear on the changelog.

The previous comment was to run through what such a change would look like.

[AVAVERIFY]

Verifier implementer input, from re-pinning to -02 today: support for
JWKS-only as the single format. Two notes from deployed reality. First,
alg: our parser accepts alg-absent, the registry form (ed25519), and the
JOSE names case-insensitively, because all three occur in the wild; per
Joshua's WebCrypto finding, guidance to omit alg (the algorithm already
rides in Signature-Input) seems right, with verifier tolerance for the
JOSE names. Second, at least one production directory (shopify.com) serves
a bare JWK rather than a JWK Set today, so a JWKS-only rule would benefit
from one migration sentence telling verifiers whether to tolerate or
reject the bare form during transition. We currently normalize it and
record the divergence.