Issuer-signed JWT Verification Key Validation - Separation of signature and identity verification/validation?

[alenhorvat]

There seem to be several mechanisms for issuer key validation (section 3.5).

Two mechanisms define fetching of keys (issuer metadata, DID), and one can be embedded or referenced (x509).

Would it make sense to enable signature validation at all times and

• require a jwk header with the issuer's signing key (https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.3) Signature is always verified using this key.

Public key - identity binding can be verified

• using x509 certificate that is in the jwk.x5c claim (https://datatracker.ietf.org/doc/html/rfc7517#section-4.7) - key certificate or the full chain.

kid could be misused to express the validation mechanism or one could define an additional header claim where identity verification mechanism is specified:

• calling the /.well-known/jwt-vc-issuer
• resolving a DID
• using Federation ...
• ...

[peacekeeper]

I think this makes sense only in the case of embedded X509 certificate.

Otherwise, I think the "validation mechanism" (e.g. resolving the DID or downloading the keys from a web server) would always have to be executed anyway. There would be no extra value in having an embedded signing key, since an attacker that can replace the signature can also replace the signing key. And there would be a risk that implementers create security holes by considering the "validation mechanism" as something optional...

Or am I missing anything?

[alenhorvat]

Excellent point @peacekeeper!

There are always 2 processes

1. Verifying the signature: By embedding a key, the signature can be always verified. This does not exclude an option to resolve the key.
2. Verifying the signer's identity: each method defines it's own process: x509 embedded or referenced (referenced x509 is almost never used); .well-known -> resolve the URL, DID -> resolve the DID (URL)

In many environments (high-loads, low connectivity, ...) we cannot rely on ". resolving the DID or downloading the keys from a web server would always have to be executed anyway". Furthermore, if the resource is not available, again, signature validation fails. Hence, these mechanisms (well-known, DIDs) should also define how identity information could be embedded in the signature (like x509, OIDFed, advanced signatures are already doing) - but this is out of scope of this specification and discussion.

[peacekeeper]

Thanks @alenhorvat

By embedding a key, the signature can be always verified.

Yes, but what's the value of knowing that a payload has been signed by "someone", if you don't know who that key belongs to?

define how identity information could be embedded in the signature

Yes that sounds useful!

[alenhorvat]

Yes, but what's the value of knowing that a payload has been signed by "someone", if you don't know who that key belongs to?

Goal is a bit broader - to clearly split and define the two processes, and show that x509 verification or .well-known/DIDs are all process of verifying the identity/identifier of the signer (link between a public key and an identifier).