[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review
thomasclinganjones at gmail.com
Mon Jun 28 23:42:25 UTC 2021
I expected that the services and capabilities available from a client (RP)
will vary wildly depending on a wide range of conditions. For example a
user from UW going to the library will have much more capability than a
user from a foreign university.
My primary use case is the client displays a 'bunch' of nascar logos for
each federation that they will support. ..tom
On Mon, Jun 28, 2021 at 2:00 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> 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
> 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
> 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,
> 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
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab