trust_chain as JWT header claim

[Giuseppe De Marco]

We have created the trust_chain parameter for the authz request of the automatic client registration.
This was a successful decision however it extended the parameters recognizable in OIDC Core 1.0.

For equal benefit I would like to remove this parameter and move the trust_chain inside the JWT header of the signed request.

This allows us to define the trust_chain parameter within the JWTs, and to use the Federation trust chain in all cases where a signed JWT would like to carry verifiable proof of the trustworthiness of its issuer.

What is now clear to me is the similarity of the x5c parameter (x509 certificate chain) with the federation trust chain. However, we know that the federation trust chain brings with it much more functionality than an x509 certificate chain in the strict sense.

currently a JWT can carry the claims jwk, kid or x5c. To these I propose to add "trust_chain" and make this not in conflict with the presence of the "kid" claim, since the trust chain carries more than one jwk. I therefore consider it appropriate to bring trust_chain together with the presence of kid or jwk.

Defining the trust_chain parameter within the Federation would enable some important features, such as that of offline verifiability or the consistency of a JWT for historical verifications

[Giuseppe De Marco]

The PR below aims to resolve this issue
https://bitbucket.org/openid/connect/pull-requests/518

[Takahiko Kawasaki]

Is it necessary to remove the trust_chain request parameter? Is this breaking change a conclusion reached through careful discussions within the working group or just a casual proposal?

[Giuseppe De Marco]

I've proposed this during the last editor's calls, I can say that's not casual

Having It as a jwt header make It usable more than the sole authz request

We May leave trust_chain as parameter in the payload as well, I think having It as jwt header Is better in design, since we have x5c that's similar

Another point Is that every signed jwt may include this header, as trust marks and every kind of verifiable attestation

The sole open point Is that we May have more than a single trust chain, and this is interesting as well!

Having more than a single trust anchor the array should became a JSON object where the trust anchor Is the Key and the related trust chain the value as JSON array, eg

{
  "trust_chains": {
    "https://ta1.example.org": [...],
    "https://ta2.example.come": [...],
  }
}

@Takahiko Kawasaki do you think that would be Better having It as payload parameter as well?

[Takahiko Kawasaki]

If there is no strong reason to remove the trust_chain request parameter, I hope that the request parameter continues to exist.

It seems that the OIDC Federation spec should have relatively stable milestones like “Implementer’s Draft X” and corresponding official conformance tests. Compared to other specs, breaking changes on the OIDC Federation spec are proposed so often.

[Takahiko Kawasaki]

breaking changes → changes

[Roland Hedberg]

The only reason as I see it of not allowing trust_chain both in the request and in the JWT header would be that it will cause interoperability problems. Implementers will most probably chose one or the other depending on how easy/difficult it would be to add this to their existing code base. I would not be surprised if most chose request parameter as that is simple to add.

On the other hand having trust_chain in the JWT header has a much large impact then adding trust_chain as a request parameter.

Imaging having it in ID Tokens, access token, distributed claims and so on.

[Takahiko Kawasaki]

I noticed that removing the trust_chain request parameter would invalidate not only the authorization code flow but also the following flows that I have already implemented.

‌

1. Device Flow (RFC 8628). The device authorization endpoint defined in the spec does not recognize a request object.
2. CIBA Flow without a request object.
3. PAR Flow (RFC 9126) without a request object.

‌

Adding and removing a request parameter should not be done so casually. Otherwise, even aggressive implementers are discouraged from implementing draft specifications. For example, if the trust_chain request parameter were removed, I would not write an implementation to support the trust_chain JWS header parameter because I predict that the new JWS header parameter will be retracted months later.

‌

[Michael Jones]

I completely agree with Taka that we shouldn’t be making breaking changes at this point.

[Vladimir Dzhuvinov]

To me the trust_chain JWS header certainly has merit, in cases where the JWT is the centrepiece and the trust chain requisite for its validation. Say for instance federation enabled access tokens or other JWT secured objects that need to be self-contained, together with the trust chain.

I felt quite enthusiastic for a trust_chain in the request object, but as Taka points out, in requests that don’t have a JWT this will create a discrepancy and the present trust_chain top-level parameter will need to be supported anyway.

I don’t have objections to breaking changes to federation “core” (and reworking our implementation), if they will make the protocol better / easier / more intuitive for everyone.

[Giuseppe De Marco]

I am aware that trust_chain can be defined and included as a JWT header, without removing the authz request parameter

at the same time I know that keeping them both would create some ambiguity: look in the jwt header Or in the http parameter.

if I had to decide, I would go the route that gives the specification the best possible design, at the cost of breaking.

In Italy we have not yet included the trust_chain parameter in the authz request, I learn that Taka has implemented it. If we have to keep it even in the authz request, it would be a compromise, albeit an important one. If we could do an effort analysis for the parameter to header migration, I think we would benefit more as a solution design in the long run

[Giuseppe De Marco]

Sorry, I’ve just read that Taka has pointed out that his implementations doesn’t use the request object. This is very interesting. During the next editor’s call we’ll take the decision considering that since some implementations doesn’t use the signed request object, there are some cases where the trust_chain in the authz request is required

[Vladimir Dzhuvinov]

That there’s no risk of this potentially breaking the Italian federation implementations is good news :)

What are your thoughts on the requirement / optionality of processing the trust_chain when it appears in a JWS header of a request object? I.e. whether it will be a crit parameter or not?

[Giuseppe De Marco]

as decided during the last editor’s call

@Vladimir Dzhuvinov the JWS header parameter won’t have a crit parameter since this JWS header is optional

@Takahiko Kawasaki the authz request object remains in the specs and its removal won’t be discussed anymore, since there may be some implementation profiles that require it, in particular where the authz request is not signed and the trust chain is required anyway

@Michael Jones the PR is now updated for your kindly revision
https://bitbucket.org/openid/connect/pull-requests/518

[Giuseppe De Marco]

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