Feature request: IDs for JWT claims

[michaelsproul]

Problem description

The execution API spec defines an optional id claim that can be set in a JWT token to convey information about the client being authenticated. This is useful for more advanced forms of authentication beyond the basic 1-CL-to-1-EL authentication that we usually do. For example, my Electric Eel multiplexer uses the id to identify the connecting client and decide which JWT secret to use. Without the ID, it has to fall back on iterating all known JWT secrets and trying to verify the token against them (which is slow).

The spec defines the id claim here: https://github.com/ethereum/execution-apis/blob/main/src/engine/authentication.md#jwt-claims

It's worth noting that the ID in the claim is distinct from the key-ID concept defined by the JWT standard, which is part of the header, not the body. Apart from being a bit inelegant this isn't an issue.

Solution description

Add a flag to Lodestar like --jwt-id which takes a string to use as the JWT ID for claims made to the EL.

Additional context

No response

[dapplion]

Sounds good! We should def implement it. What's your suggested usage of id vs clv? In Lighthouse do you set the clv to the same agent as in the libp2p identify protocol?

[michaelsproul]

Awesome!

CLV is unused in Lighthouse at the moment but I think would be well-suited to including version metadata. The downside is that it gets transmitted with every request, so it's a little wasteful.

I think it could be good to just leave the ID and CLV off by default and allow them both to be configured?

[nflaig]

CLV off by default and allow them both to be configured

What would be the expected use case of CLV that can't be achieved by the ID already?

The use cases I see for this only make sense if the CLV is included by default and set to an identifiable value by the client itself, e.g. Lodestar/${version}

• EL exposing a metric about client type / version, or prints that info in logs
• Add a workaround on EL side for a specific client implementation to fix a bug / misbehavior, this is similar to Send node impl/version as user agent on builder requests #5360

Both those use cases don't really work if it is off by default.

Until there is a clear use case for CLV I would suggest we don't implement that for now.

[michaelsproul]

That sounds reasonable to me. I think the CLV is of dubious value