Meeting minutes
decentra_: Welcome everyone, glad to see everyone. We're going to start out with some administrative items.
burn: We have the slides up, you can get to the deck via the tiny url provided.
burn: Slide are https://
burn: This group abides by the W3C Patent Policy, please understand what that means.
burn: This is a W3C Member meeting, the rules are for all of our protection. There is a link to participants in the group. If you are not on the list, please don't make substantive contributions.
<rigo> list of participants https://
burn: We do welcome everyone to listen and chat with people
burn: Code of Conduct - very important, been participating in W3C for 25 years - this is about being kind/respectful, everyone has a voice and all of he voices are important.
burn: We're all here to help broader adoption of technology, everyone is an expert, biggest surprise as a young engineer was other people that disagree are some of smartest people at their companies. Important that everyone has an opportunity to speak. If queue is long, keep comments short.
burn: Please be brief, make sure everyone has time to speak.
burn: Please join IRC and do present+
burn: Use this link to join if you are a member: https://
burn: We will need scribes, please sign up to scribe, even if you've never done it before.
burn: sign up to the scribe sheet. We're happy to help. Queuing is important.
burn: we still need someone after lunch today. If you are not a morning person, then just after lunch is probably good.
… important to look at the agenda to know when it make sense to scribe
burn: we have scribes for today
… it makes a big difference to have scribes, and it is really valuable
… moving on
… introductions. We have lots of people here, keep it brief. Give your name, organization, and (current) favorite movie
burn: 5th element clip in the slides
decentra_: Gabe Cohen, work at Block, Dr Strangelove
Wip: Will Abramson, Legendary Requirements and Digital Contract Design, Book: Three Body Problem
shigeya: Shigeya, Keio University, Originator Profile CIP also, Inception
laurens: Flander goverment, Dune
Big leboski
rigo: W3C, favorite movie, Hitchhikers guide to the galaxy
hyojin_: ministry of digital affairs taiwan, independence day
denkeni: ministry of digital affairs taiwan, independence day, the matrix
<denkeni> Hi~
Jay: Jay, W3C,
bigbluehat: Digital Bazaar, MAd MAx
dezell: David Ezell, Connexxus, Amadeus
I missed one in there
<drummond> Great quote!
ChristopherA: Christopher Allen, Breaking Bad
<burn> David's quote from the book about Amadeus: "I received way too much money for the things I did, and not nearly enough for what I could have done."
<drummond> Love it!
brent: Brent Zundel, mesur.io, The Man Who Killed Hitler and then the Bigfoot
<dezell> H.C. Robbins Landon: "Mozart's Last Year"
selfissued: Mike Jones, Independent, Blazing Saddles.
JennieM: Digital Contract Design: Waking Ned Devine
kdean: LEgendary Requirements, Groundhog day
ericaconnell: LEgendary Requirements
<ericaconnell> Ada Palmer: Terra Ignota (series)
JoeA: LEgendary Requirements,
Dan Pape, with Digital Contract Design
manu: Digital Bazaar, Spirit of the Wind
dmitriz: Digital Bazaar?, Children of Men, also recommends The Fall
someone form Singapore: loves Godzilla
Yung Lo: Singapore, Shogun
<dmitriz> dmitriz - is Invited Expert, but mostly on behalf of MIT's Digital Credentials Consortium
Kay: Singapore, the Matrix
robert: Agriculture, Murder ont he Orient Express
shoe: Legendary Requirements,
missed another
Zach: Google, Mighty Ducks 2
Ian: Google, Butterfly Effect
PaulZ: Connexxuss, Big Short
mandy: Digital Bazaar, Jurassic PArk
ericS: Intel, There's Something about MAry
IsaacF: Intel, Back to the Future
missed another
greg: Independent, Hellboy
Kyle: Singapore, Inception
Shyue: Singapore, Parasite
Calvin: Singapore, John Wick
SamG: Google, Everything Everywhere All at Once
morimori: Bottle Shock?
burn: what a great group today, we're glad to have you
<RYKay> Kay: IMDA Singapore, Matrix I
Wip: online people?
<Mirja> Mirja, Ericsson
burn: right, please queue
drummond: Can you hear me? Drummond Reed, Director of Trust services at Gen, One Flew Over the Cuckoo's Next
dlongley: Dave Longley, Digital Bazaar, favorite christmas movie is Die Hard
TallTed: Ted Thibodeau, OpenLink Software, Men in Black, Blues Brothers, The Hunger
markus_sabadello: Danube Tech, Whale Rider
<drummond> I am truly bummed about not being able to attend in person as I'd love to have dinner and talk DIDs with all these new DID WG members.
burn: Dinner, customary for us to gather for the evening. We'll get a rough count this morning, then find some options, then just after lunch we will confirm. It is self pay.
burn: We have a booking for Savor Stone for 14 people, we'll see if that's enough.
… also have some recommendations from Erica on the slide
ChristopherA: There's a food court with 7-8 restaurants a couple blocks away
… are these there?
burn: usually better to not do those.
… please raise your hand if you think you can join for dinner
… all three chairs can count
… please keep your hands up
… "silent, intense, counting ensues"
… okay, roughly 35
… after lunch we'll choose a place, any questions?
<morimori> I'll miss you guys at the dinner. Have a previous appointment...
burn: last question before real meeting: Open Topics, have any?
… write suggestions on the slide
… thank you, now we can get started
decentra_: State of the Industry followed by A Short History of DIDs, then a break
State of the Industry (Manu, Gabe)
State of the Industry
manu_: Here's what the community responded with:
… We are in production, things are exciting
… summaries are on the slides where DIDs are being used
<drummond> I’m a Bluesky user! @drummondreed.bsky.social
manu_: Bluesky networking protocol. They utilize DIDs, core identifier in the system.
<drummond> I met with a Bluesky architect here in Seattle last week to discuss the did:plc method & their plans.
manu_: They've been exploding in popularity. The potential here is that as they grow they will have a more decentralized DID Method
<JoeAndrieu> https://
<JoeAndrieu> https://
manu_: TruAge, Connexxus standardized this DID Method. Single use creds with DIDs. Several 100,000 people involved. Big potentiall.
… California DMV uses DIDs did:jwk and did:web, 100,000 DIDs added per day. ID Card and Drivers Licenses
… US DHS, committed to using did:web, also looking into did:tdw. Requirements are published, 43 million potential people
decentra_: Switchcord, help with DRM, artists can control their own music. Using DIDs
… did.ebsi used for legal entities and did.key for individuals, potentially all europeans
… Bhutan National Digital Identity
<drummond> I'm headed to the Bhutan Innovation Forum — https://
decentra_: Velocity network, uses did.ion for organizations, over 1M credentials issued
<drummond> Velocity Network is one of the founders of the Global Acceptance Network (GAN). https://
decentra_: TBD, business unit at Block, KYC and KYB, did.dht, did.web, up to #M dids registered
… and more slide, Privado, Dock and Cheqd (recent merge), wait.ID
… MSFT Entra - did.web, Trinsic, IOTA, GLEIF - 2.7M legal entity identifiers
… there's even more not on the slides
manu_: challenges - lots of use in production
… no standardized DID Methods, governments need those
… We've let a thousand flowers bloom, let's see what can be standardized
… pushback on DIDs in the EU, then push back on those. Still some hearts and minds to convice.
… did.web has huge deployments but is lacking major features
… why isn't there a standardized decentralized DID Method?
<drummond> +1 to the DID Methods WG charter
manu_: possible a DID Methods charter at the W3C. People want more vetting of DID Methods, standardized, safer for governments and large organizations to deploy
<Zakim> Wip, you wanted to ask if users are aware they have a DID in these deployments
wip: are users aware they are using DIDs?
<Zakim> rigo, you wanted to tell more about EBSI
manu_: mostlty under the hood
rigo: surprised to hear about pushback in EU
… we need archives when a domain name goes away. Don't want to rely on domain names. We need to look at why pushback. Many blockchains vendors came and said use ours, then you are locked in. The entire track and trace story will go DID
<drummond> This is the whole case for self-certifying identifiers (SCIDs) as DIDs.
A brief history of DIDs (Drummond)
drummond: using some of the same slides as before
… timeline slide, check it out
… thankfully now we don't need to teach folks the core concepts
… Where did DID come from? From the Credentials Community Group
… Dave Longley is responsible for the term.
<dlongley> DIDs evolved from WebID, coined "DID" in 2014
manu_: the concept wasn't new, at some point the poeple interested all over found each other and we wrote stuff down
<dezell> q_
drummond: I remember thinking: I would never have thought of callling it that
… the identifier Markus and I were working on were very similar
… Anil John and the US DHS was behind the funding of the first DID spec.
… Four Reasons slide: Peristnet identifier, resolvable, cryptographically verifiable, decentralized
… did.web is the crack cocaine of DID Methods
… really easy to get on and really dangerous
… Originally had to show what DIDs looked like
… same pattern as URNs
… When we started in 2019, there were 32 DID Methods
… currently 198 registered methods
JoeAndrieu: I know of several that aren't registered, so "over 200" is accurate
drummond: OrgBook in BC and Ontario also uses DIDs and is still around
… full history URL in slide
… those are the original slides from 2019
… there's an update: We wrote a book "Self Sovereign Identity"
… a DID is a digital control point
… we really wanted to get to control. The control point for email identifier is the server.
… domain names - control point is the registry
… control point for DIDs is your own device.
… whether person, organization entity, whoever has the private keys
<shigeya> I'm keep thinking about DID as a way for controlled indirection. Fully agree with the discussion.
drummond: Cryptographic triangle of DIDs: private key for control, public keys can be rotated, identifier doesn't need to change.
… DIDs are the innovation that democratizes cryptography so that everyone can use it
burn: quick comment
… please don't change the slides or the agenda
<ChristopherA> [beyond my 2015 seminal article on SSI I have a follow up at https://
dezell: I used the wrong term once, what was the term I used?
manu_: Probably IDENTITY
burn: extremely important: identifiers not identity
… also verifiable credentials, not claims
dezell: decentralized identifiers is a very good term, that was hard fought
<drummond> Links from the "History of DIDs" presentation: first one is the Decentralized Key Management Service paper funded by the U.S. Department of Homeland Security: http://
<drummond> Second one is the Rebooting the Web of Trust paper on DIDs that goes into much more history: https://
manu_: worth pointing out where things have changes. Identity was a lightning rod. We wanted to be very specific with DIDs and VCs, stayed away from identity
<TallTed> also, "distributed" was often spoken instead of "decentralized"
manu_: today there's the digital credential API, FedCM, we can talk about identity on the web.
<TallTed> that was part of what led to the rubric
manu_: there was fear about turning the web into a "papers please" environment.
… Identity was a dirty word back then, still dangerous today
ChristopherA: Manu captured why we focused on identifiers. I think the other thing is that we massively discount identifiers in general as a centralization tool. It is a powerful thing. It doesn't have to be able people, maybe access to the twitter API. A lot of the early discussiuons were about access. Centralized access can be taken away. We need
to keep thinking about that.
… most of our applications are in relatively friendly places. Right-wing governments are taking over in Europe.
<Zakim> JoeAndrieu, you wanted to ask how many identity engineers does it take to change a lightbulb? and to mention separation of control over identifiers from attributes about subjects
<TallTed> the Rubric -- https://
JoeAndrieu: How many identity engineers does it take to change a lightbulb? Define Lightbulb
… DIDs were a way to seperate the identifiers for the subjest form the claims about those subjects
TallTed
TallTed: one common error was to call a decentralized identifier a distributed identitifer.
… There is also a DID Rubric. many axes upon which DIDs can be evaluated, including how centralized it is. Many could still be added
manu_: adding to that. We had a general feeling, anti-centralization, should we allow DID Methods that are centralized, like did.web?
… which was good, because most initial deployments from governments use did.web as a first step toward true decentralization
… Ted makes an excellent point. we've been trying to thread the needle for years, we're seeing adoption because we weren't absolutists
markus_sabadello: I remember talking about how decentralized we want DIDs to be. Even if we have centralized and decentralized methods, have a common resolution mechanism is also decaentralized.
<ChristopherA> Did:Facebook was submitted about same time as did:web
<dlongley> +1 to *enabling* decentralization, not forcing it (as if this could even be done)
decentra_: come back in 30 minutes
burn: on time is 5 minutes before
Kim: I will be presenting what we presented at the DIF DID kick-off
… earlier in the summer, W3C, DIF, and others presented a letter of intent
… around DID method standardization
… we noticed push back around lack of standardization
… so we went lookin for ways to help
… to support DIDs you don't have to support all of the methods
… but not everyone knows that
… so in this letter of intent, we wanted to focus on 3 categories
… ephimeral
… decentralized
… web-based
… We want to explore these in a collaborative way
… One workstream is a DIF working group
… Another is a potential W3C WG
… as well as broader community engagement
… Let's talk more about what the DIF DID Method will be doing
… we'll be working with several orgs to identify which methods we want to standardize
… then develop them further
… and lastly get them standardized at a standardizing body
… most likely the W3C
… which is the hope of having a W3C WG
… We'll be working on criteria of selection
… This DIF WG will also be contributing to the selected SDO
… so did:web and did:tdw would go to the W3C for example
… However, we want to be careful that this not be seen as an "approved list"
… But we do want to help selection of methods around maturity, testing, traits, etc.
… Our goal is having more mature standards for methods
… We use the W3C License at DIF, which we expect will help move things forward
… to participate at DIF, you just have to be part of a member organization
… Most of the work happens on GitHub, possibly a mailing list, and regular meetings.
… We use consensus based decision making
… So, some more context around DIF and this collaboration
… We think this is tremendously important and the W3C will play a key role
… This is not a real estate grab, we're looking for collaborators.
Gabe: more participation the better
… we hope to make a path and prove it out and encourage more methods to follow this path
manu: +1 to that
… not all DID methods need to be done at the W3C, but there are a few that do make sense to do them here
… did:web, did:tdw
… and maybe others
… so one question is what are the requirements for which methods might be chosen for standardization here at the W3C
Gabe: we want to hear folks around which SDO's would help them in their selection
… we know that can be a deciding factor
Kim: any questions?
manu: there are specific DID methods in production not such as did:web and did:jwk and we'd love to see those considered for this process
… but do we need to see deployments before we consider them?
… because some governments, especially, need standardization before they will use it
… BlueSky uses did:plc and have great documentation
… did:dht is another that's deployed at Square with more than 3 million DIDs
<Zakim> JoeAndrieu, you wanted to say incubating at DIF and standardizing at W3C seems like a good idea
manu: are those good to standardize? and if so, where?
JoeAndrieu: I like this effort from DIF
<drummond> +1 to the whole effort to standardize DID methods
JoeAndrieu: I do think seeing these incubate and then figure out how to bring them into the process
… and incubation first would then help us get there
… I think incubation specifically needs to happen outside the standardization process
… which is why I think this DIF approach is good
ChristopherA: we'll be talking later today about some more of this and the problems related
… one of my proposals would be expiration dates on specs
… we have 30 minutes scheduled for this later today
… We also have signing methods to consider
… we have ssh keys working with DIDs as a method extension
… but SSH happens at the IETF
<Zakim> manu_, you wanted to note antipatterns that we want to avoid (broad DID Method incubation in a W3C WG)
ChristopherA: so DIF may help us bridge that SDO combo
manu_: there are some anti-patterns we avoid
… one thing in place to prevent those is DIF is curating the incubation process and prep it for coming to the W3C
… and the work at the W3C would be temporary and aimed at getting these done
… we also think that doing this only at the W3C would be a bad outcome
… but we have some expectations to set properly there
… we also have what we're calling DID Traits
… so discussing these across the organizations will be important but we're still exploring how/where those move toward standardization
Gabe: we have to wrap this topic up, but there's more on Wednesday from 10-11
… Kevin you're up next
Self-describing DID Methods — Kevin Dean
KevinDean: DID Method names are not guaranteed to be unique
… that's by design to support decentralization
… there are mitigations through DID extension registration
… there's also a lack of version control
… and if there's a security issue, you may have to scrap the entire method
… we could look to put version numbers in the names...but that's not standard either
… How can we avoid collision?
… Security. We'd like them to be validatable
… Versioning. We need this.
… If I have a v1.0, it should be possible to advertise upgrades be it v1.1 or v2
… and the consumer should have the option to choose
… none of this would be a requirement, but made available
… Semantic Versioning is a preferred approach
… what would that mean for DID methods?
… there should be a versioning chain for moving among them
… graphically, it looks like this (room laughs at slides)
… blue lines show compatibility breaks
… red lines denote versions that should be usable without modification
… How do we generate method names?
… randomization
<TallTed> how is 1.0.0 supposed to know that 1.8.0, 2.1.0, 8.0.0 will eventually exist?
KevinDean: we could use random numbers, or UUIDs, or a hash of some document
… we could use the DID Method spec for that method
… so, assuming we go that route, we can do a Multihash in base36 to keep them short...but they're still rather long
… Advertising the versions, though, may be harder
… from the point of view of the issuer, before I go an issue a DID, I may want to confirm I'm using the latest version
… from the point of view of the verifier, and it comes across something it doesn't recognize how does it ask if it's valid?
… if I get a DID that says it's v1.1.0, I may want to follow the version change that gets me to the earlier version that I do understand such as v1.0.0
… More of this is described in the document, but the basic goal is providing understanding of the versions
… We could do this through metadata in the documents or via a service
… The service aligns more closely to things that change overtime
<TallTed> Is the idea to dereference the DID URL of a DID Method, and what it returns (is it a DID Document?) will include the DID URLs and version IDs of all extant versions, as of the time of dereferencing?
KevinDean: Implementation. If we use a hash of the specification, then we cannot use that hash in the spec itself
… what we can do, though, is a generic statement about how to generate the hash
… that is enough for consistent hash creation
… we also want a DID representing the Method itself
… if you want a DID that can advertise it as a version of itself, then there needs to be some base hash to build up from and relate back to
… A couple of options for this is to add it to the DID Core spec...which we cannot do because it is a Class 4 change
… We could, however, do this via other means
… For example, let's say we have a Bitcoin based method
… We put the following text into the spec that says `did:method-name:{hash}`
… and publish a DID document that explains it is the base version
… then at anytime, someone can find the derivative versions
… There are a variety of scenarios put forward
… we have questions around minor versions, major versions, and other scenarios
… There's a QR code on screen to get to the repo that describes this work
<bumblefudge1> LegReq/
<Zakim> brent, you wanted to comment on "computers don't care"
brent: you said computers don't care, but sometimes they do, especially about space
<Zakim> ChristopherA, you wanted to talk to history
KevinDean: but we could do compression if needed
ChristopherA: there was a lot of controversy about this early on
<dlongley> very interesting presentation
ChristopherA: when we did the easy identifying route, the IPFS guy left when we didn't choose a route similar to KevinDean's presentation
… at the time he wanted them to be completely random
… people do route around this by padding the data like sticking "IBM" in the hash
… or generating Bitcoin addresses that actually contain company names
… the thing method approvals need to look for are moral problems, trademarks, etc.--at least according to the rules
KevinDean: that's true for the registry, but you don't have to register these at all
… and depending on your use case, registration is optional
markus_sabadello: I think this versioning of DID methods is very interesting
… whether we use metadata or service endpoints will be interesting to discuss
… do existing methods need to change?
… one thought, if you resolve a DID, you get the DID, but you could use resolution options stating what version you were wanting and that could ask the resolver to use a different version
KevinDean: and the existence of the version doesn't require an upgrade
… it's really up to the users
… it's more about knowing about the options
<Zakim> JoeAndrieu, you wanted to ask how you control who can publish an update?
JoeAndrieu: I was curious how you secure the updates
… can anyone publish the updates
KevinDean: whoever controls the DID for the core method
… and how we do that is TBD
<Zakim> denkeni, you wanted to comment of method naming: human & machine readable
JoeAndrieu: ah, so maybe the core spec could have a DID in it which makes that part of the base hash
KevinDean: yes.
denkeni: we care about method naming to be human readable
… the way moving forward could be to keep the method name for humans
… but to also use the hash to avoid collisions
KevinDean: but we may run out of meaningful name
denkeni: in ObjectiveC they use very long method names to keep things readable
… but we will need a naming space to confirm it's working correctly
… I think both should be kept and used together
KevinDean: yes. I'm not suggesting this replace how we do what we do
… it's just putting an option out there for naming and version control
… that prevents collision
Wip: that was a great discussion and we will have other places we can discuss
Gabe: and there are several places we can develop these further
Gabe: k. now we're looking at a new did method
… we don't think there will ever be just one did method
… did:jwk and did:web have their limitations
… but others have more flexibilty
… we were using did:ion
… but we had some edge cases
… there was incompatibility and some questions around is this really decentralized
… and the answer is, no it's not
… everyone has to run side-tree nodes
… and not everyone does that
… did:orb tried to address some of these problems
… Enter did:dht
… we were talking to a community member who was using the bittorrent dht
… but it wasn't using DIDs
… so we began to explore these together
… A DHT is a way to store things to avoid collision
… Kademlia paper describes one option, IPFS has another
… BitTorrent has been around for over 20 years
… in addition to being used for questionable things, it's also used by many large companies in and out of these companies and government organziations
… There are often arguments against using blockchains
… but BitTorrent and DHT are already in use in these same companies
… so, what is did:dht
… It supports most necessary feature
… we have some built in anti-spam measures
… there are signed payloads
… also DHT records expire every two hours or so
… spamming can happen to keep content online
… gateways can help here
… we are exploring a way to do gateway discovery via Bitcoin
… Interestingly, there's a chance for compatibility for single-key methods
… There are some default key types, but you can use others
… that ties back to did:jwk and did:key
… you could tie other things to those and look up more information via did:dht
… there was some talk of naming and how to address human readable names
… or you could do proof of work efforts to keep your name at the top of the list
… it does require compute power, but not money to stay at the top of the list for using that name
… We initially started with DNS, but now looking to move to CBOR
… we'd love more help with CBOR
… we're able to support pretty large things, so not as restrictive as you might think
… we're running this at TBD with 3 million+ DIDs
… we do auto-refresh the names on our gateway
… we also hade open source clients
… and now we're using Rust which allows binding to other languages
… we'd love more contributions
… We started in Q4 2023
… this year, we're working on a more production ready deployment
… we're also hoping to pursue this via the standardization process, get it into the universal resolver, and decentralize it further by reducing the gateway dependence
… There hasn't yet been a perfect did method
… this one may have a chance at wide adoption though, we hope
manu_: +1 I think this does address many of the problems that have plagued the more decentralized methods
… the main question I have is around using the old Ed25519 key
… given it's not quantum safe
… so if we look at timeline, that puts us at 2029 or maybe 2027...and then we'll hit that moment and people will ask about other key types
Gabe: good thought, I had the same one
… I raised it with BitTorrent folks and they didn't care
… we could explore a post-quantum ready DHT, but didn't find one
… but definitely something we'd like to explore
dmitriz: how much room do we have to play with
Gabe: 32 bytes? so... a bunch
ChristopherA: we've been exploring similar topics
… with dCBOR addresses some of that
… yes, someone might corrupt your root document
… but the history of them that use a hash chain or hash tree might buy you some time
… they don't care because they don't believe they need it
Gabe: yeah, we do have information on that topic, but it does need more discussion
<dlongley> i think having a timestamp you can trust into the future helps with transitioning to PQ-safe crypto
bengo: there do seem to be some issues, what do you think about putting bounty funds on a DHT and see if someone can break it
<bumblefudge1> bengo
<bumblefudge1> should be in the identity map
JoeAndrieu: we've continued the work around what's next in the bitcoin reference method
… like...the delay before being able to use a BTCR
… several did methods had some better features, and we wanted to learn from those
… there was no offline creation
… every did required a bitcoin transaction, so that could get expensive
… there were issues around privacy
… I used to feel like private did documents were too much trouble, but I've come around on that
… we also wanted to explore resolution scope
… bitcoin based ones typically have to check everything
… we've worked to reduce that
… we also looked into delegating things via zcaps
… our key things were: Beacons, zCaps, Guaranteed Invariant Provenance, and Sidecar
… Beacons let the publisher tell the reader what they can look at next
… we use zCaps which allow authority delegation via a JSON-LD format
… one issue with did:ion was separation from the data record, but we have a solution to that
… Sidecar allows for did history sharing privately.
… Beacons are represented as a service endpoint on bitcoin to be watched for spends
<rigo> I find it interesting that we already start to combine DIDs with Linked data features like DCAT. I think there will be even greater use of semantics in the near future
JoeAndrieu: those spends are guaranteed to be signed by the did controller
… in every did, you can put any number of beacons and beacons can be related to any number of dids
… it's not a network of priveledged parties
… we already use zcaps for did updates
… we looked at ucan, but it's based on jwts and we were already using Data Integrity so we went with zCaps
… for the Guaranteed Invariant Provenance
… once you have Beacons, you can check all the Beacons when it is part of the did document
… I do need a visualization of this in a graph...
… all the updates are versioned
… if you get a conflict, then the did is invalid
… but since they're all signed, then I can prevent anyone else from making changes
… The update is on chain, but the content of the update is private
… We have some suggestions we want to get into DID Core
… we also want a resolution related improvement to help with sidecars
… I had some confusion around zcaps which we need help with
… This work is in a public repo
… The spec is not short
… but it's a year+ of work
… there are some edge cases we had to pin down
… so, we've worked hard to tease out those hard parts
… Will, Jenny, and Dan and others have really helped this work move forward
decentra_: isn't there concern of rouge agents and Beacons?
JoeAndrieu: there are two signing ceremonies
… one on the signal--that's the spend--it's signed by the controller who participated in creating the address
… there are no privileged aggregators
… a cohort of the people who are going to interact with the aggregator share keys that they will use
… so unless my keys are compromised everyone else in the cohort could prevent the write by ignoring the write
… and if that doesn't happen that write will be dead
KevinDean: the Beacon and the did keys are completely separate
JoeAndrieu: right. you're signing the zcap
… that is signed by the did key
… what goes on the blockchain is from a different key
… One best practice is to always have a Beacon you can always update by yourself
<Zakim> manu_, you wanted to ask about next steps?
JoeAndrieu: it provides resilience when and if your cohort fails to do it's part
manu_: how ready is this?
JoeAndrieu: I think it's close. Will?
Will: it's complicated
… I have an implementation in Jupyter
… there are parts of it that are simple
JoeAndrieu: you can read that notebook to understand the aggregation
… we do want to pin down the protocol though
markus_sabadello: so, JoeAndrieu you said you have some suggestions for did resolution
… do you see this sidecar thing to be useful across did methods?
JoeAndrieu: not sure
… the update history could be useful, but I'm not confident it would be consistent enough
… one may start without sidecar data
<dlongley> the use of zcaps in this way is also something that has been looked at for more privacy-preserving VCs, where the "issuer" is one of many in a group/consortium.
JoeAndrieu: the resolver will sometimes discover that the sidecar is missing...and then ask for more info
… that's a loop we haven't figured out
ChristopherA: one of the issues of the resolution mechanism is relatively one pass
… this system may have several back and forth conversations
… so lots of trips to the resolver
… I call this progressive trust
… it's likely we'll see more and more of this pattern
… taproot is the latest version of bitcoin. it supports the latest schnorrr
… we had a big Frost implementers meeting
… there is already a 15k party independent device federation
… it can have up to 500 adversaries
… there are smaller things like Roast that can be combined with Frost
… so you can increase the number of adversaries
<Zakim> Wip, you wanted to comment on generalization of beacons
burn: more discussion with ChristopherA during the break
Wip: Beacons is probably the most reusable thing in this spec
… we have 3 different types
… there are several parts of this that could be broadly useful
burn: now. lunch!
… when we come back we'll discuss dinner
… please raise any concerns
… also, we need an exact count
… we'll take the info we get and do our best
… be sure to be back here by 1:20
The group is reconvening after lunch.
burn lists options for dinner.
Dinner is 6:45pm at Savor Stone Hearth Pizza and Wine. Meeting in lobby at 6:30pm.
WG is on slide 98.
decentralgabe: Want to work through work items in charter.
decentralgabe: DID Spec Registries, rubric, cbor representation, implementation guide, updated DID spec, DID Resolution which is our main deliverable. Notes and test suites.
decentralgabe: We want to make sure we're on top of all of these things.
decentralgabe: Where do we stand? Are there notes we want to discuss, interest in those thing? That sort of thing.
decentralgabe: The timing of the DID Resolution spec, chartered until 2026, we have a whole year to get things done. Healthy rythym of processing things. We have other work items we need to pay attention to
burn: We will get precise estimates, challenging discussions, this is helpful for people to see timeline.
burn: Jan 2025 is feature freeze, Aug 2025 is CR1.. and so on
<Zakim> ChristopherA, you wanted to comment on CBOR
ChristopherA: The description was "a plain CBOR representation" -- not a CBOR-LD or something of that nature. Is that a correct assumption?
decentralgabe: It's written open ended.
ChristopherA: We have a lot of experience w/ CBOR, dCBOR and CDE... what's happened is that CBOR is loose enough wrt. challenges to determacy... how to make CBOR deterministic - we tried to do original spec, submitted to CBOR WG, accepted changes w/ one question.
ChristopherA: Has to do with representation of numbers... in dCBOR, all numbers are normalized... no negative zeros, no 0.000, etc.
ChristopherA: Normalization of numbers and ASCII text to a single unicode standard.
decentralgabe: We have time to discuss this tomorrow.
ChristopherA: If there is no one else here that cares, decision of choices to make, don't want to do this by myself?
burn: Let's discuss this tomorrow?
ChristopherA: When does this need to happen, according to this slide?
burn: This timeline is for main spec, people interested in the work, not something driven by Chairs to ensure completion.
decentralgabe: Start if there is interest, definitely finish by end of the year.
ChristopherA: If there are changes in WD and CR1, we need to reflect that.
<Zakim> Wip, you wanted to add that we still need to publish a FPWG for did-resolution
decentralgabe: Back in the DID Core spec? Let's talk about that in detail.
Wip: We should also publish a FPWD.
(of resolution)
<markus_sabadello> https://
markus_sabadello: I think I created a FPWD, link in chat, we haven't voted on it yet.
decentralgabe: We have time, let's make sure it gets proposed and resolved.
decentralgabe: If you want to work on these items, take it upon yourself to do that.
Wip: Jan 2025 is not very long away.
decentralgabe: We can push that, up to us.
decentralgabe: Let's get big rocks identified, work on them for DID Resolution... for other deliverables, get WDs delivered, for notes, let's get them updated.
DID Registry Process
ChristopherA: DID Registration process... tension going back to 2016, avoid name colisions vs. risk of centralization of decentralization protocol, no easy solutions. Go with lowest weight centralized process we could do.
ChristopherA: In CCG and DID WG, we said DID names would be first come, first serve, delegated to CCG for a bit.
ChristopherA: Current method registry, key requirement, point to acceptable method spec.
ChristopherA: We have some requirements to not use trademarks, etc. Currently 198 methods registered, CCG has around a dozen people that were trained. Manu did the training for it, they've been reviewing and there is no baccklog at this point.
ChristopherA: That doesn't mean there aren't problematic entries, we don't have a process to fix these. How do we solve the small problems, what about the bigger problems? What if contact goes away.
ChristopherA: Link to spec is gone, ownership change, company legally changed names, other personnel changes. When specs are gone, point to archive.org? No process for version changes? btcr1/btcr2 what happens to old names?
ChristopherA: Some desire to expire names. Are there other problems?
<Zakim> decentralgabe, you wanted to ask about issues
JoeAndrieu: By spec we don't require unique names, but Editor's are requiring unique names.
decentralgabe: Are there issues that capture the issues raised here?
ChristopherA: Charter requires DID Method identifiers, resolution process identifiers, do we need to do a registry? Resolution process? Are any of DID Resolvers use Github?
<JoeAndrieu> Issue about name duplicates w3c/
ChristopherA: As a WG, thre is now a process for W3C registry... we wouldn't have to delegate to CCG? Does anyone have experience w/ W3C Registries? I'm not sure I'm comfortable going down that direction given we don't have onsensus on process to resolve current difficulties.
ChristopherA: There is a desire for things to be shorter -- reduce items in the list.
ChristopherA: We might want CCG maintain base method registry, already have people trained to do it, Joe has questions on this wrt. name collisions.
<decentralgabe> the web codecs groups has a registry -- https://
ChristopherA: Continue to work on minimal spec requirments, make it lightweight, avoid collisions w/ other DID Methods, simple policies to address problems. Any of these things in CCG are provisional of 1.5 years -- before end of period, new PR needs to be submitted to renew provisional for additional period.. Over time, if you haven't implemened, specs change, poof it goes away. That doesn't mean DID WG doesn't maintain additional lists -- don't want
to call them registries... they're lists.
ChristopherA: These 25 methods interop w/ DID Resolver test suite v1.1, not a registry, a list that parties have met requirements, DID Resolution, could do a variety of useful requirements... DID Methods that support minimal web based API standard.
ChristopherA: These additional lists are not registries are just a NOTE, our annotation for fit to various things we could test in this WG.
manu_: on "whether these things are W3C registries?" -- we are doing fine with the shape they are in. we have renamed them to 'DID Extensions' we don't say list or registry.
… should we make this a W3C registry under the W3C process ... I don't see a compelling reason for or against it
… how long should these things be provisional? 1.5 years seems reasonable. doing a pull request to update is workable. we are standardizing DID resolution in this group. could we add DID Resolution impls that are live?
… when you register the method, post a link to where the DID can be resolved
ChristopherA: I do like that, don't want that to be a collision source, informational source... is it another column in the current list?
KevinDean: What is the proposal for once it gets out of provisional state, there is an implemntation, ompanies behind them could abandon them... same issue? Do we maintain the entry regardless of status once it's deployed?
ChristopherA: I talked about this for a long time -- WG hasn't accepted it -- I believe everything should expire-- could be 7 years, a decade, TLS ciphersuites didn't expire, many millions/billions of dollars in losses. DID Methods need to expire as well. Everything should expire.
<Zakim> JoeAndrieu, you wanted to say about registries. we can't publish notes after the WG goes away, but registries can
<dlongley> +1 to expiry of all entries and the concept of requiring "active" status over time
JoeAndrieu: Two points that support W3C Registries mechanism, other resources, the main thing is registry has continuity and WG doesn't... who is managing what? When WG goes away, what happens?
JoeAndrieu: We couldn't update the Rubric, rgistries give us continuity that we don't have as a WG. This serves our responsibility to W3C... we have a working registry that has those features, we should lean into process. If there are things that don't work, we might be able to change it. I don't think we need to call it a registry to use that process.
decentralgabe: I love the idea to point to where to resolve a DID and concept of a registrar.
decentralgabe: I like the idea of a scorecard, privacy nutrition label, similar thing might work for DIDs -- DID Traits might be helpful as well, in favor of those updates.
decentralgabe: I'm not familiar w/ W3C Process, it might be useful to giving path to maintain after this group stops being chartered, extends beyond lifecycle of this group
<Zakim> manu_, you wanted to agree with "DID Method registrations should expire"
smccown: I like lists better than registries, term registry implies centralization, kinda hard these days, hot topic -- expiration benefits, if no one is paying attention it clears itself out... but what if people lose names they're registering. Are these reusable if you lose the registration? If I forget to re-up btcr, can someone else usurp and replace the name?
<decentralgabe> manu_: yes, you add a JSON file per DID method, which captures all information for the method. We can add additional data, like expiration data
<decentralgabe> ... we can dynamically have the webpage not list the method after the expiry date. easy to implement, but let's decide. +1 to the concept that registrations should expire and registrations should not be able to be taken over
<decentralgabe> ... if it gets past 'provisional' it is taken for the rest of time
<decentralgabe> ... unless the person who created the method chooses to cede control
markus_sabadello: Regarding well known resolver endpoint associated w/ DID Methods, I think that has pros and cons -- advantages as Christopher said, measure of maturity, can help w/ objective of practical interop, downsides are encouraging centralization, implementations might not do that -- call remote service, encourage view that's normal that DIDs get resolved through remote service vs. according to a DID Method.
markus_sabadello: For some DID Methods, might be hard to pick... what's official resolver for did:key -- did:web? If we want to introduce that, should allow multiple entries/endpoints not just controlled by author, anyone should be able to add a working endpoint for a DID Method.
ChristopherA: Specific to the resolution list, method developers don't create that list... people that write resolvers do... they list methods they support, that was my presumption. Who registers is different... could be 5 that supports BTCR, resolvers will have to deal w/ that not our responsibility
ChristopherA: Specific to resolvers list, might be worthwhile to turn it into W3C ongoing thing, see what we can do to figure out the process. Might be easy, but goes in front of AC, all of a suddent it's another 6 months and another bunch of headaches.
<burn> FYI we have rolled into the open DID Methods/Extensions conversation, which must end before 3 pm.
ChristopherA: If we do a resolution list and it's not a big deal, have list of 20 implementations of resolvers, win state, we know something. Do we want to change current delegation to CCG?
<Zakim> Wip, you wanted to discuss control over registration and update process
ChristopherA: If there is an expiration, takes thing off list or hides it, that's when it comes to our attention to decide what to do. We can use regular consensus processes to figure out how to recover. If they don't take action, tey can't complain that we didn't let them know.
Wip: If there is a DID Method and I rely on it as a business, expire processes, control, who gets to decide? There is management around that.
Wip: I like the resolver attesting to supporting specific DID Methods.
<Zakim> JoeAndrieu, you wanted to discuss robust continuity ala domains
JoeAndrieu: I like some of he points of the proposal quite a bit, as we consider what we do, wrt. deprecation. IANA cares about network staying alive vs. registrars, when domain is lost, you have a grace period.
<dlongley> +1 to "buffer / grace period"
JoeAndrieu: There are protections, removal from the network can be a hostile action.
JoeAndrieu: Points of centralization is a problem, if you don't ues endpoints, we need to be careful about connecting to services in the list. List of resolvers, +1, but to point to endpoints is dangerous idea.
ChristopherA: There are risks wrt what you're talking about... we need to be careful about those sorts of things. Presumed care.
ChristopherA: What happens when a method goes bad? I don't remember who registered btcr, what if they don't answer? Normally, we'd let Chairs decide, but sometimes you don't need to bring it to the group.
ChristopherA: As noted, this group ends in a period of time, what IANA does is assign a Designated Expert... IANA contacts experts, who punted for months, was frustrating unil it was approved.
ChristopherA: Maybe there are stewards for continuity of the network.
smccown: There is a tendency to think of DID methods like Web URLs, the counter example is to see how email is handled. You're not going to pick up a used email address if it goes away, there is so much sensitive information relied on for an email address, better or worse, 2FA comes through there. They don't get reused.
<Zakim> manu_, you wanted to mention problem w/ DEs.
smccown: Maybe we should think of DID Methods as identity sources.
<decentralgabe> manu_: let's add some designated experts to the process to maintain the registry. there can be problems there. this group tried to register a media type with two + in it which led us to a 5 year quest!
<decentralgabe> ... designated experts didn't know how to answer the question. part of me says we're over thinking this. not quite like a domain going away. we are trying to create a sense of freshness in the list.
<decentralgabe> ... if we are going to do something it would be good to do it early in the WG so that we're around to make modifications before we end and push that boat off to sea
<decentralgabe> ... let's enact some of these things quickly, provisionally, before the charter is closer to its end
hyojin_: I'm hyogin from LG Electronics -- in South Korea, we have DID method named did:wnn in terms of interop between Korea and other countires, would be nice to have layered DID Method - Have you considered hierarchical method.
<JoeAndrieu> EarthProgram/
<JoeAndrieu> wrong one
<JoeAndrieu> https://
<JoeAndrieu> did:omn
hyojin_: If we conider interop between koreans and driver's licenses an US driver's licenses, we should understand both DID Method semantics. If we provide single guideline for driver's license domain, in case of DID Method, we could easily consider them in the future.
ChristopherA: There are a lot of DID Methods now that have the Method name... you have to register the method name. It could be whatever you want, there are multiple DID Methods that can work.
ChristopherA: There are some people using hierarchy, american driver's license and korean driver's license, should an identifier have something to let you know. I think that's out of scope of where we are. You can do that if that's what's going to solve the problem. you could create a DID ffor that, it's not about mapping for DID Document. Not about core thing that we're doing here. No easy answer yet. Would like to explore more.
ChristopherA: I'll try to identify where problems are on current registry -- like what Joe said about goal -- simple statement: What is the goal: Goal is that when there are problems with the registry -- prserve the network
ChristopherA: Might be no objection consensus, 7 day period of resolution, dozen that we need to have some solutions for.
<Zakim> TallTed, you wanted to say that email addresses are not necessarily magically preserved or blocked from reuse
ChristopherA: Maybe Joe and I can work on a paragraph on that?
TallTed: A caution, we should look at this as email addresses -- email addresses don't have protections, some email providers might provide grace period, but my vanity domain doesn't offer me anything, if I lose domain, all email addresses go poof, all personal info, etc. go to new domain owner. It's a much bigger problem than what emails, can't rely on same protections for email.
JoeAndrieu: We did work on a method did:cosmos, don't know if that what y ou meant... cosmos takes over method name, any cosmos chain could register a sub did method that counter interpret chain.
<ChristopherA> @burn time check? I wanted to talk about ssh extension
<Zakim> manu_, you wanted to talk about priority of contituencies.
<decentralgabe> manu_: to follow up .. I don't think we have an example of any country that has tried to create a hierarchical DID method with another country. each country is sovereign and wants to be in some level of control. the idea that countries would work together ... I haven't seen that happen
<markus_sabadello> There's a short note in the spec about "establishing hierarchically partitioned namespaces": https://
<decentralgabe> ... I have seen the opposite -- countries picking their own methods. the methods they pick aren't hierarchical. they recognize methods other countries use ... but probably wouldn't work on a hierarchical method
<decentralgabe> ... it is a political problem, not a technical one. you could have a hierarchical method, but politically I do not see countries being able to succeed at doing that
<decentralgabe> ... there are groups like the EU which have their own blockchain services infra like the EBSI method in the EU. each nation runs their own node. the namespace is not hierarchical, but a shared namespace.
<decentralgabe> ... as Joe mentioned, we have looked at hierarchical methods, and layered methods, but it may be too politically difficult to succeed at scale
hyugin: If I had a DL specific DID Method, how could I search them?
<Zakim> ChristopherA, you wanted to talk about other extensions (not methods)
<Zakim> burn, you wanted to comment on semantics for DID methods
ChristopherA: Is there anyone else that wants to talk about methods?
burn: I head hierarchy, but I heard you say they're driver's license DIDs, requires semantic equivalence... well out of scope of what this group is going to do.
burn: Semantic equivalence is not light, at all.
<Zakim> Wip, you wanted to talk next steps
Wip: What are the next steps, agree with Manu, start soon. I also hear competing needs here -- DID Methods, extensions, don't want list to be centralized, commplexities... want management to be past lifecycle of the group.
ChristopherA: Unless there is other Methods conversations... DID Methods -- we recently reverse engineered how SSH and Git do signing, you no longer need to use PGP to sign commits/tags, you can detach sign using SSH keys, and there is a limited... Github supports it, limited key usage thing. Not supposed to use same keys for authn and signing, but implied key usage of keys for igning. Works great for Github, created DID Compatible thing using Git and
SSH keygen and bash, does everything ... DID Keys and rotation, o do this, requires current JWT signing, not sure requirements for adding those, SSH international standards, reference code for it... straight up text into object from SSH. Don't understand what requirements for this? Kyber?
ChristopherA: I don't have a feel for how we extend, what process do I follow, how do I add cyphersuite? International standard, implementation, what are the requirements?
<decentralgabe> manu_: we have more of a problem. the crypto suites are being worked on by the VCWG. we are putting things in the registry which are the specs that group is working on, and derived work from Data Integrity and VC JOSE COSE work items
<decentralgabe> ... what you are talking about is nice ... but without a home it is difficult. the cryptosuites we have in the DID registries (they're not current) ... we need to decide as a group what is that thing. it's where DI started, but it shifted to VCWG and we didn't update it
<decentralgabe> ... we need to figure out where that list needs to live. right now it's in the VCWG, but that doesn't answer Christopher's question. signing non-VC things.
<Zakim> JoeAndrieu, you wanted to say extensions must be reduced to practice with DIDs
<decentralgabe> ... there are an increasing number of people that want to sign audit logs and changes over time. it's something happening out in the market that we should pay attention to
JoeAndrieu: If it's not reduced to practice with DIDs, it shouldn't' go in our lists.
JoeAndrieu: There are thing that go in DID Methods, verification methods or services, if we reduce it to a type in DID Document, that deserved to go in the lilst. Is it there because it signs VCs, or is it to sign something else?
decentralgabe: There are thing like log formats, CBOR, maybe we should consider that as a NOTE?
<Zakim> Wip, you wanted to suggest registering it then we have to figure it out
Wip: Maybe Christopher, you want to register a Verification Method for SSH signing in a DID Document? What does that mean?
<markus_sabadello> https://
ChristopherA: I can create a PR, put keys in file in repo and when you extract them out, ou can make a DID Document out of it... assured by reading it, but Github will tell you it's correct. When I read the spec, not clear what the requirements are for adding it.
markus_sabadello: Regarding verification method, wouldn't be first time for verification method types... EthereumRecoveryMethod and VerifiableCondition2021, these are already in the xtension registry, not sure of criteria, but they were added before.
JoeAndrieu: Does this map to a did:ssh? Is there an identifier that creates it? did:git -- uses git root, sign SHA1 so its stronger
JoeAndrieu: Might be method in registry?
markus_sabadello: Sometimes, both verification method types and service types, sometimes they're completely generic and sometimes they feel more natural for certain DID methods vs. other ones. Naturally appear in Github page, SSH based did mthod, resolve that in DID Document, SSH-key based verification method? You can also have SSH-key baed DID method in another method... nothing restricting certain verification method types.
markus_sabadello: Beacons are another example, small set of DID Methods, not generic, often see patterns. I often have this question: How generic are certain verification method types and service types?
ChristopherA: Thinking about this a bit further, we had split... took stuff out of Core and put it in resolution.
ChristopherA: We also pulled out of extensions and put in resolution... is this a core extension, or is this a resolver section? Are we putting this in the wrong place?
decentralgabe: This has been a great discussion, don't want to lose what we've talked about here. If you have a thought or issue, bring it up on repo for extensions -- we'll make sure to take time on extensions, maybe special topic call, address this going forward.
burn: Is there anything that seemed to have agreement so far? People liked portions, maybe we can capture, summarize agreement?
decentralgabe: Notes will be available -- open up issues for futurre calls?
manu_: Summarising. Lets start early with this. Not hearing and objections at using the W3C registry process, understanding it is going to be challenging. There are a number of criteria for registering methods, renewal, extension. Waiting for concrete proposal around this. I heard expiration has agreement, 1.5 years
… Christopher to submit P.Rs around these
decentralgabe: PA will be back after break to talk about registry processes.
burn: Anything critical for this topic for today?
DID Rubric
JoeAndrieu: Revisited F2F presentation on rubric, talk about how we got here and next steps.
JoeAndrieu: We ran into a problem wrt. defining "Decentralized" -- we wanted a litmus test -- for decentralization.
JoeAndrieu: Some of us who love each other very much were arguing strongly against each other.
burn: We were trying to get the DID WG put together, I remember sitting at the table violently opposed to using word decentralized in the name unless we could define it prceisely.
JoeAndrieu: This is a way forward, rubric comes from educational world, way to define what someone should learn as opposed to what they should be able to do... can you name all 50 states, schools define cirriculumn on how they achievee rubrics.
JoeAndrieu: Rubric is tailored to your specific g oals... rubric i set of criteria that you care about, specific possible responses for each quetion, how did you determine that as the appropriate response. Structure, how do you apply that -- e.g., based on cryptocurrency? Is a token considered a cryptocurency... Rubric was a place to tease it out, get questions together, so person with new project can figure out what questions have been asked/ansered
before.
JoeAndrieu: Rubric isnt intended to be exhaustive... unique requirements, what should you ask? Use for corproations? Individuals? Important that it's not an authority..
JoeAndrieu: We have sample evaluations in the rubric, unfortunate that you have that, don't want W3C to stand in position of judgement about subjective matters. This was important in capturing subjective differences.
JoeAndrieu: We had IIW meetings, RWoT paper, evaluating criteria according to six different methods... one of the things that seemed important, is evaluator has the opinion on what is good.
JoeAndrieu: When evaluator works with a DID Method, someone who has certain use case will have different requirements.
JoeAndrieu: You pick use case you're working on, then pick criteria, then go through which methods matters to you, then you look into certain ones.
JoeAndrieu: Ask about did:btc, did:v1, did:web, you create a chart based on things you care about.
JoeAndrieu: A lot of the thing we care about DID, care about governance, map three branches of governments... not just governance, understand if there are alternatives, does it have adoption? How many people are using it?
JoeAndrieu: What DID Method is winning? It's decentralized, we don't know what ones are winning? Adoption is a factor in what is using a DID Method.
JoeAndrieu: Sometimes you want to use same question about different components in same system. did:web, how many layers in governance structure? Could talk about registrar, IANA, domain name, host, machine w/ layers that you can ask questions about.
JoeAndrieu: Lessons learned... even w/ six of us in a room for a week, same languge used, once we started thinking what an evaluation would be, description wasn't enough, each person reads it differently... btcr a A vs. ethr a D -- examples illustrated particular criteria. That's what leds to opinions about DID Methods.
JoeAndrieu: Other thing that came up, because of that, can't include every DID Method, can't give examples for DID Methods, maybe 3-4... for same six, change it up... needed help from DID Method implementers, mos DID Method implementers tend to focus on particular bits. Hard to get time on task for peole focused on different things.
JoeAndrieu: Since published, there is a huge nxn learing curve... you have to understand the Rubric, then you have to know use case, and hen you have to know DID Method.
JoeAndrieu: Some of the thing in DID Method are about governance, org making decisions about DID Method, focused on bits/bytes protocols.
JoeAndrieu: We did 3 full evaluations, did:ion, did:btc, and did:v1 -- questions are ambiguous, lots of questions that we wanted to ask not in rubric. Wanted to get them ino Rubric, HTML is a pain. Want to convert it to DID Spec registry, each JSON file is one criteria.
JoeAndrieu: We had litmus test as a goal... A DID Method is decentralized if...
JoeAndrieu: helped us understand the space, energy moved on, ...
JoeAndrieu: Anyone can verify proofs created by any DID Controller without reliance on a central authority. That litmus test bubbled up from our work.
JoeAndrieu: We could break into .json files, move into W3C Registry.
JoeAndrieu: In addition to formal rules, formally approve rules, that's this WG.
JoeAndrieu: One thing we should think about, we made up new criteria, we didn't have a way to get them easily into namespace of spec. We made them separately, we want to say criteria of DID ???, but couldn't put it in because it's too static.
JoeAndrieu: There is some way that this works with DID Traits work, but don't know how we plug it in.
dmitriz: Yes, thank you for work on DID Rubric. Are you suggesting that the group recommend governance section in each DID spec?
JoeAndrieu: If we were green field, I think it's a good idea, but tough since we're under way.
KevinDean: How do you define a central authority?
JoeAndrieu: Could take us another year to figure out.
<dlongley> centralization/decentralization is a spectrum not a binary :)
ChristopherA: My next steps are different... questions that I had, greatly appreciate rubric, read it lots of good stuff... but there was limited time.
ChristopherA: Ther were subcaeogires of privacy, needed to be broadened out... I care about censorship resistance... but don't know about priorities for those. is there work on them? Section B and Appendix.
ChristopherA: on a person frustration, did:git can't re-use because it's still in registry... person doesn't want it in registry, rferred to in published long-term rubric when author doesn't want anything to do with it.
JoeAndrieu: Oh yeah, it's in the rubric?
ChristopherA: What is the plan for new content?
JoeAndrieu: There is one part of new contnet... DID Evaluations... word gaps from other one. That set of critria exists in database, we have data model and could move it over. render in repo, what are we missing, if you see something, ad a JSON file that's how we get there.
ChristopherA: Are we deprecating? 7th, 8th, remove did:git?
JoeAndrieu: We need to write up in the rules what rules should be and follow our own rules. I don't know what rules should be. note that should be W3C note, get rid of did:git... in registry, we have to be more formal.
<Zakim> burn, you wanted to say that a mandatory governance section won't work because users of the method may disagree with the creators ...
Wip: That did:git thing would be good on the issue.
burn: Disagree a bit with mandatory governance secion -- governance that they think it has, that' fine -- rubric, someone using DID Method what creator thinks.
ChristopherA: I'm with Dan on that one, three big categories -- decentralization -- arrows theorem, if you're perfect in one, you destroy the others. In bitcoin, decentralized, one code base in one language and there is constant fight in implementing something else, bugs in language... centralization in code in one of the best.
ChristopherA: Principle in voting, Arrows theorem, you can't have all... no such thing as a perfect voting solution... decentralization is one of them.
dmitriz: The Working Group should update the DID Method template to include governance coniderations chapter... considerations are there... did:key short, no goernance, for did:web, website operators are authorities, similarly, those would be useful to implementers and policy makers trying to select DID Method to use.
<burn> I like the more general idea of a "rubric considerations section"
<Zakim> JoeAndrieu, you wanted to talk about opinionated evaluations and self-assessment v 3rd party
decentralgabe: centralization is very tricky, risk in rubrics like this.. you can have centralized uses of decentralized technolgies... decentralization doesn't mean one thing... slides are a good sart, complexity of world is hard to fit into buckets/traits, dosn't serve us, might be misleading... good to have in traits discussion, applied to Rubric here. We want it to be useful for folks... what does method do / not do
JoeAndrieu: Yes, agre with Dan, evalutions are opinionated.
JoeAndrieu: We have something about cost effectiveness... $1/identifier validated for bank tansfers... that's uderstandable... but for refugees it doesn't work. Innate in the question -- self-assessing DID Method can make creator mark it higher than someone else. We don't want central judgement, we want each of us to come to our own judgements.
burn: How would you like to wrap up?
JoeAndrieu: Seems like we want to support the work, get sense of room, can we make rules for registry... maybe after we talk about did traits, open to anything.
<decentralgabe> +1 to continue the work and integrate traits
burn: I like what Dmitri said about governance considerations, I like the more general section of rubric considerations. We could require it, you have to make an attempt to cconsider different aspects in rubric
burn: As long as creator says statement about them thought aobut it is valuable as long as you can ensure it's not taken as gospel by a reader.
<burn> so yes, +1 to continue the work
ChristopherA: Slight related thing there, some people might be sensitive to put in text of rubric, but would be fine for additional types of requests to add to method/rubric spec. Form for github forms, ask additional questions, some questions could be sensitive. 10 qestions we'd ike to ask you as submission to method registry. That might be less challenging.
<decentralgabe> manu_: one thing I am concerned about is putting a lot of workload on the reviewers. with 200+ methods in the registry the evaluators are tired of telling people 'please write more than 1 sentence in privacy considerations' and 'please write security considerations'
<decentralgabe> ... these requirements don't hit the people registering, they hit the people reviewing
<dlongley> if certain fields are left empty, the methods could be listed in a lower order (or something along these lines)
<dlongley> there are other ways to incentivize
<burn> Enforceability is hard
<decentralgabe> ... make it a requirement on things past provisional. if your DID method is standardized you must have a governance section (for example). this is a strong requirement for any W3C spec. help people ratchet up.
<dlongley> Sections: DID methods w/answers to all the questions, DID methods w/answers to N out of M ... and so on down the line.
denkeni: I'm not sure if it's out of scope, we are working w/ government on DID VC project, coming from community, care about centralized government rojects being too centralized. When we see APIs we think centralized, limited to govenement APIs. One of our implementations are to make sur varaible in NFC, you can communicate DID Document and VC, but not a variable for all methods. did:web wouldnt work. In Rubric discussion, focus on resolver side as
well.
denkeni: If we focus on dcentralized way, we can avoid centtalized vendo lock in.
burn: Final word?
JoeAndrieu: I'll start working on some rules for a registry.
burn: Thank you.
DID Traits
dmitriz: In looking over methods, you start to wonder, surely these have features in common. Namable blocks of features. Kudos to Wayne from Spruce for writing original blog post naming the concept "DID Traits"... legos for DID Method authors.
dmitriz: Theey are a subset of rubrics, particular features and technical affordances. In software engineering, design patterns book, chunk design patterns, advance discourese.
dmitriz: What is a trait?
dmitriz: Is VDR mutable or immutable, like did:key. Does it support service endpoints? What about alsoKnownAs? Is idetifier self-certified, user-selected? Does it have key rotation log? Security logs? Keys? Methods itself? Pre-rotation?
dmitriz: does it support specific service endpoints like DID-relative URLs? Can you delete/revoke method itself -- did:key -- no... delete/revoke individual service endpionts, etc.
dmitriz: With that lens, what are features of did:key -- deterministic, immutable, ffline capable, no support for sevice endpoints, or alsoKnnownAs, history, more than one key, etc.
dmitriz: did:web traits -- mutable, revocable, deletable, supports many key types, multiple keys, no key rotation hitory, not self-certifying, supprts alsoKnownAs, controller, service endpoints.
dmitriz: if I have a diploma signed by did:web, rotate keys every month, that diploma has 12 rotations ago, can't verify diploma without notion of history.
dmitriz: did:web isn't required to be self certifying, but it can support it.
dmitriz: did:tdw traits, mutable, revocable, deletatble, requires self-certifying identifier ey rotation log, pre-rotation, /whois, alsoKnownAs, controll er property.
dmitriz: If we bring notion of traits as an informal note or report to DID WG we'll have a chance to define/name traits more explicitly.
dmitriz: did:dht traits, similar trait profile for did:tdw, but very different... one is more centralized than the other.
<Zakim> ChristopherA, you wanted to ask isn’t there a list of dark patterns?
dmitriz: There are some identified traits at DIF did-traits document, take a look at it. Is this a useful concept? How much, if at all should it be incorprated into the group?
ChristopherA: I question the use of traits as a term, lots of collisions in computer science. Feels more like patterns?
<shigeya> +1 ChristopherA
ChristopherA: We ight want to identify dark patterns. Someone said real readable human names, then didn't want them
ChristopherA: When Manu said, putting detail into URL of endpoint meant you were identifying a person... correlation risk... same endpoint for everyone ok, different was anti-pattern.
ChristopherA: Pre-standard in software engineering, good for this , bad for that, standard pattern .
<Zakim> decentralgabe, you wanted to speak the good graces of did dht
dmitriz: Maybe we should rename to patterns.
decentralgabe: Thanks for putting together, think it's excellent, nutrition label for DID Methods. I'd like to see this, incorproated into rubric, interaction w/ DIF, don't want to take their work item away, liaison agreement, make good use of this work.
<Zakim> manu_, you wanted to bikeshed traits :P
manu_: +1 to the work in general. Think it helps understanding of different DID methods.
… Help categorise them
… I also dislike traits. Feels like feature sets
<Wip> +1 to features
manu_: Developers understand what a feature is
<dmitriz> +1 to features (i like Patterns as well)
manu_: Certain DID methods have certain features. If we can name them and tag them. Could be part of DID method registration
… Could even add filtering
<denkeni> +1 to features, easier to understanable
<Zakim> burn, you wanted to talk about token taxonomy initiative in Ethereum
manu_: Could help you decide what to apply features to
<smccown> "rubric" is a good term. Another option is "attributes"
burn: Characteristics might work as well -- feature has intent, charcteristics is just a statement
<Zakim> JoeAndrieu, you wanted to embrace patterns
burn: There was a token taxonomy initiative for ERC20 tokens, they were able to go beyond by creating template code to create features in tokens... something to think about
<dlongley> DID taxonomies ... DID families and species
JoeAndrieu: I like conversation, we might do things to separate -- two things -- building bricks (how do I think about components that make a good method)... other is easily observable patterns. Somethings might not be on the surface. Every pattern resolves a problem, that was the point. You can think of a system as a set of lights, when you break architecture you break other things.
<smccown> Joe just mentioned "characteristics" in describing this topic ... perhaps, that's the best term
JoeAndrieu: In an alcove pattern, it gives private space that solves tension in a big open space. Richer way to identify things that have more value.
ChristopherA: There are no right answers, all patterns work with one another.
markus_sabadello: Dmitri started presentation saying that this is part of rubric, related to it, in my mind differnt from rubric. Patterns, features, about features and fnctionality hat certain DID methods provide.
<Wip> +1, feels like these should not be subjective
markus_sabadello: Operations / mutable immutable, in terms of functinaltiy that DID Methods want to provide. Not anything like that in Rubric, how decentralized, how mch privacy, not in DID Traits -- quite different in that sense.
<dlongley> "how decentralized/centralized is it?" can be rephrased (sometimes) as "how resilient is the backing network to attack?" (which might be a pattern/feature/etc)
<Zakim> dmitriz, you wanted to +1 template code possibilities
danpape: Another example ... book by Neil ford on software architecture, tradeoff analysis on different types of architetures, one that is loosely coupled vs. tightly coupled... sync vs. async ... maybe did design trade offs?
dmitriz: Wanted to comment on libraries that provide this, one easy to think example is self-certifying DID Method. Type of self-certifying identifier that is part of did:tdw, that trait feature could be pulled out to standalone spec, but could see code library being creeated, SCID, that other DID methods could use in them.
<Zakim> JoeAndrieu, you wanted to suggest an easy point of integration for the rubric
<KevinDean> +1 to Joe
JoeAndrieu: The structure of rubric makes it easy to have blessed characteristic... which 12 characteristics should your method have? More esoteric might not be as important.
<dmitriz> @bengo - like horizontal DNA transfer between species!
bengo: Sounds like patterns could be useful but generic, but maybe ther are more concrete stuff -- real good innovations happen in single DID Method, versioning endpoint, but then bummer when DID Method might have something problematic... reusable properties that are reusable across DID Methods.
burn: Next steps?
dmitriz: Possible interactionw ith DIF on this?
<ChristopherA> https://
<ChristopherA> Dmitri 👆
<dmitriz> thx
markus_sabadello: I'm one of the co-chairs and DID Traits is one of work items in that group, biweekly meetings, happy to share link... JC has started work, can't comment on legal setups or liaison setups, at moment work item at DIF.
<markus_sabadello> Info about work item in DIF: https://
dmitriz: I wonder if a next step for DID SpeC registry team picks traits so we can start marking DID Methods with them.
dmitriz: start w/ a few uncontroversial ones
JoeAndrieu: Was confused about how this might roll out. Opportunity to put in DID Spec registries of methods... but think that's a different set of work wrt. characteristics?
JoeAndrieu: different list... could see the list, but how do I evaluate 200 DID Methods?
dmitriz: Counter point, mutable or immutable, or we can start.
No clear agreement on how easily that will be to achieve.
<dezell> present_
ChristopherA: Look at 80% of these, 10 ways to do it, self-certifying... 5 ways to do different ways to do self-certifying... with hashes, without hashes, with signings, ZKPs, too many might not be reducable to code atoms. Checkmarks might be good... chat pastebin of pattern, shannon and I spend a lot of time writing out pattern languages. If that's something of interest, doesn't conflict with the group, interesting patterns.
<dlongley> starting with self-attestation (from registrants) for the individual methods might be good enough
<dlongley> +1 to adding incentives based on how the registry/extensions is presented
manu_: We could ask DID method submitters to help with evaluation of traits/features. But no clear agreement for how easy this would be to achieve. Could explore incentives for making folks do this
burn: We're going to break, come back at 25 after to start at half hour mark.
Group breaks for 25 minutes.
Controller Documents
manu: We have a controller doc specification in the VCDM
… This group is planning on reusing it. This summarises how this might go
… A controller document is a generalization of a DID document
… Only real difference is you can use any URL, rather than just a DID
… DID documents can be thought of as a subclass of a controller doc
… Current plan is to take DID document and point to controller document where they are aligned
… Some weirdness in the plan. The VCDM is in charge of the document.
… Controller document happened due to folks not wanting to reference the DID core or Data Integrity specs in the VCDM
… initially controller document was a copy of the DID core spec
… However, now we have made changes to the controller doc
… It is still compatible to DID core, but does have new content
… Controller document has many of the same DID core properties. Id, controller, verification relationships and methods etc
… Changes that DID core would make would be to constrain the id field to DID sytax for example
<decentra_> https://
manu: Controller document adds normative JsonWebKey and Multikey definitions. Multibase definition and base encoding. And safe fetching of keys
… Also add a JSONLD context that doesnt depend of DIDs
… Problem is that the document has changed. So TAG and PING review had comments that need responding to
… Expecting candidate rec before end of the year. Have reassurance that TAG not trying to block the work
… PING review was easier to address. Both groups asked why this work was taking place
… Response was that DID core and JOSE/COSE was going to be reusing this
… other things that we might do are
… Service is not in the controller document currently, should it be
… service isnt in the VCDM, should they?
… This is a DID trait/feature type question, but this is a future issue for the VCWG
… Open question about transfering the controller document to DIDWG at some point in the future
… Any strong opinions and concerns?
markus_sabadello: Sounds great. We should use and reference the controller document. Feel like service should be in there
ChristopherA: Don't feel good about this. Privacy and security requirements are going to become very different for VC controller document vs documents intended for a decentralized system
… There could be risks here
<dlongley> profiling the controller document allows constraining it for DID docs however this group desires
ChristopherA: In some document type I am working on, you don't include the services but prove they are in the document
… There are different security models here. This could lead to problems
dmitriz: +1 to service endpoints in the controller document. Half the utility of DIDs
… A spec proposal in the social web working group was to start evolving actor profile to act as a controller document / DID
… Adding verification method and a standard place to look for service endpoints
… Really convenient to use the controller document her rather than DID document
<Zakim> manu_, you wanted to ask if adding 'service' is going to blow up the controller document timeline? and to speak to security model concerns
dmitriz: The use case is important
manu_: Question for Brent, if we add service to controller document is that a problem
Brent: Not concerned about adding a feature, but concerned about the timeline of getting this feature in there in time
… lets get through the TAG and PING review and see if there is appetite to do the work
… hesitant to say yes at this point
manu_: Only spec that is using the controller document directly is the VC Jose Cose spec. Which does not need service endpoints
… DID core keeps service endpoints
JoeAndrieu: Why service isnt in the controller document. If it was a mistake, lets put it in. What is the good reason for taking it out
<Zakim> ChristopherA, you wanted to ask there a way in a 1.1 schedule to be able to allow pre-committed objects?
ChristopherA: Service is in DID 1.0, good argument to say it should be in controller document
… Different sercurity and privacy principles implied with this more generic controller document. Vs something defined specifically for decentralization.
… We should not automatically inherit any divergence from our principles
… A long time ago I raised an objection about services in DID documents. Actual usage of service endpoints have user information in it
… Creates a point of correlation
… Any way to offer the ability to commit to object value without releasing it in the DID document. Can we do this in this 1.1 version
… Ability to say this is my endpoint, I can prove it
<Zakim> manu_, you wanted to note alternate to service endpoints
ChristopherA: likely not within the 1.1 timeframe, but feels powerful
manu_: dlongley has suggested that instead of service endpoints these should be verifiable credentials. Problem is this requires interaction. Having services give a way of reaching out to the DIDs
manu_: reason that service endpoint wasnt in controller document is because this was copied across from the data integrity spec
joeandrieu: Think this is possible to do with service endpoint with a specific type. Some complexities but it is possible
<Zakim> Wip, you wanted to ask why that cant just be a new type of service
Wip: Agree with Joe, you can create a service endpoint type that uses a commitment.
<dmitriz> (bengo says: you can use RFC 6920 (to turn a hash into a url)
bengo: There is a way to represent hashes as a URL, RFC 6920
manu: I want clear direction here
manu_: I will raise a PR to add service verbatum from the DID core to controller document and we can see how this pans out
wip: we need to decide as a group whether we are using controller documents
decentra_: we don't have to decide today
burn: Lets go ahead and move on to the next topic. Last topic of today
What's Interoperability?
dmitriz: Why are we asking what interop is? We want to avoid formal objections for our spec
… This was a key critisism of the DID spec
… DIDs are four things. Keys, service endpoints, alsoKnownAs, Controller heirarchy
… These four aspects of a DID document are what we should test interoperability against
… Should also consider intra and inter DID method interop
… What do we do with a DID. We sign stuff, we encrypt and decrypt and we use it for routing
… We also use DIDs to link aliases together
… What do we mean by between DID method interoperability?
… What do we mean on the policy level? Deployed issuers,verifiers, agents etc only support a given subset of DID methods
… If your DID method is not being supported at the policy level, it is hard to talk about interop
… This is not something we can explicitly test
… Why do subsets of DID methods get selected? We do have a universal resolver that supports much of the DID methods out there
… Partly it is down to affordances and features
… Also pratical limitations and library support
… Base layer underneath our unit tests are about policy decisions which DIDs to support
… For interop within a DID method. We mean testing resolvers and registrars
… This is where we can gather registrar/resolution libraries and compare them to check they are consistent
… universal registrar may include these kinds of tests
… Just because a resolver can resolve a key doesn't mean that the key type is supported.
… Resolvers may be compatible, but the key might still not be supported. Verification methods cant be verified
… Not all service endpoints and types are supported
… Consider testing on interop of service endpoints
… Does the DID method allow custom properties. DID web use has custom non-standard properties
… Other major challenge for automated testing within DID methods is infrastructure challenges. Gas fees, authentication etc
… Interop between DID methods means how many libraries support these DID methods. How many can sign and verify signed statements from that DID method identifiers
… Usage and market penetration
… Hard to talk about the interoperability of the DID method in general. Need to slice it by use case. Signing, authentication etc
… Additionally, if we have 2 DID methods and they both support the same key type a subtle interop consideration is in the scaffolding around this.
<dlongley> some thoughts: interop between DID methods: "are the semantics the same between two DID documents (regardless of method)", interop within DID methods: "do two resolvers get the same result?", and, separately, whether or not you accept a DID method: "How much confidence does this method give me in what is expressed in a DID document / does what can be expressed in a DID document when using this method meet my needs?"
dmitriz: The trust registries. The DID can be interoperable in that you can sign and verify using that DID. But for VC verification and validation it often requires checking against a registry
… Are there issue registries or specs that support this DID method
… Not only do we want to test resolution and registration. Signatures and verification. We also have to keep the dimension of time in mind
… issuing university might rotate keys every month. This rules out some DID methods.
… We want to test historical verification
… web fails this but tdw succeeds
… Interop testing is very important to delivering quality specifications
… Different levels of interoperability.
… Registration and resolution can use automated testing
… Other tests should look at use cases
… Interoperability reports for VCDM libraries might be useful
… Many hard to test aspects of interoperability
<Zakim> manu_, you wanted to speak to "Why are people picking curated subsets"? and to suggest "interop between DID Methods" is "they use the same data structures in the same way"
dmitriz: questions or discussion
manu_: Great analysis.
… First thing that comes to mind, isthe importance of demonstrating interoperability. Not clear what type of interop they are looking for
… We want to do automated testing
… Be good to hear from google to hear what they are looking for
dmitriz: A limitation is that our 1.0 charter was constrained to the data model only. Not to the resolution or registration API
… We produced a data model test suite. The objections were on the API level
… Clarifying for the 1.1. group is that restriction lifted. Can we demonstrate API interop
manu_: Want us to be really clear about the type of interop we are planning to demonstrate
… Want to get some agreement from folks who objected that this is what they are looking for
… Unclear what is meant by interop across DID methods
… We are using the same data model
… The other aspect is did resolution
<dlongley> +1 to manu on interop between DID methods being straightforward and that two DID docs are understood in the same way regardless of DID method.
manu_: The items your raise are great dmitriz but it might raise the bar too high
shigeya: An observation this discussion around rubric and traits and now this one about interoperability is trying to classify the methods in some way
<Zakim> ChristopherA, you wanted to ask about a) crypto problems, like ed25519 library problems? B) rotation
<ChristopherA> https://
shigeya: This seems to be very related to Rubric and Traits discussion. How can we integrate these discussions so they are easier to understand
ChristopherA: No discussion on the crypto problems
… The link in the chat shows a very interesting graph of lack of interop across crypto libraries
… Similar problem in bitcoin
… Cryptogrpahic validation challenges
… Grabbing libraries off the net is not gauranteed to be "standard"
… Would like to push this off to not testing DID core, but testing resolvers
… Check conformance of the data model rather than functionality when testing core
… All operational functions should be resolution tests
… Finally, two categories of testing. Nothing is a DID if it can't rotate as far as I am concerned.
… Satisfying interop in rotateable DID methods is more challenging
… Have the historical challenges
… We could test the non rotatable DIDs first
dmitriz: Specifcally wanted to leave out testing the key libraries
… We are not testing ed25519 keys
<dlongley> +1 that we're not testing any particular crypto
dmitriz: however that is a good point that crypto libraries can bring in inconsistencies
<Zakim> JoeAndrieu, you wanted to say interop is for resolution
JoeAndrieu: agree with ChristopherA did-core is about Data Model. We have tests for that. Objectors wanted a protocol that we werent allowed to produce
<dlongley> +1 we have testing of DID core/syntax/etc. that's done, need resolution interop next.
JoeAndrieu: To me interop is about if we have the same piece of software for resolution that can support many different DIDs just with changing the config file
… We also need the same thing for registration. Universal registration is under discussed. Not sure we can get registration through as a spec in this cycle
… Registration and resolution both deserve to be interoperable across did methods
smccown: Interop is the key. I am co chair in DID COMM working group. We handle this a little differently
… in DID COMM we have a message for discovering features supported
… We can drill down into what is supported by different remote parties.Might be some lessons we could pull across
markus_sabadello: Universal registrar originated in 2019, but still young in its maturity. But agree, something for another time. Not right now
… We need something more than the common data model to satisfy interop. The key addition here is the resolution specification. A standard interface to resolve a DID
<bengo> interop ideation: what would a browser vendor need to see to support rotatable did-based SRI not only nonrotable pk-based SRI? mikewest/
markus_sabadello: We are not going to have mandatory DID documents
… We will have a standard HTTP interface. May also have resolvers able to advertise DID method support
… Resolvers might also forward incoming requests to other resolvers
… DID method standardization is starting in other groups
bengo: in web application security group people were discussing edwards curve and the inconsistencies are seen even amongst browers
<markus_sabadello> DIF work item on DID Registration: https://
bengo: There might be possibilities to put signature based SRIs into the html script tags
<Zakim> manu_, you wanted to note that we can do data model test (most of them) with JSON Schema
bengo: What would it need to be to put the DID for authorized signers into an SRI. What might the end to end use of this stuff for browsers look like
manu_: Think we can test the data modelu using JSON schema
… meaning you use DID resolution to pull the test suite down
… Would be testing both DID core and DID resolution at the same time
dmitriz: hearing a deliverable for the WG. produce a DID core JSON schema
… This would simplify the data model unit tests
JoeAndrieu: Gives an anchor for real time checks
ChristopherA: The real problem is the browser vendors are the ones we need to satisfy
… Focus on that
… We can demonstrate a number of things that will make the browser vendors happy
dmitriz: In summary, next steps
1. DID core JSON schema, to simplfy data model test suites
2. Produce a data model test suite
3. Figure out a resolver test suite
4. See what other use cases we could test that would demonstrate utility and interop to browser vendors
<decentra_> Wip: we can create a DID linter
<markus_sabadello> DID Lint: https://
<decentra_> ... tied into JSON Schema!
<markus_sabadello> DID Resolution test suite: w3c-ccg/
Extensions and using W3C registries
decentra_: How does the W3C registries process work. Especially past the life of a WG
PA: Looked up the process. The process says the custodian of a registry could be a WG, the W3C team or any organisation. Could have a fallback
… Great that the process opens the door for a separate org to also manage these registries. Not sure it makes sense in this case.
… Makes sense for the WG to be the custodian, but fallback to the team
<Zakim> ChristopherA, you wanted to registry process
ChristopherA: Assumption around registries for collision resistance. We have also said we might want to have a variety of things like the rubric be registries
… The DID rubric right now contains an entry for a DID method that has asked to be removed
… We would like to delegate the authority to some entities/people to maintain the registry over time.
ChristopherA: We have requirements for a method to be registered. Setting up expiration date for entries. Can put some statements around handling expiration. But who will enforce and manage these rules over time
PA: I dont have a clear answer, but I understand the problem. Can go back to the process CG to see how they see these challenges
<Zakim> TallTed, you wanted to speak to this issue as current participant in process CG (though not official responder to these questions)
TallTed: This question comes up a number of times. Process is a moving target. The current version being worked on revises this language
… Effectively a registry is a table. What is its primary key, what are its colomns.
… Managing these things should not be hard.
… The group that sets up a registry gets to designate who will take this over
… Final backstop for registries is the Team
… The team will be empowered to designate management to another organisation
… Current intent is for the initial designation over a registry can transfer the control
… Like many things there is always a formal objection that can be raised leading to a council
… Not definite answers here. The more clearly a question can be raised, the easier it will be for us to get good answers
… might be process group. Might be the team. Or the CEO
… Still figuring this out
<Zakim> manu_, you wanted to note that we do have maintainers, could we note them?
manu_: One other weirdness. Currently 12 people in theory maintaining the registry
… Fallback would be if not an active working group, then the 12 maintainers. If something goes wrong, we defer to the team
TallTed: roughly accurate
JoeAndrieu: The process as its currently written, you have to define the purposes. This can include non-collision
… You can define how you update these tables
… You also must specify a custodian
… We have to be explict to choose the custodians. We could choose the CCG teams
TallTed: Yes you have to declare this. The default is the team. They are busy
burn: Any other commetns today on this topic
decentra_: A number of open topic proposals. If folks have other things, then add them
<TallTed> +1 it's part of the rubric process ... which may need discussion
<denkeni> +1 to the open topic of decentralization
<denkeni> Double tap on the slide to see thumbnails (editing mode), for Google Slides iPad app