[Openid-specs-ab] OpenID Federation draft 42 published

[Michael Jones]

OpenID Federation draft 42 has been published at https://openid.net/specs/openid-federation-1_0-42.html and https://openid.net/specs/openid-federation-1_0.html.  It contains the last normative changes expected before the Federation interop event planned for April 28-30 at the SUNET offices in Stockholm, Sweden.

The primary focus of this release was incorporating feedback on the metadata policy language to make it as simple and consistent as possible.  Vladimir Dzhuvinov created test cases corresponding to this set of updates, which are published at  https://connect2id.com/blog/metadata-policy-test-vectors-openid-federation.  These will be one of the kinds of tests available at the interop event.

As usual, the history entries<https://openid.net/specs/openid-federation-1_0-42.html#name-document-history> describe the changes in detail.  For this draft, they are:
-42

  *   Addresses #11, #180: Allows the following unconditional operator combinations: add + superset_of. Makes the following previously conditional operator combinations unconditional: default + one_of, default + subset_of, default + superset_of. Makes the following previously unconditional operator combination conditional: value + essential. Allows the following conditional operator combinations: value + add, value + default, value + one_of, value + subset_of, value + superset_of.
  *   Addresses #182: When applying the subset_of operator on a metadata parameter, if the resulting intersection is empty, then the metadata is made empty. Previously it was removed, which may lead to policy override for metadata parameters that a have default value, for instance grant_types RP metadata or grant_types_supported OP metadata. The merge of two subset_of operators is changed to allow empty intersection as well.
  *   Addresses #129: Clarifies that the combination rules for a metadata policy operator apply to both individual as well as merged metadata parameter policies.
  *   Fixed #184: Clarified that Request Objects can be passed by value or by reference.
  *   Fixed #178: Clarify that other client methods (than automatic and explicit) are allowed.
  *   Fixed #181: Contributed metadata policies must be logically sound and consistent with one another.
  *   Fixed #130: Allow multiple Trust Anchor values to be passed in resolve requests.
  *   Require trust_chain claim in resolve response.
  *   Fixed #161: Prohibit loops in Trust Chains.
  *   Fixed #47: Described using and not using a provided Trust Chain during Automatic Registration.
  *   Fixed #85: Clarified Trust Chain selection during Explicit Registration. Also corrected the authority_hints value in the Explicit Registration response to be the Immediate Superior of the RP in the Trust Chain selected for it by the OP.
  *   Fixed #35: Clarified that using non-interoperable JSON, as per Sections 4 and 8 of RFC 8259, can result in unpredictable metadata and metadata policy behavior.
  *   Fixed #162: Trust Mark claim id renamed to trust_mark_id. Other more specific Trust Mark JWT typ header parameter values can be used if defined by trust frameworks in use and understood by the implementation.

                                                                -- Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250305/d436e49d/attachment.htm>