Re: Principles of Identity in Web Architecture

On 13 Jun 2021, at 13:58, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

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

The complete technical description of the session identifier was “a public/private key pair generated on the client that was used to issue an anonymous X509 certificate that could never be reissued”. Keygen was the original mechanism used to create them, then SCEP was supported for Apple devices, then Microsoft’s CSR based method.

Your “session identifier” looks like this:

{ serialNumber 1234manymanynumbers7890, issuer rdnSequence:"CN=Sashkey UK G1,O=Sashkey,C=UK" }

This could be used as “username” when logging in, or it could be mapped on the fly to a more typical identifier like an email address (after the device has introduced itself).

> 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

This part turned out to be mandatory - you give a device access, and the device has a long incomprehensible name. There isn’t a nice way to do this by hand. The purpose of the automated “connect and ask for access” is it’s a way to get the DN of the certificate representing the session without the end user needing to do anything incomprehensible.

> 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

The identifier would still be a string, but it would be anonymous in and of itself:

{ serialNumber 1234manymanynumbers7890, issuer rdnSequence:"CN=Sashkey UK G1,O=Sashkey,C=UK" }

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

A big one is the app use case, where there is a lot more freedom over the implementation than exists in the browser.

Ideally, an app should be able to generate a key pair, and use that to request an anonymous session certificate from the server. That becomes the session moving forward. “logout” deletes the key pair and the certificate.

Now that a secure session exists, the apps may choose (or not choose) to request info from the end user to make the app work. For example an app like TikTok doesn’t require any details at all, but it does need a session to keep track of you separate to everyone else to decide the next video to serve you.

Regards,
Graham
—