Re: Principles of Identity in Web Architecture

Hi folks - thanks for this spirited discussion. FYI although most of our work now happens in our GitHub repositories (https://github.com/w3ctag), we do continue to monitor the mailing list. :) The TAG discussed this topic in our meeting this past week and we resolved to open up an issue against our Design Principles repo (https://github.com/w3ctag/design-principles/issues/324) to discuss whether we should add identity principles to that document and if so what those should look like. I encourage you to engage on that issue.

Many thanks,
Dan Appelquist
TAG Co-Chair

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Sunday, June 13th, 2021 at 12:58, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> On Thu, 10 Jun 2021 at 11:00, Graham Leggett <minfrin@sharp.fm> wrote:
> 

> > 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/
> > > 

> > > 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.
> 

> When you say "the key".  Was this a public key, a private key, or a hybrid derived shared secret.
> 

> What I gather is that the public key is used to create the identifier and TLS used to secure it
> 

> Then that public key was used to create an identity by adding key/values
> 

> Slight difference I think may have been that session cookies rely on an unguessable string (security by obscurity), whereas a public key is authenticated by a handshake and signing a challenge
> 

> What did the public key look like on the back end?  Was it in PEM format?
>  
> 

> > > > > 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”.
> 

> We also had UX issues getting users to export certs from one device to another.  And also allowed naming in the CN
>  
> 

> > 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.
> 

> That's great.  It's something we wanted, but never really got a good workflow for.
>  
> 

> > 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.
> 

> That's excellent.  This is a good checklist if anyone decided to go that route again
> 

> With Solid we came up with a system Web Access Control
> 

> https://www.w3.org/wiki/WebAccessControl
> 

> ( for reference: there's newer versions of this now )
> 

> The idea was that you put your public key in a profile page, and that's part of your http identifier (aka webid).  Then you could grant access to that identifier on different resources
> 

> This is veering away from the main identity topic, and onto authorization which is a whole other topic
> 

> > 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.
> 

> Sounds awesome! 
>  
> 

> > > 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?
> 

> It would be helpful to see examples of what the identifier looks like, as "a key" could have many serializations
> 

> If interoperability is the goal, then different systems need a common understanding on what that looks like
>  
> 

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

> I dont see why not, that's a great point.  Ephemeral and long-lived identifiers could work together for different use cases, with different trade-offs.  Coming back to interop, I find the long-lived ones, a bit more interesting and useful
>  
> 

> > 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”?
> 

> Yes, I think session based identifiers would work very well in certain contexts.  Especially in the browser to browser use case.  I'll add that to my notes, thanks!
>  
> 

> > Regards,
> > Graham
> > —