DID SIOP: A new form of Authentication

DID SIOP is a browser extension which implements the Self Issued OpenID Connect Provider using Decentralized Identifiers (DIDs), allowing a DID holder to “be their own issuer” of a single-sign-on token. DID Authentication working group co-chair Oliver Terbu wrote an article here, entitled “Using OpenID Connect with Decentralized Identifiers,” which sets the background for this implementation. Readers less familiar with OIDC and the mechanics of contemporary authentication systems can see Kaliya Young’s more detailed explainer as well.

Armed with Oliver’s outline above, a close reading of the SIOP section of the official OIDC core specification, and DIF’s SIOP profile working-group draft, my team at Radical Ledger set out to make a working implementation informed by the needs of our clients in the eCommerce sector. The work of specifying a new version of SIOP in the next major version of OIDC is ongoing at the AB/Connect group at the OpenID Foundation, where DIF is represented by key members of the DIDAuth WG, whose regular meetings are suspended to focus on that work. This work is expected to culminate in a v2 of SIOP that could include breaking changes. Any input other DIF members may have on the process, is best gathered by the chairs.

Lessons Learned: An Implementer’s Perspective

We see “DID SIOP” as a kind of minimal “Identity Wallet,” utilizing in-built OpenID Connect Provider (OP) capabilities to enable seamless login to web applications without depending on any external parties. The process is identical to the authentication flow provided by Google Sign-in or Facebook Login, but in this case Identity Provider is the “self-sovereign” user, or to be more precise, their wallet.

We see this as a way of boosting self-sufficiently and weening people off of the normalized relationship to identity providers, which hold large amounts of end-user personal information and sell it to third parties in exchange for this authorization convenience. It also makes it far harder for such data middlemen to control identities or monitor the activities associated with those identities.

We made DID SIOP available as a browser extension for Google Chrome, Mozilla Firefox and Microsoft Edge through their vetted extension stores. Once set up, it allows a user to set up their own Decentralized Identifier and store its controlling private key within the extension, which the end user controls with a conventional password in our implementation. When a user tries to login to an online portal (i.e. a “relying party” app, in industry lingo) which supports DID SIOP as an authentication option, the user then has the option of using the credentials saved in the extension to authenticate their session by presenting an OIDC token issued by the extension.

For DID SIOP to work as an authentication method, both the subject (end user) and the relying party (web portal) should control decentralized identifiers, which are used to negotiate a unique secure connection. In theory, both the RP and the subject have the opportunity to select any DID method which complies the W3C DID Specification. Our current implementation, however, supports only Ethereum based DIDs due to lack of readily substitutable support libraries for other methods.

The process starts when the relying party (“RP,” for short) creates a JSON Web Token (or JWT, a token format used widely in contemporary web security contexts), which it creates and signs in advance of any requests using the private key corresponding the public key identifying it outwardly, for instance via a .wellknown public record or verifiable data registry. A subject then presents their DID for Diffie-Hellman key exchange.

The “subject” (i.e., the end-user to whom this JWT is sent, and who must control the corresponding private key) can verify whether the sent JWT was actually created by that RP using the RP’s public DID Document (which has RPs public key and other information). Upon verification, the subject creates a JWT which is signed by his/her private key and passes it back to the Relying Party. Then, the RP can confirm that the subject really controls the DID against which it issued the JWT, by independently checking the published or registered DID Document.

How to get involved

If you would like to read our document, it is all organized on the didsiop.org website, and if you would like to experiment directly, all of the relevant code has been donated and is available on DIF’s github, and our extensions for the Chrome, Firefox, and Edge browsers are available through the browsers’ extension stores. Our sample implementation can be accessed here.

If you or anyone you know is interested in integrating DID SIOP based authentication to an online platform, please get in touch with us via info@radicalledger.com.