Re: Principles of Identity in Web Architecture

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

Received on Sunday, 13 June 2021 11:59:27 UTC