Request for inclusion of Decentralized Identifiers (DIDs) in the ARF

[kimdhamilton]

Privacy, security, and individual empowerment are fundamental considerations for a digital identity system. We commend the European Digital Identity Wallet Architecture and Reference Framework (EUDIW ARF) team for their dedication to the goals of user-centricity, privacy, security, and cross-border interoperability and commitment to a wallet architecture based on privacy-by-design.

We recommend incorporating Decentralized Identifiers (DIDs) into the ARF to further enhance these goals and enable a more robust, resilient, and interoperable ecosystem.

We've outlined the rationale in this document.

This document was collaboratively developed by communities and organizations committed to individual empowerment, and who embrace DIDs as a foundational element. This is backed by the Decentralized Identity Foundation, Digital Credentials Consortium, and Trust Over IP Foundation.

Thank you for fostering an open feedback process.

[ad-Orange]

Hello Kim, In your document, you're mentioning that

"In combination with zero knowledge signature schemes and Peer DID implementations, DIDs provide privacy improvements that inhibit the correlation of people, devices, and activities."

We are not sure how Peer DID would help with reaching full unlinkability.

Besides, the only way (at least reasonable in terms of implementation) we know of to ensure full unlinkability with BBS is to use DID:key. No other DID type allows performing efficient ZKPs with BBS. And using DID:key is basically exactly the same functionally as what everyone is already doing by using public keys in attestations. So we don't understand how introducing DIDs would advance the state of the art for elDAS.

Could you please detail your vision on these points?

[csuwildcat]

@ad-Orange can you expound upon why you feel BLS-12381 keys used via did:key specifically are the only way to achieve unlinkability in zero-knowledge interactions?

Additionally, arguably most useful aspect of DIDs for individuals, after the basic self-ownership of an identifier they control, is the decentralized routing features of Service Endpoints. With decentralized routing via Service Endpoints, individuals can leverage more decentralized mechanisms of content, data, and comms exchange over a number of protocols. Does your org not see this as a critical need for individuals, who are now tied to centralized intermediary corporations for identifiers and exploitative, privacy invasive systems for exchanging content, data, and communications? Does whatever alternative to DIDs your system would use provide self-owned identifiers with decentralized routing capabilities, because if not, that's a huge miss, in my opinion.

[ad-Orange]

Full unlinkability involves making sure that no one can track the holder that is doing the transaction, not even the issuer of the VC. With BBS you can easily blind specific types of public keys (but not more generic DIDs) along with the rest of the potentially personally identifying metadata, including the issuer's signature. Maybe there is another (easily implementable) mechanism to blind more generic DIDs and other personally identifying metadata but we don't know of it and all flavors of BBS we know of certainly don't allow that. By the way, the EC you're referring to is a pairing friendly curve that is not necessarily the most in love with security agencies (see here). However, BBS# allows the use of classical curves if that's what you're after.

As for the rest of your comment, you might look for additional advantages of a solution but if full unlinkability and everlasting / unconditional privacy are not here, you've already lost. I'm not exactly sure at what concrete advantages you are pointing to (not saying they don't exist, just that I probably don't know that field well enough to immediately see them from you succinct description) but what I can give you as a hint is that by using derived features of BBS like protocols you can create secure but self generated pseudonyms that guaranty privacy for its user.

[ankurdotb]

Besides, the only way (at least reasonable in terms of implementation) we know of to ensure full unlinkability with BBS is to use DID:key.

I don't disagree with this statement at all, and you're probably right. Also, you're probably right that in an end-user/client app perspective, a did:key is perhaps not very different from a JWK.

But that would be judging the entire stack by its lowest common denominator. The true difference, IMO, is for organisational-level actors (issuers/senders and verifiers/recipients) where you probably shouldn't be using did:key, and using more sophisticated DID methods instead that allow for:

1. Key rotation and multi-party control
2. Specifying additional metadata, such as API/service endpoints in a signed fashion
3. Specifying trust registries/frameworks, revocation mechanisms etc (natively, or using emerging standards like DID-Linked Resources)
4. Updating, deprecating (for future use, while still allowing to check historical validity) for all of the above while maintaining the same handle/identifier at a DID URI
5. Specifying relationships between parties using DIDs

You could probably do point 5 using X.509 certificates, but not the others. DID methods add additional structure and machine-readability for some of the additional actions necessary for trust, beyond just specifying a public key and signing messages.

