Swedish OpenID Federation Deployment and Interoperability Profile 1.0#132
Swedish OpenID Federation Deployment and Interoperability Profile 1.0#132martin-lindstrom wants to merge 15 commits into
Conversation
martin-lindstrom
requested review from
Razumain,
felix-hellman,
per-mutzell and
s-hal
|
Some feedback from a first passthrough of the document. Contradictions1: Minor contradiction on self defined terminologyDescription in 1.2 Contradicts the description of the same entity in 2.2. Clarifications1: Missing reference or wrong sequenceDescription in 2.2 is dependent on the readers understanding of 2.5, maybe add a reference and short description. 2: Not enough informationDescription in 4.1, what trust marks MAY the resolve include, is it only the trust marks defined by the given trust anchor or any trust mark? Additional notesAs is definition in 4.2.2 can lead to frustration when updating metadata. We should encourage metadata consumers to fetch metadata more often than exp in order to keep their understanding of the entity up to date. Otherwise if resolver The federation operator should recommend what a reasonable polling interval for metadata is which should be
|
Is this really a contradiction? The definition says what a "Federation Protocol Entity" is, and in the requirements we state that such an entity MUST NOT take on the role of a Federation Service Entity. The definition can be used independently of the requirement. |
Razumain
left a comment
Razumain
left a comment
There was a problem hiding this comment.
This document is very good!
I'v just added some minor thoughts and comments for consideration.
|
|
||
| Federation Resolver | ||
| : <br>A Federation Service Entity that provides functionality for obtaining Resolved Metadata and Trust Marks for a given Entity. | ||
|
|
There was a problem hiding this comment.
I actually think this is a great structure. We could consider enhancing the description of different setups by adding 2 more definitions.
Federation Infrastructure - A collective infrastructure of Federation Entities that may span over several federation operators each operating their own Trust Anchor. A Federation Infrastructure MAY contain Federation Protocol Entities that chain to multiple Trust Anchors and thus participate in several federations by registering to a single Federation Registration Entity.
Federation - A specific configuration of the Federation Infrastructure as defined by a single federation operator and its Trust Anchor.
| - It is **RECOMMENDED** that the Federation Operator defines federation-wide security requirements, such as minimum key lengths, key rollover frequency, and client authentication requirements. | ||
|
|
||
| - A Federation Operator **SHOULD** define recommended validity periods for Entity Statements in order to promote predictable behaviour and operational stability; see (#entity_statement_validity). | ||
|
|
There was a problem hiding this comment.
We may want to think twice about this. I may be hard in cases where a Trust Anchor decides to chain to an Intermediate Entity it has no control over. We may want to consider an alternative approach by:
- In the profile recommend general min/max validity periods
- State that the federation operation SHOULD assess and determine if the validity period applied by subordinate entities is compatible with the policy of the federation operator before accepting to chain to a subordinate entity.
This text is also duplicating requirement in 2.4.1. Perhaps just refer to 2.4.1 and state requirements there.
There was a problem hiding this comment.
We should change this to Federation Rules instead.
| [@!OpenID.Federation, section 10] specifies requirements for how an Entity resolves the Trust Chain and metadata of another Entity with which it wishes to establish trust. This process includes fetching Entity Statements, applying metadata policies and constraints, validating Trust Chains, and handling caching. The procedure is complex and may be difficult for all Federation Protocol Entities within the federation to implement. | ||
|
|
||
| Also, this algorithm relies on all participants publishing their Entity Configuration information at a well-known location, as specified in [@!OpenID.Federation, section 9]. However, this profile references an alternative way of publishing Entity Configuration (see (#hosted_entity_configurations) below), that requires a chain building algorithm starting with a Trust Anchor instead of the bottom-up approach specified in [@!OpenID.Federation, section 10]. | ||
|
|
There was a problem hiding this comment.
I think we need to distinguish between chain validation and chain path building. Even if section 10 is not overly clear about this, section 10.6 opens for allowing a resolver to do the job using alternative path building mechanisms (top-down). This means that section 10 path building does not require publication of Entity Statements on the configuration endpoint.
So I don't think it is right to say that "this algorithm relies on all publishing their Entity Configuration information at a well-known location".
| ### Entity Statement Validity {#entity_statement_validity} | ||
|
|
||
| The validity period of an Entity Statement is controlled by the `exp` Claim. Setting a short validity period undermines effective caching and places a burden on the issuing Entity to continuously update and sign the Entity Statement. Conversely, setting long validity periods for Entity Configurations may delay the propagation of metadata changes, as older versions may remain cached. | ||
|
|
There was a problem hiding this comment.
The main specification states clearly that statements MUST NOT be accepted beyond its exp. However, a verifier may have a local policy that asks for a new statement at any time before exp. in order to enforce freshness.
| - `ES512`, ECDSA using P-521 and SHA-512, as defined in [@!RFC7518, section 3.4]. | ||
|
|
||
| Additional signature algorithms, such as RSASSA-PSS, **MAY** be added to the above list by profiles or federation rules that extend this profile. | ||
|
|
There was a problem hiding this comment.
This may be a good middle way. I still lean towards requiring support for standard RSASSA-PSS (mgf1p)
| Similarly to algorithms, the `token_endpoint_auth_method` parameter [@!RFC7591][@!OpenID.Registration] can only hold **one** value. In a federation, a single set of client metadata may be resolved and consumed by any number of servers. This may cause interoperability problems if two servers that the client needs to interact with have different and non-overlapping requirements for client authentication, as the client would be unable to satisfy both simultaneously. | ||
|
|
||
| It is **RECOMMENDED** that the Federation Operator defines requirements for which client authentication methods OAuth 2.0 Authorization Servers and OpenID Connect OpenID Providers should support, in order to avoid such interoperability problems. This can be done by referring to a specific profile, or by including such requirements in the federation rules. | ||
|
|
There was a problem hiding this comment.
Should we say anything about whether OPs supporting this profile SHOULD support choices instead of requiring explicit values?
There was a problem hiding this comment.
Write a little bit more about choices.
|
In 4.1 Federation Resolver Requirements Should be: |
|
A very good first draft overall, here are my initial comments.
Clarification needed: Is the risk of metadata policy conflicts really completely gone with this approach, or is the risk minimized? |
For discussion: Does this affect the recommended structure of IEs, i.e. which types of entities that should be registered under a particular IE? |
I agree that the roles TA and TMI should be separate with two separate federation entitys.
And further
This reasoning is not obvious to the reader I think. Could it be clarified? Is this referring to chaining from a TA directly to a TMI (to trust it)? Which trust paths are referred to here? |
Do we mean ”adds” or ”overrides” or something else? Just "include" could mean just including metadata from the entity’s metadata configuration, but I don't think this is what we mean here.
Is this not already a MUST in [OpenID.Federation] 8.2 or is it not clear enough in the standard? |
Should we maybe also include recommendations about creating redundancy for critical federation services, such as the Resolver? |
Think it should be ”to also be a Federation Resolver”. It does not change type, it adds the capability. |
What about local policies to handle longer downtimes in federations services or networks? Make it a SHOULD to support that?
Or maybe add ”...unless there is a local policy that states otherwise for emergency or other critical situations.”
|
Think it could be more consistent to use ”SHOULD” for both criteria, since it is only optional to define a policy in the first place. |
I recommend to also have this general rule: ”The Trust Mark Policy SHOULD define rules how to ensure that identifiers for Trust Mark types are collision-resistant across multiple federations. It is RECOMMENDED to follow section 7.1 in [OpenID.Federation] for such rules.” There is a recommendation in the standard for this:
We could also choose to make this recommendation SHOULD. Think this is good in the long run because synchronization between federation operators could be challenging otherwise. |
Think this should be Section 8.6 and/or 7. |
It seems to me like a bad design (in the standard?) to have this dependency in the first place. The problem also spills over to the Federation Resolvers as described in the profile. The typical scenario where a RS, AS or OP needs to check for a valid TM of a certain type could be handled by a cached call to the TMI itself. In that way, verifying entity’s configuration and checking for TMs become loosely coupled, which is a good principle. It also decreases the burden on the Clients, also good. Also, if Entitys check directly with the TMI, the requirement ”A Trust Mark Issuer MUST expose a Trust Mark Status endpoint” would not be strictly necessary, also good. I propose that we have a recommendation regarding this (without breaking something in the standard of course) |
What the underlying rationale to require all of these algorithms for OAuth2 Clients and RPs that may not have the need to validate trust chains or resolver responses? Federation services and Server entities - yes. For discussion: What about future proofing for PQC algorithms? Can this profile pave a way to make that inevitable transition easier? |
Maybe use ”unique scope values within the federation, preferably URIs” |
I think we should consider require Client authentication at some critical federation endpoints, such as the resolve endpoints, to mitigate DoS attacks.
Further, maybe all responses from federation services including error messages SHOULD be signed? See [OpenID.Federation] Security Considerations 18.2 |
s-hal
left a comment
s-hal
left a comment
There was a problem hiding this comment.
Great work on this profile!
During the review, I noticed the use of "chain" as a verb, for example, "chaining", "chains to", and "is chained to".
While this works in discussion, using it in a formal profile creates a mental speed bump. For external developers new to OpenID Federation, it may be confusing. Since "Trust Chain" is defined in the specification, turning "chain" into a verb makes it unclear whether a sentence refers to a relationship, such as having an Immediate Superior Entity, or to a process, such as resolving and validating a Trust Chain. The text would be clearer if it used explicit OpenID Federation terminology.
Replacing this informal wording with the intended technical relationship or process would improve readability and reduce ambiguity for implementers.
| : <br>An Entity within the federation that does not play a protocol role but instead takes on an operational role within the federation, such as a Trust Anchor, an Intermediate Entity, or a Trust Mark Issuer.<br> | ||
|
|
||
| Federation Registration Entity | ||
| : <br>A Superior Entity within the federation with which a Federation Protocol Entity (for example, an OpenID Connect Relying Party) registers to join the federation. This involves the collection of Entity Configuration and metadata, and the creation of an Entity Statement.<br> |
There was a problem hiding this comment.
Metadata is part of the Entity Configuration through the metadata claim.
|
|
||
| - A Federation Operator **SHOULD** define a base URL, or domain, for the federation. This base URL **SHOULD** be used when defining collision-resistant URLs within the federation context, such as Trust Mark type identifiers. | ||
|
|
||
| Some of the above rules are enforced through metadata policies or constraints, while others are enforced by operational means such as audits and controls. |
There was a problem hiding this comment.
s/constraints/the constraints claim
|
|
||
| Also, this algorithm relies on all participants publishing their Entity Configuration information at a well-known location, as specified in [@!OpenID.Federation, section 9]. However, this profile references an alternative way of publishing Entity Configuration (see (#hosted_entity_configurations) below), that requires a chain building algorithm starting with a Trust Anchor instead of the bottom-up approach specified in [@!OpenID.Federation, section 10]. | ||
|
|
||
| Therefore, it is **RECOMMENDED** that Entities compliant with this profile use a Federation Resolver in order to resolve metadata and trust for peer Entities. A Federation Resolver is an Entity within the federation that provides a `federation_resolve_endpoint` as specified in Sections [@!OpenID.Federation, 5.1.1] and [@!OpenID.Federation, 8.3] of [@!OpenID.Federation]. |
There was a problem hiding this comment.
s/A Federation Resolver is an Entity/A Federation Resolver is a Federation Service Entity
|
|
||
| ## Federation Hierarchy Requirements and Recommendations {#federation_hierarchy_requirements_and_recommendations} | ||
|
|
||
| [@!OpenID.Federation] defines an infrastructure in which multiple federation contexts may co-exist without clear boundaries between them. Each federation context is anchored by a common Trust Anchor. A Trust Anchor defines a policy that all subordinate services must satisfy in order for their metadata to be validated through that Trust Anchor. |
There was a problem hiding this comment.
The boundary for a concrete evaluation is the selected Trust Anchor and the evaluated Trust Chain, not an unclear or absent boundary.
Perhaps:
OpenID Federation allows an Entity to belong to more than one federation and to be reachable through different Trust Chains ending at different Trust Anchors. Each federation is anchored by a selected Trust Anchor.
|
|
||
| This section contains sub-sections with requirements and recommendations for structuring a federation hierarchy in order to avoid unnecessary complexity and pitfalls. | ||
|
|
||
| ### Chaining Models {#chaining_models} |
|
|
||
| It is **RECOMMENDED** that federation deployments compliant with this profile define Registration Policy URIs for the policies that are used for registering Entities, and that Federation Registration Entities include the `registration_policy` Claim as defined by [@!OpenID.Federation.RegPolicy]. | ||
|
|
||
| **Note**: A Trust Mark could in theory be used to represent that a certain policy was applied during registration of an Entity to the federation. However, there is an important distinction between Registration Policies and Trust Marks. Whether an Entity holds a particular Trust Mark is typically checked by other Entities after its metadata and Trust Marks have been resolved and validated. Registration Policies, on the other hand, operate as part of the Trust Chain building process and are enforced through constraints defined by the federation. |
There was a problem hiding this comment.
Original:
Registration Policies, on the other hand, operate as part of the Trust Chain building process and are enforced through constraints defined by the federation.
Perhaps:
On the other hand, the Trust Chain is the technical result of a Registration Policy. This policy defines the onboarding rules and metadata constraints under which the federation structure is established.
|
|
||
| ## Federation Resolver Requirements {#federation_resolver_requirements} | ||
|
|
||
| A Trust Anchor or an Intermediate Entity that provides a `federation_resolve_endpoint` is regarded to be a Federation Resolver. |
There was a problem hiding this comment.
Perhaps:
A Federation Service Entity that provides a federation_resolve_endpoint is a Federation Resolver.
| The requirements for the resolve response `exp` Claim given in [@!OpenID.Federation, section 8.3.2] states that the validity of the response must not exceed the validities of the underlying Trust Chain and Trust Marks included. If a Trust Mark instance for the Entity is being resolved is either expired, or has a validity that is shorter than the validity of the Trust Chain, it is **RECOMMENDED** that the resolver obtains a new Trust Mark instance for the Entity by calling the Trust Mark endpoint at the Trust Mark Issuer. | ||
|
|
||
| By following this requirement, the Federation Resolver avoids issuing resolve responses with unnecessarily short validity periods. This reduces the frequency of resolve requests, as longer-lived responses are more amenable to caching by consuming parties. | ||
|
|
There was a problem hiding this comment.
This needs clarification. A national federation may have multiple resolver types with different trust roles. If resolvers may add or refresh Trust Marks not present in the Entity Configuration, the profile must define which resolvers are authorized to do so and under which federation policy. The trust_marks response claim is separate from the returned Trust Chain and has no defined precedence or conflict model against Trust Marks in the Entity Configuration.
|
|
||
| ## Requirements on Trust Mark Issuers {#requirements_on_trust_mark_issuers} | ||
|
|
||
| A Federation Service Entity that exposes a Trust Mark endpoint as defined in [@!OpenID.Federation, section 8.3.3], is a Trust Mark Issuer. |
There was a problem hiding this comment.
Perhaps:
[@!OpenID.Federation, section 8.6]
|
|
||
| The Trust Mark Issuer is responsible for maintaining a repository of the Entities that are entitled to specific Trust Mark types, including the authorizations and limitations that apply to them. The procedures by which an Entity applies for a Trust Mark, and the procedures used to determine whether a Trust Mark is granted, are outside the scope of this profile. | ||
|
|
||
| If short-lived Trust Mark instances, that is, JWTs with an `exp` Claim set to a near-term time, are issued, this affects the validity of Entity Configurations that include such Trust Marks. Consequently, the validity period of resolve responses issued by a Federation Resolver may also need to be reduced. |
There was a problem hiding this comment.
An expired Trust Mark contained in an Entity Configuration does not by itself invalidate the Entity Configuration. It only invalidates reliance on that Trust Mark.
6 participants
First draft ...
HTML version at: https://www.oidc.se/specifications/drafts/swedish-openid-federation-profile-draft.html
Closes #131