DID WG TPAC meeting — Minutes

Date: 2022-09-12

Attendees

Present: Pierre-Antoine Champin, Manu Sporny, Ted Thibodeau Jr., Brent Zundel, Shigeya Suzuki, Dave Longley, jay5, YanZhang, cabernet, Ryan Grant, Dongwoo, Markus Sabadello, GenHyung Kim, kdeangs1, Orie Steele, betehess, David Ezell, Joe Andrieu, Phil Archer, Kristina Yasuda, mkhraisha, risako, SatoshiSakamori, Charles Lehner, Gregg Kellogg, ktoumura, Osamu, Kaz Ashimura, hongcai, jeff, Steve McCown

Regrets:

Guests:

Chair:

Scribe(s): Manu Sporny, Pierre-Antoine Champin, Wayne Chang

Brent Zundel: Our agenda today is fairly straightforward.
… charter review, potential additional deliverables, remaining work, DID Methods.
… We are going to look over current charter, what does it say now, what are open PRs and issues.
… do we want to consider additional deliverables?.
… Let’s go around the room and do introductions.

1. Introductions.

Manu Sporny: Dan LaLibrete: working at Google on Privacy.

smith: Ned Smith from Intel, looking at attestation, looking at technology on supply chain integrity issues..

abernethy: Hi Chris Abernethy, software architect from from Mesur.io.

Dave Longley: Hi Dave Longley with Digital Bazaar, work on DID Core spec..

Toumura: Working in Web of Things WG.

sabadello: Markus from Danube Tech, DID company in Vienna, one of the Editors of DID Core specification..
… Also working on DID Resolution specification..

Houng Cai: Hello, good to be here..

Steele: Orie Steele, CTO cofounder at Transmute, one of co-athors on DID Core specificaion and VC..

Ryan Grant: Ryan Grant, Digital Contract Design, working on identity wallet, BTCR DID Method..

Hamono: Software engineer at Yahoo Japan..

Stringham: Russel Stringam from Adobe..

Abe: Ryosuke Abe - from SFC Keio University..

Suzuki: Ryosuke is student of Shigeya Suzuki, working on DIDs..

Sakomori: Satoshi Sakamori from Yahoo Japan.

Hager: Scott Hager, cofounder of Identity Fusion in DIFX lab, using DID and VCs for our products.

Suzuki: Shigeya Suzuki from KEIO University, in Japan now, will be in Vancouver tomorrow..

McCown: Seve McCown working for Anonymoe Labs, looking forward to meeting everyone and getting started, CoChairing DIDComm WG in DIF, looking forward to meeting everyone Thu/Fri..

Thibodeau: Ted Thibodeau, OpenLink Software, if it’s related to Linked Data, I’m probably in it..

Shigeya Suzuki: Forgot to mention that I’m one of the editors of DID Core Test Suite..

Abernethy: Chris Abernethy, software engineer with Mesur.io, working on VC API for HTTP..

Manu Sporny: rrsgent, make logs public.

Kristina Yasuda: Kristina Yasuda, work at Microsoft and co-chair of VCWG with Brent..

Geunhyung Kim: From Gooroomi South Korea, I have participated, happy to be participating in this meeting..

Alkraishi: Mahmoud Alkraishi from Mavennet.

Dean: Kevin Dean with GS1, been active in VCs and catching up on DIDs..

Andrieu: Joe Andrieu on from Legendary Requirements, DID Use cases..

Bertails: Alexandre Bertails from Netflix, looking forward to catching up..

Ezell: David Ezell from Conexxus, petroleum retail standards organization..

Kellogg: Gregg Kellogg been invovled off and on..

Archer: Phil Archer from GS1, work with Kevin.

Osamu: From Keio University..

Charles Lehner: Charles Lehner, observing today.

Siow: Eric Siow from Intel looking at work more closely..

Dongwoo: Samsung Electronics and Samsung..

Brent Zundel: Hi Brent working for Avast and Norton Life lock, Chair of VCWG and DID WG..

WonsukLee: Wonsuk from ETRI, coeditor for automotive WG and WebML..

Don: Don from Human Rights considerations, just monitoringn today.

Sakamoto: Trusted Internet and digital identity, breakout session for Trusted Internet..

Manu Sporny: Jay Kishigami: W3C KEIO.

Zhang: Web Alliance, DID VC replacing enterprise WIFI, industrial identifier, DID implementation..
… currently working on DID and payments..