Focussing on whether the end user/client side can be replaced with a public signature/JWK IMO misses the value of utilising DIDs in other parts of the journey. :)

[ad-Orange]

Maybe DIDs are better for these things but it would require going through some hairy costs/benefits debates in an eIDAS context that would I think go way beyond what could be efficient on this GitHub. Maybe DIDs could be useful for issuers mostly. Maybe it could be useful for more, I don’t know and I haven’t seen a document clearly analyzing it neutrally in an eIDAS context.

But anyway, my point was mostly to highlight the fact that contrary to what was mentioned in the document, it’s not the DIDs which provide the stated privacy advantages. It’s the use of proper anonymous credentials protocols like BBS. And this works with proper cryptographic keys, whether they’re formatted as fancy DIDs or not. And I think this aspect shall be removed from the DID / not DID debate, because it artificially confuses it.

[peacekeeper]

@ad-Orange I would agree that the topic of which cryptography to use is somewhat orthogonal to the "DIDs or not" debate.

However, one aspect where I think the use of DIDs can really help with potential privacy issues is that some of the non-DID alternatives (e.g. JWT VC Issuer Metadata) are based on the idea that the Issuer's public keys are downloaded from a webserver, which presumably is under the Issuer's control and can track such downloads. It is perhaps debatable how much information such "phone home calls" for retrieving the public keys actually leak about a user, perhaps not much. But using DIDs would make it easy to switch to other public key discovery mechanisms that do not require a callback to the Issuer, with minimal impact on the rest of the system.

[ad-Orange]

I see your point but:

• the only issue is really related to timing correlation attacks: “phoning home” usually involves sending a personally identifier (like public key, identifier, etc…) back to the issuer. It would NOT be the case here as you just need the issuer public key. And I’m still not sold on the reality of timing attacks in eIDAS.
• This is not a structural issue, barely an architectural one. It’s mostly an engineering issue: do you have the holder sending the (certified) public key ? Do you store it in some sort of CDN ? Another way yet ? There are many solutions.

[OR13]

DIDs are URNs that resolve to public keys... Plus a bunch of serialization options, and different resolution systems and storage systems.

Depending on the options you pick, it could be bitcoin blockchain or some centralized database accessed via OHTTP.

If you make them normative, be prepared to explain which methods you support and how they provide the privacy guarantees your use cases require.

[kimdhamilton]

This is a good time to expand out, because we are likely talking past each either until some fundamental issues are addressed. The most pressing needs around the ARF are procedural and structural, and may not fit into the current timeframe. What should happen:

1. Elaborate legislative requirements into detailed technical requirements. Section 1.1 of the Cryptographer's Feedback paper is an excellent example of how to do that. It's critical that this be done before moving to any specific technical solutions.

2. Use step 1 to identify elaborated requirements that will require tradeoffs and relative prioritization

3. Enable a future-proofed approach by defining profiles that can then be evaluated against the criteria, and, where relevant, defining layerable, composable standards. This has been called out and is currently unaddressed in https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/89

We can all agree that most issues in this repo skip over intermediate steps and jump to a favored solution, whether that's an entire replacement or an element.

I advocate for DIDs as part of step 3, as the most mature and considered standard to provide agency for individuals through credentials that they control, enabling holder binding in a way that does not introduce a tight coupling on the issuer. That's largely because my personal interest in DIDs comes for designing systems to enable portable, lifelong learner/worker credentials.

Reductively, you may call DIDs a URN that resolves to public keys, but that misses the extension points of this fundamental primitive called out in @ankurdotb's response. For example, DID-based communication, is a way to securely interact with parties across channels -- a mitigation for increasingly common out-of-band phishing attacks.

But to refocus on the impact to credential holders specifically, it's a win that the current version of the ARF achieves some forms of data minimization. It would be ideal to see more progress around unlinkability (a concern that is well-covered,) and sovereignty -- in other words, avoiding the need for 1-time-use credentials that introduce a tight dependency on the issuer in order to also approximate unlinkability. I think DIDs are a powerful element of such a solution.

I hope this provides some additional context and nuance around the request.

[ad-Orange]

I think DIDs are a powerful element of such a solution.

Unfortunately, I don't think your long post has brought us closer to the proof of that, at least if "such a solution" is indeed

avoiding the need for 1-time-use credentials that introduce a tight dependency on the issuer in order to also approximate unlinkability

