Re: Principles of Identity in Web Architecture

On Mon, 7 Jun 2021 at 12:48, Graham Leggett <minfrin@sharp.fm> wrote:

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

Hi Graham.  Thanks for sharing this great implementation.  We had a related
system called WebID + TLS (orgiinally FOAF+SSL) back in 2012, which did
something similar.  Instead of using the public key as the "primary
identifier"  we used a URI which was put in the subjectAltName of the
certificate

My suggestion back then was to separate out the identity piece from the
authentication piece, as two separate specs.  So that each part could stand
architecturally on its own merit.  And then be combined to make a modular,
composable system.

The motivation I gave was that large systems already existed already exist
that use identification without authentication.  One being the postal
service (physical addresses), another being email (email addresses) and
another being phone systems (phone number).  I had been making this point
for a while, but it tends to be routinely dismissed.  However, I was
fortunate at TPAC 2012 that at least it wasnt dismissed, and that this
architectural separation was agreed upon.

The 5 points I propose above are in a similar way so that different eco
systems are able to build a bigger interoperable system, even if
implemented partially.


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

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


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

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.

>
>
> Regards,
> Graham
> —
>
>