champin: Hi Pierre-Antoine Champin, working on DID WG and web of data..

2. DID WG Draft Charter.

Brent Zundel: Scope of this charter text says that the goal of this group is to maintain the DID specification..
… As well as non-normative WG notes, DID spec registries, DID Method rubric, plain CBOR representatin for DIDs, and DID Implementation Guide..

Joe Andrieu: Is there a link to the charter?.

Pierre-Antoine Champin: https://w3c.github.io/did-wg-charter/.

Brent Zundel: out of scope, class 4 changes, authn/authz, browser APIs, solving identity, defining specific authentication, signing, cryto mechanisms..
… That’s the charter as of now, the point of today’s meeting is to see what we think about that, look at open issues/PRs, and then frank discussion about scope of next WG to be..
… First PR adds liaison with APA WG..
… Any opposition to this PR?.

See github pull request did-wg-charter#22.

Kristina Yasuda: clarifying question for “Browser API”.

Brent Zundel: This was added to specification so browser vendors don’t think we’re building browser APIs.

Kristina Yasuda: What is the plan to finish brushing up the charter?.

Brent Zundel: These are the PRs that are sitting there, some of them touch on potential scope changes, what else do we want in the charter – it’s in draft state, this is the group that can modify it. That is the topic for today..

Ryan Grant: We did some work on Rubric, clean up issues, didn’t know that needed to be listed? Can we do cleanup on previous charter?.

Brent Zundel: We can talk Rubric today, it’s in scope in next charter to maintain those notes, republish the notes..
… Moving to PR 20 – adds anguage to charter, maitain DID Spec and Notes, also seek consensus on specification of DID Methods..

Manu Sporny: some background on this change.
… Specifying DID methods was out-of-scope of the previous charter..
… There are currently 300+ methods in the registry, which is a lot..
… We have been criticized for not promoting some of them..
… We do have interoperable implementations for did:key and did:web, so they are good candidates..
… But the text does not say we have to specify them..

Kristina Yasuda: manu, were you proposing to make the language in the current PR more explicit?.

Brent Zundel: Proposes limiting DID Method documents as WDs, but no further. Pretty straightforward, in addition to working on DID Method spec, could publish notes or REC-track documents, but limited to WD..

Phil Archer: Just to strongly support this, we should standardize a couple of DID Methods, did:key/did:web being a couuple of them. This text allows us to have that discussion..

Ryan Grant: scribe?.

Orie Steele: +1 phila the group should be allowed to discuss standardizing methods..

Manu Sporny: @@@: Many of the methods are for a particular blockchain, when we standardize method, we should focus on more generic ones or you get tangled with different blockchain ecosystems, define some high level generic terms, leave the smaller ones..

Ryan Grant: What is the goal, proposed benefit for providing standardized DID Methods, why any interoperable DID Method is not sufficientn to meet the standard..

Joe Andrieu: Partial answer for Ryan, this is not about deciding which DID Methods are not compliant, it’s about whether or not this WG has authority to define any DID Methods at all for any layer. I like this language, it doesn’t pick a DID Method, what’s the goal, what’s the criteria for DID Method selection. I don’t ike did:key because no roation, did:web has not end-to-end security model, I don’t think it’s what we should spend out time standardizing..

Kristina Yasuda: but isn’t that the conversation to have after we have a final charter? ie the selection criteria?.

Orie Steele: expect strong formal objections to anything that is based on Proof of Work..

Manu Sporny: I don’t think there are objections to the language. It is good..
… I agree with Joe that there’s going to be discussions..
… Another way that we could demonstrate interop is through an API..
… We could say “we are not recommend any method, by any method that works with the API”..
… This may address Ryan and Joe’s concern..

Brent Zundel: One of the motivations for DID Method specifications, clear path toward clearer demonstration of interoperability, core data model does provide interop core that we claim it has in a demonstrable way. If we can demonstrate that level of interop, it’s a direct response to core of formal objections against DID Core..

Ryan Grant: I appreciate Manu’s idea of standardizing an interoperation API. I hear sttements that standardizing DID Methods as a group is not objectionable language, so I’m willing to clarify more strongly that I’m inclined to object to standardizing any DID methods, given the chartr’s lack of reasoning why that is preferrable to standardizing interoperable APIs and a Note proving what was achived..

