Update document to reflect the capabilities of the resolve endpoint

[Stefan Santesson]

The OpenID federation provides a great structure that enables decentralised distribution of trust and metadata.

One of the initial worries was however the level of complexity of chain processing from a leaf to a Trust Anchor in order to retrieve all aspects of the chain, validate the chain and then validate all relevant trust marks. Our experience of how hard it is to get many service providers to correctly implement much easier processes made us worry quite a bit.

For this reason we found that one of the most valuable contributions to this document is the resolve endpoint described in 7.2.

For us this changes everything. Suddenly we can offer a service through which leaf entities can obtain complete and trusted data about any peer using is single request, validated through a single trusted key. In fact, this has made it possible to considerably simplify and optimise our profile and to make the life significantly easier for participating services.

However, it almost seems like this very powerful feature has almost been hidden in 7.2 without being properly reflected in the rest of the document. From what I heard, there is a good explanation for that being that it is a new feature recently added. We do however believe that it needs to be highlighted more and some sections need updating to reflect the use of a resolve endpoint as a viable alternative to chain validation.

‌

Add section about the resolver

The word “Resolver” only appears inside 7.2 without being mentioned as an entity in ints own right. It is still my impression from 7.2. that the Resolver is a function that could be delivered outside of any other role. A resolver does not need to be an Intermediate entity. It could just be an independent service e.g. under one or more TrustAnchors with the sole task to resolve entity information.

For this reason I think the Resolver deserves to be mentioned and described at least in the Terminology section and I would also welcome that it is given its own section that describes its purpose and potential benefit to a federation.

Resolve listings endpoint for resolvers

We see great value of an endpoint where a resolver can provide a list of resolvable entities (List of EntityIDs). This would be a very powerful amendment to allow a chain of resolvers to process and prefetch informations about entities from each other as background processing to optimise their services. A superior resolver could ask a resolver of a subordinate federation for all its resolvable entities and then periodically cache data about those entities directly from that resolver.

The protocol of the Subordinate Listings endpoint seems to do the job technically, but it lacks the necessary request parameter “trust_anchor”. I’m not sure if the best solution is to update the subordinate listings endpoint, or to add a new resolve listings endpoint. I suspect the latter is safer to not mess with implementations.

If a new endpoint is added, a new metadata parameter for the endpoint URL is needed in 4.2.6.

Other document updates

Section 3.2

Section 3.2 states that an Intermediary is “Neither a Leaf Entity nor a Trust Anchor”.

In the terminology section it is said to issue Entity statements. These are not harmonised as a Resolve entity may not be part of a chain and may not issue Entity Statements. 3.2 should be aligned with the text in terminologies.

Section 6.

In our draft profile we consider the user of resolvers as means to not having to require leaf entities to publish an EntityConfiguration. Whether they do or don’t is a matter of local policy between the leaf entity and its superior entity as part of their registration process.

However section 6 does not reflect this possible option. For example the last section states:

Entities SHOULD make an Entity Configuration document available at the configuration endpoint. There is only one exception to this rule and that is for an RP that only does Explicit Registration. Since it posts the Entity Configuration to the OP during client registration, the OP has everything it needs from the RP.

Use of a resolver should be an option here.

Section 8

The leading text in section 8 states:

Depending on the circumstances, the consumer MAY be handed the remote peer's Entity Configuration, or it may have to fetch it by itself. If it needs to fetch it, it will use the process described in Section 6 based on the Entity Identifier of the remote peer.

This would be OK if section 6 mentioned the option to use a resolve endpoint.

Section 10

We have several issues with section 10 related to this issue.

1. Lack of reference to the resolve endpoint as an alternative to obtain trusted data about the RP
2. Inappropriate additions to the request protocol.

Section 10 only mention two approaches to client registration “Automatic” and “Explicit”. The description of the “Automatic” registration process require that this process starts with obtaining the Entity Configuration. The use of a resolve endpoint needs to be mentioned here as an alternative strategy.

However, after reflecting over this section, I would personally consider removing it, or alternatively remove all requirements and move it to an informative Annex.

I think it is inappropriate for a metadata specification to impose rules on the OIDC protocol. Its function should be limited to specifying the infrastructure that parties can use to obtain validated data about peers. Not how that data is used. This specification already provides all information necessary to obtain and validate metadata, keys and Trust Marks from peers without having to modify, alter or amend the request protocol. The EntityID of the peer is all that is needed to obtain trusted data for that entity using OpenID federation. I find it redundant to define the “trust_chain” request parameter and I also think that it inappropriate data in a request that we normally want to keep small.

I would suggest that the specification content of section 10, probably is better handled by other specifications making use of OpenID federation. The scope of OpenID federation should end with making the information about peers available and verifiable.

[Giuseppe De Marco]

I find many interesting points in this issue, thank you @Stefan

The concerns about giving so much importance to this endpoint is that if the implementers would build an infrastructure of trust leveraging too much to the resolve endpoint like a sort of Trust Anchor we would forget the decentralized approach in favor of a centralized infrastructure

The resolve endpoint is mentioned to give two benefits:

• debug: An RP can see if/how its metadata has been processed by an OP, if the OP offers the resolve endpoint and vice versa. This would reduce tickets when metadata get misaligned or metadata policies are not implemented well by some entities

• implementation guidance to organizations that look to an architecture made by microservices within their domains and need to not discover the trust for each entity if already discovered for any of their RP within their domain.

The resolve endpoint has impacts on the trust model if we replace the trust anchor with it, in the material implementations. It should return only the data related to the already processed trust chains, taking it from its cache, without triggering any new discovery.

The actual text doesn’t prevent to the implementers to create an infrastructure that uses the resolve endpoint in a way that it would represent a central registry but, at the same time, it doesn’t really want to encourage this approach because the security of Federation is made by a chain where its statements are picked from multiple organizations, while a single registry could be tampered with some sort of attack (even at DNS+TLS level).

I agree to improve the text, however I would not guide the implementers to abandon the discovery and the fresh and secure statements took by their own

[Stefan Santesson]

Thank you for interesting views. I think we have slightly different views and expectations on the resolver.

First of all. The resolve endpoint can never replace the Trust Anchor. The Trust Anchor is the origin of trust also for the resolve endpoint.

I think the most likely entities to offer resolve endpoints are the Trust Anchors themselves and perhaps some Intermediate entities.

For me, this is not about “encouraging” services to adopt one or the other strategy. The resolve endpoint can be used to outsource the chain validation, trust mark validation and metadata processing to a service they trust. If they use the resolver, it should work and they should not have to do it themselves. If a resolver can’t be trusted to do such task, we should not define that function.

‌

[Giuseppe De Marco]

Yes, It makes sense, however the Devil Is in the details.

If you want to go in this direction the current specs allows you that as they are. I Just recommend to harden the implementation making mandatory the jws trust chain header parameter in the resolve jws Response containing the trust chain about the issuer and the trust chain parameter in the jws body about the subject

What additional text would you like to have in the current text and what you would propose to change?

I would like to get your proposal

[Stefan Santesson]

I think my first post contains a quite elaborate description of what I would like to change.

The major concern is that the resolve endpoint offers an alternative to do chain validation, but this is not reflected in the document. Many requirements in the document (as listed above) don not seem to recognise use of resolve endpoint as a valid alternative.

In my vision of using this standard the only entities that actually will perform chain validation are the federation entities (Intermediates, Trust Anchors and Resolvers). Everyone else will ask for consolidated entity data using a resolver.

We will simply make it mandatory in our profile to provide a resolve endpoint and I can’t see why any leaf endpoint would choose to not use one.

As a result of this. in my vision of using this, we will not require our leafs to publish a .well-known location. By doing so we believe that it will be easier to get services to enroll in the system with least effort. We will delegate registration of relying parties to Intermediaries and let them decide how to register the services and whether they need the RP to publish .well-known location offering an Entity Configuration. These are important simplification that we believe will be key to success.

The problem is that the standard in many places appears to require:

1. That all entities must publish Entity Configuration (with only one exception)
2. That you must start the process to resolve metadata using an Entity Configuration

We think our vision to use OpenID Federation is legitimate. We would like to use it this way without violating the standard.

In the last days I have also considered a custom extension to the resolve response: We may define a parameter like “entity-configuration-url”. This will point to the entity-configuration data of that entity if this is available. If not, it will point to the Entity Statement by its superior entity. In the latter case the Entity Statement MUST contain complete metadata of the entity. With this amendment we hope to solve the discovery challenge when Entity Configuration data is not published when you need the unaltered metadata of the leaf entity before policy processing.

[Giuseppe De Marco]

Ok.
This approach is the equivalence of the SAML2 MDQ and I understand why you look for this alternative in the federation specs.
Working only with MDQ/Resolvers we end with reducing the infrastructure and the following freedoms of the participants:

