[Openid-specs-ab] Issue #1594: [Federation] trust chain in authz request (openid/connect)

[peppelinux]

New issue 1594: [Federation] trust chain in authz request
https://bitbucket.org/openid/connect/issues/1594/federation-trust-chain-in-authz-request

Giuseppe De Marco:

we discussed about many optional ways to give as much information as possible in an authz request, considering the issues below

* [https://bitbucket.org/openid/connect/issues/1534/federation-trust-mark-hint-in-the-authz](https://bitbucket.org/openid/connect/issues/1534/federation-trust-mark-hint-in-the-authz)
* [https://bitbucket.org/openid/connect/issues/1533/federation-trust-path-hint-in-the-authz](https://bitbucket.org/openid/connect/issues/1533/federation-trust-path-hint-in-the-authz) 

and more, during the today connect A/B we discussed about this claim rised by Kristina:  
  
- [https://bitbucket.org/openid/connect/issues/1588/federation-rename-automatic-registration](https://bitbucket.org/openid/connect/issues/1588/federation-rename-automatic-registration)

this latter suggests to find a way to push a metadata in the request and avoid the client registration. We know that an entity configuration/statement is not a metadata. The metadata, in oidc fed, is the result of the trust chain.  
  
Well I’m wondering to give a solution to all these previous issues with the solution proposed below.  
  
Can we enalbe in OIDC Fed the possibility to push in an authz request an entire trust chain in the form of all the entity statements collected and validated in a path from a leaf to the TA, in the same format we proposed in the resolve entity response \(claim, trust\_chain = \[list of statements JWT\]\). I nthis way the OP would receive a static, exported, trust chain to be adopted to export the verifiable final metadata.  
  
having these assumptions as well:  
  
1\. RPs has to calculate the trust chain related to themselves by themselves \(easy task, they know the path from these to the TA they have in common with the OP to be authz to\)  
2\. OP may reuse the trust\_chain paramenter or calculate the trust chain by its own  
3\. OP may use the hinted trust\_chain having only the public keys of the federation entities \(TA and intermediaries\) already in the trust chain pushed by the RP  
  
having the trust chain we cover all the claims of the previous issues:  
  
- issue 1532, we have the entity configuration with the trust marks in it  
- issue 1533, we have a verified trust path with all the statements form the lead to the TA  
- issue 1588, we cover Kristina’s claim enabling a way the OP can trust an authz request obtaining all the required information inside the authz requests. Even if ideally we may think that this feature would remove the need of registering clients I rather think that the client registration is something that wouldn’t be removed but, anyway, it would be only an implementation option  that we wouldn’t cover in the oidc fed specs

‌