trust_chain parameter not mentioned in PAR/automatic and explicit client registration requests

[Torsten Lodderstedt]

The new request parameter “trust_chain” is defined for the signed request only.

[Giuseppe De Marco]

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

[Giuseppe De Marco]

I added some links to the definition of the trust_chain parameter along the text here
https://bitbucket.org/peppelinux/connect-2/commits/dc2e08b5e9bfb834de9114ce5a4ac7725da786ac

[Michael Jones]

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.

[Michael Jones]

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.

[Giuseppe De Marco]

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 registration

I 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.

[Giuseppe De Marco]

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

[Michael Jones]

On the 3-Nov-22 working group call, we decided to leave this open until we've addressed all of Torsten's registration comments.

[Takahiko Kawasaki]

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 the trust_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 as client_id (cf. “Implementer’s note about JAR”). Therefore, using a trust_chain request parameter outside a request object would cause interoperability issues. To be concrete, authorization servers whose behaviors always conform to RFC 9101 ignore a trust_chain request parameter outside a request object, but authorization servers that treat request objects based on the rules in OIDC Core recognize a trust_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 the request 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, a trust_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.

[Takahiko Kawasaki]

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 on trust_chain has way too many steps, though.

[Giuseppe De Marco]

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.1

The 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)

[Giuseppe De Marco]

I’ll provide a PR soon for this, according to what discusses during the editor’s call on 6 October 2023

[Giuseppe De Marco]

Resolved by https://bitbucket.org/openid/connect/pull-requests/642

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/642