Re: [External] Pop Quiz: Where do DIDs belong from an Enterprise Architecture perspective?

On Fri, Jan 17, 2025 at 4:10 PM Steve Capell <steve.capell@gmail.com> wrote:

> In supply chain we map DIDs to well known identifiers issued by trusted
> authorities - like this
> https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor
>

That approach works any time you have someone to partition the name space.
I was working on P2P systems where there is nobody to do that.

--------------
Alan Karp


On Fri, Jan 17, 2025 at 4:10 PM Steve Capell <steve.capell@gmail.com> wrote:

> In supply chain we map DIDs to well known identifiers issued by trusted
> authorities - like this
> https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor
>
> Steven Capell
> Mob: 0410 437854
>
> On 18 Jan 2025, at 9:24 AM, Alan Karp <alanhkarp@gmail.com> wrote:
>
> 
> On Fri, Jan 17, 2025 at 12:16 AM Samuel Rinnetmäki <
> samuel.rinnetmaki@findy.fi> wrote:
>
>> We might get away with pet names - a system where I store your DID giving
>> it an alias “Dan H” in my address book. However, pet names don’t work so
>> well when we bring third parties and non-digital communication into the
>> picture.
>>
>> Samuel raises a good point about pet names and third party
> communication.  Say that you call him SamR, and I call him Sam.  How do we
> know we're talking about the same person?  What do you and I call him when
> we're gossiping about him behind his back?  Say that you introduce Daniel
> to your SamR, and I introduce him to my Sam.  How does Daniel know that
> it's the same person?
>
> The answer to all three questions is to compare DIDs, but that comparison
> is better done by software than by eye.  Where does that software belong in
> the stack?  In the messaging layer?  Left up to the application?  Somewhere
> in between?
>
> I built one system where the mapping was done by the application and
> another where it was done in the messaging layer.  Doing the translation
> once in the messaging layer required few to no application changes.  Doing
> it in the application meant you could get the opaque identifier when you
> needed it, such as when talking over the telephone, but two applications
> might choose different pet names for the same opaque identifier.  I never
> built one with a name service applications could use to do the mapping.
> Maybe I should have.
>
> --------------
> Alan Karp
>
>
> On Fri, Jan 17, 2025 at 12:16 AM Samuel Rinnetmäki <
> samuel.rinnetmaki@findy.fi> wrote:
>
>> DIDs are points of control. We talk about "DID controllers". If a user
>> has points of control but doesn't know she has them, in what sense(s) is
>> she really in control? Pet names make points of control tractable from a
>> human memory perspective, but if the mental model of a user doesn't have a
>> place for the control point that they name, do we truly understand what we
>> are accomplishing? Do we need to? How does this relate to sovereignty?
>>
>> E-mail address is a point of control. As a user, you can share your
>> address daniel.hardman@gmail.com with me without knowing that the MX
>> records of gmail.com point to 142.251.167.26 (and other IP addresses).
>>
>>  Web domain is a point of control. Many people can host content on their
>> web site and publish the URL addresses of their pages without knowing the
>> IP address the server is hosted on.
>>
>> DNS provides a public mapping between (human readable) domain names and
>> IP addresses. Since DID addresses may be even more complex and hard to
>> grasp than IP addresses, there might be a need for a DNS-like system for
>> DIDs.
>>
>> We might get away with pet names - a system where I store your DID giving
>> it an alias “Dan H” in my address book. However, pet names don’t work so
>> well when we bring third parties and non-digital communication into the
>> picture.
>>
>> To answer Michael’s original question about the domain of DIDs, a DID is
>> a (technical) attribute of an entity that usually belongs to the Business
>> domain. (Applications and hardware devices might have DIDs, too.) Taking an
>> attribute (especially an identifying attribute) from an entity and moving
>> it to another domain easily leads to more confusion than clarity.
>>
>> Of course, you might create models where persons are in the Business
>> domain, their e-mail applications (including e-mail addresses) are in the
>> Application domain and the servers running those applications (identified
>> by IP addresses) are in the Technology domain. This model kind of works for
>> gmail addresses etc. (your gmail address only identifies your email
>> “application" provided by Google) but is quite misleading if you consider
>> e-mail addresses you really own yourself and can point to any provider. It
>> would be better to model the email address as an attribute of a person.
>>
>> A hostname can be used to identify an organization. (There are other
>> uses, too.) Since DNS provides a mapping between IP addresses and
>> hostnames, and this mapping can change, it is reasonable to model the
>> hostname as an identifier of an organization and the IP address as an
>> identifier of a server hosting the organization’s website (or mail servers
>> etc.).
>>
>> If we had a DNS-like system providing a mapping between DIDs and their
>> human-readable counterparts, we might model the human-readables as the
>> attributes of actors and DIDs as attributes of technology (like IP
>> addresses). But since we don’t have that mapping and the purpose of DIDs is
>> not to identify servers (like IP addresses), I claim that DIDs belong to
>> the domain where the objects they identify belong to. Personal and
>> organizational DIDs belong to the Business domain. If there is a DID for an
>> application, that DID belongs to the Application domain.
>>
>> All models are wrong, but some are useful.
>> Samuel
>>
>>
>>
>>
>>
>>
>