[Openid-specs-ab] Issue #1534: [Federation] trust mark hint in the authz request (openid/connect)

[peppelinux]

New issue 1534: [Federation] trust mark hint in the authz request
https://bitbucket.org/openid/connect/issues/1534/federation-trust-mark-hint-in-the-authz

Giuseppe De Marco:

We have worked on the security consideration in the Fed specs [here](https://bitbucket.org/openid/connect/pull-requests/205).  
These highlighted how the trust marks can be adopted as a remediation against the propagation attacks of http requests.  
  
An OP before validating a trust mark must fetch the entity configuration of the RP, and this means that the OP must start a http request to the RP’s .well-known/openid-federation endpoint.  
  
We may consider the possibility to avoid also this connection if any trust mark are available in the authz request, this is not something for the specification but only for the implementation. An OP may check for the presence of a valid trust mark before fetching the RP’s EC.  
  
this issue was inspired by some consideration exposed during the GAIN PoC meeting and also by these issues:  
  
[https://bitbucket.org/openid/connect/issues/1511/determining-if-an-rp-is-a-member-of-a](https://bitbucket.org/openid/connect/issues/1511/determining-if-an-rp-is-a-member-of-a)  
[https://bitbucket.org/openid/connect/issues/1482/static-trust-negotiation-in-a-scenario](https://bitbucket.org/openid/connect/issues/1482/static-trust-negotiation-in-a-scenario)  
  
even if we talk of thsi in oidc fed we may consider that the concept of trust marks is moving to user centric and eIDAS2 approaches and it would be interesting developing it \(in all the sauces\) in oidc fed before reusing this in many other contexts.  
  
Eg

```
trust_marks_hint=[ ... the list of trust marks ...]
```

  
In the oidc fed specs we may only consider to have this paramenter in the request object as OPTIONAL.