- From: Graham Leggett <minfrin@sharp.fm>
- Date: Mon, 7 Jun 2021 12:48:00 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: TAG List <www-tag@w3.org>
- Message-Id: <4C753246-E2C4-48DA-87D5-6667D0684122@sharp.fm>
On 06 Jun 2021, at 12:00, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > At TPAC 2012 I proposed to timbl, a modular approach to Identity on the Web. > > Back then the majority of systems tightly coupled together, Identity, authorization and authentication. My proposal was that the Identity part should stand on its own merits, and be a modular piece of a wider architecture > > To my surprise and delight, he agreed with this, and persuaded our group to take this approach, and rewrite specs into what was to become the WebID suite > > Architectural Principles > > I wanted now to propose some further architectural principles, based on what we've learnt in the following decade, and align it with web architecture. They are as follows: > > 1. Separate identifiers from identity > 2. Identifiers are a string of characters, a global primary key > 3. Your identity are keys,values,links tied to your identifer > 4. Your identity is protocol, medium and transport agnostic > 5. Separate data and protocol meta data from identity data Extending this with some practical experience. A number of years ago I started working on a similar idea, the base concept being that the base unit of everything (the identifier above) was a asymmetrical key that represented “the entity that you’ve seen before in the past”. Mapping this onto real software deployed in real life, this meant giving people anonymous certificates to people representing their devices to anyone who wanted one. This certificate meant nothing on its own, its only purpose was to say “I’m here, and if you've seen this cert/key before, I’m back”. Specifically, the certificate contains a non-unique CN (example: “My iPhone”) that allows the end user’s UI to behave sensibly, and certs are guaranteed to be unable to be reissued by embedding the serial number of the cert in the subject. The validity of these certs is long enough past the warranty of the device, if it ever expires you just get a new one. An example UI to fetch the certificate is here: https://uk.sashkey.com/sashkey/create The backend of all of this became the Redwax project, as seen here: https://redwax.eu/#redwax-server The idea is you pitch up at a site, and the site says “nice certificate, never heard of you though, care to tell me about yourself?”. You then reveal as much or as little as you want, or nothing even. In practise we asked for the person’s email address and verified it, and at that point we knew who they were, but that’s what we did, there is no requirement anyone else do the same. Our experience of deploying this is that Apple devices (iOS and MacOS) work very well. They support SCEP, and certs just work. Firefox used to work very well, then after the effort to remove keygen’s secure private key generation that broke. Microsoft IE11 and below supported their CSR based certificate requests, while Chrome never supported any standards at all. We have worked around a lot of pain of deploying these by putting them on smartcards for people. > 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. Regards, Graham —
Received on Monday, 7 June 2021 10:48:41 UTC