Proposal to add new discovery endpoint

[Razumain]

In our implementation of OpenID federation, we rely heavily on the resolver as the main tool to seek trusted information about peers.

In support of that we have found that we really lack an endpoint for discovery of matching services without having to traverse the whole federation. To accommodate this we have implemented a "discovery endpoint" as an amendment to the standard.

This endpoint is described in our profile draft: https://github.com/oidc-sweden/specifications/blob/main/swedish-oidc-fed-profile.md#discovery-endpoint

This differs from the entities listings endpoint in that this is a list of resolvable endpoints changing to a Trust Anchor, and not the direct subordinate entities of a Federation Entity.

What about large volumes?
Could this lead to requests for unrealistic volumes of data. For sure. But we don't see that as a problem. We think that 99% of all use-cases is a request for a list of OP that has a certain set of Trust Marks. This list will always be manageable. The endpoint will likely have a size cap on responses and will return an error code if the request leads to a response that exceeds that cap. That is however an implementation choice. We rather keep the API simple, as it is intended to be used by the least capable parties (RP:s).

You can see this in action in our test federation: https://sandbox.swedenconnect.se/oidfed/home

The following will make a discovery request for all OP:s that match a Trust Mark for OP:s certified to provide "eIDAS substantial":

curl --location 'https://sandbox.swedenconnect.se/oidfed/trust-anchor/discovery?anchor=https%3A%2F%2Fsandbox.swedenconnect.se%2Foidfed%2Ftrust-anchor&type=openid_provider&trust_mark_id=https%3A%2F%2Fsandbox.swedenconnect.se%2Ftrust-mark-id%2Floa%2Fsubstantial' \
--header 'Accept: application/json'

[rohe]

I've also implemented a 'discovery' endpoint.
I really, really don't like using the name "discovery" for this service.

But I agree to the need for such a service.

[Razumain]

Yeah, the name choice might not be the best. And I don't mind changing it :).
The reason why I picked that name for this is that this is what I think it will be used for primarily. That is to discover what OP:s that are available that meets my requirements. Much like a SAML discovery protocol.

[selfissued]

The name Discovery already has a well-known meaning. Maybe call it something new like "Exploration Endpoint", since it traverses the tree and looks for things.

[peppelinux]

At this stage we're working for additional drafts on top of the federation core specs, with the sole requirement that these subordinate specs don't introduces incompatibility with the federation core specs

examples are the extended listing endpoint and the wallet architecture

I agree that the term discovery collides and must not be used for the scope of a central catalog about specific features supported by participants

before the born of a new draft, for which there will be the support of the federation core co-authors, I suggest to consider using the extended listing draft to handle large responses and not at least, why the trust marked listing would be not suitable for this?

[Razumain]

I think it is a core feature provided by a resolver that is needed for OpenID federation to be complete on its own, but I understand why you would chose to push it to a new draft.

Extended listing is only handling subordinate entities and is too complex for a base service. Trust Mark listing does not solve the same problem.

[surfnet-niels]

In research and education we have several 1000s of services in approx 70 (national, SAML based) federations which all require 'discovery' in some form or shape. Some will have to list all existing OPs in a federation (which could be several 100s), some only list a handfull. In some cases such services build their own list, some use centrally provided services, like e.a. Seamless Access (https://seamlessaccess.org/). I suspect the properties we are looking for in OID fed wrt 'discovery' may overlap with the experiencs we have in these SAML federations.

One thing that makes 'discovery' different from 'a list of entities in the federation' (a list of subordinates) is the fact that it is about end-user interaction, providing the user with enough information to select the correct OP. As such the display name of the OP may need to be provided in multiple languages, the logo of the OP needs to be shown, etc. Some of that data may actually not live at the TA or resolver, but is constructed by combining a list of subordinates with information from the entity configuration information at the subordinate.

A second aspect is filtering of the OPs, based on e.g. trust marks, being a subordinate of a specific intermediate, but also on more simple things like a key word ("only listy entities that have 'University' in the name"). This either helps the user to more quickly select the correct OP, and/or allows RPs to only list the OPs that are relevent to begin with.

Finally, the discovery service and process is not trusted, it is just the equivelent of the yellow pages. One can lookup (a list of) entities, but the trust is established independently.
For inspiration, SAML discovery is part of the SAML specification, as can be found here: https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf