trust_chain parameter not mentioned in PAR/automatic and explicit client registration requests
The new request parameter “trust_chain” is defined for the signed request only.
Comments (15)
-
-
I added some links to the definition of the trust_chain parameter along the text here
https://bitbucket.org/peppelinux/connect-2/commits/dc2e08b5e9bfb834de9114ce5a4ac7725da786ac -
As discussed in the 6-Oct-22 working group call, this is also related to there not being a normative definition of explicit registration. There is a set of parameters shared by all the registration mechanisms, but that’s not clearly spelled out.
-
- changed status to open
As discussed during the 6-Oct-22 working group call, the registration mechanisms share a common set of parameters. The specification needs to be clear about that.
-
-
assigned issue to
-
assigned issue to
-
at point 3 and 4 of https://openid.bitbucket.io/connect/openid-connect-federation-1_0.html#section-10.2.1.1
we read how an RP builds the explicit client registrationI agree that we need to improve the text, we should define the format of the request and the method and give to readers a small text with clear properties of the requests.
I also assume that an EC may have 0 or more than a single Trust Mark and many of redirect_uris and jwks, for this reason the HTTP method for the explicit client registration should be POST.however, those points explains that in the request there should be a EC or an entire Trust Chain.
This means that we don’t have any parameters in the request, but the EC/TC in the body of HTTP POST. -
I suggest to close this issue and work on a better text of the explciit registration request in the issue below, considering that these seems duplicated
https://bitbucket.org/openid/connect/issues/1660/section-102-explicit-registration-lacks -
On the 3-Nov-22 working group call, we decided to leave this open until we've addressed all of Torsten's registration comments.
-
To decrypt a request object and verify the signature of it, authorization server implementations refer to the following metadata of the client as necessary.
request_object_signing_alg
request_object_encryption_alg
request_object_encryption_enc
jwks_uri
jwks
signed_jwks_uri
That is, the client metadata need to be available before contents of a request object are used. Therefore, when a client making an authorization request is not registered yet (meaning that client metadata of the client are not available yet), the
trust_chain
claim in the request object is not referenced until client metadata are collected through the normal trust chain construction process that is initiated from the entity ID. So, even if thetrust_chain
claim exists in a request object, its purpose is always “update” after initial client registration.You may think that a
trust_chain
request parameter may be put outside a request object. OIDC Core allows it. However, RFC 9101 (JAR) does not allow request parameters outside a request object to be referenced except special parameters such asclient_id
(cf. “Implementer’s note about JAR”). Therefore, using atrust_chain
request parameter outside a request object would cause interoperability issues. To be concrete, authorization servers whose behaviors always conform to RFC 9101 ignore atrust_chain
request parameter outside a request object, but authorization servers that treat request objects based on the rules in OIDC Core recognize atrust_chain
request parameter outside a request object.Even if the
trust_chain
claim exists in a request object, an unregistered client has to have a web server that issues an entity configuration of the client. Not only at the authorization endpoint but also at the PAR endpoint, the same applies if a PAR request uses therequest
parameter (a request object by value). Note that the PAR endpoint must always treat request objects based on the rules in RFC 9101 (JAR). That is, atrust_chain
request parameter outside a request object, even if given, is always ignored at the PAR endpoint.It might be worth mentioning in the specification that the
trust_chain
claim in a request object is not used to collect metadata of an unregistered client and so the client still needs a web server that issues its entity configuration. -
Sorry. Rather, when
trust_chain
is included in a request object, the request object can be processed without preparing relevant client metadata beforehand because the request object can become a self-signed JWT (but I’m not 100% sure yet). This is an interesting finding for me. The procedure of verifying the self-signed signature based ontrust_chain
has way too many steps, though. -
the request object can become a self-signed JWT (but I’m not 100% sure yet)
Yes, as defined here
https://openid.bitbucket.io/connect/openid-connect-federation-1_0.html#section-10.1.1.1The procedure of verifying the self-signed signature based on
trust_chain
has way too many steps, though.the trust chains has the entity configuration of the RP and the statements that attests it, verifiables with the sole public key of the TA.
the authz request is signed with the OIDC jwks published in the Entity Configuration.Where and how you find too many steps, help me to understand if we can improve the text of the specs or the simplicity of the solution.
for the first registration, I’m aware the specs mandates the check on the entity configuration (so a kind of trust based on https and dns as well). Would you like to give more power (and trust) to the trust_chain parameter to avoid this requirement on the federation entity discovery process?
I’m aware that the trust chain in the request may address some use cases we have for the mobile wallets. Mike is working on an Annex to open the doors for more implementation profiles, so if you have some claim, please let us know (even in this thread)
-
-
assigned issue to
-
assigned issue to
-
I’ll provide a PR soon for this, according to what discusses during the editor’s call on 6 October 2023
-
-
- changed status to resolved
- Log in to comment
Confirmed and thank you for this.
I made the pointers to prevent copy and paste of the same parameter in multiple sections but It seems that they went lost along the revisions and the commits
I'd add the pointers to the trust_chain parameter
Before doing this we should decide if the three sections should adopt the same structure and probably do some more editorial work