Thursday, May 7, 2015

Unverified Identities on Websites

Unverified Identities on Websites

Earlier article for context: 

During my re-implementing to simplify the email identity thing, I realized that it could be useful to allow unverified identities, and I have now implemented that. At first, I tried simply not verifying email adresses of certain patterns; for example emails ending in "". Which works, of course, but I feel hesitant about it for a bunch of reasons. 

Firstly, an email is a lot to type just to get an unverified nickname. If you want to try a site, it should really be even simpler. Of course, many sites don't even tell you that they give you a temporary identity, tracking visitors by cookies. Yeah, you're now by law in many places required to inform the user that they're being tracked. But it would also be good to have the user be a little more aware of what their id is, so that they can be more recognizable in pages where that is useful. So, I'll either allow typing in a nickname, or have it be generated for the user, probably something readable. 

Secondly, it may be prone to user confusion. Well, everything is, but of course I'd like to minimize that. I can even have a separate page to set an unverified identity, which I hope will give maximum clarity and simplicity for everybody. 

Thirdly, it doesn't 'feel' good, architecturally. It's coat-tailing, re-purposing. Alternatives are not clearly demarcated, which I feel is a cornerstone of good software architecture. 

Fourthly, I'd like to implement it as a separate module from the email identity, for simplicity, and to be able to exclude the email identity module in favor of something else, like OpenId or Facebook identities, if an application so requires. 

I think I'll add a little clarifying detail on the 'unverified' identity idea. It will not be the case that the access token cookie is not verified. It will still be a signed access token that the server has to issue and check. One could of course dispense with that too, since the id is not really verifed to start with, but I think it's best to limit identity access tokens to only be available via the server. Perhaps to limit their number. But there's also the advantage of not having separate paths. The 'outer' format of the tokens is always the same; and the signature is always checked. Simpler, less room for mistakes resulting in security problems. 

And finally, some low-level implementation details, which don't really matter, but might still put a little meat on the conceptual bones. The token content is JSON, of the form {"id": [id], "utcs":...}. An email identity is of the form {"email": ""}. An unverified identity is of the form {"unver": "anything_goes_here"}. This is the 'id' field, in the JSON object that also contains the "utcs" field, which holds the number of seconds since 1970 of the moment the server issued the token. Having a time-of-issue allows expiration to be checked. 

Next, perhaps something about how to implement this in Java, or more on sending email links with access tokens. I hope this scheme gets implemented in place of the awful username/password scheme on the internet, unless something better is available. 

No comments:

Post a Comment