Operations -> endpoints
Issue #1387
resolved
The specification now defines a Federation API that supports several operations (fetch, resolve_metadata and listing).
Two more operations has been discussed (search and trust mark introspection).
Only fetch is mandatory to implement, the rest is optional to implement. Regarding the new trust mark introspection operation it would probably make sense to make it mandatory for a trust mark issuer to implement.
When it comes to the different operations it’s quite clear that they will have different needs when it comes to authentication of the operation requester. fetch anyone should be able to use, not so with for instance resolve_metadata. One could also imaging listing returning slightly different sets of data dependent on who’s asking. Which then means that the who must be authenticated.
This leads me to the conclusion that we should move from one endpoint supporting several operations to one endpoint per operation.
Using unique endpoints would also make it simple to signal which operations/endpoints an entity supports in the same way OIDC Discovery does it.
Comments (4)
-
-
Completely agree, as proposed in the following issue, I believe that would be better to separate the API in many, specialized, endpoints
https://bitbucket.org/openid/connect/issues/1382/proposal-of-an-improved-federation-apiyou know that I’m also looking to get pagination in fetch (with multiple statements) and in listing (with application/jose instead of json) with the hope of having made clear my motivations
-
- changed status to open
There was agreement on the 10-Jan-22 to go with this approach. It is cleaner and enables discovery metadata to specify which of the operations are supported.
-
reporter
- changed status to resolved
This was approved on the January 13th 2022 Spec Call.
- Log in to comment
- Assignee
- Type
- Priority
- Status
- resolved
- Component
- Federation
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 5
I support this proposal since it allows to distinguish endpoints to offered for different purposes by different parties. For example. „fetch“ must be supported by all intermediate entities and trust anchors, whereas „trust negotiation“ in my opinion could be a good basis for (independent) federation data resolvers.