Trust Chain in unsigned Authz request

[Giuseppe De Marco]

In the Authorization Request parameters we have the trust_chain defined as following:

OPTIONAL. Array containing the sequence of the statements that compose the Trust Chain between the RP that makes the request and the selected Trust Anchor, sorted as shown in Section 3.2. When the RP and the OP are part of the same federation the RP MUST select the Trust Anchor that it has in common with the OP, otherwise the RP is free to select the Trust Anchor it deems most significant.

implementers than may wonder when a Trust Chain should be brought in the authorization request as parameter or as JWS header parameter.

I would say that when the Authorization Requets is signed the trust_chain is provided in the JWS header parameter, while, in the cases where the Authorization Request may be not signed, it can be provided in the request parameter.WDYT?

[Michael Jones]

Given that the Trust Chain consists of signed JWTs that will be verified by the recipient, it’s always fine to send them in the request parameter. I don’t know that we need to say anything about the header parameter also being an option, because unless we say why to send it one place or the other, we’ll just create confusion.

[Michael Jones]

A related question about providing trust chains that came up during my review yesterday…

In https://openid.net/specs/openid-federation-1_0-31.html#name-resolve-response, the subject's trust chain MAY be returned in the body and the issuer's trust chain MAY be returned in the header. How do implementations decide whether to return these (including when to return both)?

[Giuseppe De Marco]

For the resolve response the trust chains have different subjects.

The one in the header is related to the resolve response issuer, the one in the body is related to the subject

[Michael Jones]

I get that. But as far as I can tell, the spec doesn’t help developers understand when they would include those trust chains or not, and why. Providing options without giving a clear understanding of when to use them isn’t all that helpful.

[Takahiko Kawasaki]

At least for authorization requests, the trust_chain parameter should be placed in the payload section of the request object, just like other request parameters. If the trust_chain parameter is placed in the header of the request object, it will be difficult to justify not to place the response_type and redirect_uri parameters in the header.

[Giuseppe De Marco]

Yes I agree with Taka, “at least” for the authorization request we need to say that the trust_chain is expected to be (optionally) in the payload and not as JWS header. This makes the same approach for both signed and unsigned requests → PR required.

While for the resolve response, the two trust chains have different scopes and the current text seems very clear about this

https://openid.net/specs/openid-federation-1_0.html#section-7.2.2

‌

[Michael Jones]

@Giuseppe De Marco , can you create the needed PR?

[Giuseppe De Marco]

@Michael Jones it seems that Roland made the work here: https://bitbucket.org/openid/connect/pull-requests/680#Lopenid-federation-1_0.xmlT961

[Roland Hedberg]

My PR has nothing to do with the Authz request. It’s about the listing endpoint.

[Giuseppe De Marco]

PR that resolves this issue https://bitbucket.org/openid/connect/pull-requests/685

@Takahiko Kawasaki included in the revision

[Giuseppe De Marco]

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