kdeangs1: I agree with the statement that did:web has issues, it is useful for rapid prototyping, speaking with experience, in a team where VCs are new and focus is within our environment, use of VCs for business processes, used did:web because it was easiest one to implement for scope of what we’re doing. For did:web, it might be useful for template for other DID Methods, we could say it’s not recommended for production becuase other DID Method.

Manu Sporny: implementers could address in their implementations..

Orie Steele: I like the proposal of looking at DID Resolution and adding additional normative requirements around resolving things over HTTP. I also like standardizing DID Registration, getting method specific in ways that could be harmful. I’m a fan of standardizing DID Resolution, I’m concerned about standardizing did:key and did:web with where they are today..
… We might be able to get away from standardizing specific DID Methods..

Ryan Grant: I appreciate Manu’s interoperation API, standardizing some DID Methods, I’m inclined to object to standardizing any DID Methods to stanrdize interoperable APIs with what was achieved..

Phil Archer: Perhaps this question has been asked? Why is resolution not in this charter? It was missing from the first one. It was a problem, resolution should be in here..

Orie Steele: Add DID resolution to the charter please..

Joe Andrieu: +1 for adding DID resolution to the charter.

Brent Zundel: To clarify, we are talking about the charter, this PR adds the potential for workingn on these things to the charter, it wouldn’t require the group to work on them. We could decide to not do that… but we can have converation, w/o this language in the charter, we can’t have the discussion..

Ryan Grant: I am strongly inclined to believe that the purpose of discussing DID Method standardization is to create winners and losers based on political preferences..

Markus Sabadello: I also think this language should be in the charter, favor of merging PRs, including DID Resolution, exisitng work item in CCG, interesting to work on standardizing on other CRUD operations, but that is more complex than resolution..

Orie Steele: +1 Markus.

Markus Sabadello: Regarding DID Methods, have mixed thoughts, it can be valuable to standardize DID Methods to demonstrate interop, but also share concerns about picking which DID Methods to standardize. Neither did:web or did:key are ideal, they lack certain desirable qualities..
… I favor adding this language..

Brent Zundel: I agree that DID Resolution could be very valuable, we should add that to the charter, add WG-draft level language. We intended this charter to be more maintenance level. I’m concerned about groups capacity to work on Data Model 2.0, go all the way to REC, in light of largest contributors are involved in RCHWG and VCWG – that’s one reason resolution isn’t already in here..
… We might not have capacity – can we talk about methods, resolution? Introduce documents for that..

Pierre-Antoine Champin: +1 for language in charter to authorize this conversation, we need to have it, slight addition, of “DID Method specifications or other specifications demonstrating interoperability”. This aims at DID Method specifications w/o which ones..

Ryan Grant: The purpose of discussing DID Method specifications is to choose winners/losers and push that discussion to later. The engineering way forward is to define what interoperability is and prove it, it doesn’t need to create winners/losers the same way, based on which DID Method can deliver what they can deliver..

jeff: I note that in the last round we have several objections for DID Core because of lack of method standardization, some objectors felt like w/o methods, we haven’t demonstrated utility of DID Core. Those objections were overruled in the last round, but I’m not sure the’ve gone away in minds of objectors..
… Have we asked the objectors if they have had a preference, if methods should be convered in next round?.

Brent Zundel: Yes, we have open issues that are calling for standardization of DID Methods from objectors..

Kristina Yasuda: +1 to Jeff’s suggestion to get input from the objectors.

Manu Sporny: On the capacity concerns: we don’t have the capacity to go beyond WD..
… All editors are busy with other specifications, and no other editors in sight..
… As you can see, we are facing objections either way..

Kristina Yasuda: note that stadardized DID Method is not an MTU (mandatory-to-implement) DID Method.

Manu Sporny: We have talked with the objectors, they insist of “truly decentralized”..
… Everyone hates did:key and did:web for some reason, but the specifications can be done in a short time and can be useful..

Dave Longley: kristina_: re: “not mandatory”… yes, however, once any DID method is standardized, the argument will be “don’t use other DID method X, because it’s not standard, ‘just use the standard’”.

Manu Sporny: The situation, if we are objected either way, it will occur anyway..

YanZhang: q.

Kristina Yasuda: @dave, standards are voluntary to implement.

Dave Longley: kristina_: of course, but if some DID method is to be used, there will be enormous pressure on it being one of the standard ones vs. a non-standard one (just based on that classification).

