Public key in JWT

[bc-pi]

Please consider using the jwk header parameter to convey the public key in the JWT sent by the browser. That would better leverage existing standards, be similar to how DPoP did much the same thing: https://www.rfc-editor.org/rfc/rfc9449.html#name-dpop-proof-jwt-syntax, and remove ambiguity of "key": "public key", in the current example.

[arnar]

Thanks. Just to check: The jwk header field is only meant to hold a key for which the JWT itself is signed with, correct?

That works fine here because the registration is self-signed, but if it ever wasn't (e.g. if we added cross-signing between sessions at some point) would it still make sense?

[bc-pi]

Thanks. Just to check: The jwk header field is only meant to hold a key for which the JWT itself is signed with, correct?

Yes. That's from https://www.rfc-editor.org/rfc/rfc7515#section-4.1.3

That works fine here because the registration is self-signed, but if it ever wasn't (e.g. if we added cross-signing between sessions at some point) would it still make sense?

It's hard to say in the abstract or hypothetical but wouldn't it make sense to figure out how that would work and define it when/if such a thing was added?

[sbweeden]

Right now I captured a sample JWT from Chrome Canary:

eyJhbGciOiJFUzI1NiIsInR5cCI6Imp3dCJ9.eyJhdWQiOiJodHRwczovL2VsZmluLWNhcmFtZWwtZnJ1aXRhZGVucy5nbGl0Y2gubWUvaW50ZXJuYWwvU3RhcnRTZXNzaW9uIiwiaWF0IjoxNzE4MzM4MDA4LCJqdGkiOiJjaGFsbGVuZ2UiLCJrZXkiOnsiU3ViamVjdFB1YmxpY0tleUluZm8iOiJNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVMWHhlVEdibjlIcW5rdlUtSlNkeEZ6ZFBXeWpSc0VJdTl1X1NiMUh3NkkwRUdxd25NQ2d2N2ZjY3ptUWxCbXVhOG9ueE1LMTBPOG1kajQxZVZXelJ4QSJ9fQ._eZ0B-f8cayEjntGOwag6OQBtHvj8T9KaDRg-Sb-hp-w0RsYmiaHbQi52582dhrbFtzx8kTsmrwEmo8XWS6RSA

Which has claims:

{
  "aud": "https://elfin-caramel-fruitadens.glitch.me/internal/StartSession",
  "iat": 1718338008,
  "jti": "challenge",
  "key": {
    "SubjectPublicKeyInfo": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELXxeTGbn9HqnkvU-JSdxFzdPWyjRsEIu9u_Sb1Hw6I0EGqwnMCgv7fcczmQlBmua8onxMK10O8mdj41eVWzRxA"
  }
}

This SubjectPublicKeyInfo is base64 asn1, and is difficult to parse. It would make more sense for this to be a JWK public key format as suggested.

[kmonsen]

I'm looking into using JWK instead, should get some answer this week hopefully.

[bc-pi]

I maintain that the jwk header parameter would be more appropriate but this in https://github.com/WICG/dbsc/pull/68 is an improvement nonetheless. Thank you.

[kmonsen]

I maintain that the jwk header parameter would be more appropriate but this in #68 is an improvement nonetheless. Thank you.

How would you prefer it, like this? Sec-Session-Response: Sec-Session-Key:

[arnar]

Brian, is the implication of a jwk field in a JWT header that the JWT itself is necessarily signed by that key?

That happens to work in the most general case here where the registration message is self-signed, but it would preclude any form of deployment where the registration JWT is signed by a different key (this may be relevant to the enterprise-flavored proposal in #67).

If possible I'd like to leave that possibility open. The purpose of this public key is to save it on the server for verifying future refresh JWTs, more than it is for verifying the registration JWT itself.

(Sorry about the SubjectPublicKeyInfo bit left in there, it makes sense to use JWKs in the spec. We use SPKI formats for Google-specific deployments since we find it significantly safer and easier to parse than JWKs.)

[arnar]

Sorry, I see I asked the same question back in April and you answered then already. We do want the ability to convey a public key in the registration JWT that is not the signing key of that JWT itself. That seems to violate the definition of the jwk header field.

[bc-pi]

My comment in https://github.com/WICG/dbsc/issues/44#issuecomment-2320985474 did mention a preference but wasn't meant to ask for this to be reopened, apologies for that. It was more intended to acknowledge and say thanks for the change to JWK formatting.