[Openid-specs-ab] Issue #2089: Update document to reflect the capabilities of the resolve endpoint (openid/connect)

[Stefan Santesson]

New issue 2089: Update document to reflect the capabilities of the resolve endpoint
https://bitbucket.org/openid/connect/issues/2089/update-document-to-reflect-the

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](https://openid.net/specs/openid-federation-1_0.html#federation_configuration) 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.