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

SIOP with any OIDC flow

Issue #1399 resolved
Torsten Lodderstedt created an issue

I suggest to evolve SIOP to work with any OIDC flow. The current focus on the implicit flow makes sense for SIOP implementations (wallets) running on the user’s phone without server infrastructure. However, there are other architectures for self-issued SSI applications, for example web wallets. They have been around for some time and are capable of exposing the necessary endpoint for a code flow. Such wallets could benefit from the advanced capabilities of code flow (or CIBA) and utilize standard OIDC libraries/products.

What would it mean to enable SIOP for those flows? If we boil down SIOP to its essence, it is a trust model where the user is in control of the key material and asserts claims about itself. From a technical perspective, this means the user is ultimately becoming the issuer of the ID token. Well, that can be done with any other OIDC flow. So I think there is not much to add to the spec than look for the issuer (or the i_am_siop claim) to decide how to process the ID token. And in case of SIOP the way the key is determined for validating the signature differs from “traditional” OIDC.

The specifics around SIOP with the implicit flow still hold true but become an implementation option out of many others.

Comments (20)

  1. David Waite Account Deactivated

    I would agree that the subject-based signatures are generally usable in a broader sense, including for hosted software. There is a question of what the ramifications are of each additional feature - for instance, what would an access token mean? What would UserInfo mean?

    This potential value in broadening the use of core SIOP features throughout OIDC and into OAuth is one of the reasons also I’ve been arguing against SIOP-specific security loosening for months, specifically:

    1. we still allow unsigned registration data on the request, despite no documented use cases which would push for client_id=redirect_uri. I would argue that this special case makes no sense compared to usage of client_id=did:key and signed request objects.
    2. response_mode=post, which fundamentally breaks conformance to OAuth2 (most specifically 10.2) and for which we admit we have no valid security mitigations.

    ‌

  3. Michael Jones

    It’s not clear to me whether this would help or hurt interoperability, given we’d be going from a single response_type value to six of them.

  4. Torsten Lodderstedt reporter

    I think it would foster interoperability be removing exceptions. Currently, using OIDC for self-issued/SSI use cases uses a specially tailored flow and only this flow. This requires new implementations, new conformance tests, … It also adds confusing since developers familiar with OIDC and the code flow have to “re-learn” OIDC.

    Leveraging the existing OIDC flows for SIOP allows to leverage implementations, developer expertise, conformance tests, and, as Daniel pointed out, existing security measures and considerations.

    I think in the end SIOP will just differ from “normal” OIDC in the way issuer and signature validation works. Supporting that for all OIDC flows will give developers more flexibility within the current set of OIDC flows.

  5. Stephane Durand

    I agree with the objective. Combined with federation and dynamic client registration (a la SOP or connect), I think it would make sense for OIDC clients in an “open ecosystem” to be able to interact with SOPs or regular OPs with as much as possible similarities.

    (Note for below: As discussed in last call, SOP may not only be implemented as pure mobile app but could also be featuring an hosted part, therefore capable of exposing endpoints.)

    This might come with not such much difficulty when considering an SOP implemented as something like mobile app + managing service but if the SOP is a mobile app only, some flows may be impossible, or seriously affected.

    As an incomplete study, the authorization code grant returns from an hosted authz endpoint with a redirection (or equivalent). This returns to the same browser/tab/session of where the initial call was made from. In a mobile only SOP, the return path would be through a mobile platform ‘open’ call, that will not return to the same browser/tab, in a different session.

  8. Kristina Yasuda

    Can this be a general definition of SIOP we can agree on?

    • Self-Issued OpenID Provider (Self-Issued OP): An OpenID Provider (OP) used by the End-users to prove control over a cryptographically verifiable identifier

    ‌

  9. Stephane Durand

    The question of the SIOP definition was also nudging me for a few days and I think it relates to more than one issues currently discussed so I took the initiative to create a dedicated issue: 1417

    In your formulation Kristina, I read that “prov(ing) control over a cryptographically verifiable identifier” is presented as a goal of the SIOP. I would rather say it’s a means / key characteristic (is it the only one we want to retain though?).

  10. Kristina Yasuda

    @Stephane, refining further based on what you said,

    Self-Issued OpenID Provider (SIOP) is an extension of OpenID Connect that allows a user to sign ID Tokens and (potentially) prove possession of information issued by trusted authority using the key material within the user’s local control

    ‌

  12. Michael Jones

    So I think there is not much to add to the spec than look for the issuer (or the i_am_siop claim) to decide how to process the ID token.

    Now that we’ve merged the “iss” == “sub” PR, I think this makes more sense. Am I correct that we’d be determining the keys the same way when “iss” == “sub” for all response_types?

    Beyond keys, the other thing to work out is how to retrieve the OP metadata when we no longer have “iss” pointing to a .well-known/openid-configuration file.

  14. David Waite Account Deactivated

    Within the mentioned PR, I proposed a new claim, tentatively named “moi” (metadata of issuer) to replace the use of iss in the response to understand that the response does indeed come from a SIOP acting as part of the requested issuer.

    In the absence of something like this, there is the theoretical potential for abuse with unsigned requests, as the requested iss (and underlying metadata including security capabilities) is no longer repeated with integrity protection in the response.

  17. David Waite Account Deactivated

    That wallet in the context of a request/response would be operating as part of an abstract or concrete OpenID issuer, e.g. would have agreed to operate in a certain way with certain capabilities as part of a certain trust framework. For an OP this might represent “ACME Corp”, for SIOP this issuer value might represent for example “professional credential exchange for healthcare workers within the UK”. A issuer value might only represent a single wallet as well.

    This split between SIOP and OpenID issuer value is still confusing. We have experience in the difference with say OAuth confidential and public clients. Currently, I would say SIOP protocol has defined its ID token variant to be analogous to ‘public clients in OAuth do not have client ids.’, although the ramifications are different since it impacts the request vs the response.

    Just like with a software which can be clients against multiple AS’s, a SIOP could be operating under multiple OpenID issuers to indicate support for different defined profiles. The self-issued scheme is a fall-back catch all; you can ask anything, but have zero guarantees that any additional features will be supported, and with no concept of any additional governance rules being in play.

  18. David Waite Account Deactivated

    @Torsten Lodderstedt There is the potential for the wallet to have an identity or an attestation, which is what #1412 is about. Attestations would normally be chain of custody of the software to publishing entity, and/or hardware to the manufacturer. A hardware attestation does not serve to replace iss.

    Getting a presentable statement that a particular wallet represents a particular trust framework likely would involve post-installation bootstrapping, exchanging such a hardware attestation for a wallet-as-subject VC or other PoP token.

    I don’t know if anyone has argued for such a thing - it has a more limited utility for OIDC4VP, as a successfully presented credential has certain implications on the wallet meeting issuer policy. I’m somewhat hoping we can punt on defining anything special now and just use VCI+VP later if such statements are needed.

  20. Kristina Yasuda

    Note: might need to continue discussing how SIOP endpoints for CIBA/PAR, etc. can be discovered.

  21. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Component
SIOP
Milestone
–
Version
–
Votes
0
Watchers
7
Jira: the preferred issue tracker for Bitbucket. Join the team!