Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toronto Songwriter / Performer Use Case: DID Method Candidates #22

Open
mwherman2000 opened this issue Dec 15, 2024 · 9 comments
Open

Comments

@mwherman2000
Copy link

mwherman2000 commented Dec 15, 2024

Click here to watch: Toronto Songwriter / Performer Use Case: DID Method Candidates

image

In this use case, there are 66 potential DID Methods (out of a domain of approximately 1.5 million total DID Methods).
Reference: #14 (comment)

UPDATE: DID Methods are used to name classes or clusters of related entities (subjects). For example, did:songs might be a DID Method for clustering the identities for all "song" subjects (i.e. song titles).

UPDATE: A hierarchical DID can be both a DID (with or without a DID Document) and a DID Method - at the same time. Checkout the CCG mailing list.

@stevenvegt
Copy link

I think you might confuse the entity with its identity. A DID method describes the technical method of (mostly) resolving the public keys on layer 1 of the trustOverIP model. What you seem to describe here are claims about the entities role in a system, in other wordt the identity of the entity. This concept lives on the third layer in the ToIP mode. An Identity claim can be issued by an authority by using Verifiable Credentials, e.g. create a MusicIndustryCredential with the claim "role".

So the DID method should only describe the mechanism for the Create, Resolve, Update and Deactivate operations and nothing about the actual identity of the entity.

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 24, 2024

@stevenvegt I very much appreciate your analysis. This is where many people get confused about the nature and purpose of a DID (i.e. the decentralized identifier character string) as defined by [DID-CORE]. This confusion dates back to some of the earliest days in the history of DIDs (e.g. 2018 Hyperledger Global Forum DID presentations in Basel, CH ...almost exactly 6 years ago).

A DID is simply (a sometimes verifiable) name (identifier) for something (aka a subject). DIDs can name (reference, identify) Every Little Thing (#ELT) on the planet, every piece of knowledge, every bit of understanding, every ounce of wisdom (every possible subject). I made sure this was so when I contributed to the original [DID-CORE] specification - along with Drummond and others.

From [DID-CORE]...

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.

DIDs can refer to documents, services, schemas, and other things that might be associated with individual people, households, clubs, and employers

The subject of a DID is, by definition, the entity identified by the DID. The DID subject might also be the DID controller. Anything can be the subject of a DID: person, group, organization, thing, or concept. This is further defined in 5.1.1 DID Subject.

The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.

This specification encourages new, DID-aware endpoints to use nothing more than the DID itself for any identification necessary.

This diagram (less my highlighting) is taken directly from [DID-CORE]. Aside from what's inside the green box, everything else is optional.

image

My current estimate is there are about ~1.5 million potential basic DID Methods (~4.1 million actual potential Methods) and these can be automatically generated using a custom AI LLM I'm creating as I write this. Here's a very small sample...

image

#iDIDit

NOTE: The #ToIP model has no bearing on [DID-CORE]. (I was part of that effort too.)

Joyeux Noel,
Michael Herman
First Principles Thinker
Web 7.0 Foundation / Trusted Digital Web (TDW)

@peacekeeper
Copy link
Member

A DID is simply (a sometimes verifiable) name (identifier) for something (aka a subject). DIDs can name (reference, identify) Every Little Thing (#ELT) on the planet, every piece of knowledge, every bit of understanding, every ounce of wisdom (every possible subject)

I agree with this, but I also agree with @stevenvegt that "the DID method should only describe the mechanism for the Create, Resolve, Update and Deactivate operations and nothing about the actual identity of the entity."

DID methods were introduced to distinguish between different techical infrastructure that can be used for implementing DIDs, but this has nothing to do with what DIDs identify.

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 29, 2024

DID methods were introduced to distinguish between different techical infrastructure that can be used for implementing DIDs, but this has nothing to do with what DIDs identify.

@peacekeeper Markus can you quote a reference from [DID-CORE]?

...or is this folklore? We need to stay with the facts (as written in [DID-CORE]) - that's what specifications are for.

I was deeply involved in the [DID-CORE] and always viewed DID Methods as (abstract) classes of subjects/data types. I believe there is language in the spec that says a DID Method isn't expected to be limited to a single underlying implementation (which is just the opposite).

Web 7.0-DID-STACK ARM 0.11-annotated.png

@peacekeeper
Copy link
Member

@peacekeeper Markus can you quote a reference from [DID-CORE]?

I have provided references several times before, so please just see those other threads, or read the DID specification.

I was deeply involved in the [DID-CORE] and always viewed DID Methods as (abstract) classes of subjects/data types.

I was much more involved in DID Core than you, and this interpretation has never even occurred to me. Please accept that this is NOT what DID methods are for.

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 29, 2024

This is a professional forum and we shouldn't rely on individual options that are stated with no backup.

IMO your reply is an example of https://hyperonomy.com/2019/04/09/clique-speak/

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 29, 2024

This has never occurred to me before

This totally surprises me. I have written extensively on this topic for several years (publicizing most if not all of these articles on the CCG mailing list):

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 29, 2024

Lastly (I hope), we have taken this 2 huge steps further with:

  1. Dynamically generated DID Method names (removing the need for static DID Methods)
  2. A fully functional DID Document inheritance model...

Web 7.0-DID-OBJECT-ARM 0.4.png

We're huge believers in the #OpenToInnovation Principle for the Internet...
https://hyperonomy.com/2019/03/12/internet-protocols-and-standards-not-only-need-to-be-open-but-more-importantly-open-to-innovation/

@mwherman2000
Copy link
Author

mwherman2000 commented Dec 29, 2024

So the DID method should only describe the mechanism for the Create, Resolve, Update and Deactivate operations and nothing about the actual identity of the entity.

This statement is not completely true.

The entire purpose of a subject's service endpoints are to enable interaction with the underlying entity (addressable by its DID). In Web 7.0, DIDScript(tm) exploits this concept:

In addition, DIDScript supports round-robin, load-balanced DID Agent Clusters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants