Create a documentation for Self-Issued Identifiers

Issue #1175 closed
Tom Jones created an issue

Changes to the nature of user’s mobile devices and challenges with the section in the current core doc create a need to revisit some of the assumptions in that section. New implementations are springing up from Distributed Ledger Technology and other areas that make divergence a potentially large issue. The goal is to bring together workers on the various implementations to forge a common spec that all can follow.

Comments (16)

  1. Michael Jones

    I’ll note that the uses of the self-issued OP functionality that I’m aware of, including those used for DID authentication, are compatible with the spec, including using the JWK Thumbprint of the key as the “sub” value. That doesn’t mean that we couldn’t have a separate spec for the convenience of developers, but that spec can and should remain compatible with OpenID Connect Core 1.0.

  2. Tom Jones reporter

    If you mean compatible with the exact detailed formulation of the sub in section 7, then i disagree. If that becomes a criteria for going forward then i will withdraw the proposal.

  3. Michael Jones

    If you have a profile that needs additional information, then the logical way to do that is to add it as an additional claim. For instance, the Decentralized Identity Foundation SIOP profile uses a “did” claim to convey the DID being authenticated. Whereas, the subject of any particular OpenID Connect Authorization Response remains the JWK Thumbprint of the key used.

  4. Tom Jones reporter

    i guess i disagree that your proposal is a logical solution as the sub is bound up to most of what the rest of the transactions are about. i request that this issue of strict adherence to the largely unused current spec be on the agenda for the next meeting.

  5. Anthony nadalin

    Tom, can you give specifics on what is exactly wrong with the current assumptions? Why would a separate specification be needed?

  6. Tom Jones reporter

    Having the sub bound to the key make key-rollover undefined. My implementation used a simple sub (which could be a did) and added a jwks.

  7. Anthony nadalin

    Not sure creating a separate spec is the right thing to do. I understand your issue but as Mike points out there are other ways to handle this, i do believe its fundamental not to have SIOP break core. I would suggest we look at alternative ways to solve your issue.

  8. Tom Jones reporter

    And I believe it is fundamental to have a good user experience. If you can find one that does not break core i will listen, but only if the UX is attractive.

  9. Nat Sakimura

    What about creating a document anyways so that we can just talk about it? We can integrate it to other drafts anytime.

  10. Tom Jones reporter

    If it is true that the oidc section 7 requires a sub that does not allow for key roll-over then if object to the change in the title.

  11. Tom Jones reporter

    I am disappointed in the approach to solving the problem. I would prefer a standard that was independent of section 7 of the OPIC spec but that does not seem to be the way the committed wants to proceed. I suspect that i will need to introduce a full solution at some time in the future.

  12. Log in to comment