[Openid-specs-ab] Issue #2151: Put federation endpoints in a more logical order (openid/connect)

[mbj]

New issue 2151: Put federation endpoints in a more logical order
https://bitbucket.org/openid/connect/issues/2151/put-federation-endpoints-in-a-more-logical

Michael Jones:

The federation endpoints are currently in this order:

> federation\_fetch\_endpoint  
> federation\_resolve\_endpoint  
> federation\_list\_endpoint  
> federation\_trust\_mark\_status\_endpoint  
> federation\_trust\_mark\_list\_endpoint  
> federation\_trust\_mark\_endpoint  
> federation\_historical\_keys\_endpoint

I'm wondering if this order makes more sense:

> federation\_fetch\_endpoint  
> federation\_list\_endpoint  
> federation\_resolve\_endpoint  
> federation\_trust\_mark\_endpoint  
> federation\_trust\_mark\_list\_endpoint  
> federation\_trust\_mark\_status\_endpoint  
> federation\_historical\_keys\_endpoint

I'm thinking this because Fetch and List are more foundational than Resolve, which is optional, and I think we want the main Trust Mark endpoint to be before the other Trust Mark endpoints.

Note that to be consistent, reorderings would have to happen both in the list at [https://openid.net/specs/openid-federation-1\_0-34.html#name-federation-entity](https://openid.net/specs/openid-federation-1_0-34.html#name-federation-entity) and the descriptions at [https://openid.net/specs/openid-federation-1\_0-34.html#name-federation-endpoints](https://openid.net/specs/openid-federation-1_0-34.html#name-federation-endpoints) .

This would be something we do as the last step before publishing the proposed Implementer's Draft, because it would cause merge conflicts galore!

Responsible: Michael Jones