1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

[Federation] trust chain in authz request

Issue #1594 resolved
Giuseppe De Marco created an issue

we discussed about many optional ways to give as much information as possible in an authz request, considering the issues below

and more, during the today connect A/B we discussed about this claim rised by Kristina:

this latter suggests to find a way to push a metadata in the request and avoid the client registration. We know that an entity configuration/statement is not a metadata. The metadata, in oidc fed, is the final result of the trust chain.

Well I’m wondering to give a solution to all these previous issues with the solution proposed below.

Can we enalbe in OIDC Fed the possibility to push in an authz request an entire trust chain in the form of all the entity statements collected and validated in a path from a leaf to the TA, in the same format we proposed it in the resolve entity response (claim, trust_chain = [list of statements JWT]). In this way the OP would receive a serialized trust chain for the production of a verifiable final metadata.

having these assumptions as well:

1. RPs have to calculate the trust chain related to themselves by themselves (easy task, they know the path from these to the TA they have in common with the OP to be authz to).
2. OP may reuse the trust_chain paramenter or calculate the trust chain by its own.
3. OP may use the hinted trust_chain having only the public keys of the federation entities (TA and intermediaries) already in the trust chain pushed by the RP.
4. PAR wouldn’t be an option in this case but a real requirement, due to the length of the resulti authz request

having the trust chain we cover all the claims of the previous issues:

  • issue 1532, we have the entity configuration with the trust marks in it
  • issue 1533, we have a verified trust path with all the statements form the lead to the TA
  • issue 1588, we cover Kristina’s claim enabling a way the OP can trust an authz request obtaining all the required information inside the authz requests. Even if ideally we may think that this feature would remove the need of registering clients I rather think that the client registration is something that wouldn’t be removed but, anyway, it would be only an implementation option that we wouldn’t cover in the oidc fed specs

‌

Comments (18)

  2. Giuseppe De Marco reporter

    More generally with this new and not breaking feature we adopt in oidc federation a mechanism similar to x5c. This latter contains the X.509 certificates chain, while oidc fed allows the submission of the statements chain.

    and more, with this feature we can solve the problem of the stale metadata.
    If an RP changes its Entity Configuration and an OP doesn’t updated the trust chain related to this RP, this latter submits the updated statement chain

  3. David W Chadwick

    Generalising this approach to any type of trust federation, cannot we go up one level (in the OIDC4VP spec) and wrap your proposed contruct with a trust_framework_type URI, and then other types of trust framework can specify alternative data structures that define how the metadata for these other frameworks are specified in the Authz request (rather like in PR #255)

  4. Michael Jones
    • changed status to open

    We discussed this on the 12-Aug-22 Federation editor’s call. This shouldn’t be called a trust chain. It's an Entity Statement chain, and should be described as such.

    @John Bradley pointed out that this could be data more current than what's in the server's cache. @Roland Hedberg pointed out that the server is free to ignore it if it has other preferences, for instance, as to which federation to use among multiple federations.

  6. Michael Jones

    It was noted that because of size, this parameter would have to be passed in a post. Thus, Pushed Authorization Requests or a Request URI would likely need to be used.

  10. Giuseppe De Marco reporter

    Considering that in the resolve endpoint response we have the trust_chain claim, containing the statements chain, I’d propose to adopt the same term trust_chain.
    Wel, I’d prefer statement_chain but I believe that trust_chain is more understandable due to the assumptions below

    1. even if the array contains the statements chain, all the statements together represent a raw export of a trust chain
    2. trust chain is a defined term, statement chain even if is more closer to its real meaning, represents a new term that miss the pointer to the trust_chain
    3. having already implemented it in the resolve endpoint, adopting the claim name statement_chain we may have to change also the resolve endpoint claim

    Another assumption is related to the ordering of the statements in the trust_chain.
    I don’t think that the order is important, the parsing of the chain should be done by its content, even if the statements are sparse, and not to the ordering of the sequence. This keep the door open to different implementation of how the trust chain can be represented, stored, exported and imported.

  11. Vladimir Dzhuvinov

    I like this proposal because it removes one potential obstacle for RPs to go along with automatic client registration - the requirement for RPs to have extra OIDC Federation endpoints. That was why two years ago when we piloted OIDC Federation for one particular project the explicit client registration had to be chosen over the automatic one. The ability to push or reference the (unverified) trust_chain can also prove appealing to mobile / native apps. So this proposal is something I want to call a “game changer”.

    Explicit client registration has a significant issue when client registrations expire / become invalidated because there is no good way to communicate this, unless RPs use PAR (see issue below). So, if the no extra endpoints argument no longer holds for explicit registration, I wonder whether this mode of client registration could be made obsolete.

    https://bitbucket.org/openid/connect/issues/1529/federation-how-can-an-explicitly

  12. Giuseppe De Marco reporter

    I agree that this new feature may represent for many developers and architects a new implementation strategy for OIDC Federation.
    However we started with the assumption that the federation endpoints should be implemented anyway and that an OP may not support or use the trust_chain pushed in the authz request, but, anyway, these are implementation aspects that can be adapted to any narrow or customized implementation of Federation.

    Regarding explicit registration I think that’s not made obsolete by this feature because even if a client has been registered with the explicit flow it can always push the trust_chain in its authz request to signal an update of its entity configuration. Thank you for your feedback @Vladimir Dzhuvinov

  15. David W Chadwick

    This issue has not yet been fully resolved because my request on 12 Aug to generalise the approach so that other trust schemes (apart from Federation) can also be supported has not yet been addressed. However, PR #255, if accepted, will fully resolve this issue.

  16. Giuseppe De Marco reporter

    we focused this thread on the Federation requirements, for a wider adoption of this Federation feature in other contexts, eg: SIOPv2/VP, I think that it would be better to open a separate issue otherwise this issue will block the Federation specs that are completely avulse from other contexts and ongoing specs

  17. Michael Jones

    I agree with Giuseppe that if we want to discuss adoption of Federation spec features in other specs, that that deserves its own issue.

  18. David W Chadwick

    Please correct me if I am wrong, but I thought that the inclusion of the trust chain in the authz request from the RP to the wallet was not purely a Federation spec feature, but would effect every use of the authz request from the RP to the wallet, including SIOPv2 and OIDC4VPs. This is why I would like the authz request to be generalised so that it is applicable to other uses.

    But if the spec says that this parameter is only applicable to federation endpoints, then I agree that this current issue has been resolved, because the other issue already exists as #1551.

  19. Log in to comment
Assignee
Type
proposal
Priority
major
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!