"OpenID Connect Federation" specification is useful beyond multilateral federations using OIDC.

[Kristina Yasuda]

Introduction of the specification says

This specification describes the basic components to build a multilateral federation and provides a guide on how to apply them when the underlying protocol used is OpenID Connect.

However, it is useful in the context other than OpenID Connect and other than multilateral Federations. For example, trust management in issuer-holder-verifier ecosystems that use OAuth based OpenID4VC specs.

Please generalize the language in the spec and not limiting it to miltilateral federations based on OIDC (though ofc mentioning them), and rename the specification to something like “Dynamic Trust Establishment“ would be very very useful and powerful.

‌

[Torsten Lodderstedt]

I support this issue. OpenID Connect Federation has a lot of potential for other technologies and domains than OpenID Connect and Federated Identity. We try to use it for decentralized identity (issuer-holder-verifier ecosystems). However, the current name causes people to believe it is limited to OpenID Connect.

I therefore support the proposal to give it a new, more universal name. I suggest to call it “JWT-Secured Trust Graphs (JTG)“, following the analogy of JWT Secured Authorization Request (JAR) (https://datatracker.ietf.org/doc/html/rfc9101).

[Giuseppe De Marco]

My only concern is that changing the name of the specs would make .well-known/openid-federation not usable anymore, another name should then be used (.well-known/jwt-trust ?)

the implication of changing the path of the most important endpoint of the specification is very critical for infrastructures that has already deployed oidc federation.

This would result in a disastrous break, occurred in a very considerable state of maturity of the specification.

With this I don't want to say that something useful shouldn't be possible, because I appreciate the value of your proposal especially in new contexts still being explored, very different from the experiences gained within traditional digital identity infrastructures.

I would ask to look for alternative paths, such as the birth of specifications that take from oidc federation, with appropriate references to this one and without reinventing everything, but modify some design principles for wider scopes.

This would make the birth of a specification with a new name and a new well-known path as a natural consequence, which highlights the evolution of an approach through a specific parent (oidc federation) and other children (jwt secured trust graph).

Just to be creative, why “JWT-Secured Trust Graphs (JTG)“ and not “JWT-Secured Trust Trees (JTT)“?

[Michael Jones]

I agree that the spec provides trust establishment functionality that is broadly useful. Whether to rename it, given the existing name recognition and deployments is a separate question, which warrants further discussion in the working group. There are upsides and downsides. The alternative to changing the title is to update the abstract and introduction to be clear about the broad applicability of the functionality defined.

[Michael Jones]

Discussed on the 6-Apr-23 working group call.

[Torsten Lodderstedt]

Naming influences perception. The current name clearly causes people to think „this is for OpenID / federated identity”.

[Giuseppe De Marco]

I’m in favour of removing “connect” and having then “OpenID Federation“

Regarding the removal of OpenID, I’m not in favour of this because it would imply that also .well-known/openid-federation should change and this represent a dangerous breaking change

My concern on the use of the title *JWT-Secured Trust Something* is that the specs doesn’t define just a data model encoded in JWT but a set of endpoints, an entire REST API, that more than confined to a JWT spec only. Concerns additionally reinforced by many claims to not to sign the response but rather to obtain in clear JSON, which reduces the evidence to the use of JWT, consequently.

Regarding the use of the term “Trust” instead of “Federation” I think that Trust is the proven margin guarantee, while Federation is an infrastructure, that’s both normative and material. I agree that this sounds something monolitic, but, at the same time, the specification enables extreme flexibility and promiscuity of the participants, in adhering to many federations at the same time, drawing paths that are not entirely linear (graphs?). Let's think about it, I think it's important to meditate on the true meaning of words and with the right assumptions, while avoiding creating editorial and content traumas guided by ambitions of a cosmetic nature

With this I don’t want to stop the process of exploring new semantics for the scope of the spec, indeed, I find this process extremely useful, and if critical even better, whatever the cost, we go all the way

[Giuseppe De Marco]

This PR removes the words OIDC in the introductionary text, making wider the scope of the specs for the OAuth2 implementers and not just for the multilateral federations

https://bitbucket.org/openid/connect/pull-requests/510

[Giuseppe De Marco]

Resolevd by https://bitbucket.org/openid/connect/pull-requests/510