Once again, to reach that goal, in the current state of the discussion, DID are not the solution and anonymous credentials are (whether they are then bundled with DID:key or not).

[csuwildcat]

@ad-Orange as it turns out, only a tiny sliver of credentials exchanged in human life are even intended to be anonymous. Diplomas, work history, public certifications, licenses, supply chain proofs, legal contracts (yes, those are just Verifiable Credentials), etc., are all things people willingly attach to their identity to enhance some aspect of life or business dealings tied to them as a person or entity.

For far too long, a diminutive, governmentally interned view of credentials that represents 1% of identity has dominated the thinking in this space, and I strongly lament that it is now hobbling the direction of these technologies. People need the 99% of identity too, which includes DIDs/VCs to support all the types of credentials listed above, as well as social media, personal communications, and all manner of app-related interactions.

We face a choice: do we leverage a foundation that addresses the broad needs of identity as a digital system for human, business, and machine interactions that spans the ecosystem of use cases, or do we, out of some form of apathy or myopia, end up with one-off 'solutions' for every little niche, forcing redundant concepts and fragmentation upon a world that deserves something better.

[ad-Orange]

@csuwildcat I respect your point of view (not necessarily your numbers coming out of nowhere though). I don’t see how the issuer / holder / verifier model not based on DID definitely precludes (or makes particularly inefficient) anything of what you’re saying but I respect that you might be of a different opinion and I didn’t dig deep enough to challenge all the advantages you’re mentioning for DIDs. What is harder for me to swallow is the insistance on statements that are not based on facts. DIDs by themselves do not improve privacy in any way and insisting on it is just wrong. For all the other statements, I don’t really have a strong opinion and I’m happy for other people to agree on it or debate them.

[csuwildcat]

@ad-Orange the numbers are self-evident: look around you at the world and tell me what currently analog, siloed, and legacy forms of proof that would be digitized as Verifiable Credentials are 007 private:

1. LinkedIn - education, work, and skills proofs. All are publicly associated to one's identity.
2. Small businesses - licenses, insurance proofs, sanitary premises certification, etc. All are publicly associated to one's identity.
3. Supply chain - product certifications, safety certifications, ship manifests, item-level proofs, green supply chain proofs, delivery proofs. All are publicly associated to the identities involved.
4. Legal sector - literally all work, property, construction, and business contracts are publicly associated with the identities involved.

As far as DIDs enhancing privacy, you may be surprised to learn 80% of human identity interactions are intentionally not private:

1. LinkedIn and career sites are identity apps - my profile IS identity, and making an anonymous resume would be absurd.
2. Twitter is an identity app - my posts ARE identity, as they explain my views, thoughts, beliefs, and communicate things about me. Social media is at least pseudonymous, and many people associate their social subset of identity with their person.
3. GitHub is an identity app - my code profile shows my skills, my projects, and what people and organizations I interact with. People who use Github are at least pseudonymous, but most associate their engineering subset of identity with their person.

If you ask a person "Tell me who you are, what is your identity is in this world?", I assure you they are not going to whip out their driver's license or national ID and read off the small set of fields on them, they are going to tell you about who they are and what defines them in the world.

Perhaps the reason all this seems so surprising and different to you is that you didn't realize identity is everything you do, say, write, and express, as well as everything anyone else associates with you. The vast majority of all these interactions and accrued data sets are fully associated with your person, while some are pseudonymous, and a smaller percentage are anonymous. Identity is almost everything around you, and we need to a platform that is prepared to handle the full scope of it. DIDs, VCs, and personal datastores are the solution, so let's not squander this opportunity to lay the right foundation.

[csuwildcat]

I can't help but note the irony:

EU Agencies: "Here are 400 million regulations and brutal monetary punishments (e.g. Digital Markets Act) targeting companies for holding your personal identity data (profiles, posts, content, preferences, etc.) hostage in their silos. We think people should have greater control of their identities and the data that it's composed of!"

Decentralized Identity community: "Here are DIDs, VCs, and personal datastores, which can be used in public, pseudonymous, and private formulations to solve the issues you passed 400 million regulations and punishments about."

EU identity/wallet folks: "We only care about 007 super secret governmental credential exchange, why would we ever support DIDs/VCs (and personal datastores) in our wallets for any other reason?"

Me, thinking to myself, absolutely befuddled: Are the right and left hands here even aware they exist on the same body, and that the same fundamental tech stack is the foundation for solving this whole range of interrelated issues?

