You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #307, where @lywinged raised it and said it deserved its own issue rather than being settled as a side effect of a DPoP question it is not actually related to.
The question
Could cnf carry an RFC 7638 thumbprint instead of the key material, as an alternative representation?
Why it is not obviously wrong
The reference verifier's binding check already reduces both sides to a thumbprint before comparing:
jwk_thumbprint is RFC 7638, base64url SHA-256, unpadded, which is byte-for-byte the value DPoP carries in jkt. So a thumbprint confirmation would reach the same comparison with one hash step fewer, and offline verification is unaffected, because the trusted key arrives out of band either way.
What it costs
Three things, all raised on #307 and worth recording here so they are not re-derived:
The verifier can no longer check that the named key is well formed or of a supported type before using it. That check just became load-bearing: fix(schema): hold an RSA confirmation key to carrying its key material #311 tightened the schema so {"kty": "RSA"} with no n/e is refused, and a thumbprint form has nothing for that rule to inspect.
The record stops being self-describing about the key it needs, so a reader cannot tell from the record which key to fetch.
allow_embedded_key, the opt-in internal-consistency check, has nothing to work with.
Where this stands
@lywinged's view, which I share, is that a key is a few dozen bytes and the verifier needs the material anyway, so the trade does not pay. Recording it rather than closing it, because the reasoning is worth having written down the next time someone arrives from a system whose identity layer already carries a jkt and asks the same question. If a concrete integration turns up where carrying the key is genuinely not possible, this is the issue to reopen the argument on.
Normative text here would need an organisational sponsor under the usual rule. Nothing is held pending that today, because nothing is proposed yet.
Split out of #307, where @lywinged raised it and said it deserved its own issue rather than being settled as a side effect of a DPoP question it is not actually related to.
The question
Could
cnfcarry an RFC 7638 thumbprint instead of the key material, as an alternative representation?Why it is not obviously wrong
The reference verifier's binding check already reduces both sides to a thumbprint before comparing:
jwk_thumbprintis RFC 7638, base64url SHA-256, unpadded, which is byte-for-byte the value DPoP carries injkt. So a thumbprint confirmation would reach the same comparison with one hash step fewer, and offline verification is unaffected, because the trusted key arrives out of band either way.What it costs
Three things, all raised on #307 and worth recording here so they are not re-derived:
{"kty": "RSA"}with non/eis refused, and a thumbprint form has nothing for that rule to inspect.allow_embedded_key, the opt-in internal-consistency check, has nothing to work with.Where this stands
@lywinged's view, which I share, is that a key is a few dozen bytes and the verifier needs the material anyway, so the trade does not pay. Recording it rather than closing it, because the reasoning is worth having written down the next time someone arrives from a system whose identity layer already carries a
jktand asks the same question. If a concrete integration turns up where carrying the key is genuinely not possible, this is the issue to reopen the argument on.Normative text here would need an organisational sponsor under the usual rule. Nothing is held pending that today, because nothing is proposed yet.