– DRAFT –
DID Method Standardization

manu_: what is a DID Method?
… there are different methods that use various protocols, etc.
… there are over 200 DID methods
… some see that as a benefit
… others as a concern
… we'll talk about that today
… there are over 16 million people using DIDs today
… first up, BlueSky. It's a decentralized social network
… they have over 10 million DIDs deployed
… this caught us a bit by suprise
… but as people move from other networks to alternative options, that number continues to grow
… Next, is the TruAge program
… this is typically used in convenience stores
… there are several hundred thousand issued across the country
… they're used whenever an age verification is done with the TruAge application
… up to millions of times a day
… Next, CA CMV
… 600k+ have DID's with about 1.2k per day being added
… they use `did:key` and `did:web`
… Next, US Citizenship and Immigration Services
… they are readying `did:web` deployment with some features pulled into `did:tdw` to make things more trustworthy
… they've already confirmed they will be using DIDs and VCs
… for things like permanent residence cards, etc.

decentralgabe: Bhutan's National Digital Identity group is using `did:sov`
… this is a neat example of nation-wide adoption
… Next, EBSI, the European Blockchain
… member states can use the `did:ebsi` and individuals to use `did:key`
… this can be used across borders
… with the plan that these will be available to all Europeans as an identity option in the coming years.
… Next, Block, this is my company
… we're working to use `did:dht`, `did:web`, and `did:jwk`
… these will potential be used in Cash App, Square, etc.
… Here are some others: Privado ID, Dock, Cheqd, Walt.id
… this is a flurishing ecosystem
… we don't have specific data on these, but a rough estimate would be hundreds of thousands of transactions
… Here are a few more, Microsoft Entra, Trinsic, IOTA Identity Framework, and GLIEF
… Entra is used with LinkedIn for verified profiles

manu_: as we can see, DIDs are being adopted
… but, as ever, there are challenges
… why should we define methods at the W3C?
… many of these nation states and government orgs need SDO support
… others are looking for statements of adoption
… many W3C members are looking for at least a few being standardized
… and there are 200+ methods out there
… and would help the community to know the difference between ones with strong commitments, standards, and community vs. those that were just weekend projects
… the W3C Credentials Community Group and the Decentralized Identity Foundation and the IOTA Foundations have recently started an effort to promote standardization
… so there's wide support for this effort and they are also supporting active incubation of various methods

<bumblefudge> One DIF workstream worth mentioning to the uninitiated is the Identity and Discovery WG (informally the "DID Method Working Group") : https://identity.foundation/working-groups/identifiers-discovery.html

decentralgabe: we just did our first call last week and there is huge interest

<bumblefudge> lots of history of did method design and assessment/evaluation there going back 5 years

decentralgabe: we're working on determining categories of use
… we're not here to gate keep

<bumblefudge> (including the DID Traits work item)

decentralgabe: but we do need to start promoting the ones that want to be standardized and help them to a different level of usability
… W3C, DIF, etc. are all great options for getting these standardized
… there are ephemeral DID methods
… there are DNS dependent ones like `did:web`
… and truly decentralized ones like `did:dht` and those that use blockchains

manu_: today we'd like to hear from the room about what would be wanted in terms of requirements for this standardization process, etc.
… so, `did:web` is one that we might standardize here because it's webby
… but the ephemeral methods like `did:key` don't take much standardization
… but then there are harder ones like "what does a truly decentralized did method look like?"
… should it use a blockchain?
… blockchains have not received a warm reception at the W3C
… and then there are all the various methods that have a wide range of deployment and use numbers
… we're also looking for what things folks might object to?

<bumblefudge> https://identity.foundation/did-traits/

<KevinDean> 1+

Mike Jones: in the DID WG from earlier, we could not get consensus for chartering for DID methods
… so, I'd love to see it happen now
… but why do we think we can get it through chartering this time when we couldn't before?

manu_: great question. The earlier objections were around that particular group holding that charter
… the feeling was that group must remain agnostic to the method creation
… and at that time those same members did and still do support a separate group from doing the method standardization
… the goal was to keep those separate
… which is what this approach now should address

KevinDean: when we started looking into VCs, DIDs came along for the ride at my company
… we went with `did:web` "for now" but want something more robust
… so if we're going to formally specifying DID methods, I'd like to see them kept simple
… prototyping is important, but support is key
… and I'm concerned we won't be able to provide that support
… DID Traits may help with exploration
… but we'll have to draw a line that doesn't tread on the toes of solution providers
… maybe a supplemental approach would be a certification process

bumblefudge: my question is in the spirit of fretting and worst-casing
… what is the timeline on the DID resolution spec?
… all the draft work still in progress seems like it may need to be complete before we do method standardization

manu_: so the DID WG was just rechartered
… we have 2 years on that charter
… but we need to go into feature freeze next january...so that's not a lot of time...maybe Q2 for a stable spec
… in the meantime, we need to incubate many of these methods
… which I expect to take at least that long
… so, the timelines seem to be aligning
… there is also work in interop exploration
… so we're not starting from scratch
… we're fairly far along from a standardization timeline

bumblefudge: so, one of the deliverables is the resolution spec?

manu_: yes

decentralgabe: yes. the FPWD for the resolution spec should be up in a couple weeks
… and it would be super helpful to have methods to test with

manu_: for those of you who don't know decentralgabe is one of our wonderful co-chairs

janina: my heads been spinning since I heard CA DMV was using this technology
… there's so much opportunity for A11Y here

