[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review

David Waite david at alkaline-solutions.com
Tue Jun 29 01:17:48 UTC 2021


I believe the model (or at least the ideal model) would be that all the entities participating could publish all their respective capabilities across roles. Under the lens of a particular authority for the federation policy, their potential capabilities each get clarified in that context. (e.g. they support three signing algorithms, but this authority mandates ES256). When two parties attempt to communicate with one another under respective roles under a common authority,  you use rules like those in client registration to determine exact operational capabilities.

But your base metadata as a client can indeed be “everything”.

I will say that in the SIOP context, it is likely that the SIOP variant of an OP will likely be several parties operating under a “collective” [insert better term if available]. That is, a particular instance of local software isn’t able to advertise additional capabilities beforehand. So thus I expect the collective itself to be the entity that has metadata - and that a SIOP wallet may decide to operate under multiple entity identifiers as multiple collectives, each with different advertised capabilities.

As an example, there may be a federation with a collective operating as https://example.gov that is dedicated to providing government identification and mandates that participants can present a credential in a particular format, and another federation with a different collective operating under https://example.edu which can provide educational transcripts, and mandates that participants can provide a different credential, potentially in a different format.

As a RP/verifier, I might make a SIOP request to one collective (e.g. redirect to its authorization endpoint) for a government id, and another for a transcript - but a particular native wallet or PWA can support both.

A collective could also be created as an entity under both federations, and have an entity id of say combined.example.com, and a RP/verifier could take advantage of that to request both at once.

Of course, the RP can always request more than advertised - but since the process of SSO is disruptive because of the redirect, you will often want stronger guarantees that the user will either be sent into a piece of software that can handle the request, or will land on a page that has consistent recovery behavior (letting the user install software, automatically sending the user back with an informative failure, etc).

-DW

> On Jun 28, 2021, at 5:42 PM, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> 
> 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 <mailto: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 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.)
> 
> -DW
> 
> > On May 25, 2021, at 5:27 PM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto: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 <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 <https://self-issued.info/?p=2175> and as @selfissued.
> >  
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210628/cc5ae249/attachment-0001.html>


More information about the Openid-specs-ab mailing list