[Federation] entity configuration in plain text

[Giuseppe De Marco]

In the italian implementations we have adopted the parameter ?format=json for sake of readability of the .well-known/openid-federation, to speed up development tasks and debug.

In the editor’s call of the 18 November we decided to discuss this parameter and open this issue to have a feedback about the possibility to get this parameter in the specs

the default response format is entity-application/statement (signed jwt) but with this parameter the response would be application/json

[Andrii Deinega]

I believe you are referring to /.well-known/openid-federation, not to /.well-known/openid-configuration in the first sentence.

The challenge I see here is that /.well-known/openid-federation can be just a static file and a requirement

1. to handle new query parameters
2. return any other content types than application/entity-statement+jwt

means that the backend must generate a response in a dynamic way… which will add some (probably unnecessary) complexity for implementers.

‌

[Roland Hedberg]

I didn’t remember the discussion in the way Guiseppe describes it.

What I thought we agreed on was that the query would be the same but that the response could be either a signed JWT or an unsigned JSON document. Which one you got is to be determined by looking at the content-type header. If application/entity-statement+jwt you know you got the signed JWT if application/json the unsigned JSON object.

[Giuseppe De Marco]

I'm sorry @Roland Hedberg

I wrote this issue during the call and probably quite tired, I've missed some points.

I fully agree with you and Andrii, using the content type in the response is better. That parameter to the .well-known endpoint is quite horrible.

Having said this, the discussion Is open for having the entity-configuration also in plain text, using a request with a content-type set to application/json to .well-known/openid-federation

@Roland Hedberg what I remember, but correct me if something Is wrong, Is that by default, with any particular content-type in the request, the response should be signed

[Roland Hedberg]

Yes, the default is that the response SHOULD be a signed JWT. Only if an operator know exactly what they are doing may they return an unsigned response. It is definitely not something we recommend.

[Torsten Lodderstedt]

Wouldn’t different accept headers the proper way to request different representations of the data?

[Roland Hedberg]

One fundamental question then is if the sender or the receiver or both should be allowed to decide what is transmitted.

My vote is for the sender.

[Giuseppe De Marco]

My vote
Considering that the audience of the response is the receiver, I vote for the receiver but in the specs I think that we use the term SHOULD and not MUST , letting the sender (and the underlying implementation profile) decide to allow this or not.

Assumptions
I believe that we should talk more about the scope of this proposal because obtaining the Entity Configuration in plain text makes it non verifiable in a trust chain (or differently verifiable, using a comparison of the federation jwks without any verification of the signature).
This has obvious implications that should prompt us the identification of use cases where an Entity Configuration can be used even if unsigned and outside a trust chain, and the same for Entity Statements.

Starting from this consideration, and expressing all my enthusiasm to explore alternative mechanisms for establishing trust, it occurs to me whether also the Entity Statements returned by the fetch endpoint could or should be able to be requested in plaintext (json).

The problem
I would like to get to the point and reduce the number of words: some implementers believe that the FQDNs and HTTPs are enough to establish trust, and everything returned by these endpoints becomes certifiable as secure and authoritative.

Federation adds application-level signing and verification operations.

For some this is excessive.

The Chance (or Challenge)
I think Federation should keep the current setup and add the possibility to get the response in clear text, if requested by the senders of the requests in both .well-known/openid-federation and federation_fetch_api.

We should describe the implications of this in the specs, without changing the current approach based on trust chains.

In the same way, this small possibility of obtaining responses in plain text will allow the creation of several implementation profiles. One of these would be the offline use case in the Wallet/SSI implementation. How to use Federation to establish the trust without being able to reach the federation API, through a broadband connection. Using federation_list_endpoint and federation_trust_marks_status_endpoint we could have a proposal for the eIDAS trusted list.

Possibility that I find extremely interesting, provided that the trust infrastructure, obtained with the Federation API with the mandates that each trust verifier can always build a Trust Chain in a canonical way, must be respected and implemented as the specs defines. So we force the deploy of the Federation API to allow the less or the most way to build the trust, allowing the responsability of how trust is established to the trust verifier.

Warnings and implications
allowing alternative ways to establish the trust without the use of the trust chain will reduce the power of the metadata_policy and metadata in the entity statements, that could be eluded by a naive trust verifier.

