Read signed metadata with the right trust boundary

A supported, validated signed value takes precedence over the plain value.

• Metadata may be self-asserted by the server origin over HTTPS or conveyed in signed_metadata, an OPTIONAL string containing a JWT. A JWT is a JSON Web Token carrying claims; its compact serialization is used here (§§1,1.1,2.1). It is not encryption merely because it is signed.
• Signed metadata MUST be digitally signed or MACed using JWS and MUST contain an iss claim identifying the party attesting to its claims. That JWT iss is distinct from the metadata issuer identifying the authorization server. This distinction does not authorize an arbitrary signer or establish a trust relationship by itself (§2.1).
• Consumers MAY ignore signed metadata if they do not support the feature. If they support it, metadata values conveyed in signed metadata MUST take precedence over corresponding plain JSON values. The fourth picture assumes signed claims have already been appropriately validated under the consumer’s trust context (§2.1).
• A signed_metadata claim SHOULD NOT itself appear inside the JWT. The picture omits it; it does not upgrade that SHOULD NOT into a new MUST NOT. Signed metadata is not a way around exact issuer matching or TLS requirements (§§2.1,3.3,6.1).
• The validation gate illustrates an invalid or untrusted signature being stopped before claims are used. Key selection, attestor trust establishment, allowed algorithms, MAC secrets and complete JWT processing are not implemented by this educational helper. Signature validity alone does not establish that the signer is an acceptable authority.