CHARACTERIZATION OF USES OF "Subordinate" and "Superior" Characterization of existing uses of the term "Subordinate". Uses are categorized into these meanings: Immediate Subordinate - 13 uses (5 explicitly labelled as "immediate") Tree of Subordinates - 14 uses No Difference for Subordinate usage in the Context - 2 uses Uses of "Subordinate Statement", other than its definition, are not included in the counts. Characterization of existing uses of the term "Superior". Uses are categorized into these meanings: Immediate Superior - 17 uses (5 explicitly labelled as "immediate") Chain of Superiors - 4 uses No Difference for Superior Usage in the Context - 2 uses PERTINENT TERMNOLOGY PHRASES USED ================================= "immediate Subordinate" and "immediately Subordinate" 5 uses "immediate Superior" 5 uses "Subordinate Entity" / "Subordinate Entities" 5 uses with immediate Subordinate meaning 2 uses with tree of Subordinates meaning "Superior Entity" / "Superior Entities" 5 uses with immediate Superior meaning 0 uses with chain of Superiors meaning "descendant" 1 use with immediate Subordinate meaning ================ CHARACTERIZATION OF USES OF "Subordinate" ================ IMMEDIATE SUBORDINATE ===================== Subordinate Statement An Entity Statement issued by a Superior Entity about an Entity that is immediately Subordinate to it. Subordinate Entity An Entity that is a direct descendant of a Superior Entity (a Trust Anchor or Intermediate). The Trust Anchor and its Intermediates issue Entity Statements about their Subordinates called Subordinate Statements. The sequence of Entity Configurations and Subordinate Statements that validate the relationship between a Superior and a Subordinate, along a path towards the Trust Anchor, forms the proof that a Leaf Entity is a member of the federation rooted at the Trust Anchor. Superior Entities in a federation publish Entity Statements about their immediate Subordinate Entities called Subordinate Statements. The corresponding private key is used by the Entity to sign the Entity Configuration about itself, and by Trust Anchors and Intermediate Entities to sign Subordinate Statements about their immediate Subordinates. In some cases, a Superior may want to be explicit about what metadata should be used for a Subordinate. In that case metadata MAY be used in a Subordinate Statement. If metadata is used in a Subordinate Statement, it is only valid for the subject of the Subordinate Statement and has no impact on the subject's Subordinates. A Trust Chain begins with a Leaf Entity Configuration, and has zero or more Subordinate Statements issued by Intermediates about Subordinates, The Trust Anchor's public keys are used to verify the signatures on ES[i] (the Trust Anchor's Entity Configuration) and ES[i-1] (the Trust Anchor's Subordinate Statement about the Entity immediately Subordinate to it in the Trust Chain). When for a given metadata parameter both the combined policy at the current step and the Subordinate Entity specify a policy operator, for example subset_of, the two operators are merged, as described in Section 6.1.3.1. For example, the Trust Anchor states who its Subordinates are and Entities may choose to trust them. Use the fetch endpoint of each Superior to obtain Subordinate Statements about the Subordinate Entity, per Section 8.1.1. When building the Trust Chain, the Subordinate Statements issued by a Superior about its Subordinate are used together with the Entity Configuration issued by the Leaf. Combining the metadata policies from the three Subordinate Statements we have by a Superior about its Subordinate and applying the combined policy to the metadata statement that the Leaf Entity presented, we get: TREE OF SUBORDINATES ==================== The metadata policy applies to the Entity that is the subject of this Subordinate Statement as well as to all Entities that are Subordinate to it. Applying to Subordinate Entities distinguishes metadata_policy from metadata, which only applies to the subject itself. Trust Anchors and Intermediate Entities MAY publish Entity Type-specific policies that apply to the metadata of their immediate Subordinates as well as any further Subordinates along the Trust Chain. If a Superior has specified essential=true, then a Subordinate cannot change that. If a Superior has specified essential=false, then a Subordinate is allowed to change that to essential=true. If a Superior has not specified essential, then a Subordinate can set essential to true or false. If those rules are not met this MUST be treated as error. If the claim appears in an Entity Configuration, it MUST be applied to all Subordinates of that Entity. If the claim appears in a Subordinate Statement, then it MUST be applied to the subject of the Subordinate Statement and all the subject's Subordinates. The naming_constraints member specifies a URI namespace within which all Entity Identifiers for Entities Subordinate to the subject of the Entity specifying the constraints in a Trust Chain MUST be located. The listing endpoint is exposed by Federation Entities acting as a Trust Anchor, Intermediate, or Trust Mark issuer. The endpoint lists the Subordinates about which the Trust Anchor or Intermediate issues Entity Statements. As a Trust Mark issuer, the endpoint MAY list the Subordinates for which Trust Marks have been issued and are still valid, if the issuer exposing this endpoint supports Trust Mark filtering, as defined below. If the responder knows the Entity Types of its Subordinates, the result MUST be filtered to include only those that include the specified Entity Type. When multiple entity_type parameters are present If the parameter trust_marked is present and set to true, the result contains only the Subordinates for which at least one Trust Mark have been issued and is still valid. If the responder has issued Trust Marks with the specified Trust Mark identifier, the list in the response is filtered to include only the Subordinates for which that Trust Mark identifier has been issued and is still valid. If the parameter intermediate is present and set to true, then if the responder knows whether its Subordinates are Intermediates or not, the result MUST be filtered accordingly. The following is a non-normative example of an HTTP GET request for a list of Subordinates: The following is a non-normative example of a response containing the Subordinate Entities: Keep signing the Entity Configuration and the Entity Statements using the old keys for a long enough time period to allow all Subordinates to have obtained the new keys. NO DIFFERENCE FOR SUBORDINATE USAGE IN THE CONTEXT ================================================== Leaf Entity An Entity with no Subordinate Entities. Superior Entity An Entity with one or more Entities that are Subordinate to it. ================ CHARACTERIZATION OF USES OF "Superior" ================ IMMEDIATE SUPERIOR ================== Subordinate Statement An Entity Statement issued by a Superior Entity about an Entity that is immediately Subordinate to it. Subordinate Entity An Entity that is a direct descendant of a Superior Entity (a Trust Anchor or Intermediate). The Entity Configuration of a Leaf Entity contains one or more references to its Superiors, found in the authority_hints parameter These references can be used to download the Entity Configuration of each Superior. The sequence of Entity Configurations and Subordinate Statements that validate the relationship between a Superior and a Subordinate Superior Entities in a federation publish Entity Statements about their immediate Subordinate Entities called Subordinate Statements. This claim is REQUIRED in Entity Configurations of the Entities that have at least one Superior above them, such as Leaf and Intermediate Entities. In some cases, a Superior may want to be explicit about what metadata should be used for a Subordinate. The Subordinate Statements are obtained from the federation_fetch_endpoint of the subject's Superior. The URL of the federation_fetch_endpoint is discovered in the Superior's Entity Configuration. From its immediate Superior authorities, the RP MUST select one or more authority_hints so that every hint, when used as the starting point for a Trust Chain collection, leads to at least one of the Trust Anchors in the subset selected above. The authority_hints claim MUST be set to the OP's immediate Superior authority in the selected Trust Chain. It MUST be a single-element array, whose value references the immediate Superior authority of the OP in the Trust Chain that the OP selected to process the request. The RP MUST ensure the signing Federation Entity Key used by the OP is present in the jwks claim of the Subordinate Statement issued by the OP's immediate Superior authority in a Trust Chain that the RP successfully resolved for the OP when it prepared the Explicit Registration request. Pick out the immediate Superior Entities using the authority hints. Use the fetch endpoint of each Superior to obtain Subordinate Statements about the Subordinate Entity, per Section 8.1.1. Combining the metadata policies from the three Subordinate Statements we have by a Superior about its Subordinate and applying the combined policy to the metadata statement that the Leaf Entity presented, we get: CHAIN OF SUPERIORS ================== (The value might contain no entries when Superiors supply any needed metadata). it MAY be the empty JSON object {}, which may be the case when Superiors supply any needed metadata values. If a Superior has specified essential=true, then a Subordinate cannot change that. If a Superior has specified essential=false, then a Subordinate is allowed to change that to essential=true. If a Superior has not specified essential, then a Subordinate can set essential to true or false. If those rules are not met this MUST be treated as error. When building the Trust Chain, the Subordinate Statements issued by a Superior about its Subordinate are used together with the Entity Configuration issued by the Leaf. NO DIFFERENCE FOR SUPERIOR USAGE IN THE CONTEXT =============================================== Superior Entity An Entity with one or more Entities that are Subordinate to it. This claim MUST NOT be present in Entity Configurations of Trust Anchors with no Superiors.