In practical terms, for the advancement of your own EU interests, your wallets should:

1. Allow users to login to apps and sites with DIDs (DID Authn), restoring user control over digital identifiers so they don't have to rely on corporate silos.
2. Equip people and businesses with the ability to exchange non-007 credentials, which make up the vast majority of credentials/proofs exchanged in the world.
3. Eventually integrate personal datastores, so individuals and businesses are less reliant on centralized corporate actors for their personal, business, and social identity interactions.

[ad-Orange]

I’m not sure you properly understand the role of the DMA (and possibly of eIDAS either) and just throwing acronyms at the issue or repeating your point indefinitely will not make it more believable.

I will just add one comment for perspective: contrary to what you seem to think, unlinkability and everlasting privacy have nothing to do with managing “007 super secret governmental credential exchange”. They’re here to ensure that whatever you chose / is necessary to share can not be overtaken by external actors without your consent. What you’re saying implies (among other things) that selective disclosure is useless. It might be your opinion. It’s not the opinion of the European regulator or most Europeans you’ll ask (once they understand the issue), seriously questioning your posturing as a white knight European society protector.

[csuwildcat]

"What you’re saying implies (among other things) that selective disclosure is useless." - this is not an accurate recitation of what I said. What I said is that the vast majority of identity/credential interactions in life are with credentials and identity data that is intentionally linked to a person/persona or business entity, and that is demonstrably true with even a cursory scan of activities across the vertical spectrum. Where privacy is required for exchange of more secretive, unlinked credentials that feature selective disclosure, obviously we should have options for that, and DIDs do not preclude formulations that allow for it. You are posing this as an either/or, while I am asserting that you should care about and support both.

The I believe we should all be focused on empowering people with wholistic digital identity they control. If the sum total of your concept of identity is a narrow sliver of private credential use cases, you will fail to fix all the most impactful issues in identity systems and digital life. Why on Earth would anyone argue for continuing to be stuck with the status quo of the largest cloud providers and a handful of social media companies effectively owning the identifiers individuals rely on to build their digital identities? You have an opportunity to stop just speaking in the language of regulations and penalties and actually offer people an option to have digital identities that exists independent of these corporations, with apps and services that store their data with individuals themselves, not corporate silos. The way this opportunity to truly empower people with digital identity and identity data protocols seems to be headed for the discard pile deeply saddens me.

As far as the DMA goes, it includes provisions that require 'gatekeeper' companies to provide users with access to their data through open/standard protocols. Specifically, Article 6 of the DMA mandates that 'gatekeepers' must ensure effective portability of user data, including the tools to facilitate the transfer of data to other apps/services. This means that gatekeepers must allow users to export their data in structured, machine-readable formats, over protocols that enable app/service switching. Now, don't you think the whole point of DMA's provisions in this area - which is to empower users with their own identities and data - gets a lot more realistic if we had a system where users authenticated with apps/services using identifiers they own, that transcended any provider/company, like DIDs, with personal datastore endpoints attached to those identifiers that app/service companies could export/stream data to? Obviously this is going to require more work over the long-term to land, but Step 1 is to empower people with decentralized identifiers, the root of most app/service identity interactions that serve as the foundation for adding decentralized data/comms routing and personal datastores. If not this, what do you envision it looking like, every company dumping their data for a user into massive, provider-specific blobs of JSON and binary that each company has to reverse engineer to ingest? What a disappointing future, especially when we have the tools to deliver a better one right in front of us.

[ad-Orange]

To clarify a few things:

