Add section on use of Resolvers

[Torsten Lodderstedt]

As discussed in issue #1432, the new “Resolve Entity Statement“ introduces a very valuable additional function without considering the impact on trust model and security. Those must be clearly discussed along with advise for implementers, otherwise the resolver function may be the cause of security flaws in actual deployments.

Topics should include:

• pros and cons
• trust model
• security advise

‌

[Giuseppe De Marco]

The reasons why we designed the Resolve Entity Statement endpoint:

1. Debugging, implementors shall obtain feedback on the correct validation of trust marks and especially on the correct application of metadata policies, by type

   Dividi et impera Design, a standard API to handle the OIDC Federation 1.0 operations in a dedicated microservice, internal in a organization or domain. For implementers that doesn't want to implement OIDC Federation in existing/legacy RPs or OPs, they just need to query this microservice to get a trusted metadata to store in their backends. In this case the endpoint can be also protected with a client_authorization mechanism. An example with the SAML2 world is an internal MDQ server to avoid the duplications of xml on each SAML2 entity instance.

   Interoperability, A standard API to have Proxy functionality to other technologies, such as a Ledger or other registry based on other protocols and functional paradigms.

Pros

1. allows us to obtain the final metadata and valid trust marks with a single https request to a trusted third party. Without this endpoint, http discovery metadata and trust mark validation requests can become more than 5 for each session request.
2. allows us to define a standard interface of concentration and release of finished metadata, with cache functionality, according to a scalable model on microservices

Cons

1. It risks replacing the standard trust chain construction methods with by-design.
2. An attacker can offer this endpoint to attract the operations of the "laziest" leaves of the federation and establish itself as a point of trust exclusively for the service it offers rather than by its authority. A mechanism that would establish a "social" type of trust rather than based on solid elements.
3. It would ideally return some answers not always fresh, being with extreme probability these preserved on cache. For this reason this endpoint weakens the dynamic requirement of the federation.

Trust model and security advices

• This endpoint MUST be trusted only if it’s exposed by a Trust Anchor or a Superior entity (intermediary)
  OR
• This endpoint MUST be trusted only if it’s internal of the same organization where a verifier acts
• The iss parameter MAY be ignored by the party who expose this endpoint and receive the http requests
• The aud claim in the signed JWT, in the response, can be present only if the endpoint is protected by some client authentication mechanism
• This endpoint, like all other Federation API endpoints MUST implement a Rate Limiting standard that makes clear to clients quotas and usage thresholds (see https://bitbucket.org/openid/connect/issues/1416/security-considerations-for-federation-api)

‌

[Giuseppe De Marco]

A further consideration is the non-obligation to link a metadata discovery, and subsequent validation of a trust chain, for each request received on resolve statement endpoint.

The security consideration would be precisely to prevent this from happening if the endpoint was not protected. In this case, the resolver response would contain the latest metadata and trust marks available, validated in the past, and cached, onyl if already available.

If the endpoint instead is protected an organization could trigger a procedure of metadata discovery although this as standard should be synchronous and return the result in time appropriate to the web synchronous.

A further consideration on the use of this promising resolver endpoint is to locate it as a diagnostic endpoint for each node, even leaf. Within a federation it may happen that as a result of a change in a metadata may take place a few minutes of misalignment between the definitions collected between the parties. These being related to different organizations one can only assume what may be the cause of the problem. Rather, if each node exposed a resolver endpoint a RP could automatically "diagnose" why its request failed at an OP, simply obtaining evidence of its metadata held at the OP

in this latter use-case, the endpoint should be protected by private_key_jwt to prevent an anonymous person from obtaining information about the RP they have applied for and those who have never applied to a OP. This latter use-case is difficult and should be analyzed better then as it is here

[Michael Jones]

In https://bitbucket.org/openid/connect/commits/c30cf723a828b72a3b7ba0b341310659da588c22 and https://bitbucket.org/openid/connect/commits/50ba36872dab0c2b2434bee31f5c2b82603b2f3a Roland described the trust model implied by “Resolve Entity Statement”. I recognize that these additions don’t do everything that Torsten was asking for. We should keep working on this.

[Nat Sakimura]

Is more background information available?

[Michael Jones]

Torsten had said that he could write text for this by the end of June.

[Michael Jones]

During the 12-Aug-22 Federation editor’s call, we decided to assign this to Roland, who will take a stab at it. Roland said that this pertains to Section 7.2.3: Considerations.

[Giuseppe De Marco]

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