Re: Principles of Identity in Web Architecture

On 08 Jun 2021, at 16:58, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> That's a smart system.  We also had our fair share of issues with KEYGEN.  Here are the two specs that we made:
> 
> https://www.w3.org/2005/Incubator/webid/spec/ <https://www.w3.org/2005/Incubator/webid/spec/>
> 
> WebID 1.0 - Web Identity and Discovery
> 
> WebID-TLS - WebID Authentication over TLS
> 
> I think your system is more like Trust on First Usage (TOFU) or perhaps finger printing a device

The idea in our case was to treat the key as practically the same as a typical session cookie.

In a web interaction involving session cookies, the session cookie is created first, and has the task of tying the otherwise stateless requests together. In my case I said let the key do that job. Because real-life-software, the key has a certificate attached, and because real-life-usability, the certificate has a CN that appears in drop down lists, but that’s a detail that’s ignored for the system.

There is no trust on first use, because like a session cookie until you’ve performed some task to reveal more about who you are you are anonymous, and there is no obligation to reveal more.

There is no fingerprinting the device either, because at any time the key could be deleted forever (think “hard logout”) and replaced, or a smartcard could be unplugged and plugged in somewhere else.

I went through the webid specs recently, they have a very similar philosophy, and are very cool.

>> Applying these 5 architectural principles, I believe it would be possible for every identity system on the web to be largely interoperable.  And by web I include other URI schemes that http, and the P2P web
> 
> This is exactly what I was going for. I wanted the ability to use the anonymous cert to allow you to connect to wifi, and this works well. On the case with using these anonymous certs to allow you to connect to email as well, to make phishing more difficult.
> 
> In short, what we’ve done works well, and the client likes the “I don’t have to know or care about a password” aspect of it.
> 
> That's great regarding UX

The way I approached UX was by saying “what’s hard?” and eliminating it.

Trying to export a certificate from one device to another is hard (think a machine got upgraded, or you want a cert on your phone as well as other device). “Hard” means very unlikely to be done by an end user or even a technical person helping them without risk of things going wrong That meant two things - people needed multiple keys (one for each device) and long expiry times (longer than device warranty). Cert/keys appear in UIs, and having ugly random character strings is awful. For this reason, let the end user choose a name, and don’t force user to reveal their identity in the name. Thus the CN saying “My iPhone”.

There are additional systems in place after issuing the key. Hit an URL and you don’t have a key, you are redirected and told to get one. Hit an URL and you do have a key but we’ve never heard of you, redirect and ask you to introduce yourself. Hit an URL and you have a key that maps to someone introduced but you don’t have access? Invite user to ask for access. Owner of URL either grants access or doesn’t after checking the end user request is legit by conversation.

End goal was that access control was 100% a business controlled business concern and no technical person ever got involved. No helpdesk tickets, no superusers. This has worked very well in an environment where people routinely taped passwords to monitors or gave their password to a technical person to put on a list.

> So perhaps the identity in this case was either the certificate of the public key, depending on what you used on the back end.  Then tying the email address to it.  So in your case the transport could be either over TLS or via your back end, which I think is a pretty good start.
> 
> Further exploration, if you wanted to interoperate with other systems may be to write out the identity, say in json, in a way that it could talk to other systems, be used in single sign on, etc.

In the architectural principles you listed, you specify an identity and identifier, and the identifier is a global primary key.

In theory a key could be an identifier (like an old school session cookie could be an identifier), and an email address or a phone number could be an identity (like an old school username/password pair could be an identity), does that mapping make sense?

In other words, can you say that identifiers are ephemeral?

Thinking more out loud, would it make sense to have a clearly defined role in the architecture for a session-identifier, meaning “same entity who was here previously”?

Regards,
Graham
—