[Openid-specs-ab] Issue #1343: Inconsistency in limitations on metadata (openid/connect)

David Waite issues-reply at bitbucket.org
Sat Sep 25 21:30:25 UTC 2021

New issue 1343: Inconsistency in limitations on metadata

David Waite:

Section 3.1 \(Entity Statement\) defines the metadata parameter as:

> metadata  
> OPTIONAL. JSON object including protocol specific metadata claims that represent the entity's metadata. Each key of the JSON object represents a metadata type identifier, and each value MUST be a JSON object representing the metadata according to the metadata schema of that metadata type. An entity statement MAY contain multiple metadata statements, but only one for each metadata type. If the iss of an entity statement points to the same entity as the sub, then the entity statement MUST contain a metadata claim. If iss and sub are not the same, then the entity statement MUST NOT contain a metadata claim.

Section 4 \(Metadata\) however states:

> The metadata document MUST be a JSON document. Beyond that there is no restriction.

JSON Document is no longer a concept in ECMA 404/RFC 7259, but it was originally defined to be either an array or an object.

These specifications define valid JSON text, which includes the other non-structured types. So for example, `4`, `true`, and `"foobar"` are all considered valid JSON data for interchange. 

I would recommend that the values for metadata type identifiers either be specified in both places either to broadly to be any valid JSON, or constrained to just JSON objects.

I have a slight preference for any valid JSON, as this further clarifies that the existing metadata policy language is not meant to constrain or necessarily be compatible with the formats of policy for new metadata types.

More information about the Openid-specs-ab mailing list