[Openid-specs-ab] Issue #1791: [Federation] Address gaps and inconsistencies in the Trust Mark validation spec (openid/connect)

[Vladimir Dzhuvinov]

New issue 1791: [Federation] Address gaps and inconsistencies in the Trust Mark validation spec
https://bitbucket.org/openid/connect/issues/1791/federation-address-gaps-and

Vladimir Dzhuvinov:

The current draft 26 was found to have several gaps and inconsistencies about the Trust Mark \(TM\) validation. This is mostly developer feedback trying to implement generic library support, it is not targeting a particular federation.

In particular:

* There is ambiguity about how a TM is to be validated - by calling the TM status endpoint or checking the TM signature. Are both acceptable? If yes - pros / cons, considerations?  
* When an entity is presented with one or more TMs, how should it know which ones are required \(essential\) and must pass validation and which not?  
* When resolving a trust chain, if a TM fails validation should this mean an invalid trust chain?  
* If a federation \(or trust anchor\) has a policy that a given TM ID is required, how is this communicated? Or is this outside the spec scope, i.e. must be configured by other means?

‌

List of the relevant sections:

[https://openid.net/specs/openid-connect-federation-1\_0.html#section-5.3](https://openid.net/specs/openid-connect-federation-1_0.html#section-5.3)

> The validation of such a signed statement is performed in the same way that an Entity Configuration is validated. To make this validation possible the key used by the Trust Mark Issuer to sign Trust Marks MUST be one of its Federation Entity Keys.

This paragraph suggests that TMs are validated like ECs, but the section below says use the TM status endpoint. If the validation must happen by calling the TM status endpoint, the first sentence should be removed and the second should just say that the TM signing key must come from the issuer’s federation JWK set.

‌

[https://openid.net/specs/openid-connect-federation-1\_0.html#name-validating-a-trust-mark](https://openid.net/specs/openid-connect-federation-1_0.html#name-validating-a-trust-mark)

> Validating a Trust Mark issuer follows the procedure set out in [Section 8](https://openid.net/specs/openid-connect-federation-1_0.html#resolving_trust). Validating the Trust Mark itself is described in [Section 7.4](https://openid.net/specs/openid-connect-federation-1_0.html#status_endpoint)

In the referenced section 8 there is no specific text about the TM issuer validation. The validation method given here is the TM status endpoint. Perhaps it would be better to move the text in section 5.3 about the TM validation to this one.

‌

> A Trust Anchor MAY publish a list of accreditation authorities of Trust Marks that SHOULD be trusted by other Entities. A Trust Anchor uses the `trust_marks_issuers` claim in its Entity Configuration to publish this information.

Does this exclude intermediates? Can they publish TMs?

‌

[https://openid.net/specs/openid-connect-federation-1\_0.html#name-resolving-trust-chain-and-m](https://openid.net/specs/openid-connect-federation-1_0.html#name-resolving-trust-chain-and-m)

This section was referenced to specify the TM issuer validation. I suppose what is missing is specify that the TM IDs must be found in the `trust_marks_issuers`. However, it is not clear what should happen if the trust chain resolves with success, but included TMs do not.