feat: added discovery patterns section

[peppelinux]

This PR introduces a dedicated section about the discovery patterns implementers should implement according to specific use cases.

This PR aims to describe the different ways to implement trust discovery according to different approaches. These approaches were collected during the past few years and based on real-world implementations and implementers' experiences.

[binaryape]

This is a good idea, thanks for writing this. Something that surprised me about the current spec is that there's not much information (if anything) on how to actually use it, particularly discovery and how to integrate it with OpenID Connect flows

[peppelinux]

Suggested change

	to a trusted resolver implementing the <xref target="resolve"/>. This pattern is useful for:
	to a trusted resolver implementing <xref target="resolve"/>. This pattern is useful for:

[daserzw]

I think this is useful, though I have a pair of questions:

1. All three patterns end with trust resolving, so this is not just about discovery, but also trust chain resolution? And is this really needed for example to build a directory of OpenID Providers to be used for discovery in the common sense of a list of OP to be selected by the user at login time at a specific RP? In the end the only trust chain that will be used is the one between the RP and OP involved in the access transaction, so unless we are talking specifically about an RP that is building its own set of available OPs, I don't understand why the Top-Down discovery should always entail trust chain resolution --- in the case of an external generic discovery service such as Seamless Access of Federations' WAYF services Trust Chain resolution is probably not so useful.
2. If I understand it well Pattern number 2 is about discovery as dynamically performed at run-time by different entities. I confess I think this is plain Trust resolution, and not discovery in the sense of collecting information on available entities for a specific function.

[selfissued]

Suggested change

	<t>Entities that want to offload trust chain resolution complexity</t>
	<t>Entities that want to offload Trust Chain resolution complexity</t>

[selfissued]

Please apply all of my suggestions - most of which simply apply appropriate capitalization to defined terms.

[zachmann]

I generally agree with Davide, but have some additional / extended comments:

I'm reserved about the current content of this PR. You introduce the concept of "discovery". But it's not clear what this actually means. OIDC has a spec on "discovery". In the federation world we understand something else under discovery. I would generally understand it as "finding entities that are part of a federation".
I assume that this is also your intention, but it is not really clear from the text.
Also from my view only the top-down approach really fulfills that. As Davide already mentioned, bottom-op does not do discovery, since you already must know where to start.
The single point of trust approach is viable, but current mechanism in the spec do not allow for discovery there either. Also here, you already must know the subject. The entity collection endpoint would offer such a way to offload the discovery of entities to a single point in the federation.

I'm also not sure if this should be a dedicated section, or rather under implementation considerations.

[daserzw]

I think @zachmann is right saying that it would be helpful to explain exactly what type of discovery we are referring to. In this context there are at least two types of discovery:

1. Discovery as "finding entities that are part of a federation" as @zachmann said and can be mapped to "Top-Down Discovery".
2. Federation Entity Discovery that is already well defined in the spec and apparently it is exactly the same thing as the "Bottom-Up Discovery".

I think the current text could benefit from a description of what we mean exactly by discovery for each pattern, while here we have only the why, the how, and the final/expected outcome.

I also agree that being this text probably go into implementation considerations.

[lj-raidiam]

I read the document before seeing the comments above, and I was also a bit surprised to see the bottom-up section labeled as "discovery." It gave me the impression that it overlaps significantly with trust resolution. I agree with the earlier comments in this regard.

I definitely see the value of adding the top-down discovery as this is something that hasn't been covered.

When it comes to the rest, I find this to be a very useful guide for implementers, especially those just getting started with the spec. It clearly explains that implementers can take either a bottom-up or single-point approach. The latter for example isn't particularly prominent at the moment - a developer would need to read into the second paragraph of Section 10 to realize they can delegate resolution.

[peppelinux]

I think this is useful, though I have a pair of questions:

1. All three patterns end with trust resolving, so this is not just about discovery, but also trust chain resolution? 

yes, a discovery would not be trustworthy without a trust chain resolution, be this direct or delegated (by resolve endpoint, recommending transparent evidences of the trust chain within the response)

And is this really needed for example to build a directory of OpenID Providers to be used for discovery in the common sense of a list of OP to be selected by the user at login time at a specific RP?

listing alone doesn't give policy or entity type constraints, therefore it is. Trust Chain confirms all the claims superiors say about subordinates and leaves about themselves.

In the end the only trust chain that will be used is the one between the RP and OP ...

discovery has therefore multiple layers. at the end, once all the entities matching some protocol specific application requires to be evaluated by processing their trust chain befose be considered, for instance about an RP, in a discovery page.

2. If I understand it well Pattern number 2 is about discovery as dynamically performed at run-time by different entities. I confess I think this is plain Trust resolution, and not discovery in the sense of collecting information on available entities for a specific function.

Trust resolution using a discovery mechanisms starting from the leaf's entity configuration and following the authority hints ... making the trust chain collection.

[peppelinux]

we can move it in a subsection of the impl consideration as well

we have the term federaiton discovery in the defined term section as well and the current PR should change the content of the defined term: https://openid.net/specs/openid-federation-1_0.html#section-1.2-3.34

or be moved within the impl considerations

the final choices would be accomodated according to the comments collected durint the connect ab calls and within this thread as well. Thank you ppl!

[selfissued]

Please merge with main and then move the history entry into the -45 section.

[zachmann]

we can move it in a subsection of the impl consideration as well

we have the term federaiton discovery in the defined term section

You are - of course - right with that. I missed that. (Assumed I would know the defined terms by now).
With that definition in mind, I think that this should not go into implementation considerations. I think section 10 should be expanded. This is currently titled as "Resolving the Trust Chain and Metadata" - which is exactly what "Federation Entity Discovery" includes. I think section 10 should handle federation entity discovery, list the available approaches (currently it explains the bottom-up approach in details, and also says something about using a resolver, it misses the top-down approach). I think it would be best to have an overview at the beginning of the section and then explain the three approaches.

Also I Think it would make sense to include a note that entities can evaluate additional requirements as part of the discovery, such as requiring certain trust marks to be present and valid.

[selfissued]

I agree that this should be an Implementation Considerations subsection