Joe Andrieu: Those comments were a great segue, I don’t think did:key or did:web meet definition of DIDs, I don’t think we can standardize. I propose an alernative, maybe we standardize a set of criteria that we believe captures vision of DIDs, litmus test – does it need rotation, verification relationships, it doesn’t feel like open ended problem, different sensibility of when is the right time to work on this..

Kristina Yasuda: @dave, sure, i’ll just note that proposed two that are already being used without any “standard” existing..

Ryan Grant: Reiterate that picking any DID Method, even if we say we don’t like it, is telling W3C that WG is in the busienss of standardizing DID Methods, there is an engineering solution that focuses on interop, can be written down, can be proven, that can happen whether or not this WG is in busienss of standardizing DID Methods, and that’s why we don’t need to be..

Dave Longley: kristina_: sure … but imagine if some other DID methods were standards (other than those two proposed) … then the two being proposed now might lose support (is my point).

mkhraisha: One other question, did objectors ask for specific method? Do we believe if that’s the case, they’ll be happy with just interop definition?.

Dave Longley: kristina_: i think what people are really looking for is some measure of interoperability – so they know whether it is wise to commit to using a particular method or not..

Brent Zundel: In view of the objectoirs, the specification of DID Methods is the only reasonable way to demonstrate interoperability. If we don’t take that route, DID Resolution route – like nailing that down, we have additional task that that defines interop just as fully as specification of DID Methods..
… on interoperability track, on Rubric, how does a solid rubric demonstrate interop.

Kristina Yasuda: @dave and at least now the current state is that people achieve interop by using did:key and did:web while looking into other methods..

Kristina Yasuda: @dave but I might be missing the recent developments in the market.

Brent Zundel: Yan, I’m a bit confused, how DID Methods should be definied in interoperability sense, we could define method of specifiatoin to define a method..
… The current specification, has normative guidance on how to create DID Methods..

Dave Longley: kristina_: sure – i just think that what people want is to understand the level of interop for each DID method so they know whether to commit … one way to achieve this is to make some of them standards, however, that path also brings with it a cudgel that can be wielded against DID methods that are not standards but that still have the same (or greater) interop..

Joe Andrieu: The main mechanism of rubric is about differentiation, method A and method B, can on feature basis have criteria on interoperability, currently in published version – does a DID Method support any verification relationship? That’s a lack of interop for methods that don’t, curating moves into standards space, we can deal w/ DID Methods that are not interoperable..

3. Open Issues on DID WG Charter.

Kristina Yasuda: dlongley: sure, hence the current conversation of pros and cons and both. and I am trying to understand how alternatives are more straightforward to prove interop that standardized did methods.

Orie Steele: -1 to “one key representation to rule them all”… we addressed this in the WG… I feel like a broken record here..

Dave Longley: kristina_: they may not be as straightforward … but they may be more fair … and those two things are sort of “meta” potential trade offs themselves..

Brent Zundel: comments from microsoft: want to add cross-compat guidelines for implementers, want to focus on one did method for consolidation, want to work the WG to define an actual DID method..

Kristina Yasuda: to clarify, it does not have to be one, what Travis meant was MTU DID method.

mkhraisha: MTU?.

Orie Steele: kristina_ thats a huge difference..

Brent Zundel: there’s interest in the issues to standardize DID methods. the next issue is manu’s take of the formal objection, request being that they want to see the standardization of 3 DID methods. so we think the need is here..

Dave Longley: MTU = mandatory to use / implement.

Brent Zundel: we’d need to have a killer test suite to demonstrate interoperability. manu says that DID key could be something we could standardize, and also DID web. manu also expands on the formal objections, and follows up that we don’t standardize DID methods that are not environmentally sustainable. end recap of the conversation..

Kristina Yasuda: Orie: can sync with Travis.

Ryan Grant: …but objects for an excellent reason that NO ONE HAS ANSWERED.

Brent Zundel: should we allow next WG to talk about DID methods? my read of the room says that there is interest, and only one person who would object to a charter including this language. seems that the great majority of people agree to have this in the next WG..
… is there interest in introducing language to the charter that would allow us to publish a recommendation-track document on DID method resolution, up to a working draft level? is there anyone who would be opposed to that?.

Joe Andrieu: fwiw, I believe Ryan has convinced me that opening the door to specific methods is a problem.

Manu Sporny: concern is asking markus to work…markus, is this realistic in the next 18 months to put forward a DID resolution specification, given your workload?.

Dave Longley: JoeAndrieu: i’m somewhat in that camp – but mixed … saying we can discuss whether we do FPWD is not the same as taking it all the way to REC..

