Webapplication with Login via Sovrin


#1

Hi,

I’m testing different BYOI-approaches based on Blockchain technology. My goal is to create an example web application that offers the possibility to sign in via self-sovereign identities.

I have successfully implemented the web application and login to the app via uPort and Blockstack. Development of both integrations was quite straight forward using the libraries uport-connect and blockstack and the provided uPort mobile app and the Blockstack browser for managing identities.

However, I’m a bit lost when it comes to integrating Sovrin into the login process. I couldn’t find an identity management app and no JS library for the integration of Sovrin or Hyperledger Indy.
Are there any tools or libraries anyone can recommend to integrate Sovrin in an existing web app and manage identities in easy way?

Thanks


Need Sovrin on my website for KYC kind of process
#2

Indy has all the raw ingredients you need for this, but they are not yet packaged in a way that will make this easy.

For example, there is a node.js wrapper (and a python, and .net, and java wrapper) around indy-sdk. This would allow you to send authenticated messages to/from a web server, where the authentication of those messages is tied to a Sovrin DID. This would effectively log you in with very high security. But there is not a sample in the indy-sdk, and the samples that do exist are not oriented around a web server / web client use case. To do this from a browser, you’d probably need a javascript client library like TweetNaclJS, or you’d need to compile indy-sdk into a web assembly.

There is also an ongoing effort to do what’s called “DID Auth” with Sovrin, where you prove that you own a DID, and thereby establish a session of sorts. You could contact Kyle Den Hartog on Indy’s Rocket.Chat (#indy-agent) to learn more.

Part of the reason why your workflow is not a first-class sample at this point is that indy thinks about authentication a bit differently, by design. Instead of establishing trusted sessions and then holding that trust until the session expires, it establishes a secure (but untrusted) channel. Every message sent over that channel is individually authenticated; there is no session construct that gives it extra credence. Trust of the party at the other end of the channel is tied to credential exchange, not to the mere existence of a secure channel. (If that paragraph sounds confusing, I’ll simply say it really means what it says, and that it matters. Could be discussed more on a community call.)

Anyway, this doesn’t invalidate your use case for Sovrin/Indy–far from it!–but I am just setting expectations that the way the problem is modeled is going to have some subtle differences.


#3

Hello Martin,

Login to a web application is what we would consider one flavor of DID Auth. DID Auth means proving control of a DID, but this can be realized in many different use cases and flows. Login to a web application is one possible scenario. Establishing authenticated channels (as explained by Daniel) is another possible scenario.

It’s also conceivable that we can re-use certain parts of existing protocols such as OpenID Connect, but adapted for use with DIDs.

For the latest thinking on DID Auth, have a look at this paper:
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.pdf

We hope that eventually this effort will result in a set of common DID Auth protocols and standards, rather than having uPort- and Blockstack- and Sovrin-specific ways of doing things.

Markus


#4

Hi both,

Thanks for your extensive answers.
I will take a deeper look at DID Auth to see if I can find a scenario for my implementation.

Martin