14:58:34 RRSAgent has joined #did 14:58:38 logging to https://www.w3.org/2024/07/11-did-irc 14:58:38 RRSAgent, make logs Public 14:58:39 please title this meeting ("meeting: ..."), pchampin 14:58:55 present+ 14:59:03 Chair: Dan Burnett 14:59:18 Topic: Agenda Review, Introductions 14:59:38 meeting: Decentralized Identifiers WG 14:59:39 present+ 14:59:41 present+ 14:59:56 RRSAgent, draft minutes 14:59:58 I have made the request to generate https://www.w3.org/2024/07/11-did-minutes.html TallTed 15:00:06 RRSAgent, make logs public 15:01:32 present+ 15:01:40 JoeAndrieu has joined #did 15:01:40 decentralgabe has joined #did 15:01:42 tminard has joined #did 15:01:42 present+ 15:01:54 scribe+ 15:02:02 phila has joined #did 15:02:06 present+ 15:02:10 present+ 15:02:21 present+ 15:02:23 present+ 15:02:25 present+ 15:02:30 present+ 15:02:51 JennieM has joined #did 15:02:58 present+ 15:03:01 Topic: Agenda Review 15:03:07 bigbluehat has joined #did 15:03:10 markus_sabadello has joined #did 15:03:58 KevinDean has joined #did 15:04:09 q+ 15:04:14 ack pchampin 15:04:18 burn: topics https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0012.html ... reminders first, then ARF/ EU note, any changes? 15:04:30 present+ 15:04:56 pchampin: small announcement ... github repos have been changed to automatically generate teams by the w3c systems. we no longer need to add/remove WG participants. side effect - if you lose access to the repo if you github is not linked to your w3c account 15:05:20 ... link your account on your w3c page, please do that or you could lose github access 15:05:22 Topic: Reminders: TPAC, Special topic call, and minutes approval 15:05:40 your W3C account is accessible at https://www.w3.org/users/myprofile 15:05:46 https://github.com/w3c/did-wg/issues/57 15:06:02 burn: first reminder about TPAC ... please register if you haven't yet. if you have topics/presentation please look at issue 57 to add comments in there. 15:06:07 https://doodle.com/meeting/participate/id/e0X6wEye 15:06:16 ... we'd like to remind you to fill out the doodle poll for finding a time for a special topic call 15:06:16 What is the agenda for that call?d 15:06:17 s/effect - if you lose access/effect — you lose access/ 15:06:41 decentralgabe: i will extend the poll a few days 15:06:46 q+ 15:06:54 ack ivan 15:07:22 ivan: the poll is for a regular special topics call? not a single call? 15:07:33 smccown has joined #did 15:07:47 burn: yes, it will be a reserved spot for a special topics call when we want them. do not look at the specific dates in the poll, just days/times during the week 15:07:48 So this is not a specific call, but just choose an ideal time if we can be consistent. 15:08:26 danpape has joined #did 15:08:36 ... minutes approval: the minutes will be posted within 1 day of the meeting. if no objections on the mailing list, or by the following week's call, then the previous minutes are considered to be approved 15:09:04 ... we forgot to mention this before, so we will extend the review time for the first week's minutes and today's minutes until the end of next week's meeting 15:09:12 present+ 15:09:26 q+ 15:09:28 ... please send an email to the mailing list if you have any concerns before the end of next week's call. any questions? 15:09:39 Knj1978 has joined #did 15:09:47 ack pchampin 15:09:54 https://www.w3.org/2019/did-wg/ 15:10:28 pchampin: historically we've published our minutes on our homepage, which is different from other groups. https://www.w3.org/2019/did-wg/ -- the difference is that it requires manual intervention. I do my best to publish the day after the meeting 15:10:50 ... may be some disruption during the summer. may need help from Ivan 15:10:57 burn: if not enough review time, we can extend time 15:11:04 Topic: Response to EU DID Usage 15:11:07 ivan: will help 15:11:20 scribe+ 15:11:52 decentralgabe: regarding EU's architceture reference framework, an issue was raised discouraging use of DIDs. Kim and others wanted to make a statement in favor of DIDs. 15:11:54 https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/205 15:11:55 https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/278 15:11:56 ... Kim has done that. 15:12:43 ... not enough time for this group to review before it went out, but we would like to gather support from the group in the linked issue. 15:13:10 q+ 15:13:16 q+ 15:13:23 burn: will probably hear more about this in coming weeks. important that there is sufficient time to review, so we did not want to throw this on the group mid week 15:13:27 q- 15:13:29 ack manu 15:14:15 identitywoman has joined #did 15:14:17 manu: +1 that was a good call. nice to see support for the statement that Kim raised. my hope is that we are able to make more formal support for this kind of thing. for any state/nation that are looking at digital ID, they should pick future proofing, good privacy guarantees, etc. all of us are here for that. I hope we can make a more formal position statement as the DID WG 15:14:45 present+ 15:14:52 burn: thanks Manu. everyone please review that. the chairs would like to see if we could get a formal statement from the group even if it's coming later. coming later because we're careful, and that would be more meaningful as well 15:14:53 Topic: DID Core 1.1 Roadmap 15:15:09 https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/att-0009/2024\_DID\_Core\_v1.1\_Roadmap.pdf 15:15:25 ... main topic of the DID Core 1.1 Roadmap. please see the link Manu sent out 15:15:36 link in here - https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0009.html 15:16:32 manu: our charter has us working on the DID v1.1 deliverable. where are DIDs used these days? mostly Verifiable Credentials. they have identifiers in them. we want to use identifiers that have some cryptographic guarantees, be able to prove the identifier is yours 15:16:43 s|https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/att-0009/2024\_DID\_Core\_v1.1\_Roadmap.pdf| https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/att-0009/2024_DID_Core_v1.1_Roadmap.pdf 15:16:59 RRSAgent, draft minutes 15:17:00 I have made the request to generate https://www.w3.org/2024/07/11-did-minutes.html TallTed 15:17:31 ... we use emails, phone #s, URLs/DNS based, govt issued IDs, SSNs, NIDs, etc. There are problems with these identifiers. They can be compromised, depend on a centralized authority. Not portable between systems. 15:18:02 ... if an entity gives you an identifier it can be locked in there. email/phone don't preserve privacy. they follow you around for the rest of your life. many problems with these identifiers. that's why we started this work on DIDs 15:18:46 ... DIDs are globally unique; highly available; cryptographically verifiable; no requirement for a central authority. cannot be confused with another identifier in the world. truly unique. can be used as a tracking token (not good). but you can generate many of them 15:19:51 ... in theory they are highly available. if you use a verifiable data registry like IPFS, blockchain, DHT, you can make sure the ID is highly available. cryptographically verifiable = you can prove the identifier is yours and you have access to private key material 15:20:31 ... you cannot do that with a SSN, can kind of do it with an email, but not really decentralized. no central authority = DIDs are agnostic to the underlying backing storage mechanism. you can use blockchains, DHTs, other types of non-centralized mechanisms 15:21:27 ... [slides that show what a DID looks like] ... scheme identifier (always `did`) then the method (196 now!) - we have a lot and still growing, then a DID Method specific string which gives the identifier uniqueness 15:23:17 ... used in ecosystems like Verifiable Credentials - 3 party model. issuer -> issues to holder. holder -> pass on to verifier. underlying it all are identifiers, like DIDs. agnostic to the underlying data registry. can be built on an ephemeral concept like did:jwk, web based mechanisms, bittorrent like did dht, btc like did:btcr, a number of eth based methods as well. all with slightly different characteristics for distinct us 15:23:17 e cases 15:24:19 ... we have been at this for 10 years! foundational work around DIDs goes back 10-20-30+ yrs ago. Incubation was May 2014-2019, first WG in 2019. v1 ran 2019-2021. now working on v1.1 and resolution 15:25:39 ... what can we do within our charter? Class 1-3 changes. 1 - minor, like a link fix. 2 - change spec text, can be small or more significant text refactor. 3 - a significant change...can change conformance rules. can modify to make current things conforming that weren't before and vice versa. 15:25:39 -> The official terminology for the classes in the W3C process https://www.w3.org/2023/Process-20230612/#correction-classes 15:26:05 ... we can not add new features. we can fix text, modify conformance rules, fix things that were a little loose before; tighten up language to help implementers. 15:26:11 q+ to comment on maintenance 15:27:15 ... what does this actually translate to? examples: modernize examples (current ones are old). we have a Controller Document spec now in the VCWG, which has overlap with DID Core, we could clean up the references. 15:27:19 ack burn 15:27:19 burn, you wanted to comment on maintenance 15:28:15 burn: You may start disagreeing with me on the changes, but this is supposed to be maintenance WG. Ideally the changes should fix well known bugs, clarifying things that are unclear, like vague text. Often, there could be differing interpretations that we could make more precise. We are not supposed to change fundamental concepts. 15:29:13 ... there are some strong edge cases where we could disagree on changes being proposed. Chairs will be watching out for attempts to seriously change the notion of what the spec is....that can lead to failure 15:30:03 manu: fantastic clarification! some of these bullet points (in slide) are meant to be controversial. there is a lightweight way to implement, and a debatably heavy-weight way which would be pushing the class 3 language. as an editor I would avoid doing massive changes to the document, especially given what Dan said. 15:31:08 ... Controller Doc alignment would be good. It would layer things in a nicer way. Started with a copy+paste from DID Core with the intention to not break DID Core. Should be totally aligned conceptually with DID Core and should not change any implementation 15:32:16 ... DID Core specializers Controller Document. We could simplify/remove the abstract data model ... was controversial when it went in, now we are seeing people aren't really leveraging it. There is an option for us to do it or decide it's best to revisit in 2.0. We want to keep the group focused on resolution. 15:32:38 s/specializers/specializes/ 15:33:24 ... We could move "DID Resolution" to the DID Resolution. Now we're chartered to work on DID Resolution, can move interfaces into the new spec given our charter. Finally...there is movement to standardize DID methods, you will probably hear more about that over the next weeks/months. 15:34:15 ... It would be interesting if this group could - not endorse - since that's off the table - but we might want to spend time providing non-blocking guidance to help organizations who are standardizing DID methods 15:34:47 q+ to set some context for discussion after Manu's done 15:35:07 maybe we need a phone home to demonstrate use... ;-) ;-) 15:35:09 ... we are not able to, as a WG, bless/endorse a certain DID Method. Just a couple ideas. There are 30+ issues we need to process. That's what it looks like the DID Core work might become. Would love to hear from others 15:35:11 ChristopherA has joined #did 15:35:16 ack 15:35:49 q+ 15:36:00 burn: We have time open for discussion. There is not a specific requirement on what we discuss. We are the beginning of this group. There should be plenty of time to discuss all of these topics. The chairs are interested in hearing 'big issues' / concerns so we can schedule time for discussion appropriately. 15:36:47 ... if anything big comes out let's be aware of it early rather than late. We may wrap up with specific items, and may not depending on how discussion goes. We will end this discussion at 10 minutes to the hour. We have about 13 minutes. 15:36:50 ack 15:36:53 ack ChristopherA 15:38:16 ChristopherA: WGs can also do notes, and things that aren't specs. We have a couple on our agenda. We haven't really talked about, parallel to things in the VC world, things like unlink-ability and herd privacy. A DID-like document where you can have 100k+ proofs of keys. Proofs of inclusion to show you're in a DID Document. Is there desire from the community to puzzle out opportunities for anti-correlation, herd privacy, sele 15:38:16 ctive disclosure in DID Docs? 15:38:27 ... could be a possible note 15:38:34 q+ to talk a little about resolution 15:39:02 s/ctive/... selective 15:39:10 burn: The group is authorized to do certain things, we can do other notes if the group decides to do so. If you would like to create a separate non-normative document, I suggest sending an email to the mailing list. Propose something for the group to consider as a note 15:39:10 ack phila 15:39:10 phila, you wanted to talk a little about resolution 15:39:19 s/privacy, sele/privacy, 15:40:41 something i think/hope our community can start doing is insert the word "unwanted" before correlation ... since identifiers are of course *for correlation*, but there is often correlation you don't want, happy to hear about interesting tech around preventing unwanted correlation. 15:40:41 phila: This group is focused on privacy/security...I am here for focusing on Resolution. Potentially, and have spoken to Markus, ... without changing what's there now, expanding the scope of what a resolver might expect. Would like a service to resolve DIDs and identifiers that we work with at GS1, DOIs, ID numbers, other things that are not DIDs 15:41:17 q? 15:41:36 q+ 15:41:39 ... have an idea for a resolver for DIDs which could also handle x,y,z other identifiers. There could be an ecosystem of such systems. Could find a resolution service that could handle the identifier you are looking for. Does this have traction? 15:41:40 ack markus_sabadello 15:42:31 q+ to note generalizing the "input URL" to the resolver. 15:42:49 markus_sabadello: Not sure if possible in this group to standardize something other than DIDs. Could advertise other capabilities, which I think is a good idea. Resolver can resolve multiple DID methods, and perhaps other types of identifiers ... 15:43:16 q+ 15:43:16 phila: yes that's what I mean. let's not define a resolution method for something other than DIDs, but advertise other identifiers a resolver may support 15:43:18 q+ 15:43:18 ack manu 15:43:19 manu, you wanted to note generalizing the "input URL" to the resolver. 15:43:37 q? 15:43:40 ack burn 15:43:40 burn, you wanted to set some context for discussion after Manu's done 15:44:04 manu: Phil what you're saying is interesting. Parallel to what we've had to do in the VC-API. Originally focused on W3C VCs, we found the design pattern would work for any type of credentials (mDL, mDoc, something else). 15:44:09 KevinDean has joined #did 15:44:53 q+ 15:45:10 also, this "keeping the door open to other identifiers" looks consistent with the generalization of DID documents into Controller documents 15:45:22 ack ivan 15:45:25 ... +1 that DID Resolvers should not be focused so much on DIDs that they are impossible to be used for other types of identifiers. Since the minimal DID Document really just is an identifier. Those who know how Linked Data works know this is just another resource. We have an open identifier scheme. Can express many things in a DID Document, not just keys. 15:45:46 ack markus_sabadello 15:45:54 q+ ivan 15:45:58 q+ to bring up "the big rocks that we have to DECIDE to move or not". 15:46:11 markus_sabadello: another approach to resolve other types of identifiers is to define a new DID method that does this 15:46:30 ack KevinDean 15:47:20 KevinDean: having come from the DID world myself with GS1... the approach taken has been to make a statement of principle that any work done shall not prevent adaptation of this standard by other standards. we shall not do anything deliberate to close off from other identifiers, but could close things off for some people. 15:47:34 ack ivan 15:47:35 ... not do anything that would deliberately impede adaptation from others 15:47:38 @KevinDean +1 15:48:14 zakim, close the queue 15:48:14 ok, burn, the speaker queue is closed 15:48:21 q+ to note that if we don't have browser vendors involved, doing WebIDL might not be worthwhile. 15:48:21 ack manu 15:48:21 manu, you wanted to bring up "the big rocks that we have to DECIDE to move or not". 15:48:21 ivan: with the resolution spec do we aim to support implementations in browsers as well? Like a WebIDL interface? Do we want to get implementations in terms of browser extensions? I believe it would make a tremendous difference in the acceptance of DIDs 15:48:38 q+ 15:49:32 manu: If we don't have at least 1 browser vendor involved, specifying WebIDL may be premature. We want that to be true, but we need browser vendors involved. Might want to talk to Brave. IPFS has some traction with Firefox. Need to get a vendor involved. 15:49:58 q+ 15:50:33 q- 15:50:35 ... big rocks: need controller document alignment. the other is this suggestion that the abstract data model is adding too much complexity. I do expect that to be an involved debate. then there is a question of our media type, which we tried to register. We got a 'I don't know what that media type means' response from the IETF 15:51:03 ... now we have clarity and know what we might want to register to have that discussion. Those are the 3 big things I see us needing to have a discussion on sooner than later. DID parameters too 15:51:10 +1 to parameters/paths being bigger 15:51:32 zakim, open the queue 15:51:32 ok, burn, the speaker queue is open 15:51:34 burn: I want to make sure we're focused on DID Core here. We will have more time to focus on resolution, registries, etc. What are specifically the rocks for DID Core? 15:51:38 q+ 15:51:43 ack ChristopherA 15:51:45 q+ 15:52:43 ChristopherA: do we have any people from the KERI community here or who have been involved? there has been a big rock around things like envelopes, micro ledgers, the did repo which used git, where a DID Document can be created, but is not actually signed with something like an LD signature 15:52:49 JoeAndrieu9 has joined #did 15:53:03 q+ to talk about the abstract data model 15:53:30 ... instead it is constructed from another data model. There was a debate on how important round tripping is, conformance with security proofs, etc. I would recommend to the chairs that if there is not an Invited Expert from the KERI community, or a member, we may want to invite one of them. 15:53:55 burn: I will have to leave then hand the meeting over to Will to finish 15:54:04 ack markus_sabadello 15:54:16 zakim, close the queue 15:54:16 ok, burn, the speaker queue is closed 15:54:25 markus_sabadello: Agree with Manu on alignment of Controller Document, and the abstract data model are important issues we should talk about first. 15:54:30 ack JoeAndrieu9 15:55:02 JoeAndrieu: I am the individual who said we should look at the abstract data model. I don't believe it has been tested, or is testable. I know this will be a longer conversation, but want to introduce that position. 15:55:04 q+ 15:55:05 q? 15:55:08 Thanks Joe! Agree that's a good conversation to have. 15:56:13 ivan: I want to emphasize my personal view - not that of W3C - removing the abstract data model goes beyond what we're chartered to do. any change that makes a conformant implementation non-conformant should be a big no-no. We do not know if there are implementations that rely on the Abstract Data Model, they could become non conformant. 15:56:25 ... should not be able to make changes of that affect 15:56:51 Wip: That is it today, thanks for your contributions. Next week we will be focused on registries. Also looking for editors of registries! 15:57:00 https://github.com/w3c/did-spec-registries/issues/565 15:57:07 RRSAgent, make minutes 15:57:08 I have made the request to generate https://www.w3.org/2024/07/11-did-minutes.html pchampin 15:57:15 ^^ take a look at that and add comments before the discussion