Markus Sabadello: i think it is, i would like to see it get added and would work on it a bit more. yes, i work on a lot of things, but my business work aligns here. recently, in the last few weeks/months, we had several contributions to the DID resolution specification as it exists in the credentials community group, so yes i’d be interested..

Brent Zundel: if there are other folks who want to jump on the queue to stimulate conversation?.

Markus Sabadello: Current DID Resolution specification in CCG: https://w3c-ccg.github.io/did-resolution/.

Ryan Grant: the principles of consensus under the w3c are that you’re focusing on engineering, and if someone has a good engineering question, you should be able to answer it. so…appealing to consensus, the group should have technical reasons instead of vote-count reasons. i don’t think anyone has offered an engineering reason, and focusing on interop cannot be done without specifying a standardized DID method to do the interoperation..
… formal objectors have already been declared “wrong” in the sense of what w3c is working for, insofar as consensus and widely broadly usable web, and we can meet the bar of being interoperable and demonstrating it, and we do not need to take the formal objector’s word, so we can do it the right way..

Manu Sporny: i wanted to provide an engineering rationale for DID methods. at the end of the day, you make a request for DID methods and get a bunch of bytes back. there needs to be a specification for what those bytes are. you can’t write a test suite for something that is not realized in some kind of syntax. i think the objections to did-core, did have some relevance..
… the way that we had to prove interoperability, we really had to bend backwards, bend ourselves into a pretzel, just to demonstrate interop just one did-core, so fundamentally we have to define something that is testable. the concern i have with what joe’s proposing with the rubric, is that we put ourselves back into a situation, where we are speaking about things in the abstract..

Orie Steele: DID Core objections were a function of 2 things… failure to define did resolution… failure to properly signal ESG concerns in the core spec regarding operating blockchains… only 1 of these things can be solved with a test suite..

Manu Sporny: the way to get out of this is to have a really solid test suite on something that is testing bytes, you ask for a DID, you get bytes back, and you test those bytes back for a very specific set of structure. any DID method, or most would be able to provide. let’s say it’s not did-web or did-key, it could still provide that. rgrant, did you find that engineering rationale convincing? do you have a counterproposal?.

Ryan Grant: by choosing to bless certain DID methods, this WG will destroy the decentralized aspect of decentralized identifiers. i think this is a bigger risk than arguing about what interoperability is. if we pick, then we will always be fighting with each other about who to pick next. who has the business pull to say “i’m next”. decentralized identifiers can be legitimately decentralized, and the bytes can be a matter of proving impls..
… the proven impls are out there, and they do send bytes over the wire, so the fact that did methods must all be published through the w3c instead of other ways, is a red herring. if this group accepts the reframing of what a DID method is, that would destroy the decentralized aspect, and that would be terrible..

Joe Andrieu: +1 to the risk to decentralization from picking winner.

Brent Zundel: i wanted to clarify the response to the formal objections–the decision to overrule at this time the entirety of the formal objection. it’s not a complete rejection of those ideas. it’s saying that at this time, we can believe that we can move forward in spite of these formal objections..

Phil Archer: +1 to brentz.

Brent Zundel: the objection is there, and if we don’t include language in the charter around possibly having the conversation about addressing them, then we’re hamstringing ourselves. i’m not saying we’re defining did methods, but we need to talk about it. if we talk about it for two years, and cannot come up with a did method specification, then we will have the notes to show we tried. it could be the case where we come up with no decentralized identifiers[CUT].
… and succeed this way in decentralization..

Orie Steele: +1 Joe.

Joe Andrieu: picking winners and losers is indeed risky. however, manu, we do have bytes being tested from did-core. where we don’t have interoperability is DID resolution. so i take from your argument that we must define DID resolution’s outputs, not that we have to define specific DID methods..

Dave Longley: +1 to Joe.

Manu Sporny: fair point, I’m on the fence about that particular point. our current test suite presumes a certain output and tests again that. we don’t need to standardize any DID methods to show that did-core works as designed. i’m pretty sure it won’t be convincing to the objectors (this approach)….if we’re not allowed to recharter the work at all, then there’s no anything–no did resolution spec, did methods or not, etc..
… we talked about the dangers of putting in the charter, putting it scope, and messing it up. we have not addressed the danger of not having it in the charter at all, and the work just stopping. rgrant_, would your objection be withdrawn if we just focused on DID resolution?.

Orie Steele: -1 to “if W3C doesn’t give a charter DIDs are dead”… there are other standard orgs (IETF,ISO, DIF) that can take the work..

Kristina Yasuda: -1 to not talking about DID methods in the charter.

Ryan Grant: that’s correct, i would not object to DID resolutions, so long as this group is not picking a DID method to standardize..

Manu Sporny: then we can ask if objectors would object to the charter, and framing it that way..

Orie Steele: I’m a +1 generally to being allowed to discuss did methods… I doubt that W3C will succeed at standardizing a truly decentralized method, but it deserves a chance to try..

YanZhang: there are multiple blockchains that come out, Ethereum became that standard. we didn’t specify something upfront, and it was based on market adoption. we have to find the balance between decentralized and centralized. we can monitor the performance of each DID method in the marketplace, and allow that to determine what is used. the general public needs something simple to use, so we shouldn’t pre-define methods, but we can define test suites[CUT].
… performance of each method, allowing the market to choose. at the end of the day, hundreds of DID methods probably won’t work, and there will be a few. as a WG, we should focus on tools to evaluate and guide the methods..

Joe Andrieu: revisit allowing objectors to object informally. if objectors want to object, they can come here to object. some of those objections, i believe were outright not legitimate, based on political or business motivations, and did not rely the goals on the DIDs. we should build a bigger tent, but not allow people with business or politic interests dictate what we’re doing if they don’t show up here..

Orie Steele: +1 to focusing on objections that can be addressed, did resolution is a thing we can fix..

Phil Archer: if you think any members org on the planet doesn’t listen to its big members more than its smaller members, you are mistaken..

Joe Andrieu: i just want them to do it formally so it’s on the record, so we can point out the fallacies of the arguments by these orgs. yes, different orgs have different powers, and we shouldn’t alienate all the objectors. for the vision of what DIDs are, what are the objections that will make it better, and what haters will just hate because it undermines their business model?.

Kristina Yasuda: i don’t saying that objectors keep objecting is a constructive argument. at microsoft, we did make a comment that from an interop perspective we’d like to see another implemented method, so standardizing DID methods would be helpful for the engineering reasons mentioned by manu earlier. i do see the benefits of standardizing DID resolution too..
… i don’t see why it needs to be mutually exclusive. i would not support just discussion the resolution without also supporting the potential to discuss DID methods. we do need to discuss DID methods, and it is immature to assume that DID methods will be chosen for “political reasons”. this WG is known for having a robust decision-making process with rough consensus. we’re currently talking about did-key and did-web, and we may need to pick a[CUT].
… to talk about too. not having an opportunity to even discuss? that doesn’t sound like a good alternative.

Kristina Yasuda: +1 brentz.

Phil Archer: +1 brentz.

Orie Steele: +1.

Brent Zundel: chair hat off. we’d like to see the conversation happen about did methods. whether we standardize them or not, it’s important we have that conversation..

Manu Sporny: +0 torn :).

Ryan Grant: what i hear is a restatement that this WG must pick a certain DID method to demonstrate interoperability. however, i still haven’t heard the engineering case for why this necessary. DID methods already exist, so the fact that DID methods defined this group need to exist is what we’re arguing about..
… i hear people saying don’t worry about, we’ll design the worse DID methods, or we’ll pick them off the shelf. i formally object if we have anything in the charter that says we are picking a DID method..
… if we include doing the work of addressing the previous formal objections, that could be okay. i heard that DID resolution could be enough to demonstrate the engineering requirements for interop, so we can move forward with that..

Manu Sporny: i wanted to agree with rgrant_, the engineering argument for specifying a did method is weaker, but not necessarily eliminated completely. i wanted to clarify. we’re not picking bad DID methods, we’re not going to standardize bad DID methods. they’re imperfect. did-key doesn’t have rotation, did-web has security aspect considerations..
… we don’t have a DID method that has 100m people using it. if we had that, then it would be hard for us to watch that go by without considering it. there’s nothing out there like that now. i hear rgrant_ and what JoeAndrieu is saying right now. but talking about these things, i don’t know why we’re talking about taking this off the table. if it doesn’t happen here, it’ll just happen elsewhere..

Brent Zundel: q.

Joe Andrieu: we don’t have a huge number of publicly used DID methods. it is inevitable that we will create bad DID methods. we don’t have a standard criteria for what is a “good” method that we should standardize with an SDO. i think that’s what is a good discussion to have the community–if it’s going through the gauntlet of standardization, what should this DID method be able to do?.

Ryan Grant: i wanted to answer manu’s point about which DID methods are standardized by pointing out that of course i’m more concerned about the precedence of when i can standardize my favorite DID method. that’s what i’m arguing about. i don’t want to come to you. i want a decentralized standard..

Kristina Yasuda: and if your DID Method is a great one and fits a certain use case perfectly, standardizing a DID method will NOT stop anyone from using it.

Ted Thibodeau Jr.: other)..

Ryan Grant: further, if the measure is totally user-based to demonstrate usability, then the answer is to go to the incumbent identity providers. your gmail, icloud, etc. so, that’s not the right measure. the right measure for why we want and need DIDs is to provide specific solutions for going your own way. if this group comes together and recognizes the reasons for going your own way, then it will fail. we don’t have a standard to do that. that’s why i[CUT].
… that’s why i’m going to formally object to opening up that can of worms, because it doesn’t have an engineering basis, and will be opened up to politics et al.

Manu Sporny: Ryan has a legitimate point about “just go to the incumbent identity providers”… he’s not wrong..

Charles Lehner: i’m observing the contention of standardizing did methods, and observing there are other WGs or new WGs, and perhaps they want to standardize DID methods and perhaps that would help them..

Brent Zundel: now that it’s a standard, folks anywhere can specify DID methods.

Orie Steele: +1 cel, there are other places to do politically contentious work… ISO for example..

Brent Zundel: a proposal, not official, but a thought. the language in this PR is handwavy and general, my proposal is to make it even more handwavy and more general. and borrow some language that someone said–we should add to the charter that this group will come to consensus about the ways to address the concerns brought up by the formal objectors..
… which may include recommendation documents that do not go past a draft stage. rgrant_ would you object to this broader language going into the charter?df.

Kristina Yasuda: -1.

Ryan Grant: i heard this group will come to consensus on the objections brought up by the formal objectors….

Brent Zundel: attempt.

Kristina Yasuda: we need to say more clearly what those objections are.

Ryan Grant: i have to come to every meeting to explain the things and be consistent, and hold my formal objection in reserves. i understand that i disagree with microsoft, google, apple, mozilla, and i understand that. i think you’re just asking me to come to a lot of meetings and be persistent with my objections. so i don’t think it’s a good use of anyone’s time..

Orie Steele: Brent make sure to tell the objectors what you just said..

Kristina Yasuda: you disagree not only with those you listed, as you heard there are other companies interested in talking about DID methods who did not object.

Kristina Yasuda: ^ @Ryan.

Brent Zundel: if you’re not willing to come to meetings and talk about the things you care about, the things you care about will not be realized in specifications and WGs. i appreciate you’re upfront about it, but if you want your thoughts incorporated you do need to show up..

Ted Thibodeau Jr.: i am very familiar with attending a lot of meetings and making an unpopular position well-known, well-heard, if not well-understood by the other participations. sometimes it’s what you need to do for the unpopular thing to be understood by everybody. the way this develops is by putting things that not everyone agrees with, and working together to figure out consensus..
… can we implement this in a way that satisfy everyone’s use case and allow the work to continue. i suggested a line above towards this effect, but i anticipate building a test suite that satisfies the requirements, we’ll have implemented an unnamed DID rubric..
… none of the DIDs will be perfect for every use case, even if we picked a DID method today, it would say that “it’s satisfying these axes but not those axes”.

Joe Andrieu: i appreciate the increased focus on the language, but i’m not sure we need that at all. we do need to stick to legitimate objections, i’m tired of addressing illegitimate ones..

Ryan Grant: wanted to say for the records that DCD has representatives at these meetings and we’ll be there. i think there’s a technical way forward by focusing on DID resolution. one might call it an “abstract DID method” may need to be formalized. i believe it’s acceptable to reference existing DID methods for interoperability purposes, in doing so, we would not make the did spec weaker, but sufficiently prove it’s implementable and will further guide p[CUT].
… implement it..

Orie Steele: +1 phila.

Ted Thibodeau Jr.: +1.

mkhraisha: +1.

Phil Archer: there’s a lot of good stuff here, i think we’re heading towards consensus. one of the reasons the objections were overruled was that what they were asking for was out of scope for the charter. therefore, i think the new charter should specifically say what we’re doing that the old charter prevented us to do, so we can address those points..

Brent Zundel: +1.

