Inconsistency in limitations on metadata

Issue #1343 closed
David Waite created an issue

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.

Comments (7)

  1. Tom Jones

    DW suggested that metadata should be limited to operational rather than legal which might make it possible to use. David C’s idea that it could be used to establish a trust relationship seems extremely unlikely to me. I had a lawyer take a full hour to explain the TOU for the TEFCA federation. Not something a machine could process.

  2. Log in to comment