- edited description
Clarifications and proposals on Trust Negotiation
In “7.2.1. Trust Negotiation Request” we have the following parameters as REQUIRED:
1. operation
2. respondent
3. peer
4. type
5. anchor
and this is a non normative example of a request:
GET /federation_api_endpoint?
operation=resolve_metadata&
respondent=https%3A%2F%2Fopenid.sunet.se%2Ffederation&
type=openid_provider&
anchor=https%3A%2F%2Fswamid.se&
peer=https%3A%2F%2Fidp.umu.se%2Fopenid HTTP/1.1
Host: openid.sunet.se
With this issue I intend to ask for clarification on the parameters adopted and resolve the following doubts:
a) why we found different term names, as “respondent” and “peer“, which have not been defined in “1.2. Terminology”. Can we change them to follow the entities defined in the terminology paragraph? Eg: “respondent” could be “authority_hint“ or “superior” or “intermediate“ and “peer” could be “sub”.
b) Can we consider making the parameter "respondent" optional? Consider having the distribution of entities within a federation:
b1 is a RP
b2 is an Intermediary
b3 is a trust anchor
Ideally we could request the b1 metadata indicating as trust anchor b3, that’s all, whitout having to use the “respondend” paramenter.
Also in “7.2.2. Trust Negotiation Response” the non normative example of the response is “Content-Type: application/json”. Can we specify that the response can be application/json or application/jose?
Comments (6)
-
reporter -
- changed status to open
As discussed on the 10-Jan-22 call, Mike to review with Roland and John.
-
reporter As discussed on 13 jan 2022 I’ll do a proposal to change the parameter names
-
reporter Changes made here
https://bitbucket.org/openid/connect/pull-requests/105 -
reporter -
reporter - changed status to resolved
- Log in to comment