• change their metadata in their EC when desidered/needed, without bureuocracy costs
• join to multiple federation at the same time without changing their metadata or pretend to propagate their metadata to multiple resolvers/onboarding systems.

In Italy, for instance, a SPID RP is part of the CIE federation without notifying its metadata to nobody. It just has the freedom to change it anytime.

I understand your point and I understand your requirements and impl constraints. For this reason I would suggest to you to work with static trust chains.

RP1 issues an authz request containing its Trust Chain:
- RP1 knows who its Intermediate/TA is
- RP1 knows where to fetch the statements about him
- RP1 self issues its entity configuration without providing it in the well-known/openid-federation endpoint

OP1 that receives RP1’s authz request validates the Trust Chain contained in the request, since it is not expired it just checks for revocation, by fastly updating the statements using the source_endpoint parameter. This approach, without the revocation checks, would works also for offline flows (!).

The RPs would be able to build their discovery page, obtaining the list of the OPs, using the subordinate listing endpoints or the trusted marked listing endpoints. The Entity Statements related to the OP would contains also the OP’s metadata, if the OP are not able to publish their openid-federation endpoints (even if I assume that at least the OP are able to do so, at least the OP I would say)

Tell me you like it

[Stefan Santesson]

I really, really would like to tell you that I like it. And I do, because it is you :)

But unfortunately it contains 2 major deal breakers.

1. It would require an update to the current OpenID profile with regard to the request protocol and materially changes how requests are processed.
2. It would require the OP to implement the whole complexity of OpenID trust chain validation.

If I presented this to the largest OP in Sweden they would just say. Thank you, but no thank you. In that case we will continue to manually enroll RPs.

I have what I think a much easier process in mind.

1. RP1 issues a completely normal OIDC request, with no modifications from what they send today
2. OP choose the resolver and TA they trust and make a resolve request for the requesting EntityID.
3. They receive the validated metadata, Trust Marks and keys and determines if they want to serve the request.
4. If they do, they import the metadata to their already existing metadata parser for RP metadata and serves the request accordingly.

‌

For RP:s wanting to build a discovery page, I need the new resolve listings endpoint I proposed. The RP will ask the resolver of a list of all resolvable OPs that are valid under the relevant TA. If the RP operates in multiple federation contexts, it will choose the TA relevant for the current context.

This I think I can sell both to the RPs and to the OPs.

[Michael Jones]

We discussed this on the 13-Nov-23 working group call.

This issue actually covers several different topics, which should probably be addressed individually.

[Michael Jones]

Hi Stefan. It was great to sit down with you in person last week at TIIME. I’m going through the open issues in light of our discussions there.

Could you have a look at the latest editors' draft at https://openid.bitbucket.io/connect/openid-federation-1_0.html and let us know what specific changes you’d still like to see to address this issue? If there are none that you’re still suggesting, could you close the issue or indicate that we can do so?

Thanks.

[Stefan Santesson]

Hi Mike. I see that you have been very active. Thank you for a great time in Denmark. I have had some really busy days, but I will go through all my issues this week and compare the status with the new draft.
I hope we can close most issues after that!

[Michael Jones]

Thanks!

[Stefan Santesson]

Hi,

I think most of my comments here got ignored. Here is what I would like to see given our latest discussions:

• Define the “Resolver” as an entity in its own right (not only an endpoint that may be provided by other federation entities. You may provide the role of a resolver without performing any other role.
• Section 10 should mention the use of a Resolver as a supported alternative to performing your own chain validation.

In addition to this I would also suggest:

• Add means to obtain a list of endorsed resolver federation entities in a TA or Intermediate Entity Statement
• Add a discovery endpoint for resolvers where you can list all Entity Identifiers of services that are resolvable under a TA, that matches basic selection criteria (Type, Trust Marks etc.)

‌

[Michael Jones]

It makes sense to have Section 10 (Resolving the Trust Chain and Metadata) mention the possibility of using a resolver. I’ll create a PR to do that.

We discuss the updated proposal on today’s editors' call. On one hand, there’s nothing stopping deployments from hosting resolvers that aren’t advertised in federation_entity metadata. They just wouldn’t be discoverable in the normal way. We’re not in favor of adding a second way to discover resolver endpoints. The spec has a standard way of advertising endpoints of all kinds. Interoperability will be improved if deployments consistently use the standard mechanism.

[Michael Jones]

The promised PR is at https://bitbucket.org/openid/connect/pull-requests/710

[Michael Jones]

Done by https://bitbucket.org/openid/connect/pull-requests/710