Require JAR in SIOP to strongly ID the Relying Party

Issue #1217 open
Tom Jones created an issue

I have been implementing a chooser for SIOP. One thing that has struck me is that if a URL AR is allowed there is no real way for the SIOP (aka user) to know the identity of the client. There is a client ID (could be made up) and a redirect which is be best evidence, but i don’t know how to turn that redir URL into a value that the user could understand. Therefore i would like to enforce the use of a signed packet from the client (relying party) for all siop operations. I would required that the sig match the key and the the client id be something recognizable, or that we we create/require a new field to identify the client in terms that the user can understand. (A JAR is just my suggestion. Other suggestions welcomed.)

THIS IS A SECURITY AND PRIVACY ISSUE which i consider to be pri one.

See the following for related commentary. https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must

Comments (14)

  1. Tom Jones reporter

    Phishing of the user is easier if the web site can confuse the user about where they are providing their authentication information. When the user is given a consent UI by the SIOP, that UI should contain strong identification of the web site that is asking for the consent. The request can be triggered from a third party iFrame.

  2. David Waite

    The identity of the relying party would have to be anchored in some known root to be presented to the user. There are many ways to do this, e.g.

    • origin of `redirect_uri`, anchored in DNS
    • corporation name operating redirect_uri, provided by EV certificate
    • hosted trust mark of OpenID Federation in path resolvable from client id, e.g. well-known path on domain of redirect, DID metadata
    • trust mark included on cryptographically signed request

    Up until this point, we have pushed back against relying party metadata, instead indicating metadata should be known and verified by the issuer ahead of time via out-of-band exchange or DCR.

    The solution to identifying a relying party (to the SIOP or to the user) may intertwine with the methods of indicating relying party behavior, e.g. resolvable from client id via .well-known or DID metadata, included on signed request via key that can be rooted up to some trusted party.

  3. Nat Sakimura
    • changed status to open

    Agree with David.

    I kind of agree with the utility of using Request Object/JAR just like in the case of FAPI for high assurance use cases, but it would be a touch too much to ask for every case. The SIOP can indicate whether the request was signed & trusted (e.g., in the trust registry) to give the end-user some indication of the trustworthiness of the request.

  4. Tom Jones reporter

    Agree - we could make a signed request optional and tell SIOP that it SHOULD indicate the trust level to the user - we already get that from browsers - so there is no reason we shouldn’t get it from SIOP

  5. Michael Jones

    Looking at it again, it’s not clear to me what attack using a signed attack is intended to mitigate. In general, we shouldn’t be making SIOP flows more complicated than other flows, unless there’s a compelling reason to do so. I believe we should close this unless a compelling case is made.

  6. David Waite

    Uniquely signed requests are a requirement of automatic registration in OpenID Connect Federation

  7. Kristina Yasuda

    what attack does uniquely signed request in OIDC Federation automatic registration mitigate?

  8. Tom Jones reporter

    A trivial attack is for the bogus web site to put up a trust logo for the user to click which was not backed by any trust registry at all. If the request was signed by a key trusted by the registry it would be easy for SIOP to assure that the request was from a web site that was actually approved by the federation. This would not be required if the RP was able to display a link that went directly to the user’s wallet. It seems to me that is an unlikely scenario to be deployed.

  9. Log in to comment