Kristina Yasuda: +1.

Shigeya Suzuki: +1.

Phil Archer: if we do not have an opportunity to revise the charter to include the specific items we will address, then it may fall flat. i have a lot of sympathy for what rgrant is saying and others, and if we discuss and decide not to specify DID methods, then that’s a strong argument..

Kristina Yasuda: +1 brent.

Brent Zundel: what the objections fall down to is how would i as an implementor, without any contact with the group, produce interoperable implementations. if we each sat in a room with a computer implemented the same specification, would it be interoperable? however the group wants to do that, we need to..
… the way that the objectors have expressed how it ought to work is via specification of DID methods..

Joe Andrieu: +1 for resolution (I don’t need to repeat what Brent just said).

Brent Zundel: i personally disagree with that, i think DID resolution is that way to do that. i believe in that as a way forward. but i also believe for us to get the charter off the group, we're going to need to talk about DID method specification as an approach. we need to be able to talk about it--we may produce a note that says why it can't happen as an outcome, but only if it's in the charter</chair hat off>.

Orie Steele: +1 brent.

kdeangs1: +1 to the rant.

Ryan Grant: objectors are not objecting to the wording used in core specification, they want examples. if you believe did specification is good, then it’s sufficient for two people to sit down and making it interoperable for themselves. i think it’s a fine line between example specifications and example code..
… i think the way forward is to hold the line on not picking winners and losers in the decentralized identity group..

nms01: A registry of known DID methods is a resolution method. A registrar makes sure different methods have different names and duplicates are filtered. Registries address interoperability while avoiding picking winners/losers as long as the registry is open..

Joe Andrieu: i think we need to define DID resolution independent of the method..
… i thought you wanted to supported defining DID methods..

Brent Zundel: that’s not what i said, i said i supported having the discussion.

Joe Andrieu: i’d rather spend time on DID resolution instead of discussing DID methods.

Dave Longley: +1 to Joe.

Manu Sporny: there seems to be strong consensus that we’d rather focus on resolution, but i do think that this conversation is not gonna go way, and it’ll come up over and over again. we’re not going to make it go away. part of me is wondering is how do we end up in the nightmare scenario of picking a winner?.

Dave Longley: perhaps we can say that we would focus on resolution and demonstrate that it works with at least one example DID method as opposed to standardizing those methods..

Brent Zundel: +1 to Joe.

Manu Sporny: i imagine some subset of the group will formally object to picking of winners and losers..

Ted Thibodeau Jr.: +100.

Manu Sporny: there’s a big difference between being able to talk to something versus coming to consensus on a global standard. brent, i believe you’re proposing that we just talk about it. probably we won’t be able to come to consensus, and that would be the end. i share the same concern that rgrant brought up of picking a winner. i don’t think the personalities in this group will let that happen..

Ryan Grant: i don’t think we would be the ones picking a winner, others may hold up the same words and assume we picked a winner. or others could be unimpressed with the methods and drop the spec. so i think it’s not okay to make these decisions. if someone wants to create new language that could include a particular DID method specification, please let me know. i would have to object later if we move this direction..
… it will be formally objected by me if we add this to the charter specifically..

Pierre-Antoine Champin: the current text doesn’t say that we will, but that we may. the current text exclusively restricts the state of WG from becoming a recommendation, so i believe the concerns you raised are addressed by the text..

David Ezell: i want to give a comparable non-DID, non-security-related example from old W3C history. i was chairing the XML schema WG. i had a lot of people who believed there was one single way to define a language, and XML schema allowed you to integrate into any of those systems–a lot of debate about how people will view the spec: too hard to understand.
… gentleman from IBM offered to write a primer on an example to improve the readability of the spec, but not necessarily picking the winner..

Kristina Yasuda: rgrant: can you propose the language in the PR.

Ryan Grant: can i strongly suggest the group help me find better wording around the word “MAY”?.

nms01: The charter should include DID resolution..

Brent Zundel: closing thoughts. thanks scribes. very much appreciate the comments + conversations. it takes courage to talk about what’s important to you. grateful for the work in this group, just grateful people are actively trying to come to consensus on this. let’s continue the work on the PR, my hope is to wrap up this draft charter in the next month or so..
… then we can pass to AC. officially, the WG is chartered to the end of this year. don’t be surprised if you get a message for another WG meeting..

Joe Andrieu: there’s a small change i’m trying to get in to the DID method rubric, so look out for that.