<Zakim> rigo, you wanted to talk about digital product passports, gaia-x and IDSA

janina: we could capture so many needs in VC documents

manu_: agreed. great opportunities here

rigo: I think we cannot wait on someone else to do this work
… I was promoting the `did:web` at a meeting in the EU
… and someone pointed out the flaws of DNS
… and the risk of fraud that domains are so easily susceptible to
… if we don't standardize and describe these well, someone else will
… it definitely should be more than one method
… things like long term archiving I probably need a blockchain

<Zakim> manu_, you wanted to ask what combinations make sense? Fully decentralized has to be done?

rigo: but if I have short lived stuff, we may need something simpler and faster

manu_: to that point, if this new method WG were created, we may consider focusing on a web one and an ephemeral one...but what about a decentralized one?
… that is rather the point of DIDs.
… there's work going into `did:dht` for example
… so given the choice between one that does or does not have a decentralized, do people have thoughts on that?

rigo: just because the charter has it in there as a possibility doesn't mean they'll deliver on it
… and the WG would give a space for these to be explored
… and the group can deal with the "blockchains are great, please use mine."

manu_: so...if we put a blochchain DID method in scope, how do we think the membership will respond?

<bumblefudge> to speak to decentralized methods

manu_: last time bitcoin came up in an AC meeting...it did not go well [room laughs]
… the `did:dht` method isn't bitcoin or blockchain, so maybe it has a better chance
… or something like that may avoid these risks

bumblefudge: I don't like the framing of one HTTP, one ephemeral, and one decentralized method
… I don't think there's product land agreement on decentralization
… words like archival, temporary, heavy cryptographic
… those may be better
… it avoids the wiggly words that get away from us
… and words like "truly" don't help the conversation
… so maybe more technical terminology

rigo: yes. finding these words would be helpful for legal methods
… then you don't need the word decentralized...because often those end up being centralized anyway
… so this functional language seems much better

manu_: agreed

JakeJones: building off what bumblefudge just said, decentralized is just a buzzword...and is meaningless
… I'd just avoid the word and not try to define it

gkellogg: I'd support being generic
… my concerns around blockchain relate to literally boiling the ocean energetically
… we should layout that energy impact of these methods should be a real concern

<rigo> security, energy impact

manu_: so adding that as a concern?

gkellogg: yes. I think that was in the way in the past

<Zakim> manu_, you wanted to ask about government engagement.

manu_: some of these government groups are now participating in the W3C
… there are initiatives in the EU around EU individual identities
… but to date we have not really tried to get the EU Commission in to talk about their needs
… or other groups about their use of DIDs and VCs
… our CGs provide input into what the EU is doing
… but it ended up being pretty minimal
… as no one was confident it should be the part of the group to do that
… so...should that go into the charter?

<JakeJones> Just as a response to the energy cost of blockchains is something that was actually solved in the initial design of Bitcoin. If you grow the block size to accommodate more transactions per block, the energy cost actually decreases as usage increases with respect to Proof-of-Work blockchains

manu_: US and CA are engaging...but not the EU really

rigo: because it can't
… there is no group
… not that can do the liaison
… this current topic is a "new approach" legislation
… they write requirements, must be standardized, and then implemented

<gkellogg> Energy considerations may be needed to address pre-conceptions, if not actuality.

rigo: it must get to normalization
… we've done this in the past around accessiblity

manu_: so the most we could do is a liaison relationship?

decentralgabe: I wanted to +1 bumblefudge around the need for clearer definitions which may relate do Traits

bigbluehat: an interest group for observers has served well for aggregating business/gvt concerns into notes that WGs can use, we have precedent for that in other spaces, good place to hear out the use cases

<bumblefudge> comment on europe's priorities for EUDI-ARF -- i think that project is a rough/approximate match to the goals of DIDs-- it might be an input to the specifically "non-repudiable" or "legal-grade controller document" use case, but not to DIDs in general

kaz: I'm doing a session later today
… and group conversations also include government interests
… this group should also think about global government concerns, not just EU

manu_: this is the wrong question...but what countries? [lots of laughs]

rigo: we have a process for that
… the cool thing is that we're moving from single DID method focus to functional need conversations
… and as we continue that, it will have magnetic power
… people will then work to connect and liaison
… and we should bring in folks we already know are in this area
… and we could even ask the AB
… but it's a process over time

kaz: at this moment, I'd suggest that we start with several key countries and organizations
… and note that it is not an exhaustive list

manu_: we have 5 minutes left
… any other thoughts?

manu_: it seems like there is support for doing method standardization at the W3C
… if we standardize them here, we should focus on traits, features, and functionalities
… and we should also make sure that we have a handful of existing methods--not starting from scratch
… I also heard we should lean headily on W3C liaison work
… and potentially using an Interest Group could be of interest for that
… anything else?

<bumblefudge> on the energy-intensitivity question, i don't think we can be completely mute on the subject (some stakeholders might object), but i also think we can't draw a line in the sand-- relative terms like "compute intensivity" or "compute per DID" are more useful than general/architectural biases like "anything that uses a consensus mechanism will burn

<bumblefudge> too much carboN"

Mike Jones: do you intend to list candidate DID methods?

<bumblefudge> we can get sidetracked in energy measurability debates as easily as we get sidetracked in decentralization definitions

manu_: I don't know...it feels risky for those methods

Mike Jones: then the first thing the group has to decide is which methods

manu_: yes. definitely
… look for a charter announcement in the coming months