Add section on use of Resolvers
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
Comments (7)
-
-
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
-
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.
-
- changed status to open
Is more background information available?
-
-
assigned issue to
Torsten had said that he could write text for this by the end of June.
-
assigned issue to
-
-
assigned issue to
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.
-
assigned issue to
-
- changed status to resolved
- Log in to comment
The reasons why we designed the Resolve Entity Statement endpoint:
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
Cons
Trust model and security advices
OR