Visual RFC.
ALL RFCs / RFC 8414
Read the RFC ↗
RFC 8414 / Authorization server metadata

Compare issuer and strings exactly

04

Use the original expected issuer and the returned value after JSON decoding. Do not silently normalize two different identifiers into a match.

RFC 8414 · § 3.3EXAMPLE
4 / 4
Compare issuer and strings exactlyGeneral metadata strings use precomposed versus combining Unicode accents. Equality is false. No normalization may turn these distinct code-point sequences into a match.Compare decoded code points without normalizationLooks similar; different code-point sequencesCode-point equality checkDo not case-fold, URL-normalize or apply Unicode NFC
04
Keep Unicode sequences distinct

General metadata-string example: combining accent and precomposed accent remain different. Unicode normalization is explicitly prohibited for these comparisons.

Source for this drawing: RFC 8414 · Read RFC section 3.3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

A mismatch means the response data MUST NOT be used.

  • The returned issuer MUST be identical to the issuer identifier used to derive the retrieval URL. If not identical, the response data MUST NOT be used (§3.3). A host that resolves to the same address, a valid certificate or a similar-looking path does not replace this equality check.
  • §4 requires JSON escaping to be removed before comparing Unicode code points. It explicitly says Unicode Normalization MUST NOT be applied and requires code-point-to-code-point equality. These rules cover JSON member names and other strings as well as issuer values.
  • For example, a JSON escape for the t in /team decodes to the same string as a literal t. A differently cased hostname, an extra terminal slash, an explicit default port or a percent-encoded path spelling remains a different string in this check. Do not first serialize through a URL canonicalizer.
  • The final state compares general metadata strings with precomposed é versus e followed by a combining acute accent. They may look similar, but their code-point sequences differ. It is a string-comparison example, not a claim that either string is a valid issuer URL.
  • Passing this equality comparison is necessary, not sufficient for trustworthy metadata: the client must also check TLS and any applicable signed metadata, and still needs a legitimate choice of issuer and protected resource (§§1,2.1,6).
DETAILS

Comparison works on decoded strings. The examples do not make DNS, certificate, Unicode-security or complete URL-validation claims.

Read the RFC section ↗

All chapters in RFC 8414

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