14:49:41 <RRSAgent> RRSAgent has joined #did
14:49:45 <RRSAgent> logging to https://www.w3.org/2024/08/08-did-irc
14:49:52 <Wil> rssagent, draft minutes
14:50:03 <Wil> rrsagent, draft minutes
14:50:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-did-minutes.html Wil
14:50:14 <Wil> rrsagent, make logs public
14:50:26 <Wil> Meeting: Decentralized Identifier Working Group
14:50:31 <Wil> Chair: Will Abramson
14:50:43 <Wil> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0001.html
14:56:35 <Wil> present+
14:58:06 <TallTed> TallTed has joined #did
14:59:45 <ivan> present+
15:01:22 <markus_sabadello> markus_sabadello has joined #did
15:01:55 <decentralgabe> decentralgabe has joined #did
15:02:03 <decentralgabe> present+
15:02:30 <KevinDean> KevinDean has joined #did
15:02:31 <JoeAndrieu> JoeAndrieu has joined #did
15:02:31 <KevinDean> present+
15:02:49 <JoeAndrieu> present+
15:02:55 <JoeAndrieu> scribe+
15:04:18 <Wil> Topic: Agenda Review, Introductions
15:04:22 <markus_sabadello> present+
15:05:02 <Wil> Topic: Special Topic Call Summary
15:05:16 <TallTed> present+
15:05:21 <decentralgabe> https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0002.html
15:05:43 <manu> q+
15:06:15 <JoeAndrieu> gabe: reporting on the special topic call, especially scribing
15:06:15 <andres> andres has joined #did
15:06:35 <JoeAndrieu> .... did not get to consensus on the Abstract Data model, but lots of good discussion
15:06:51 <JoeAndrieu> ... notes cover more detail
15:06:55 <decentralgabe> https://github.com/w3c/did-core/issues/855
15:07:08 <Wil> ack manu
15:07:08 <JoeAndrieu> ... we can discuss this topic more on future calls
15:07:33 <JoeAndrieu> manu: thanks for the summary. About note taking, it's typically a bad idea not to scribe meetings.
15:07:36 <Stephan> Stephan has joined #DID
15:07:53 <JoeAndrieu> ... It creates bad situations where it seems like there's a cabal talking about something, that later shows up at the main meeting
15:08:09 <JoeAndrieu> ... and people in the main meeting don't have a way to understand the conversation that actually happened
15:08:25 <JoeAndrieu> ... As a global standards group, there are legal consequences to these conversations
15:08:38 <JoeAndrieu> ... e.g., if a patent was mentioned, that would go unrecorded and create IP issues
15:08:52 <JoeAndrieu> ... sometimes there are behaviors, such as CPC violations also get undocumented
15:09:09 <JoeAndrieu> ... I know you get that, Gabe, but I wanted to underscore for the rest of us the reason this is important.
15:09:24 <andres> andres has joined #did
15:09:27 <JoeAndrieu> wip: good points, we agree to scribe going forward
15:09:39 <manu> q+
15:09:44 <Wil> ack manu
15:09:53 <JoeAndrieu> gabe: Dan's notion was that a casual conversation might be good
15:10:24 <JoeAndrieu> manu: anyone *can* meet anywhere, yes, but when it is official W3C process, which means every decision we make is defensible and scribed
15:10:44 <TallTed> q+
15:10:47 <JoeAndrieu> ... DB would probably stop participating if the group were to stop scribing
15:11:00 <Wil> ack TallTed
15:11:29 <JoeAndrieu> tallted: along similar lines, I have been having problems with conversations and decisions that are handle in chair calls or editor calls that don't involve the general group.
15:11:43 <JoeAndrieu> .... that's problematic because its presented fait accompli
15:12:09 <JoeAndrieu> ... e.g., yesterday Ivan thought the scribing notice was sent to the list, but it actually wasn't. It was sent to editors list.
15:12:20 <ivan> +1 to Ted, I realized later that it was in a direct email
15:12:22 <JoeAndrieu> will: good points, tallted
15:12:25 <manu> Yes, completely agree ^ -- this has been a problem at W3C (and IETF) in the past and we need to do better.
15:12:30 <JoeAndrieu> ... next week: no special topic call
15:12:42 <JoeAndrieu> ... Our goal is to announce at least by the Thursday before
15:12:51 <JoeAndrieu> ... Let us know if you have any topics for a future special topic call
15:12:52 <Wil> Topic: DID Resolution Big Rocks
15:13:00 <Wil> Subtopic: https://github.com/w3c/did-resolution/issues/80
15:13:22 <JoeAndrieu> markus_sabadello: can I talk about some PRs before that?
15:13:30 <markus_sabadello> https://github.com/w3c/did-core/issues/857
15:13:33 <JoeAndrieu> will: yep
15:13:52 <JennieM> JennieM has joined #did
15:13:55 <Andres> Andres has joined #did
15:13:57 <JennieM> present+
15:13:57 <JoeAndrieu> markus_sabadello: this issue is about moving all the context related to did resolution to the did resolution spec
15:14:14 <JoeAndrieu> ... the idea is to make everything related to resolution is in one place
15:14:35 <JoeAndrieu> ... I opened two pull requests that go together. One on did core and one on did resolution.
15:14:37 <markus_sabadello> https://github.com/w3c/did-core/pull/858 and https://github.com/w3c/did-resolution/pull/84
15:14:59 <JoeAndrieu> ... it would be great if that could be reviewed
15:15:18 <manu> q+
15:15:26 <Wil> ack manu
15:15:35 <JoeAndrieu> manu: +1 to support PR
15:16:07 <JoeAndrieu> will: so we give it a week for any comments. then we'll get that merged in
15:16:17 <JoeAndrieu> markus_sabadello: there is one related question about metadata
15:16:40 <manu> q+
15:16:44 <JoeAndrieu> ... we have did document metadata and did resolution metadata, such as when was the doc created/updated, etc.
15:16:59 <JoeAndrieu> ... with these PRs, this is moving over as the metadata is about resolution.
15:17:09 <Wil> ack manu
15:17:09 <JoeAndrieu> ... but I thought maybe its worth asking about.
15:17:26 <JoeAndrieu> manu: +1 to support that. any metadata feels like it goes in the resolution spec.
15:17:50 <Wil> Subtopic: https://github.com/w3c/did-resolution/issues/80
15:17:52 <JoeAndrieu> will: markus_sabadello I'll let you pick the next issue
15:18:36 <JoeAndrieu> markus_sabadello: there are a couple to see if we have a general direction to proceed
15:18:42 <JoeAndrieu> ... (four topics)
15:19:01 <JoeAndrieu> ... These are the most prominent sections.
15:19:18 <JoeAndrieu> ... If we're agreed, then we can proceed to other issues
15:19:33 <JoeAndrieu> ... I'll quickly summarize if that would help
15:19:53 <JoeAndrieu> ... first one #80 is about DID resolution and did dereferencing algorithms
15:20:06 <JoeAndrieu> ... so far in the spec we have defined resolution and reference as abstract functions.
15:20:25 <JoeAndrieu> ... we said "here's a resolve function, inputs & outputs) but not how they are processed
15:20:48 <JoeAndrieu> ... we have not specified how to process certain query string parameters or how to dereference a path if there is one
15:20:55 <JoeAndrieu> ... or how to process meta-data from the functions.
15:21:12 <JoeAndrieu> ... So there's a section that defines a more concrete algorithm for resolving and dereferencing
15:21:29 <JoeAndrieu> ... I'd like to get feedback about if this is the right direction
15:21:47 <JoeAndrieu> ... if we agree it is, then good. this is one of the key areas we have to address.
15:21:56 <Wil> Subtopic: https://github.com/w3c/did-resolution/issues/81
15:22:04 <JoeAndrieu> ... On to #81 is about architecture
15:22:18 <ChristopherA> ChristopherA has joined #did
15:22:24 <ChristopherA> present+
15:22:24 <JoeAndrieu> ... That has to do with how do you communicate with a resolver. Is it a local library? A remote service?
15:22:42 <JoeAndrieu> ... how does the client talk to a resolver, and how does the resolver process a request
15:22:49 <JoeAndrieu> ... maybe resolvers redirecting to others
15:23:00 <JoeAndrieu> ... and topics about how you trust a resolver. do you run it yourself?
15:23:09 <JoeAndrieu> .... do you use someone else's. if so, how do you check the result?
15:23:15 <JoeAndrieu> ... Things like that.
15:23:23 <Wil> q+
15:23:52 <JoeAndrieu> ... it would be good to get high level feedback
15:24:08 <manu> q+
15:24:12 <JoeAndrieu> ... for example, if there are people who think resolution should be a strict client-server protocol
15:24:20 <JoeAndrieu> q+ to ask about mandatory to implement
15:24:25 <Wil> ack Wil
15:24:34 <manu> scribe+
15:24:46 <Wil> ack manu
15:24:48 <ChristopherA> q+
15:24:49 <JoeAndrieu> will: as I hear you talking through that, I'm wondering how much might be in implementation guide instead of in spec
15:25:02 <JoeAndrieu> manu: I think it is important to highlight that there are multiple architectures.
15:25:18 <JoeAndrieu> ... I was kind of ambivalent to that until you mention client/server
15:25:25 <JoeAndrieu> ... to which I'm like "NO." not client server.
15:25:47 <JoeAndrieu> ... We're in a situation now where we do need to clearly delineate the architecture.
15:26:00 <Wil> ack JoeAndrieu
15:26:00 <Zakim> JoeAndrieu, you wanted to ask about mandatory to implement
15:26:04 <JoeAndrieu> manu: there is a difference between local only and remote at a minimum
15:27:06 <manu> JoeAndrieu: This client server question -- it's going to be vital to have mandatory to implement HTTPS API -- I think that's how we get cross-site/cross-method interop. If each Method HAS to expose common endpoint, we'll have interop between methods, if we have customized architecture but no mandatory to implement, we won't achieve interop goals.
15:27:11 <manu> q+
15:27:13 <markus_sabadello> q+
15:27:17 <Wil> ack ChristopherA
15:27:22 <manu> q+ to speak to "cross method interop"
15:27:37 <JoeAndrieu> ChristopherA: I have questions about how much we need to talk about trust models in this document
15:27:49 <JoeAndrieu> ... I think there's a minimum that we should clarify.
15:27:56 <JoeAndrieu> ... the first resolver you just have to trust.
15:28:02 <JoeAndrieu> ... maybe because it's on your local machine
15:28:32 <JoeAndrieu> ... we should be careful other than locking that down, other than you have to trust that first one, but if that one then calls others, that's another layer of trust
15:28:40 <Wil> ack manu
15:28:40 <Zakim> manu, you wanted to speak to "cross method interop"
15:28:48 <JoeAndrieu> will: markus we'll give you last word on this before we move on
15:29:18 <JoeAndrieu> manu: I think most methods would implement the http api, maybe doesn't need to be MTI
15:29:37 <Wil> ack markus_sabadello
15:29:39 <JoeAndrieu> ... I'm concerned about "cross method interop" and I don't think I know what that means. for a future discussion
15:29:42 <danpape> danpape has joined #did
15:29:46 <JoeAndrieu> markus: relating to trust models
15:30:07 <JoeAndrieu> ... totally agree. there's some discussion in this section.
15:30:08 <TallTed> s/be MTI/be MTI (mandatory to implement)/
15:30:40 <JoeAndrieu> ... e.g., running your own bitcoin node versus remotely querying
15:30:59 <JoeAndrieu> ... What Joe said about mandatory http endpoint: yeah, maybe. a counter example.
15:31:18 <JoeAndrieu> q+ to mention did:key should have a software component that exposes the endpoint
15:31:30 <JoeAndrieu> ... these are the things that would go into that secton
15:31:42 <JoeAndrieu> ... more discussion on the github would be appreciated
15:31:43 <Wil> ack JoeAndrieu
15:31:43 <Zakim> JoeAndrieu, you wanted to mention did:key should have a software component that exposes the endpoint
15:31:54 <Wil> Subtopic: https://github.com/w3c/did-resolution/issues/82
15:32:21 <JoeAndrieu> markus: this is about having a concrete serialization / representation of the result of resolution funciton and entity reference function
15:32:40 <JoeAndrieu> ... we had these defined in an abstract way, but we have not defined every presentation or serialization of that
15:33:01 <JoeAndrieu> ... defines a JSON_LD model where you have did document and metadata in the same document.
15:33:20 <JoeAndrieu> ... this is related to the abstract data model, so not so simple, but I'm curious if anyone in the group doesn't like this idea
15:33:46 <Wil> Subtopic: https://github.com/w3c/did-resolution/issues/83
15:34:05 <JoeAndrieu> markus: this is about https interface
15:34:14 <JoeAndrieu> ... how to implement the abstract resolution over https
15:34:17 <manu> q+
15:34:46 <JoeAndrieu> ... it defines how the abstract endpoints are satisfied by the http endpoints, how to contsruct URLs and headers, etc.
15:35:11 <JoeAndrieu> ... If you resolve a DID that is deactivated, then how is that returned over an HTTPs binding? Some say there should be an HTTP error code.
15:35:27 <JoeAndrieu> ... others say it's not an error if it is deactivated. so return 200 with appropriate metadata
15:35:47 <JoeAndrieu> ... I'm looking for initial feedback. Is this one of the things we should be doing? An http interface?
15:35:52 <Wil> ack manu
15:35:59 <JoeAndrieu> ... separately we can discuss if it should be mandatory
15:36:01 <JoeAndrieu> manu: +1
15:36:31 <JoeAndrieu> ... the theme here is "do we want to talk about abstract stuff" in the space, then do we want to provide concrete instances of those abstract concepts
15:36:40 <JoeAndrieu> q+ to say get rid of abstract
15:37:08 <JoeAndrieu> ... are people going to kick up a fuss about an http API. I think we should do it.
15:37:17 <JoeAndrieu> ... we were "too abstract" before
15:37:34 <JoeAndrieu> ... We're doing this to ensure that interoperability is demonstrable.
15:37:37 <Wil> ack JoeAndrieu
15:37:37 <Zakim> JoeAndrieu, you wanted to say get rid of abstract
15:38:22 <manu> JoeAndrieu: The way you presented it, Manu, you made it seem like we keep abstract notions in new spec w/ concrete thing. I think we need to move beyond abstract -- take what we defined as abstract and define that into concrete endpoint.
15:38:25 <manu> q+
15:38:28 <Stephan> q+
15:38:29 <Wil> ack manu
15:38:48 <JoeAndrieu> manu: I was saying lets keep both of them for now. maybe they merge in the future.
15:39:09 <JoeAndrieu> ... it may help us think about it abstractly, then make all interop testing about concrete things
15:39:23 <JoeAndrieu> ... in theory we should be able to separate those two notions
15:39:35 <JoeAndrieu> ... that is what got us in trouble with the abstract data model
15:39:37 <Wil> ack Stephan
15:39:39 <JoeAndrieu> ... but some people like that
15:40:02 <JoeAndrieu> Stephan: back to mandatory to implement, do you mean to define the API or an actual service endpoint
15:40:11 <manu> JoeAndrieu: I definitely just mean the API
15:40:50 <manu> JoeAndrieu: Some decentralized services cannot be resolved to a specific URI -- there is no URI for a bitcoin node, but you can provide a piece of software that can expose itself on an IP or domain and interact w/ that resolver. Not an actual service endpoint, I agree, that would be a point of centralization. I'd just like to see an API.
15:40:52 <JoeAndrieu> will: moving on.
15:40:55 <Wil> Topic: DID Core Big Rocks
15:41:20 <JoeAndrieu> manu: these are just big rock concepts that don't necessarily have much to do with each other.
15:41:26 <JoeAndrieu> ... just general decisions we need to make
15:41:32 <manu> subtopic: https://github.com/w3c/did-core/issues/857
15:41:47 <JoeAndrieu> ... first one is do we want to move did resolution from did core to did resolution. we said yes to that today. done
15:42:00 <JoeAndrieu> ... unless folks want to speak up
15:42:04 <JoeAndrieu> ... pausing a beat
15:42:12 <manu> subtopic: https://github.com/w3c/did-core/issues/850
15:42:14 <JoeAndrieu> ... going a bit out of order
15:42:31 <JoeAndrieu> ... 850 is just updating JSONWebKey examples
15:42:45 <JoeAndrieu> ... did:core contains outdated examples. I'd like to update them
15:43:09 <JoeAndrieu> ... small snag, v1 context doesn't contain the JSONWebKey type
15:43:24 <JoeAndrieu> ... I'd recommend another context in the example, since the example is not normative.
15:43:44 <JoeAndrieu> ... So first question do we want to update from the 2020 stuff to the latest?
15:43:51 <manu> subtopic: https://github.com/w3c/did-core/issues/854
15:43:55 <JoeAndrieu> ... Hearing no objection, moving to next item
15:44:11 <burn> burn has joined #did
15:44:24 <JoeAndrieu> ... 854 is about normative referencing the controller document specification
15:44:37 <JoeAndrieu> .... folks in VCWG didn't want to use DIDs, but did want to use DID documents
15:45:05 <JoeAndrieu> ... so we created this separate document that is generalized. Any URL can be used, https is what most from that community wnat
15:45:38 <JoeAndrieu> ... what we could do in did core is, instead of duplicating text, we can refer to the controller document, with annotation about where you use DID documents in a controller document.
15:45:41 <ivan> -> VC Version of the controller document https://www.w3.org/TR/controller-document/
15:45:56 <JoeAndrieu> ... we think the controller document will be a REC before we are done in our group.
15:45:59 <Wil> q+
15:46:03 <Wil> ack Wil
15:46:07 <ChristopherA> q+
15:46:10 <JoeAndrieu> ... suggestion: start referencing the normative controller document
15:46:19 <JoeAndrieu> will: if we did this, what would be left in did:core?
15:46:25 <JoeAndrieu> manu: quite a bit still
15:46:57 <JoeAndrieu> manu: did syntax, introduction, example, design goals, architecture, identifier, data model, and core properties of identifiers remain
15:47:05 <JoeAndrieu> would remove verification relationships and methods
15:47:18 <JoeAndrieu> ... services might also be moved
15:47:55 <JoeAndrieu> ... we would leave representations in here. We'd keep Methods in the main document. Maybe 70% of considerations are in the controller doc.
15:48:04 <Wil> ack ChristopherA
15:48:05 <JoeAndrieu> ... so it would shrink quite a bit, but there's still plenty left
15:48:40 <manu> q+
15:48:47 <JoeAndrieu> ChristopherA: part of me likes the simplification and I have a reservation that, in the VC group, are we moving toward looking down to JSON-LD with the latest ieration.
15:48:58 <JoeAndrieu> ... by doing this is that totally out of our control?
15:49:14 <Wil> ack manu
15:49:20 <JoeAndrieu> ... other than the loss of control... I kinda like the idea
15:49:36 <JoeAndrieu> manu: not locked to JSON-LD
15:49:53 <ChristopherA> Oh, is there a cbor version of it being discussed there?
15:49:58 <ChristopherA> (ideally dCBOR)
15:49:59 <Wil> q+
15:50:03 <JoeAndrieu> ... as far as control. it really should be in this group, but for historical reasons it was created in response to needs from the VCWG
15:50:09 <markus_sabadello> q+
15:50:20 <bigbluehat> bigbluehat has joined #did
15:50:25 <JoeAndrieu> ... we may want to reimagine how we do data-integrity development and did development in the future
15:50:37 <JoeAndrieu> ... that would need a rechartering, which we don't want to do now
15:50:39 <ChristopherA> q+
15:50:48 <Wil> ack Wil
15:50:56 <JoeAndrieu> ... I don't see a particular risk with the VCWG making negative decisions.
15:51:03 <bigbluehat> present+
15:51:11 <decentralgabe> q+
15:51:15 <JoeAndrieu> will: what is the scope of this group take ownership of that work?
15:51:16 <Wil> ack markus_sabadello
15:51:31 <JoeAndrieu> markus_sabadello: I think it's a great idea to just reference the controller document
15:51:48 <JoeAndrieu> ... I'm already getting questions about what's the difference?
15:52:01 <JoeAndrieu> ... Concern that if we keep it separate, then we diverge with conflicting language
15:52:21 <Wil> ack ChristopherA
15:52:26 <manu> q+ to suggest a potential, future (in 2+ years) "Decentralization WG"
15:52:46 <manu> q+ to mention CBOR representation.
15:52:47 <JoeAndrieu> ChristopherA: at some point there was discussion about a CBOR version or other representations. Did that continue?
15:52:55 <Wil> ack decentralgabe
15:53:01 <ivan> q+
15:53:06 <decentralgabe> https://www.w3.org/TR/did-cbor-representation/
15:53:15 <JoeAndrieu> gabe: its in our charter to have a plain CBOR representation
15:53:25 <JoeAndrieu> ... I'm not aware of any efforts, but that would be cool.
15:53:43 <JoeAndrieu> ... I'd prefer the item be in this group, but rechartering seems painful.
15:53:57 <JoeAndrieu> ... It may be confusing to go across multiple documents from different groups
15:53:59 <manu> q- later
15:54:09 <JoeAndrieu> ... any way we can reduce that burden would help
15:54:19 <Wil> ack ivan
15:54:37 <ChristopherA> a deterministic CBOR (an IETF internet-draft subset of CBOR that addresses determinism issues of CBOR) is of interest to me. Just don't have time to submit to another group.
15:54:44 <JoeAndrieu> ivan: Rechartering is never painless. We should avoid that.
15:54:51 <ChristopherA> If there are others interested, let me know.
15:55:24 <JoeAndrieu> ... one more aspect toward referrijng to the VC document. We define a bunch of terms in did document, but they are all defined, formally in the VC document. They are all in the security vocabulary.
15:55:43 <JoeAndrieu> ... the controller document must be controlled by the working group that takes care of the relevant vocabulary
15:55:56 <JoeAndrieu> ... that is in favor of keeping that in the VCWG
15:56:01 <Wil> Zakim, close the queue
15:56:02 <Zakim> ok, Wil, the speaker queue is closed
15:56:17 <JoeAndrieu> ... As far as I can see the DID part only adds one or two terms, like services, which are not in the security vocabulary
15:56:27 <Wil> ack manu
15:56:27 <Zakim> manu, you wanted to suggest a potential, future (in 2+ years) "Decentralization WG" and to mention CBOR representation.
15:56:54 <JoeAndrieu> manu: we do have a CBOR-LD that will compress all the terms and keys. You get a fairly tight compression.
15:57:05 <JoeAndrieu> ... I don't recommend we pick that up. We are working on a charter for a separate WG
15:57:35 <JoeAndrieu> ... Second: specifications keep landing in weird places. They make sense at the time of chartering, but over time they really want ot be somehwere else.
15:57:50 <JoeAndrieu> ... things end up taking their life of their own.
15:58:07 <JoeAndrieu> ... we should think about the right place for these to go
15:58:40 <JoeAndrieu> ... VCs in VCWG, etc., adjusting that (charters) is painful, but we can do it as we naturally recharter into the future
15:58:51 <decentralgabe> +1 to imagining the 'ideal state' even if not possible today
15:58:56 <JoeAndrieu> will: continuing next week!
15:59:02 <ivan> rrsagent, draft minutes
15:59:03 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-did-minutes.html ivan
16:00:16 <ivan> rrsagent, bye
16:00:16 <RRSAgent> I see no action items