- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 25 Feb 2026 10:55:32 -0500
- To: Steve Capell <steve.capell@gmail.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On Tue, Feb 24, 2026 at 9:40 PM Steve Capell <steve.capell@gmail.com> wrote: > I’d like to confirm this this draft specification meets the design goals of what we call a DIA (digital identity anchor) in our UN standards - see here https://untp.unece.org/docs/specification/DigitalIdentityAnchor > I think it probably does but I also note a rather fundamental difference in conceptual architecture Oh interesting, I was unaware of this particular page in the UNTP work (even though I recall you mentioning this multiple times over the years). Having read through the requirements just now, yes, I think the spec would meet the design goals of DIA, though I think we (the Verifiable Issuers/Verifiers group) should do a deep dive to understand exactly how these two things fit together. I created a tracking issue to make sure we do this work: https://github.com/w3c-ccg/verifiable-issuers-verifiers/issues/48 > BUT - that works nicely when that list of recognised entities is manageable in size and relatively slowly changing. However consider a business register such our national register in Australia. 2 million members and roughly 1000 changes per day. And we are only a mid sized economy Yes, you're right... and for that use case, the national register could provide a VerifiableRecognitionCredential directly to that business. The business, or anyone downstream in a supply chain process that has to prove that the business is recognized by the national register, could then turn around and provide that VerifiableRecognitionCredential to the verifier that needs to know that information. So, at a high level, I think it works and is compatible with DIA... but I hesitate to say it's a 1-to-1 mapping. There are some properties you have in DIA that aren't in the recognized entity credential. My hope is that we can mix the DIA stuff into a recognized entity credential (by just including the UNTP context, but that's what we need to make sure of in issue 48. > So no lists and no assumption that an authorised member has any direct relationship with a verifier Yes, those are core requirements for VerifiableRecognitionCredentials as well. > I “think” this draft specification might fit our needs - but I’m not sure I see the explicit credential subject ID (members did) and the link to registered identity (as known to the issuer that is the authoritative register) Yes, I think it might meet your needs as well, but does have the deficiencies you mention. Let's try to close those gaps in issue 48... or figure out if the two credentials serve different purposes. They feel really close to me, but the devils in the details. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Wednesday, 25 February 2026 15:56:14 UTC