[Federation] Address gaps and inconsistencies in the Trust Mark validation spec

[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

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

Validating a Trust Mark issuer follows the procedure set out in Section 8. Validating the Trust Mark itself is described in Section 7.4

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

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.

[Giuseppe De Marco]

Very good chance to improve the text here https://openid.net/specs/openid-connect-federation-1_0.html#name-validating-a-trust-mark, then

• 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?

Yes, we have a static validation (signature verification using the public key of the well known TM issuer) and a dynamic validation, using the status endpoint.
Example: https://italia.github.io/spid-cie-oidc-docs/en/trust_marks.html#trust-mark-validation
* 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?

it depends by its issuers, considering that multime TM issuer may belong to different federation and trust frameworks.
it depends by the value and meaning of each specific TM.

it’s up to the trust framework and to the trust verifiers checks one or more trust marks related to the operations requested by an RP
* When resolving a trust chain, if a TM fails validation should this mean an invalid trust chain?

No, trust chain and TM are indipendent. TM are trasversal to the way we have to establish the trust and create a trust chain.
TM acts more like custom extensions, for attestations of capabilities, administrative/onboarding properties, security profiles and so on.

Example: an RP requests an authorization for a specific resource, audience and/or using RAR. How an AS/OP/RS knows if that RP is enabled for doing that?
example: an RP that wants to authenticate an under-age user. A TM may assert its compliance for this specific use-case.
* 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?

it should be defined in the trust framework and in the federation onboarding procedures. In italy, for example, at the end of the onboarding process a disclosure is made for the obligation to display trustmarks within the EC. As defined in national technical rules.

later a RP can update its onboarding status to enable further services/profiles, such the usage of AA/RS. Further trust marks are issued at the end of the onboarding updates.

‌

[Giuseppe De Marco]

• Does this exclude intermediates? Can they publish TMs?

In italy if an entity is also a tm issuer for one of its descendants, it must publish the related TM in the entity statement issued for the specific descendant

‌

[Roland Hedberg]

My answers to your questions are:

1. Both checking the TM signature and using the TM status endpoint
2. Out of scope for the specification
3. When a TM fails is does not affect the validity of the trust chain. These things are separate unless the federation (like the Italian) has specified that a TM must be valid for the Entity Configuration to be valid.
4. Outside the scope of the spec.

‌

[Vladimir Dzhuvinov]

Thanks!

How frequently should TMs bound to status endpoint validation be checked? For an auto client, when the client is registered and then not until the trust chain expires (provided a TM doesn’t expire before that)? For requests that come with a trust_chain?

[Giuseppe De Marco]

How frequently should TMs bound to status endpoint validation be checked?

It’s an implementation choice which should tend to check the real-time status of the TM as long as the trust mark status endpoint was reachable to its issuer. Otherwise the evaluation of validity would take place exclusively in a static way, evaluating signature, exp value and claims id, sub and iss

For an auto client, when the client is registered and then not until the trust chain expires (provided a TM doesn’t expire before that)?

Exactly, a TM is quite indipendent from the TA or the trust chain where it’s contained. An expired TM in a previously evaluated trust chain, considering this latter as still valid, should require the check to the TM status endpoint or the reevaluation of the entire trust chain, for keep the trust chain consistent with only the valid TMs (considering only the ones recognizable under the TA where the Trust Chain is resolved)

For requests that come with a trust_chain?

We assume, that the client that hints the trust chain in the authz request should submit only a fresh and still valid trust chain. This should be valid also for the TM contained in the statements within it. I believe that in this thread we can explore the way we can make this more clear, so this PR would be a good place for how we would get the final result in the text: https://bitbucket.org/openid/connect/pull-requests/441

[Michael Jones]

On the 23-Mar-23 working group call, we noted that Roland has supplied some answers to the questions in the issue. On the next editors' call, we should decide whether some of those answers should be added to the spec as points of clarification.

[Michael Jones]

On the 19-May-23 federation editors' call, Roland agreed to create a pull request for this issue.

[Giuseppe De Marco]

Resolved by https://bitbucket.org/openid/connect/pull-requests/529