Example of naive trust evaluation
Here's an example of an alternative trust evaluation mechanism:

A participant publishes its Entity Configuration with a Trust Mark inside that certifies its membership in a federation. The trust verifier verifies the trust mark on the trust mark status endpoint and trusts it (online use case) OR the trust marks signature, having previously obtained the federation public keys of the trust mark issuer (offline use case).

This is to say that just as in civil society, each individual uses different methods to establish trust, even if there are canonical and safe methods for doing so, often on different occasions individuals adopt different methods (implementation use cases). This is to say that if we identify in Federation the role of defining how a trust infrastructure, based on the mechanism of delegation, must be built and at the same time we leave it to the participants to define new trust mechanisms (less or more secure), I believe that the specification can evolve without changing the infrastructure that defines, but only the values ​​of the interactions between the participants.

in other words we can bring Federation closer to the logic of social adaptation (as in the human society) and let the implementers use the components of its infrastructure (Federation API) and show us what evolutions it can have, of meaning and value on interactions, without making any changes on a technical level.

Sorry if I took poetic license for this post.

[Roland Hedberg]

I have two major objections to making the receiver decide.

1. It makes the client code more complicated
2. It makes it way to simple to do something which is not end-to-end secure

If we let this into the specification we should at least make it hard to do things insecurely. It should at least necessitate something like a change in the configuration of the client. Just setting accept headers is way to simple IMHO.

‌

[Tobias Looker]

IMO if this approach were looking for consistency with how other related aspects of discovery and metadata management works in the broader OAuth2 and OIDC space, then the primary response form would be unsigned (e.g refer to RFC 8414 for example https://www.rfc-editor.org/rfc/rfc8414) making it easy for the simplest client to consume the metadata as an ordinary JSON document. Then if required for additional security the JSON document could also include a JWT that features the same metadata in a signed form. I appreciate there are already implementations of OpenID federation so this is likely un-workable because of that, I just felt it was useful to point out.

It makes it way to simple to do something which is not end-to-end secure

I dont think it is that accurate to say serving a JSON document over HTTPS is inherently insecure, if you don’t trust your TLS / HTTPS connection then it is not, however OpenID and the broader OAuth2 space often makes this assumption so there is definitely precedent to trust HTTPS/TLS in this way.

[Giuseppe De Marco]

I would like to reconnect to this thread with the following schema.

Scope

S1. Make Federation flexible, facilitating the born of implementations profiles that doesn’t use all the features of Federation, or the default security profile offered by Federation, but its Federation API to explore alternative ways to establish the trust. Federation can become a framework for building different trust mechanisms using common building blocks (Federation API).

S2. Make Federation able to define trust mechanisms also in offline scenarios, where the online Federation API is not usable.

Requirements

R1. Preserve the stability of the specs without introducing any breaking change that would have impact on the current implementations or the default security profile defined in the specs.
R2. Keep the security-by-default approach using language that give clear indications about the rationale behind every aspect the text mandates without forcing a normative language that would reduce the born of new implementation profiles.
R3. Collect use cases in support of R2.

Assumptions

A1. RFC8414 doesn’t specify the content-type of the request (section-3.1), it gives the content-type of the response as application/json.
A2. FQDN and HTTPs are traditionally used in the trust mechanisms between two entities.
A3. Federation mandates the signature of the responses (JWT) to keep its security profile very high (listing and trust mark status endpoint made an exception on this). The current approach is resistant to any kind of ssl-split mechanisms or https2http on the edge of the Web infrastructures. Federation API contents can be deployed also in a single or multiple CDNs (see this) or through an http frontend of frontends, preserving the integrity and the verifiability of the data.
A4. OAuth2 Clients are not forced to fetch openid-federation, they can continue working with oauth-authorization-server, as RP can continue working with openid-configuration. Federations doesn’t collides with other well-known endpoints.
A5. openid-federation is the metadata of the metadata, it contains all the known roles in the OAuth2 and OIDC ecosystems (client, as,op,rp,rs …) and also the Trust Marks. It has its own schema.
A6. Even if a legacy OAuth2 Client obtains openid-federation in plain-text, it must know openid-federation schema to take the relevant information needed by it (this breaks compatibility with the legacy implementations).

Proposal

P1. See R3 (@Torsten Lodderstedt @tobias please feed this if you can, in support of your claims).
P2. Allow the content-type application/json in the http request to .well-known/openid-federation and to federation_fetch_endpoint and return application/json in the response, allowing a human readable approach to federation resources.
P3. Say in the text that the responses in application/json are not intended to be usable for the composition of the trust chains.

Implications and consequences

Hypothetical born of a new or more then a single Federation implementation profile that:

a) uses only the Entity Statements with subordinate’s metadata in it, to give final metadata of a subject
b) uses only the Leaf’s Entity Configuration to get the metadata and optionally adopts only the trust marks in it to attests compliances … considering that Trust Marks are signed apart.
c) uses only the Leaf’s Entity Configuration and the TA’s Entity Configuration, even without the proof that an Entity belongs to a TA (yes !). The Leaf’s Entity Configuration gives the metadata, the TA’s Entity Configurations may give the metadata_policy and the trust mark issuers to be considered (even for those who are not its descendants!)

