Meeting minutes
Agenda Review, Introductions
Agenda Review
burn: topics https://
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 — you lose access to the repo if you github is not linked to your w3c account
… link your account on your w3c page, please do that or you could lose github access
Reminders: TPAC, Special topic call, and minutes approval
<pchampin> your W3C account is accessible at https://
<burn> w3c/
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.
<burn> https://
burn: we'd like to remind you to fill out the doodle poll for finding a time for a special topic call
<ChristopherA> What is the agenda for that call?d
<burn> decentralgabe: i will extend the poll a few days
ivan: the poll is for a regular special topics call? not a single call?
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
<ChristopherA> So this is not a specific call, but just choose an ideal time if we can be consistent.
burn: 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
… 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
… please send an email to the mailing list if you have any concerns before the end of next week's call. any questions?
<pchampin> https://
pchampin: historically we've published our minutes on our homepage, which is different from other groups. https://
… may be some disruption during the summer. may need help from Ivan
burn: if not enough review time, we can extend time
Response to EU DID Usage
ivan: will help
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.
<pchampin> eu-digital-identity-wallet/
eu-digital-identity-wallet/
decentralgabe: Kim has done that.
… 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.
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
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
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
DID Core 1.1 Roadmap
https://
burn: main topic of the DID Core 1.1 Roadmap. please see the link Manu sent out
link in here - https://
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
… 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.
… 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
… 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
… 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
… 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
… [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
… 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
e cases
… 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
… 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.
… 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.
… 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.
<ivan> The official terminology for the classes in the W3C process
<Zakim> burn, you wanted to comment on maintenance
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.
… 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
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.
… 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
… DID Core specializes 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.
… 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.
… 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
<TallTed> maybe we need a phone home to demonstrate use... ;-) ;-)
manu: 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
ack
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.
… 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.
ack
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,
… selective disclosure in DID Docs?
… could be a possible note
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
<Zakim> phila, you wanted to talk a little about resolution
<dlongley> 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.
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
… 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?
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 ...
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
<Zakim> manu, you wanted to note generalizing the "input URL" to the resolver.
<Zakim> burn, you wanted to set some context for discussion after Manu's done
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).
<pchampin> also, this "keeping the door open to other identifiers" looks consistent with the generalization of DID documents into Controller documents
manu: +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.
markus_sabadello: another approach to resolve other types of identifiers is to define a new DID method that does this
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.
… not do anything that would deliberately impede adaptation from others
<ChristopherA> @KevinDean +1
<Zakim> manu, you wanted to bring up "the big rocks that we have to DECIDE to move or not".
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
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.
… 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
… 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
+1 to parameters/paths being bigger
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?
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
… 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.
burn: I will have to leave then hand the meeting over to Will to finish
markus_sabadello: Agree with Manu on alignment of Controller Document, and the abstract data model are important issues we should talk about first.
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.
<manu> Thanks Joe! Agree that's a good conversation to have.
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.
… should not be able to make changes of that affect
Wip: That is it today, thanks for your contributions. Next week we will be focused on registries. Also looking for editors of registries!