While Steemconnect provides a valuable service for steem based third-party services that need to be delegated user authority, so the service can do signed operations in our names, the service is a rather poor fit for services that merely want the user to authenticate him/her-self.

After the whole @utopian-io ordeal with SteemConnect, despite the way it was professionally handled by all parties involved, I personally concluded that the model used by SteemConnect isn't one I want to put my trust in. Not for authorization purposes, but most certainly not for mere authentication of my identity. I chose not only to never use SteemConnect again but also to move all funds away from the account I had once connected to SteemConnect. At this moment I am powering down my @mattockfs account, powering up my @pibara account and delegating SP back to my @mattockfs account, just in case SteemConnect still has my keys and at one point in time these were to get compromised. It will probably never happen, but I just feel uncomfortable with having authority delegated to a service I intend to not ever use again.

When I first saw the link to the Introductionary post on UserAuthority (UA) by @scipio in my feed, and then saw that @holger80 too was working on this project at first I was hoping, given the name, that it was about a new authorization and maybe also authentication initiative, so I started reading. Unfortunately, like so many words, the word authority is overloaded. The article and the service weren't about authority as inauthorization but about authority as in (being of high) reputation. I 100% agree the steem reputation system has been broken by the reality of bid-bots, so a great initiative nevertheless, just not what I was expecting. So I kept on reading and ran into the link to https://steem-ua.com/ that seems to do exactly use SteemConnect for the thing I am most convinces SteemConnect is overkill: authentication.

Given that the name of the service had put me into an authentication/authorization mindset to begin with, this usage triggered me having a long thought about the possibilities for alternatives to SteemConnect for the specific use cases of zero-delegation zero-authorization authentication-only usage.

Cookies and micro-transactions for authentication

At its core, the STEEM blockchain provides for a great foundation for doing authentication at a site level. At zero transaction cost and with the possibility of adding a short memo to a payment transaction, we can create a relatively simple way to authenticate to one specific site:

• The user visits your site.
• A unique and sufficiently sparse unguessable session-id is allocated.
• A site-secret is used to create a HMAC-SHA2 or BLAKE2 session-hash for the session-id.
• The user is given a site-wide session identification cookie consisting of a concatenation of the session-id and the session-hash
• The user is asked to pay either 0.001 STEEM or 0.001 SBD (whatever is convenient) to the site's owner, using the session-id as memo field.
• The site monitors payment transactions to it's owner account and maps sessions id's mentioned in memos to the from account. From this point on until the cookie expires, the session will be authenticated to your account.

Basically, in its simplest form, this is it. From the user perspective, it is a bit more involved than using SteemConnect, but the advantage of not having to trust any third party with anything more than providing you access for the prize of 0.001 SBD should make this more than worth it for security-savvy users.

From session to user with X509

While the cookie scenario works for a single browser on a single domain for a limited (cookie expire) time, many users may want to access your site from different devices. If you are willing to be your own light-weight certificate authority, you can separate cookie-based user authentication as described above from the actual authentication of the user by using X509 client certificates. For this the scenario would be as follows:

• The user creates one or more key and a x509 Certificate Signing Request (CSR) containing his steem account name as Common Name (CN).
• The user authenticates him/herself using the microtransaction and cookie setup described above.
• The user uploads his CSR
• The server checks that the X509 CN and authenticated user are one and the same.
• The server signs the CSR and returns the client certificate.
• The user installs the client certificate in his/her browser.
• The site uses its own CA certificate to validate the clients certificate and authenticate the user.

The user can use this method to get multiple CSRs signed for each and every one of his devices. Once installed, the user can authenticate to your site using the client certificate, until the certificate expires, what typically be a longer time period than that for a session.

A "trusted"CA service.

While giving out X509 client certificates on a per-site basis works, it is a cumbersome process for the user and it requires each site owner to run an x509 certificate signing service on his/her site. Could we do better? Well, if a generally trusted entity such as @steemit inc, one of the top witness accounts were to run a single trusted CA, or even the company behind SteemConnect for that matter, then the user would only need to fetch a client certificate from the trusted signing service and would be able to use it on any site that also trusts this CA. For the user, such a service would work exactly like the one above. From someone running a service though, the process would be much simpler:

• The site owner downloads and installs the CA Certificate of the trusted CA to his server.
• The site authenticates the user from his/her client certificate signed by the trusted CA.

The trusted CA could (and should) go out of his/her way to set up his/her CA in a professional and secure way using physical and logical security measures to make sure his/her key material, that is the backbone of the trust in the authentication properties of the certificates, will never get compromised. The use of intermediate levels in the CA structure should be an absolute must, as should keeping root key material stored offline in a secure facility and physical, system and logical security measures for the online signing service.

Conclusions

I believe the per-site X509 signing service to be unpractical, but both the low-level microtransaction/cookie-based authentication setup and the trusted CA scenario should be serious competitors for SteemConnect as far as pure authentication (and zero delegation) services are concerned. I am currently considering creating a proof-of-concept asyncsteem script for X509 signing. That proof of concept, together with a tutorial like this one could show people wanting to build a Python Twisted-based service that accepts micro-transaction based authentication. At the same time, the proof of concept could help a potential trusted party get started with setting up their signing service. If you think that writing this proof of concept (with tutorial) is a particularly good or particularly bad idea, please comment below. I really would love to hear how others feel about the concepts described in this post, so I can learn if spending some time and effort into a proof of concept is worth my time.