Trust Chain in unsigned Authz request
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?
Comments (13)
-
-
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)?
-
reporter 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
-
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.
-
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 thetrust_chain
parameter is placed in the header of the request object, it will be difficult to justify not to place theresponse_type
andredirect_uri
parameters in the header. -
reporter 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
-
-
assigned issue to
@Giuseppe De Marco , can you create the needed PR?
-
assigned issue to
-
reporter @Michael Jones it seems that Roland made the work here: https://bitbucket.org/openid/connect/pull-requests/680#Lopenid-federation-1_0.xmlT961
-
reporter -
assigned issue to
-
assigned issue to
-
My PR has nothing to do with the Authz request. It’s about the listing endpoint.
-
reporter -
assigned issue to
-
assigned issue to
-
reporter PR that resolves this issue https://bitbucket.org/openid/connect/pull-requests/685
@Takahiko Kawasaki included in the revision
-
reporter - changed status to resolved
- Log in to comment
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.