1. Selective disclosure w/o full unlinkability is useless and even arguably dangerous
2. DIDs preclude the use of the known “easy” to deploy technologies for full unlinkability, namely anonymous credentials, except with DID:key
3. What makes you think that you can’t define your own credentials by yourself with the eIDAS model ? While I agree that the current ARF 1.4 is a catastrophe for privacy, it is just because the commission refused to listen to anything people have been telling them for more than a year. There are solutions today to create your own keys, your own pseudonyms that RPs won’t know who they are linked to, etc… the resulting level of independence and privacy is arguably better than what you could achieve with DIDs. Once again: agreed it’s not the way it’s done in the ARF, but it’s due to the inept choices of the commission in terms of protocols, NOT due to the underlying model nor to the lack of use of DIDs.
4. It is not realistic to build a full ID infrastructure that does not rely at its root on the sovereign identity of people. Latter on for transactions, you can hide it, minimize it, ZKP it the way you want or simply not use it, but hoping it is possible to build something not relying on it as a trust anchor for identity is just unrealistic and counterproductive
5. Sorry but I think you’re sad about the wrong thing: you shouldn’t be sad that there isn’t blockchains or DIDs in the ARF, you should be sad (for us Europeans if you really care) because the commission actively and violently refuses to include ZKPs and anonymous credentials at the core of the ARF.
6. I don’t think you properly understand the architecture of the European regulation. 6(1)(h) doesn’t even exist and I think you’re referring to 6(9) which, as is explained in recital 59 just reminds in the DMA the obligations actually coming from the GDPR. Whether you’re happy or not with the GDPR is your problem but it is considered by many Europeans as the first and deepest line of defense against the assaults of the actors you’re mentioning to our privacy.
7. The vision you’re describing for self management of people’s data is nice. But, first I’m not sure it’s very realistic (in the same way that everyone could theoretically have their own DNS and mail servers, but guess what: they don’t) and second I don’t see why the same type of situation couldn’t be achieved with the overall architecture defined in the ARF (once again, I’m not talking about the choices that were in the ARF and that are catastrophic for privacy but about the overall issuer/holder/verifier paradigm).

As a conclusion, and this will be my last post in this thread:

• Any sort of serious privacy (full unlinkability & everlasting privacy) provided by DIDs doesn’t actually come from DIDs, but from the ability to use anonymous credentials and this is only the case with DID:key
• Identity structurally steams from the sovereign State, whether you like it or not
• It seems to me that most (if not all) of the alleged benefits of DIDs can be obtained by building the right service layer over a solid security and privacy infrastructure provided by eIDAS. And arguably better if the privacy layer is more solid than what can be obtained with DIDs.
• The main issue with eIDAS and the ARF today is not the lack of DIDs. The main issue is the lack of anonymous credentials which prevents building this security and privacy layer I mentioned just above. European people couldn’t care less about DIDs. They will definitely care about their privacy.

[csuwildcat]

"Identity structurally steams from the sovereign State, whether you like it or not."

^ this highlights a fundamental philosophical difference, but is also inaccurate:

1. Every person has an identity independent of any other person or government - we exist in the world and form identity-based relationships all the time that never touch a single thing that's government-related. Point 3 expounds upon this.
2. The government does not provide identity, it's simply a very reliable source of credentialized information about natural persons and issue claims about people others choose to rely on (or are mandated to in certain cases). Businesses can do the same, and frequently do (e.g. work history).
3. Most of our identity and identity interactions have nothing to do with governments - here are a few examples to illustrate: people maintain their identity and engage in identity interactions across Twitter, LinkedIn, and Github, which form their social, career, and engineering/hobbist subsets of their identity. Over time they build up their identity across these centralized apps and amass reputation (which is just a crowdsourced form of unstructured credential). The question is: why is my social or career subset of my identity locked to a provider? I argue they shouldn't be, that individuals should be able to authenticate to apps like with DIDs the can use across providers, taking their identifiers, reputation, graphs, and identity data with them whenever they choose. I'm genuinely shocked you 1) don't see these examples as identity, and 2) seem to have 0 care about supporting these identity use cases, which make up the 99% of a person's daily identity activities.

[Sebastian-Privado]

@ad-Orange - about your initial comment:

Besides, the only way (at least reasonable in terms of implementation) we know of to ensure full unlinkability with BBS is to use DID:key. No other DID type allows performing efficient ZKPs with BBS. And using DID:key is basically exactly the same functionally as what everyone is already doing by using public keys in attestations. So we don't understand how introducing DIDs would advance the state of the art for elDAS.

It is not accurate. did:iden3 (and by extension did:polygonid) allow to have efficient ZKP (client-side generation). You can try it from your phone or browser, the ZKP is generated in less than 2 seconds. It relies on BJJ elliptic curve, but we are researching to work also with more traditional curves.

did:iden3 also allows for key rotation (blockchain based), pairwise DID and private and scalable revocations.

Privacy is at the core of our did method and we strongly support the point made by DIF about how the DID addition to ARF could elevate the privacy of the ARF.

[mfosterio]

