[Openid-specs-ab] Issue #1391: Clarifications and proposals on Trust Negotiation (openid/connect)

[peppelinux]

New issue 1391: Clarifications and proposals on Trust Negotiation
https://bitbucket.org/openid/connect/issues/1391/clarifications-and-proposals-on-trust

Giuseppe De Marco:

In “[7.2.1. Trust Negotiation Request](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.7.2.1)” 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](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.1.2)”. Can we change them to follow the entities defined in the terminology paragraph? Eg: “**respondent**” could be “[**authority**](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.1.2)**\_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.  
  
Also in “[7.2.2. Trust Negotiation Response](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.7.2.2)” 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**?