Conclusions

C1. All the implementations that doesn’t adopt the trust chain should be considered naive implementations, because of their lacks regarding metadata_policy and delegation mechanisms to the intermediaries. These are very important features that Federation exalts in its interactive and completely dynamic infrastructure of trust.

However
C2. it would be a loss to prevent the "creative" use of the Federation API even as a transitional implementation before its full adoption within one or multiple organizations.
C3. It would be worse not to allow building something different, with the components already defined in Federation.
C4. It would be risky, for the fate of the specification, to freeze any possible evolution in the bud and deprive new implementers of exploring their possibilities, using tools already tested and far more powerful than their expectations and needs (like a Ferrari in the courtyard, but ... it's still a ferrari, no matter who drives it).

C5. all the required Federation endpoints MUST be deployed, to allow any participant to build the trust in the canonical way.

‌

[Michael Jones]

I appreciate the useful discussion in this issue (and the in-person discussions that informed it). It seems to me that using content types in the request and response are part of how we can extend the reach of the metadata mechanisms defined in the spec while keeping appropriate security properties for the different use cases.

One editorial device that we could employ is continuing to describe the JWT-secured entity statements and trust chains in the main body of the spec, while adding descriptions of unsigned entity statements and possibly trust chains in an appendix, clearly stating that these are for other use cases. We should be clear about when the signed trust chains anchor the trust decisions versus when Web PKI anchors them. Both are legitimate trust mechanisms but they are distinct.

FYI, I’m going to be with John and other federation experts at the Internet2 Technology Exchange Conference in Denver Dec 5-9. Hopefully we can use that time well to make progress on these important topics.

[Tobias Looker]

It seems to me that using content types in the request and response are part of how we can extend the reach of the metadata mechanisms defined in the spec while keeping appropriate security properties for the different use cases.

+1 this on the surface looks like a solution that retains the security characteristics of existing openid-federation deployments while adding the capability for a less complex implementation option (unsigned metadata JSON document) for cases where the signing is not required.

‌

[Michael Jones]

I plan to do this in a new appendix enabling this functionality.

[Torsten Lodderstedt]

Hi all, based on the discussion at IIW (and previous discussions at IETF 115), I have put together some slides illustrating what we (co-authors of OpenID4VCs) want to achieve and how we think OpenID Connect Federation could be evolved. I share this because I want to give more context for the discussion (also in this issue). Happy to schedule a call to talk you through the ideas.

https://docs.google.com/presentation/d/1BRVrMSY7fbVOtQz-neomvi8Txm24IpbCQMzgB4R7q28/edit#slide=id.p

[Michael Jones]

Torsten, we discussed your presentation during the Federation editors' call yesterday. We’d be glad to take you up on your offer to schedule a conversation. I’ll be in touch in the coming week.

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/447

[Michael Jones]

Will be resolved by https://bitbucket.org/openid/connect/pull-requests/448

[Michael Jones]

Having revisited this issue during the 4-Aug-23 Federation Editors' call, the editors don’t see a compelling reason to have Entity Statements as unsigned JSON. It would hurt interop. We propose to close this issue in a week unless reasons are stated to keep it open.

[Michael Jones]

Closing, per decision on 4-Aug-23 Federation Editors' call.