[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review
david at alkaline-solutions.com
Mon Jun 28 21:00:27 UTC 2021
I have other feedback items but would like to focus on a particularly thorny one; entity statements are perhaps broad and dynamic enough that they are both challenging to understand as a concept and have business logic involved in evaluation. Some of the flexibility around them I believe could also result in interoperability issues.
To summarize my understanding, an entity statement JWT defines multiple new concepts:
1. Self-issued statements which provide a metadata structure superset of OpenID Connect Discovery, supporting multiple protocols/roles as well as defining them as a signed document format.
2. Specific federation metadata representing information about the entity's role within the federation
3. One or more authority hints, pointers to parent intermediate entities which are expected to offer trust this entity, hopefully chaining up to an authority that a party processing entity statement has a trusted relationship with.
4. Trust statements in the form of an ’sub’ which is a separate child entity, creating a trust chain
5. Constraints on the ability for a child entity to make trust statements about other descendant entities
6. JWT and metadata mustUnderstand-style critical sections.
7. Trust marks, which are basically external statements but are outside the scope of the defined trust hierarchy.
Which claims can be within an entity statement depends on whether you are a leaf node or intermediate node. Which claims can be used _also_ depend somewhat on context, as you can fetch iss=sub statements about an entity, and iss != sub statements about the trust of another entity. Finally, I can share return different entity statements per-entity - leveraging the ‘aud’ claim on the federation endpoint and by submitting different RP entity statements to OPs on explicit federated registration. This includes an intermediary dynamically changing metadata policy for a particular audience.
That the intermediate can offer metadata as well as policy creates issues, including one of what metadata policy is applied to the intermediary or not.
Finally, note that since you can provide both authority hints and trust statements, you effectively form a directed cyclic graph.Assuming no cycles, you could still wind up resolving metadata differently for two different paths from an entity to a single trust root - one through a intermediate node that performs a metadata policy ‘add’ or ‘default’ and one which doesn’t.
I would propose:
1. Consider the impact of intermediates being able to issue to both provide services themselves and offer services to other child entities. Clear rules need to be defined here about impact and interoperability, e.g if metadata policy applies to oneself or only to children. I lean towards an intermediary who wants to offer direct services must create their own leaf (since URL are cheap), but realize there may be services that make sense to provide at the root authorities, e.g. federation-wide trusted services.
2. Consider defining three different kinds of statements - an entity metadata statement describing metadata, a ‘policy’ statement describing authority and dictating policy of child entities as a group, and a ’trust’ statement which declares trust of a particular child entity (along with additional trust chain restrictions). If metadata statements can’t be issued by intermediaries and root authorities, these actually would become three separate kinds of JWTs, possibly distinguished by `typ`. If an intermediary can offer metadata/services, this becomes a conceptual differentiation - we define these statements first as interrelated concepts, then define how we put them into JWTs.
3. Provide a statically resolvable form for all JWT-protected statements - e.g. a URL resolution process like a no-parameter GET from a `well-known` location. Trust statements are the only piece which would need a dynamic resolution process due to number of child entities, and this could be declared as part of the policy statement.
4. Eliminate via a combination of technical and conformance measures the ability to provide custom policy statements and custom metadata statements. A technical measure would be making the well-known resolution authoritative, with a requirement that the statement not be distinguished by the requesting audience or authentication. Other systems (such as a trusted metadata resolution endpoint) would build on top of the authoritative information.
5. Define an alternative method over a trust statement resolution endpoint to statically provide an authoritative list of trust statements - such as embedding the trust statements as a JSON array within a policy statement. This should allow for all federation metadata to be served statically.
6. Forbid the use of `default` or `add` metadata operations on any operationally impacting policy field - An intermediary can set a default tos_url, but I can’t add a registration_endpoint or a id_token_signing_alg.
7. Define a default behavior for authority_hints where it is a priority list, with the ability to specify other behaviors via future critical claims in the statement.
8. Using this default behavior of authority_hints, define a specific resolution steps such that there is a deterministic resolved form of metadata based on a given set of statements. Note now that these inputs and thus this output is invariant to the audience who is doing this evaluation.
9. Do not define a broad federation_api_endpoint - define purpose-specific endpoints (since URLs are cheap), The only endpoint needed is to retrieve trust statements from an intermediary. The current form prevents discovery of operational features on the federation api. Note that I already did this above with a trust statement resolution endpoint in policy statements, leaving the federation api endpoint as defined entirely for optional behavior (resolution of statements, evaluation of statements, etc)
10. Evaluate whether a trust statement and the entity metadata statement both need to support JWKS e.g. multiple keys. I would expect a trust statement to only use a single JWK.
(I can elaborate and propose PRs for these separately, but do not wish to do so before broader discussion.)
> On May 25, 2021, at 5:27 PM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> The OpenID Connect Federation specification has been updated to add Security Considerations text. As discussed in the recent OpenID Connect working group calls, we are currently reviewing the specification in preparation for it becoming the third and possibly last Implementer’s Draft.
> Working group members (and others!) are encouraged to provide feedback on the draft soon before we start the foundation-wide review. We will probably decide next week to progress the draft to foundation-wide review. In particular, there’s been interest recently in both Entity Statements and Automatic Registration among those working on Self-Issued OpenID Provider extensions. Reviews of those features would be particularly welcome.
> The updated specification is published at:
> • https://openid.net/specs/openid-connect-federation-1_0-16.html
> Thanks to Roland Hedberg for the updates!
> -- Mike
> P.S. This notice was also published at https://self-issued.info/?p=2175 and as @selfissued.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab