Define how to validate Entity Statements

[selfissued]

This PR explicitly defines how to validate entity statements. It begins by defining how to validate all entity statements.

While currently incomplete, I will add rules for validating specific kinds of entity statements, such as those used for Explicit Registration.

Fixes #84

[zachmann]

There is some inconsistency with regards to claims that can only occur in entity configurations / subordinate statements. For some claims it is listed as something to check, for others not.

This should be made consistent, either by adding the required check to all claims or by adding a general step to verify that no "wrong" claims are present.

[teamktown]

To better support key rollover, replace 837 to 843 with:

The Entity Statement's kid (Key ID) header parameter value
MUST be a non-zero length string and
MUST exactly match the kid value
for a key in the jwks (JWK Set) Claim
of the Entity Configuration of the issuing Entity.
The jwks Claim MAY contain multiple active signing keys
(for example, during key rotation). A validator MUST accept any signature
that verifies successfully with a currently published key in that set.
Publishers SHOULD retain the retiring key alongside the new key
for an overlap period sufficient to allow dependent Entity Statements
to refresh before the old key is withdrawn.

[selfissued]

The validation section isn't the place to add statements about how the "jwks" claim is used. If you want to file an issue suggesting text to add in the claim definition, I'd welcome that.

[teamktown]

Got it and accept the recommendation. Will work through the way to get these items organized for discussion.

[teamktown]

Anchor Set Semantics: Validators maintain a configured set of Trust Anchors (“Anchor Set”). A Trust Chain MUST be considered valid if it terminates at any Trust Anchor in this Anchor Set and all other validation requirements in this specification are satisfied. Implementations MUST NOT assume the existence of a single exclusive Trust Anchor.

[selfissued]

This is another comment that probably warrants its own issue. Please file one with suggested wording updates. Thanks!

[teamktown]

Got it and accept the recommendation as in previous comments. Will work through the way to get these items organized for discussion.

[teamktown]

update 932-939 with this to support possible multiple trust anchors
If the trust_anchor Claim is present,
validate that its value is an Entity Identifier corresponding to one
of the configured Trust Anchors in the validator’s Anchor Set.
Implementations MAY retrieve the Entity Configuration for the
Entity Identifier and validate that it is a Trust Anchor,
and they MAY also validate that it is the Trust Anchor
used for the Explicit Registration.
Validators MAY also accept Explicit Registration responses that omit
the trust_anchor Claim if the associated Trust Chain
terminates at any Trust Anchor in the Anchor Set.

[selfissued]

Ditto

[teamktown]

..at reasonable intervals that take into consideration the key roll over grace window where the new Trust Anchor key is valid and the old one is valid to allow for adequate key material circulation.

[selfissued]

Ditto

[teamktown]

Short-Lived Entity Statements. To promote timely circulation of new signing keys and metadata, Entities SHOULD issue Entity Statements and Entity Configurations with short expiration times (for example, between one hour and one day), depending on federation scale and cache behaviour. Validators SHOULD refresh Entity Configurations before their expiration to minimize the impact of key rotation events.

[selfissued]

Ditto. This deserves an issue of its own right for discussion by the working group.

[teamktown]

Got it and accept the recommendation and add it to the items for discussion like the others.

[teamktown]

• Augmented some existing comments alongside others and the flow of trustmark verification.
• added where necessary the recognition of multiple keys for CA rollover into the Entity Statement verification process so that it allowed for a set of CAs
• add some operational aspects to key rollover section

No new fields, no behaviour removals. Only action item is to ensure the validator picks the correct key by kid from a set and to optionally allow multiple anchors. No durations mandated and included guidance to model grace window to reflect refresh expectations to not be in conflict thus avoiding to short a refresh window for slow refreshes thus breaking trust due to rollover anchor aged out but not yet fetched.

While back compatible with deployed OpenIDFed it will reveal where libraries are overly rigid to a single key/single TA and not a set. There are clear, testable paths forward with this that in turn will mean more seamless keyrollover experience.

[teamktown]

Good to proceed.
Will be working through feedback from @selfissued for items I commented on.