I've got a very short non technical response. Interoperability is fundamental in a vision for seamless access world and supporting DIDs with the aid of Verifiable Credentials adds to the ability for your citizens to connect and verify that they are a real human and selectively disclose information that your organization can validate and verify in thier online interactions. This only helps in building trust and in supported W3C recommendations. I urge you to learn the differences of the different DID methods and support one that fits your technical and regulatory requirements. If you need help I'm sure the DIF community will guide you along the way.

[sdellava]

It would be highly beneficial for the ARF to also incorporate the use of DIDs (Decentralized Identifiers), as DIDs enable the creation of a hierarchical chain of identities, which is not possible with PID alone. This hierarchical structure allows, for example, the establishment of relationships between minors and their parents, enabling parents to sign on behalf of their children as controllers of their children's DIDs.

Moreover, the hierarchical chain facilitates the creation of identities for non-human entities. For instance, it is possible to create an identity for a car, controlled by its owner. This opens up numerous applications that can greatly benefit from the hierarchical structure of DIDs, effectively preventing fraud.

A DID can also be assigned to an organization, with control assigned to multiple members. A document signed according to a specific signing criterion described in the DID document could have legal validity, as it would be signed by the majority (or all) of the controllers, i.e., the members of the organization.

Additionally, ISO/IEC 27000:2018 provides the definition, “3.6 Authenticity property that an entity is what it claims to be.” An entity is clearly an abstract subject, not just a person, so adding DIDs to the ARF is crucial for addressing the security criteria of ISO/IEC 27001 and thus also of NIS2, which will be mandatory from October 2024.

In essence, adding DIDs to the ARF would make wallets compliant with the European Digital Identity Framework a universal tool for the security of any business application.

[ottomorac]

This point made by @ad-Orange "Identity structurally steams from the sovereign State, whether you like it or not" is not quite accurate, in terms of allowing the free usage of identifiers.

Allowing citizens to "bring their own DID" is much like your government asking your for your email in order to contact you. Now whether you use Gmail, Hotmail, or your own domain is something the citizen chooses and not something that should be dictated by the government.

[csuwildcat]

Exactly - people exist and have an identity (who they are as a person) independent of any org, government or otherwise, and use their identity in many ways that requires no government registered identification. Government merely provides a high trust proof of individual identification, in the form of a credential. I have a social identity I expose on Twitter and LinkedIn, and never has anyone claimed those are not valid expressions of my identity because I don't attach a Driver's License or passport to them.

This point made by @ad-Orange "Identity structurally steams from the sovereign State, whether you like it or not" is not quite accurate, in terms of allowing the free usage of identifiers.

Allowing citizens to "bring their own DID" is much like your government asking your for your email in order to contact you. Now whether you use Gmail, Hotmail, or your own domain is something the citizen chooses and not something that should be dictated by the government.

[stevenvegt]

As argued above, DIDs have a lot of advantages, but with such a complex project as the ARF, that can also be a bit scary. I understand the tendency of Keep It Simple Stupid.

Let's go back to the basics here: We are designing a spec for issuing claims to a holder which can in their turn present the claims to a verifier. We trust a small group of issuers so we can trust a large group of holders. We identify these issuers based on an identifier. The claim contains a subject and an issuer. In order to validate the signatures on the claims and presentations, we need to resolve key material.

We need a secure method to go from identifier to public key pair.

So, you can use e.g. an ebsi specific identifier to a published key, of perhaps trust DNS and host the key on a https endpoint, or use the key of the wallet during a p2p interaction. But now we already have 3 different possible methods of resolving key material which might be used in some combination. It is not unthinkable that in the future this list becomes longer.

Lets design a simple datastructure for that. We can prepend the key-identifier with a label for each key type. Per label, describe how to use the key-identifier for resolving the key. Add to that a standardized container format for the key and you have remade the DID specification.

Assuming there will be multiple key methods anyway, lets use the standard that has been developed to support exactly this use case.

Imho the discussion should be about: How do we limit the usage of the DID spec to reduce complexity and risk for the v1.0 ARF spec, instead of "should we use it or not".

But, since there are a lot of smart people here I might be missing something. Let's discuss!

[peacekeeper]

Fully agree with @stevenvegt 's comments.

There is maybe a misperception that the "DID community" wants everybody to support dozens of DID methods, blockchains, etc., and that this would create an interoperability nightmare.

But in fact, the primary benefit we propose with DIDs is to have a common identifier syntax and a common discovery data structure for obtaining public keys associated with an identifier. If you don't use DIDs in a system but still want to support different ways of retrieving public keys, then you'd be basically just re-inventing DIDs.