Clarifications and proposals on Trust Negotiation

Issue #1391 resolved
Giuseppe De Marco created an issue

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)

  1. Log in to comment