Re: Principles of Identity in Web Architecture

On Sun, 13 Jun 2021 at 21:07, Daniel Appelquist <dan@torgo.com> wrote:

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

Thanks, Dan.  That was nice of you!

I'll try and curate the feedback here, and see if I can summarize it, while
wrapping up this thread, if it hasnt been already

Motivation is that I'm chatting to some dweb folks next week about identity
on the web, and I wanted to get down some idea, and see if there were any
particular thoughts on it

Hopefully I'll be able to create a cohesive summary, and I'll put it into
the open 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
>> —
>>
>>