Kaliya – Identity Woman has authored many seminal posts including a lucid discussion of the nature of online identity that I still find myself referring people to, 10 years later.
She’s done it again with “Where to begin with OIDC and SIOP” (OpenID Connect / Self-Issued OpenID Provider) – demonstrating her unique ability to distill the essence out of a daunting parade of otherwise interminable technical discussions.
The proposal, Kaliya describes is to leverage the DID (Decentralized Identifier) specification being developed at the W3C to add decentralization to the OpenID protocol. As Kaliya puts it, “The vision of DID-SIOP is a way of bringing decentralized identity concepts into alignment with the ideas of “self-issued” portable identity that the original OpenID innovators had.”
I share that greater vision of bringing decentralized identity concepts to the everyday interactions that people and organizations have online. But when I read that “OIDC-SIOP leverages the code that OpenID Connect relying parties already have in place across all these millions of sites” I had to hit the pause button for a moment.
A search revealed that yes, the OpenID Connect spec does indeed stub out a method for what they term a “Self-Issued OpenID Provider” and that there are client libraries that at least claim to support “Consuming Self-Issued OpenID Provider ID Token response.”
However, an admittedly far from exhaustive search did not turn up any provider libraries that even claim to support that. What’s more, getting the many client and server libraries to adapt to using DIDs and then shoehorning that into a half-baked wave at the notion (forward thinking as it was) in the OpenID spec – well, it doesn’t seem at all trivial imho.
Instead, I propose that we as a community consider that DIDs themselves might enable a completely new method of secure authentication that would actually be much simpler to understand and implement.
The reference implementations of this new approach would be much easier to adapt to the many use cases, and would be a lot less work than mucking around with the internals of a myriad of existing idiosyncratic OpenID Connect provider servers.
There are only two actors in this proposal – software agents for 1. a service provider and 2. a service consumer, call them SP and SC. These roles may, depending on the use case, switch back and forth, but in any single interaction one party acts as the SP and the other as the SC.
The SC, either on its own or prompted by the SP, issues a service request to the SP’s appropriate API endpoint. This request is encoded as a JSON object and contains the SC’s DID along with any other information the API specifies.
The SP looks up the DID document, either on the fly or from its cache, and replies with a JSON object including a challenge, which is just a long very random string, known in cryptography as a nonce.
The SC signs the challenge with the signing private key referenced in its DID document. The SC can then present this signed challenge as a capability to obtain the requested service, that can be validated cryptographically by the SP.
There are of course many many details to work out such as the form of the JSON objects and which replay prevention techniques to use, but the basic concept couldn’t be much simpler.
There would only be one prerequisite for inter-operation between two implementations, that they either use the same DID method, or know how to resolve each other’s DID method. This could either be via prearranging access to each other’s DID method resolvers, or (more likely) by accessing a DID resolution service such as the universal resolver under development at DIF.
The JLINC DID method offers an open source client, and a very simple resolver demo using that client. JLINC will be submitting a did:jlinc driver to the DIF universal resolver project, and we are actively exploring opportunities to partner with other organizations to demonstrate interoperation.
