Re: [Identity-discuss] What are the problems we are solving?

[Phillip Hallam-Baker <[e-mail]>]

There are some problems where the problem is we have no solution.

There are others where the problem is we have too many solutions and they
don't really work together.

DNS has many faults. But it has established itself as a single namespace
for providers of Internet services. There is no similar namespace for
people.

I have dozens and dozens of Internet identifiers which all refer to me and
many more that refer to avatars. And the problem for me is that I don't
have control or the cost of that control is a DNS name registration, they
are all subordinate to another third party or they only work in a walled
garden.


Nöth's trichotemy of symbols may be of use:

Firstness: The signifier is the signified itself, e.g. a raw X25519 key, a
data: URI

Secondness: The signifier bears an indexical relationship to the signified,
e.g. SHA-2 hash of a data object

Thirdness: The signifier is only related to the signified by convention. It
is a 'name'.


Before applying that, let us also look at use cases for identifiers:

* Passed in speech
* Passed as a QR code
* Activated by clicking on a contact entry in an address book
* Presented to the user when receiving a communication


A signifier that is a name 'i.e. thirdness' can be user friendly. It can be
easily typed in or read. But that comes at the cost of being issued by some
form of registry. This may be a public body like ICANN, a private body like
Meta, Twitter, Mastodon instance etc. or it can be local to the user
themself.

Only a signifier of type firstness or secondness can be 'owned' by the user
who uses it. If we insist that only the user should be able to use the
signifier, we have defined a public key cryptosystem: We have two roles,
the signified role and the relying party role. The ability to act in the
relying party role must not allow someone to impersonate the user. Ergo, we
have defined the requirements for a public key cryptosystem. This means
that our signifiers must necessarily be rather long and rather user
unfriendly.

Mesh identifiers are Base32 fingerprints, e.g.
MASN-NAYB-IY7F-JCFZ-RFWV-UIT4-MSEZ

That is as short as I could make them and present an acceptable work
factor. We could make use of a natural language dictionary in which case we
get ~12 bits per word. So 'horse, battery, staple, boomerang, nut, .... '

So looking back at the set of requirements, to meet the 'user sovereign'
criteria, we have two options:

1) Only use signifiers of type firstness and limit exchange to modes where
the ugliness can be hidden from the user (QR code, click, etc.)

2) Use signifiers of type firstness are the primary identifier and use
names as a means of exchange. So when Alice meets Bob, she gives him her
Mesh service address, [e-mail] and the contact exchange protocol
then maps that to her permanent private identifier MASN-NAYB-...


Of course at this point, people will start screaming I have glossed over
privacy issues. And actually, I haven't. If Alice wants to have multiple
identifiers and keep them separate, she is going to have to create multiple
identifiers and keep them separate.

The other major objection to my approach is that any system that relies on
public key cryptography for user authentication has to address the problem
of provisioning credentials to multiple devices: Alice has a phone, two
tablets, three laptops, a watch, four desktops and a cat. Which is the
problem I have used threshold to address.

Bottom line is that in 1993 when I first started looking at this problem,
my solution would be utterly beyond the capabilities of the machines of the
day. But technology has moved on since and a Raspberry Pi model 1 is more
than capable of doing what is necessary to manage a personal PKI with
hundreds of keys.



On Fri, Jul 28, 2023 at 9:18 AM Heather Flanagan <
[e-mail]> wrote:

>
> Hi,
>
>
> On Jul 27, 2023, at 17:51, Phillip Hallam-Baker <[e-mail]>
> wrote:
>
> 
> Rather than getting into definitional arguments, I would like to see
> discussion of problems that we are either trying to solve or looking to ask
> others to solve.
>
>
> I absolutely agree that falling into the trap of definitional arguments is
> a Very Bad Idea. I am less clear that discussions of the problems to solve
> at the level you’re describing below is a better path, though. Could you
> perhaps say more? When I look at your questions, I immediately think, “But
> there are already protocols that do that.”
>
> What I think is more interesting is to understand is why would anyone
> choose one protocol over another? What are the gaps that are driving people
> to different solutions? Can the IAB advise on how to evaluate identity
> protocols for a given architecture?
>
> I’m definitely interested in engaging in those conversations.
>
> -Heather
>
> These include:
>
> How does Alice initiate an instant messaging conversation with Bob?
>
> What forms of identifier can Alice use to specify the Bob she wishes to
> communicate with?
>
> How does Bob know the request comes from the person he knows as 'Alice'.
>
> At what times and to what extent are Alice and Bob reliant on third
> parties?
>
> How does Bob signal that he is ready to accept inbound contact on a
> particular device?
>
>
> --
> Identity-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/identity-discuss
>
> --
> Identity-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/identity-discuss
>