Resolve a key identifier or a key-set URL
04kid names a key in an application context; jku locates a public JWK Set and may need a matching kid.
Separate invalid case: cnf.jku references multiple keys but cnf.kid is absent. Do not choose an arbitrary key.
Source for this drawing: RFC 7800 · Read RFC section 3.4 ↗
New to this? Start hereA quick picture + helpful background
A key is different from permission.
An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A key reference needs a trusted resolution path and an unambiguous selection.
- cnf.kid can identify the key instead of carrying it, provided the recipient can obtain that key. Its content is application specific: it is not necessarily a URL, thumbprint, globally unique name or proof.
- cnf.jku is a URI for a set of public JWKs. If the referenced set contains multiple keys, cnf.kid MUST also appear and the selected JWK MUST contain the same kid value.
- Acquiring the resource MUST provide integrity protection. HTTP GET MUST use TLS, and the server’s identity MUST be validated. A supplied URL does not itself establish issuer trust or safe application access policy.
All URLs and identifiers are fictional examples. A reference is not a command to fetch an arbitrary URL without application security policy. No live key URL is fetched by this educational guide.
Read the RFC section ↗