01:11:29 <TallTed> meeting: Decentralized Identifier WG F2F day 2 @ TPAC
01:11:29 <TallTed> previous meeting: https://www.w3.org/2024/09/23-did-minutes.html
01:11:29 <TallTed> next meeting: https://www.w3.org/2024/10/10-did-minutes.html
02:49:20 <Jay> Jay has joined #did
04:30:12 <dmitriz> dmitriz has joined #did
04:30:21 <manu_> manu_ has joined #did
05:27:21 <Kyle> Kyle has joined #did
05:34:28 <Zakim> Zakim has left #did
05:37:14 <Kyle> Kyle has left #did
06:32:56 <dmitriz> dmitriz has joined #did
12:19:54 <manu_> manu_ has joined #did
15:59:07 <RRSAgent> RRSAgent has joined #did
15:59:07 <RRSAgent> logging to https://www.w3.org/2024/09/24-did-irc
15:59:08 <Zakim> RRSAgent, make logs Public
15:59:10 <Zakim> please title this meeting ("meeting: ..."), ivan
16:00:03 <Wip> Wip has joined #did
16:00:03 <decentra_> present+
16:00:12 <Wip> present+
16:00:18 <burn> burn has joined #did
16:00:28 <ivan> ivan has changed the topic to: TPAC Agenda 2024-09-24: https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.g2a8b040676_0_74
16:00:28 <laurens> laurens has joined #did
16:00:33 <ivan> Agenda: https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.g2a8b040676_0_74
16:00:44 <TallTed> TallTed has joined #did
16:00:47 <markus_sabadello> markus_sabadello has joined #did
16:01:43 <ericaconnell> ericaconnell has joined #did
16:01:43 <HaoYuan> HaoYuan has joined #did
16:02:06 <decentra_> 5 min warning
16:02:42 <dlongley> dlongley has joined #did
16:03:56 <TallTed> it seems like there should be some liaison between DID and FedID. https://www.w3.org/events/meetings/ecf72b3f-b081-499b-b50f-b9065036af65/
16:06:57 <TallTed> pchampin - Did you see my note of last evening, about IRC log and minutes? (RRSAgent rolled over at midnight GMT.)
16:07:52 <pchampin> RRSAgent, this meeting spans midnight
16:08:24 <TallTed> pchampin - That's good for today, but what happens to *yesterday*'s data?
16:08:34 <bigbluehat> bigbluehat has joined #did
16:09:16 <wes-smith> wes-smith has joined #did
16:09:25 <bigbluehat> present+
16:09:34 <shigeya> present+
16:10:42 <ivan> present+
16:10:45 <laurens> present+
16:10:48 <Jay> present+
16:11:04 <markus_sabadello> present+
16:11:13 <manu_> manu_ has joined #did
16:11:36 <manu_> present+
16:11:40 <mandyv> mandyv has joined #did
16:12:11 <TallTed> present+
16:12:12 <danpape> danpape has joined #did
16:12:15 <dlongley> present+
16:12:24 <denkeni> present+
16:12:25 <danpape> present+
16:12:50 <HaoYuan> present+
16:13:43 <JoeAndrieu> JoeAndrieu has joined #did
16:13:48 <JoeAndrieu> scribe+
16:13:53 <JoeAndrieu> present+
16:13:56 <cc> cc has joined #did
16:14:11 <Kyle> Kyle has joined #did
16:14:21 <shiyu> shiyu has joined #did
16:14:28 <JoeAndrieu> wip: any changes the agenda?
16:14:43 <JoeAndrieu> [discussion of possible adjustments]
16:14:57 <Wip> q?
16:15:29 <Jenniem> Jenniem has joined #did
16:15:40 <JoeAndrieu> wip: First up, Markus to talk about extensibility of DID Resolution
16:16:09 <kaz> kaz has joined #did
16:16:35 <JoeAndrieu> markus_sabadello: What I wanted to do with this session is to get a discussion and changing thoughts on extensbility and the algorithm of resolution when you give a DID to a resolver or a DID URL to a dereferencer
16:16:49 <kaz> present+ Kaz_Ashimura
16:16:51 <JoeAndrieu> ... this has to do with the discussion from previous meeting, around primary and secondary resources and fragments
16:17:04 <JoeAndrieu> ... can you resolve to something other than the DID document?
16:17:35 <KevinDean> KevinDean has joined #did
16:17:38 <KevinDean> present+
16:17:42 <JoeAndrieu> ... What's already in DID core (showing basic syntax) for resolve. Input is the DID, plus a map of options. The output is primarily the did document plus two types of meta data.
16:17:49 <JoeAndrieu> ... We've had that for a long time.
16:18:15 <JoeAndrieu> ... A bit of innovation in places. Regarding extensibilty, most of these elements are points of extensibility
16:18:34 <JoeAndrieu> ... described in the specifications, but they are ways to add features
16:18:51 <JoeAndrieu> ... resolution options haven't been used much. I don't know of any particular implementations.
16:19:20 <JoeAndrieu> ... the one that is definitely being used is the request for a particular representation of the did document
16:19:28 <Wip> q+ to ask about how you might supporting sidecar data
16:19:38 <brent> brent has joined #did
16:19:42 <JoeAndrieu> ... the result is guaranteed to have meta data, but that meta data may be customized
16:19:49 <brent> present+
16:19:51 <JoeAndrieu> ... So how flexible should the resolution spec be?
16:20:04 <JoeAndrieu> ... How constrained or open should the generic did resolution process be?
16:20:10 <burn> q?
16:20:12 <Jenniem> present+
16:20:17 <burn> ack Wip
16:20:17 <Zakim> Wip, you wanted to ask about how you might supporting sidecar data
16:20:39 <JoeAndrieu> wip: I wanted to ask, because of did:btc1, we have a need for that options, but we weren't sure if it fit
16:20:54 <JoeAndrieu> ... we want to pass in the did and some additional data to help resolve the DID
16:21:19 <JoeAndrieu> markus_sabadello: absolutely. I remember your conversation and also KERI methods where the DID itself isn't sufficient to fully resolve.
16:21:26 <decentra_> q+
16:21:28 <JoeAndrieu> ... I think absolutely that's something to put in there.
16:21:40 <burn> ack decentra_
16:21:48 <JoeAndrieu> decentra_: I think a common resolution option would be a version of the did document
16:22:01 <Wip> Version or time
16:22:16 <JoeAndrieu> markus_sabadello: yes. I have a few more examples also
16:22:44 <ChristopherA> ChristopherA has joined #DID
16:22:51 <ChristopherA> present+
16:22:53 <JoeAndrieu> ... Dereferencing a DID URL is when you have a DID with an optional path, query, and fragment parts
16:22:54 <dezell> dezell has joined #did
16:22:54 <burn> present+
16:23:05 <dezell> present+
16:23:06 <JoeAndrieu> ... the tension is that the result *may* be a DID document, but it may be something else
16:23:11 <ChristopherA> q+
16:23:19 <dmitriz> dmitriz has joined #did
16:23:23 <dmitriz> present+
16:23:25 <JoeAndrieu> q+ to say DID URL deref  to did document != resolution
16:23:54 <JoeAndrieu> ... you can have parameters in the query stream, but the interesting question is what should the spec say about the dereferencing algorithm
16:24:08 <markus_sabadello> q?
16:24:11 <burn> ack ChristopherA
16:24:44 <JoeAndrieu> ChristopherA: One of the things we've run into is you may need to speak to a ... you may need to have a more interactive back & forth with the resolver
16:24:46 <manu_> scribe+
16:24:59 <JoeAndrieu> ... and there is no way to have an id for "this particular conversation"
16:25:13 <dlongley> +1 for a simpler/modular design so that you either get back a DID document, a portion of it, or another URL that would could be resolved via another resolver -- rather than trying to have `dereference()` do everything (including resolving that other URL to get its content, etc.)
16:25:19 <JoeAndrieu> ... so if the resolver needs more information, we don't have a standard way to relate the next resolution to the prior one
16:25:35 <JoeAndrieu> ... lots of advanced use cases, you won't immediately get the answer.
16:25:44 <JoeAndrieu> ... So can we have some sort of id for a series of transactions?
16:26:34 <JoeAndrieu> markus_sabadello: we've done something very much like that in the did registration specification. I think it could be done. Through the options object and metadata returned.
16:26:55 <JoeAndrieu> ... The metadata could communicate that more is needed and the additional information can be sent in the options
16:27:09 <JoeAndrieu> ... You could send something like a state identiifier or cookie to keep track
16:27:22 <JoeAndrieu> ... But also, we could discuss extending the interface to have more inputs
16:27:24 <markus_sabadello> q?
16:27:30 <burn> ack JoeAndrieu
16:27:30 <Zakim> JoeAndrieu, you wanted to say DID URL deref  to did document != resolution
16:27:50 <manu_> JoeAndrieu: The way you introdueced this Markus, a DID URL could resolve to a DID Document -- I think that's correct.
16:28:14 <manu_> JoeAndrieu: We need to communicate that that is not a form of resolution. Just because a DID Document resolves, doesn'tmean it is the DID Document for the DID.
16:28:26 <manu_> JoeAndrieu: For DID Document that is canonical for the DID -- we need to be clear about that.
16:28:29 <decentra_> q+
16:28:42 <JoeAndrieu> markus_sabadello: I think we're aligned there.
16:28:43 <smccown> smccown has joined #did
16:28:53 <JoeAndrieu> ... Resolving a did != dereferencing a did URL
16:28:58 <burn> ack decentra_
16:29:05 <manu_> scribe-
16:29:15 <JoeAndrieu> decentra_: I'm wondering if there's language in the spec today about trusting the resolution process?
16:29:21 <JoeAndrieu> markus_sabadello: there is a section about that
16:29:22 <jets> jets has joined #did
16:29:39 <Wip> q+ to ask about examples of where you would use a path in the DID url
16:29:46 <JoeAndrieu> ... it's called DID Resolution architecture. we can probably expand that
16:30:04 <cc> cc has joined #did
16:30:13 <JoeAndrieu> ... Let's talk about the inputs and outputs. And definitely the metadata can help you make some trust decisions
16:30:24 <burn> ack Wip
16:30:24 <Zakim> Wip, you wanted to ask about examples of where you would use a path in the DID url
16:30:28 <JoeAndrieu> ... Maybe we can save the trust conversation and get to the next slide
16:30:32 <JoeAndrieu> wip: do you have examples?
16:30:39 <jets> present+
16:30:40 <JoeAndrieu> markus_sabadello: Yes, on my next slide
16:31:10 <jets> present+ Brian_McManus
16:31:13 <JoeAndrieu> ... Here are a bunch of examples of DID Urls
16:31:48 <JoeAndrieu> ... Some of these combinations are very generic. Maybe could be defined in the spec itself. Some could be defined in extensions. Some may not work with all DID methods.
16:31:55 <JoeAndrieu> ... Let's look at them one-by-one
16:32:09 <JoeAndrieu> ... First is a #fragment to refer to a key.
16:32:12 <JoeAndrieu> ... Fairly common.
16:32:18 <burn> Examples: https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.g3027975a40a_0_2
16:32:19 <JoeAndrieu> ... So what should the spec say about it?
16:32:41 <JoeAndrieu> ... I hope we agree that dereferencing that is one of the verification methods from the DID document.
16:32:50 <Bert> Bert has joined #did
16:32:52 <JoeAndrieu> ... because the fragment is a related resource.
16:33:04 <JoeAndrieu> ... I was using the language of primary resource and secondary resource.
16:33:47 <JoeAndrieu> ... when that first DIR URL is dereferenced, you first dereference the DID to get the primary resource, the DID Document which you can use to get the secondary resource of the verification method with that id
16:33:51 <decentra_> q+ to ask about the relationship b/w fragments and options
16:33:59 <manu_> Agree that it sounds right to me
16:34:05 <burn> ack decentra_
16:34:05 <Zakim> decentra_, you wanted to ask about the relationship b/w fragments and options
16:34:06 <Wip> Me too
16:34:16 <JoeAndrieu> decentra_: I'm wondering. Is it worth having an understanding that these fragments should be coordinated or aligned with resolution options?
16:34:23 <JoeAndrieu> markus_sabadello: I don't think so.
16:34:41 <JoeAndrieu> ... If we look at the next example, with version time as a query parameter.
16:35:08 <JoeAndrieu> ... The specification currently says that to dereference, the versionTime must be passed as a resolution option
16:35:28 <tre> tre has joined #did
16:35:32 <JoeAndrieu> ... so when you do resolution, you do it differently because of the parameters.
16:35:35 <dlongley> q+ to say if any DID URL resolves to another "intermediate URL", i would recommend that just be the result -- rather than automatically trying to resolve that... for example, i imagine the did:tdw DID URLs with `.../governance/issuers.json` maps to an HTTPS URL, so ideally (to me) the result of resolution is that HTTPS URL, not whatever content lives at that HTTPS URL.
16:35:40 <burn> ack dlongley
16:35:40 <Zakim> dlongley, you wanted to say if any DID URL resolves to another "intermediate URL", i would recommend that just be the result -- rather than automatically trying to resolve that...
16:35:44 <Zakim> ... for example, i imagine the did:tdw DID URLs with `.../governance/issuers.json` maps to an HTTPS URL, so ideally (to me) the result of resolution is that HTTPS URL, not whatever
16:35:44 <Zakim> ... content lives at that HTTPS URL.
16:35:45 <JoeAndrieu> ... so, yes a relationship for query terms, but not fragments
16:36:15 <Max> Max has joined #DID
16:36:26 <JoeAndrieu> dlongley: if many of these, resolveing the DID URL probably returns an HTTP URL
16:36:55 <JoeAndrieu> ... if that points to something other than the VDR, then dereferencing should should RETURN that URL, not attempting to handle all possible URLs
16:37:28 <JoeAndrieu> ... a boundary: are the resolvers just returning content they generate (per method resolution) or is it something that is from somewhere else (and they should just return the http URL)
16:37:28 <manu_> +1 to what Dave said.
16:37:42 <JoeAndrieu> markus_sabadello: that is what happens when we use the service parameter.
16:38:06 <dlongley> +1 to a compositional design
16:38:07 <JoeAndrieu> ... so a DIDURL with a service parameter is not the final resource, (the content) but just the URL that can be separately dereferenced
16:38:52 <manu_> q+ to note that different rules in each Method specification could be challenging.
16:39:01 <JoeAndrieu> ... however with did:tdw (we can discuss that)... in my mind, (with the governance example), it should return the content, because the webserver *is* the VDR
16:39:26 <bkardell_> bkardell_ has joined #did
16:39:34 <burn> ack manu_
16:39:34 <Zakim> manu_, you wanted to note that different rules in each Method specification could be challenging.
16:39:34 <markus_sabadello> q?
16:39:41 <JoeAndrieu> ... look at did:cheqd, you also get something back other than the DID document, but the result is not the URL.
16:39:50 <dlongley> having to mirror every possible thing you can do with HTTP into `didResolutionOptions` (or whatever that param is called) ... is not something we want to do (IMO)
16:40:15 <JoeAndrieu> manu: I'm concerned if DID methods can define how things are resolved differently where its really up to the did method and different did methods do it differently.
16:40:39 <JoeAndrieu> ... for example, if it's a service, it just returns the URL back. But did methods could do something completely different.
16:41:04 <JoeAndrieu> q+ to talk about DID URL as http replacement in HTML
16:41:06 <shigeya> Consistency from the point of view of Developer is important.
16:41:11 <dlongley> +1 for consistency
16:41:26 <JoeAndrieu> markus_sabadello: yes, we should put some things in the spec that methods can't or shouldn't override
16:42:09 <manu_> scribe+
16:42:12 <JoeAndrieu> ... At one point we had different syntax for method-specific and generic parameters, and we decided that was too complicated
16:42:24 <Aaron> Aaron has joined #did
16:42:34 <JoeAndrieu> ... if people come up with new parameters, but make sense to be consistent across different methods, they can be registered
16:42:55 <JoeAndrieu> ... the did:cheqd example is a good model
16:43:15 <markus_sabadello> q?
16:43:17 <burn> ack JoeAndrieu
16:43:17 <Zakim> JoeAndrieu, you wanted to talk about DID URL as http replacement in HTML
16:43:30 <manu_> JoeAndrieu: Wanted to push back a bit on something Dave Longley said.
16:44:18 <manu_> JoeAndrieu: In Linked Resource for did:cosmos, it was designed that if the DID URL has a path part, we replace the resource, so you can put that URL as src in image tag in URL. When you put DID URL in, what you get back is a resources, we miss opportunity to update Web to use DIDs.
16:44:41 <manu_> JoeAndrieu: I would like to use DID URL as src in image tag. I'd like to be able to support that use case.
16:44:42 <manu_> q+
16:44:45 <dlongley> q+ to say that's an interesting use case, but i don't if it can't be supported either way
16:44:49 <JoeAndrieu> markus_sabadello: I agree
16:44:50 <burn> ack manu_
16:44:59 <JoeAndrieu> manu_: +1 to supporting the use case
16:45:07 <dlongley> q-
16:45:09 <dlongley> +1 to what Manu is saying.
16:45:10 <wes-smith> wes-smith has joined #did
16:45:35 <JoeAndrieu> ... there are two things going on here. The question is what do you send to the resolver api to get one of two things:
16:45:35 <JoeAndrieu> 1 is fully resolved URL 2 what do you do to get the actual content
16:45:37 <JoeAndrieu> q+
16:45:45 <burn> ack JoeAndrieu
16:46:00 <dlongley> (notably, you can return a data URL as well)
16:46:04 <dlongley> q+
16:46:26 <manu_> JoeAndrieu: The way we navigated it, but not how did:cheqd did it, we treated, if there is a path part,  you get back resource. That was a definitive one way or the other. If you don't have a path, you want DID Document, if you have path,  you get back secondary resource.
16:46:45 <manu_> JoeAndrieu: Maybe service query pattern gives you URL -- maybe we can break it into different responses based on URL structure.
16:46:47 <burn> ack dlongley
16:46:58 <JoeAndrieu> dlongley: I support the use case. a number of different ways to do it.
16:47:20 <JoeAndrieu> ... it may be that if a URL is always returned, then browsers are told they should continue dereferencing
16:47:39 <kazho> kazho has joined #did
16:47:41 <JoeAndrieu> ... but adopting design when we can use current tooling would be powerful
16:47:43 <JoeAndrieu> +1
16:48:02 <manu_> s/+1/JoeAndrieu: +1/
16:48:20 <manu_> scribe-
16:48:40 <JoeAndrieu> markus_sabadello: keep in mind, like with did:cheqd, there are other did methods where there isn't a URL. We could use a data URL... but then why have an interface to return a content stream in the first place?
16:49:30 <JoeAndrieu> ... regarding the path. the resolution specification doesn't tell you anything about how to dereference the path. Maybe that is defined by the did method, or by an application, but other than that is completely open and flexible.
16:49:41 <JoeAndrieu> ... So it doesn't say that if it's a path, it must be content.
16:49:51 <Wip> q+ to ask about tdw examples
16:49:51 <dlongley> q+ to say: i'm not against returning a content stream, but with no clear guard rails on when that would happen, we run the risk of having to wrap every possible protocol for retrieving other content
16:49:51 <JoeAndrieu> ... In current design its left up to did method
16:49:56 <burn> ack Wip
16:49:56 <Zakim> Wip, you wanted to ask about tdw examples
16:50:16 <JoeAndrieu> wip: About the tdw examples, could you explain the difference
16:50:31 <Kyle> Kyle has joined #did
16:50:44 <markus_sabadello> did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com#whois
16:50:51 <markus_sabadello> did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com/whois
16:51:30 <JoeAndrieu> markus_sabadello: the one with the hash is just a DID URL with a fragment. in this case, when you dereference, you first get DID document, then process fragment according to rules of the media type.
16:52:02 <JoeAndrieu> ... Assuming this is a service, the result would be the service with the id that matches the hash
16:52:17 <JoeAndrieu> ... The second example with /whois, the DID method would have to define that.
16:52:38 <JoeAndrieu> ... I realize its tempting to come up with a generic set of rules, but I don't think that would be right.
16:52:40 <JennieM> JennieM has joined #did
16:53:25 <JoeAndrieu> ... In the did:tdw spec, it says that in order to dereference, you find the endpoint, then you look for the service and return the content
16:53:26 <dezell> dezell has joined #did
16:53:53 <burn> ack dlongley
16:53:53 <Zakim> dlongley, you wanted to say: i'm not against returning a content stream, but with no clear guard rails on when that would happen, we run the risk of having to wrap every possible
16:53:56 <Zakim> ... protocol for retrieving other content
16:54:20 <JoeAndrieu> dlongley: you mentioned returning a content stream and making sure we have reason to do that. I'm not against that, but we need to figure out guardrails
16:54:21 <Kyle_> Kyle_ has joined #did
16:54:40 <JoeAndrieu> ... there's an imedence mismatch where you'd have to know what is behind the URL to pass the right options for further resolution
16:55:01 <JoeAndrieu> ... I'm concerned that we are trying to enable a generic solution but only having a limited mechanism to do it
16:55:05 <danpape> s/imedence/impedence/
16:55:34 <JoeAndrieu> ... I'm worried that if we don't give people any guardrails, then clients will need to have magical super powers to know what to do.
16:55:43 <JoeAndrieu> markus_sabadello: I agree.
16:56:14 <JoeAndrieu> ... these examples would theoretically work with no additional parameters in the dereferencing
16:56:24 <JoeAndrieu> ... some of it is defined by DID methods, some by the spec
16:56:40 <JoeAndrieu> q+ to say I think interop between methods is the better options
16:56:43 <markus_sabadello> did:example:123?service=DecentralizedWebNode&queries=W3sgTUV
16:56:48 <burn> ack JoeAndrieu
16:56:48 <Zakim> JoeAndrieu, you wanted to say I think interop between methods is the better options
16:56:52 <manu_> scribe+
16:57:16 <drummond> drummond has joined #did
16:57:23 <drummond> present+
16:57:42 <manu_> JoeAndrieu: Wanted to provide counerpoint on advocacy to leave bulk up to DID Method. We have a challenge where did:cheqd is doing what did:cosmos did, going to limit interop -- what is the common pattern that these DID Methods upgrade to? Can we figure out how we could have mechanism to get resource back in a common way.
16:57:46 <manu_> q+
16:57:54 <dlongley> +1 to Joe for finding consistency and creating more well-defined boundaries / layers
16:57:56 <JoeAndrieu> markus_sabadello: I would love to learn more about the did:cosmos approach.
16:57:58 <drummond> +1 to defining a common pattern that any DID method can adopt for DID URL construction.
16:58:19 <JoeAndrieu> markus_sabadello: the objective for this discussion is the question of how much we should standardize
16:58:23 <JoeAndrieu> +1
16:58:31 <drummond> +1
16:58:40 <ivan> +1
16:58:42 <manu_> manu: +1
16:58:49 <denkeni> +1 to define the scope of dereferencing should happen on DID resolution lev,e
16:58:55 <denkeni> Or the did method, etc
16:59:05 <markus_sabadello> did:example:123?transformKeys=JsonWebKey
16:59:05 <JoeAndrieu> markus_sabadello: we have a mechanism to define common parameters (did core and extension registry)
16:59:46 <JoeAndrieu> ... this JsonWebKey example is defined by the method, but maybe it could be elevated to be worth putting in did-core
17:00:04 <JoeAndrieu> ... So we might want to create a section for path patterns
17:00:25 <drummond> +1 to extension registry for common path patterns such as /whois
17:00:27 <JoeAndrieu> q+ to say the linkedResources is in the extension registry
17:00:39 <markus_sabadello> q?
17:01:01 <burn> ack manu_
17:01:29 <JoeAndrieu> manu: to note the plus ones further up. I think making it so that we don't know how to interpret path patterns is going to lead to a lot of problems.
17:02:03 <JoeAndrieu> ... I'd go a bit further. Maybe we do need path patterns, but I'm concerned that they might be totally different. So you see similar patterns, but handled wildly differently
17:02:13 <JoeAndrieu> ... can we not just standardize the path pattern?
17:02:35 <smccown> +1 for standardizing the path pattern
17:02:37 <JoeAndrieu> ... I am not certain about the ramifications of that option, but it seems the other way feels like we are buying ourselves trouble
17:02:54 <JoeAndrieu> markus_sabadello: the counter argument would be that isn't how http urls to work
17:03:04 <manu_> q+
17:03:11 <dlongley> and maybe it ends up being ok for the paths to be wildly different, but we need to make sure it's really clear where the lines are and that we can *construct* (in a compositional way) the pieces we need to do interesting things, using existing interfaces, without having to wrap every interface to integrate existing technologies with DIDs.
17:03:18 <markus_sabadello> q?
17:03:32 <burn> ack JoeAndrieu
17:03:32 <Zakim> JoeAndrieu, you wanted to say the linkedResources is in the extension registry
17:04:27 <manu_> JoeAndrieu: linkedResources are in the extension registry. That particular use of that property determines how the path is used because it's method specific. That's the dangerous pattern we're in and anyone can add that pattern to the registry, but no one outside DID IXO community understands it. Creates the problem Manu is raising a concern about.
17:04:33 <burn> Agree with Markus that expectations from HTTPS URLs need to be met as much as we can to reduce confusion
17:05:23 <manu_> JoeAndrieu: We have a path property that is a property of linked resource that would be looked up... bespoke way to do it, but we just thought through it in our own internal conversations.
17:05:25 <burn> ack manu_
17:05:39 <Wip> LinkedResources - https://earthprogram.github.io/did-cosmos/#linked-resources
17:06:00 <JoeAndrieu> manu: I didn't mean to imply that the same path on two different did methods would give you the same resouce. I agree. the path on one DID URL may give you a totally different resource than that same path on another DID
17:06:39 <dlongley> agree that that would be a big problem
17:06:45 <drummond> also agreed
17:07:01 <JoeAndrieu> ... In one situation, it results in getting the DID document and the second is a direct resource, then the DID method fundamentally overwrites the fundamental expectations
17:07:11 <burn> Sounds like the key is not so much what is returned but whether behavioral actions differ
17:07:11 <JoeAndrieu> ... there needs to be some level of predictabiliity
17:07:35 <JoeAndrieu> ... the linked resources is a great example, I would expect that to behave the same way across DID methods
17:07:50 <markus_sabadello> q?
17:07:55 <JoeAndrieu> ... So we might restrict extensions to prevent that kind of duplication / ambiguity
17:08:00 <drummond> What would be ideal is if you can request the same type of resource (or action) with a specific path construction that works across all DID methods that adopt it. Linked Resources is a good example.
17:08:03 <dlongley> (can't put the requirement on DID registry administrators though :) )
17:08:13 <drummond> +1
17:08:27 <denkeni> +1 to manu, probably we could have a more strict resolution rules, rather than just putting everything we’ve used from URL dereferencing
17:08:32 <JoeAndrieu> markus_sabadello: I've organized those examples into patterns we've been seeing
17:09:14 <dlongley> we need different categories that can each be reasoned about similarly -- and DID method authors can put their extensions in the right place/category.
17:09:42 <TallTed> I wonder whether people would be feeling the same way if these URLs were fully opaque/obfuscated (as URLs are specified to be), rather than using human-friendly-ish parameters, values, etc.
17:09:52 <manu_> q+
17:09:58 <JoeAndrieu> ... The method independent ones don't require any method-specific logic. Selecting a service endpoint from a did document that doesn't have to be encoded in a method specific way
17:10:02 <TallTed> q?
17:10:05 <TallTed> q+
17:10:40 <dlongley> TallTed: i think the point Manu is raising starts to involve something like verbs / actions and how those interact with URLs (or if they are "part of" the URLs)
17:10:41 <JoeAndrieu> ... The processing of the service parameter is completely independent of the DID method
17:10:52 <TallTed> s/TallTed: i/TallTed -- i
17:10:55 <JoeAndrieu> ... Some of this could be changed or improved
17:11:06 <JoeAndrieu> ... Where these things are specified is the heart of this discussion
17:11:07 <markus_sabadello> q?
17:11:13 <burn> ack manu_
17:11:43 <Wonsuk> Wonsuk has joined #did
17:11:48 <JoeAndrieu> manu_: looking at the list, my gut is that anything that's a query parameter feels right. It's the path part for /whois, and leave that method-specific
17:12:03 <ChristopherA> q+
17:12:07 <JoeAndrieu> ... if that were a query term, it would feel less confusing
17:12:21 <decentra_> +1 to confusion b/w path and query param
17:12:39 <JoeAndrieu> ... in the extensions, if query and path are interchangeable that could become confusing
17:12:58 <denkeni> And that has happened everywhere
17:13:06 <JoeAndrieu> markus_sabadello: the different between /whois and ?whois  and /governance/issuers could be anything.
17:13:26 <JoeAndrieu> .... you can have any arbitrary path and how to dereference it.
17:13:33 <markus_sabadello> q?
17:13:35 <burn> ack TallTed
17:13:36 <JoeAndrieu> ... because the DID method may want to support arbitrary paths
17:14:06 <JoeAndrieu> TallTed: I'm concerned people seem to be interpreting URLs based on their intuititive interpretation of the words they are seeing there. URLs are by definition opaque.
17:14:31 <JoeAndrieu> ... so if we used opaque identifiers, would that change our sense of how these things work?
17:15:03 <JoeAndrieu> ... replaceing "whois" within "xc13" would shift expectations, but *it shouldn't*
17:15:04 <burn> q+ to agree with Dave Longley that this is about verbs/actions
17:15:25 <dlongley> `did:method:abc/p1/p2.ext?x=y&z=1#f` <-- need clear boundaries around how each of these "things" work :)
17:15:39 <manu_> q+ to note that URLs are supposed to be opaque, but the patterns we build on top of them are not.
17:15:42 <burn> ack ChristopherA
17:15:44 <JoeAndrieu> ... There's intuitive understanding of how things work because of an incorrect believe that we understand how things work. Because the services don't have any intuitive anything
17:16:13 <JoeAndrieu> ChristopherA: I'm struggling with a trust model problem. Which is, how much does the resolver that I trusted
17:16:28 <JoeAndrieu> ... versus a resolver going and asking something else for an opinion?
17:16:34 <manu_> q+ to speak to "don't know what is handled by DID Core / DID Resolution vs. DID Method"
17:16:49 <JoeAndrieu> ... In a bunch of these there is zero trust, because there aren't mechanisms to ensure it.
17:17:23 <JoeAndrieu> ... What data comes from my browser resolver and I am forced to trust, but if it calls some other resolver, how/why should I trust it?
17:18:00 <JoeAndrieu> markus_sabadello: there is some language about this in the architecture section. It's incomplete, but it tries to decsribe that it is possible to have a setup where one resolver talks to another resolver, even at different parts in the process
17:18:08 <JoeAndrieu> ... that has implications on trust model
17:18:31 <JoeAndrieu> ... For example, fragment could be used to resolve the document, then processing the fragment yourself.
17:18:35 <TallTed> How do you know to trust the HTTPS server your browser sends a GET to? How do you know that HTTPS server isn't parsing your GET and passing chunks of it to a remote process, that does the same, etc., until something gets returned to you?
17:18:51 <JoeAndrieu> q+ to talk about fragments not being sent to resolvers and dereferencers
17:18:53 <dlongley> also something to note... if you can't resolve a DID URL to an intermediate URL, it becomes harder to figure out what to update :), i.e., people will need/want to update "pointers" to things and they might need to know what those pointers are, not only get back the fully dereferenced content.
17:19:20 <markus_sabadello> q?
17:19:23 <burn> ack burn
17:19:23 <Zakim> burn, you wanted to agree with Dave Longley that this is about verbs/actions
17:19:38 <shiyu> shiyu has joined #did
17:19:40 <dlongley> +1 to TallTed, when we hide the HTTPS calls behind a DID resolver we also don't necessarily know what's being used there for trust
17:19:40 <JoeAndrieu> burn: I want to go back to Manu's comment on the example of what concerns him with path.
17:20:16 <JoeAndrieu> ... I think it really is about verbs and actions. Even with HTTP urls, it feels wrong when the path has "actiony" things like "next" or "prev".
17:20:31 <shigeya> q?
17:20:39 <TallTed> I don't believe there's an suggestion of that in HTTP URLs that are not strictly Locators
17:20:40 <JoeAndrieu> ... So that is something not mandated with HTTP urls but if we can restrict/enforce/control that, that would be valuable
17:20:41 <burn> ack manu_
17:20:41 <Zakim> manu_, you wanted to note that URLs are supposed to be opaque, but the patterns we build on top of them are not. and to speak to "don't know what is handled by DID Core / DID
17:20:42 <denkeni> +1 to burn
17:20:44 <Zakim> ... Resolution vs. DID Method"
17:21:02 <JoeAndrieu> manu: Agree with Ted, yes, URLs are supposed to be opaque and you get something back.
17:21:25 <TallTed> you don't necessarily get anything back. You *should* usually get a response code, but that may be all!
17:21:31 <JoeAndrieu> ... in that way, thy are opaque, but we also have design patterns like .well-known which we now depend on for certain protocols
17:21:48 <JoeAndrieu> ... I'm concerned about not know which systems resolve which parts of a path
17:22:14 <JoeAndrieu> ... To really understand what happens, you have to have the entire registry in your head of every possible parameter and path to understand what applies
17:22:28 <JoeAndrieu> ... Yes, this stuff is support to be opaque
17:22:46 <burn> Correct, Ted, but there is an implication that a path leads to a location and not an action.  Maybe something at the location is returned, or maybe not, but path-as-action is problematic.
17:23:05 <JoeAndrieu> ... but it's a high cognitive load. that increases the chances that people will come to the wrong conclusions, leading to security mistakes
17:23:15 <burn> q?
17:23:18 <TallTed> It's no less complex with an HTTP(S) URL and all the things that might be behind /cgi/...
17:23:28 <burn> ack JoeAndrieu
17:23:28 <Zakim> JoeAndrieu, you wanted to talk about fragments not being sent to resolvers and dereferencers
17:24:02 <TallTed> Fragments are not sent to servers by clients. It's in the RFCs.
17:24:06 <manu_> JoeAndrieu: Wanted to speak to a conceptual boundary -- typical pattern in browser is you don't send fragment to server. You process w/ results of resolution or dereferencing. We haven't written that up.
17:24:08 <shigeya> q+
17:24:47 <JoeAndrieu> markus_sabadello: I think you do pass the entire DID URL to the deferencing process, but different things can happen in different components
17:24:53 <JoeAndrieu> ... all of which could happen locally
17:24:59 <burn> ack shigeya
17:25:15 <JoeAndrieu> shigeya: I'm confused about which type of software is using this API
17:25:18 <dlongley> "the server" gets ambiguous, "the resolver" is perhaps not "the server", but the client (even if it also happens to function as a server just to enable you to use its interface), i.e., there is a server/client when resolving and a server/client that provides a resolution interface.
17:25:27 <JoeAndrieu> ... There is some confusion about differences of assumptions
17:25:31 <Wip> q+
17:25:39 <KevinDean> q+
17:25:41 <JoeAndrieu> ... Some think the end result should be resources, but somethings not
17:25:53 <JoeAndrieu> ... we could put this onto the browser to get there.
17:26:19 <decentra_> Zakim, please close the queue
17:26:19 <Zakim> ok, decentra_, the speaker queue is closed
17:26:26 <burn> ack Wip
17:26:26 <JoeAndrieu> markus_sabadello: all of these are implemented somewhere. Maybe not exactly to the interfaces we have in the spec, but these are live uses
17:26:49 <JoeAndrieu> wip: It'd be good for everyone to think about next steps. We need some issues and actions we are going to take
17:26:54 <PZ> PZ has joined #did
17:27:17 <JoeAndrieu> q+ to mention inconsistency problems with extensions
17:27:20 <burn> ack KevinDean
17:27:38 <TallTed> (Sorry, yes, my bad, I'm usually a stickler about "qualifier server", "qualifier client".)
17:28:19 <JoeAndrieu> markus_sabadello: with did resolution you don't always have client and servers
17:28:32 <JoeAndrieu> Sure you have clients and servers!
17:28:44 <KevinDean> From RFC 3986 (https://datatracker.ietf.org/doc/html/rfc3986): As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user
17:28:44 <KevinDean> agent, regardless of the URI scheme.
17:29:56 <JoeAndrieu> markus_sabadello: it's also a question of which application is treating "dereferencing" to call a dereferencer
17:30:01 <Kyle_> Kyle_ has left #did
17:30:05 <Kyle_> Kyle_ has joined #did
17:30:11 <JoeAndrieu> wip: off to a 30 min break, after an optional group photo
17:30:39 <Kyle_> Kyle_ has left #did
17:30:48 <decentra_> back at 10:55
17:45:26 <PZ> PZ has joined #DID
17:47:14 <PZ> PZ has left #did
17:47:14 <shigeya> We're experiencing power outage at the venue hotel. We may not able to resume at 10:55...
17:48:45 <TallTed> RRSAgent, draft minutes
17:48:46 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
17:50:27 <TallTed> i/5 min warning/topic: extensibility of DID Resolution/
17:50:34 <TallTed> RRSAgent, draft minutes
17:50:36 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
17:51:02 <dlehn1> dlehn1 has joined #did
17:51:40 <TallTed> i/Last topic of today/scribe+ wip
17:52:17 <TallTed> i/5 min warning/scribe- wip
17:52:21 <TallTed> RRSAgent, draft minutes
17:52:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
17:58:08 <TallTed> i/5 min warning/agenda: https://docs.google.com/presentation/d/1s6tf0VOKdIr3Gf_t7ROypyeg07Lk_myoOFby6AL4I7g/edit#slide=id.g2a8b040676_0_74
17:58:21 <TallTed> RRSAgent, draft minutes
17:58:23 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
18:07:49 <decentralgabe> decentralgabe has joined #did
18:07:58 <decentralgabe> We are delayed - power is out in the building. No estimate of return just yet.
18:08:37 <decentralgabe> decentralgabe has joined #did
18:13:30 <decentralgabe> decentralgabe has joined #did
18:15:31 <decentralgabe> decentralgabe has joined #did
18:16:37 <Bruno5> Bruno5 has joined #did
18:22:38 <decentralgabe> the local power co's website shows a 3PM return. please follow the mailing list, we will post an update when we're able to resume.
18:23:11 <Aaron> W3C in the dark
18:24:00 <markus_sabadello> In case it makes anyone feel better, here in Europe it's dark as well :)
18:24:21 <decentralgabe> 😂
18:26:08 <TallTed> The sun has set on Europe.
18:58:56 <Wip> Wip has joined #did
19:55:24 <ChristopherA> ChristopherA has joined #DID
19:55:42 <ChristopherA> I’m hanging out at pool patio, much cooler there.
19:57:19 <Zakim> Zakim has left #did
20:05:56 <dmitriz> dmitriz has joined #did
20:05:57 <kaz> kaz has joined #did
20:23:21 <Jay> Jay has joined #did
20:47:42 <markus_sabadello> markus_sabadello has joined #did
21:00:43 <decentralgabe> decentralgabe has joined #did
21:01:02 <decentralgabe> scribe+
21:01:16 <Wip> Wip has joined #did
21:02:31 <spshin> spshin has joined #did
21:02:42 <Bert> Bert has left #did
21:05:53 <Kyle> Kyle has joined #did
21:06:00 <KevinDean> KevinDean has joined #did
21:06:01 <dmitriz> dmitriz has joined #did
21:06:04 <KevinDean> present+
21:06:06 <ChristopherA> Present+
21:06:06 <dmitriz> present+
21:06:17 <burn> burn has joined #did
21:06:17 <markus_sabadello> present+
21:06:18 <JennieM> JennieM has joined #did
21:06:27 <shigeya> present+
21:06:31 <Wip> present+
21:06:37 <JennieM> present+
21:06:41 <ericaconnell> ericaconnell has joined #did
21:06:49 <danpape> danpape has joined #did
21:06:56 <danpape> present+
21:07:16 <ty-everett> ty-everett has joined #did
21:07:22 <wes-smith> wes-smith has joined #did
21:07:24 <ty-everett> present+
21:07:47 <Brayden> Brayden has joined #did
21:08:32 <cc> cc has joined #did
21:08:33 <Brayden> present+
21:08:34 <decentralgabe> burn: the agenda has adjusted. we will skip issue/PR processing for resolution, which we normally do on calls.
21:09:36 <manu_> manu_ has joined #did
21:10:06 <decentralgabe> ... we were going to do editor onboarding for resolution editors. to help with the process for doing that. we will skip it for now. we are going to run a resolution for the FPWD for DID Resolution, so we can begin making edits under the proper structures
21:10:15 <decentralgabe> ... I will turn it over to Will to run that process.
21:10:17 <manu_> present+
21:10:30 <Zakim> Zakim has joined #did
21:10:38 <denkeni> present+
21:10:42 <TallTed> Zakim, who's here?
21:10:42 <Zakim> Present: denkeni
21:10:44 <Zakim> On IRC I see manu_, cc, Brayden, wes-smith, ty-everett, danpape, ericaconnell, JennieM, burn, dmitriz, KevinDean, Kyle, spshin, Wip, decentralgabe, markus_sabadello, kaz,
21:10:44 <Zakim> ... ChristopherA, dlehn, jets, dlongley, TallTed, RRSAgent, rhiaro, hyojin_, manu, denkeni, cwilso, jyasskin, hadleybeeman, shigeya, pchampin, cel, ivan
21:10:45 <manu_> q+ to ask about using echidna for publishing.
21:10:51 <burn> q?
21:10:54 <decentralgabe> ... we have draft text. please adjust it
21:10:57 <burn> ack manu_
21:10:57 <Zakim> manu_, you wanted to ask about using echidna for publishing.
21:11:03 <isaac> isaac has joined #did
21:11:05 <manu_> q+ christophera
21:11:21 <Wonsuk> Wonsuk has joined #did
21:11:39 <decentralgabe> manu_: I don't know if we've made a resolution to use echidna to auto publish, but we should do it.
21:11:40 <TallTed> present+ TallTed, manu, manu_, burn, ChristopherA, markus_sabadello, dlehn,
21:11:46 <TallTed> Zakim, who's here?
21:11:46 <Zakim> Present: denkeni, Wonsuk_Lee, TallTed, manu, manu_, burn, ChristopherA, markus_sabadello, dlehn
21:11:49 <Zakim> On IRC I see Wonsuk, isaac, Zakim, manu_, cc, Brayden, wes-smith, ty-everett, danpape, ericaconnell, JennieM, burn, dmitriz, KevinDean, Kyle, spshin, Wip, decentralgabe,
21:11:49 <Zakim> ... markus_sabadello, kaz, ChristopherA, dlehn, jets, dlongley, TallTed, RRSAgent, rhiaro, hyojin_, manu, denkeni, cwilso, jyasskin, hadleybeeman, shigeya, pchampin, cel, ivan
21:11:54 <shiyu> shiyu has joined #did
21:12:01 <decentralgabe> burn: I would like Will to run the proposal first for this, then Manu you can run one for echinda
21:12:26 <decentralgabe> manu_: the other thing ... we need to suggest the short name, which I presume is did-resolution
21:12:27 <pchampin> present+
21:12:28 <decentralgabe> present+
21:12:32 <dmitriz> present+
21:12:38 <burn> present+
21:12:39 <ericaconnell> present+
21:12:40 <JennieM> present+
21:12:45 <JoeAndrieu> JoeAndrieu has joined #did
21:12:51 <danpape> present+
21:12:52 <JoeAndrieu> present+
21:12:59 <EricS> EricS has joined #did
21:13:09 <Wip> the DID WG will publish the following https://w3c.github.io/did-resolution/FPWD/2024/index.html as an FPWD for did-resolution with the short name did-resolution on the 24th of October 2024
21:13:14 <EricS> present+
21:13:47 <TallTed> s| the DID WG will publish the following https://w3c.github.io/did-resolution/FPWD/2024/index.html as an FPWD for did-resolution with the short name did-resolution on the 24th of October 2024||
21:14:03 <manu_> s|the DID WG will publish the following https://w3c.github.io/did-resolution/FPWD/2024/index.html as an FPWD for did-resolution with the short name did-resolution on the 24th of October 2024||
21:14:12 <TallTed> RRSAgent, draft minutes
21:14:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
21:14:19 <manu_> rrsagent, draft minutes
21:14:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html manu_
21:15:09 <TallTed> q+
21:15:13 <decentralgabe> Wip: Does anyone have any concerns for the proposed text before we move forward?
21:15:16 <decentralgabe> ack christophera
21:15:44 <decentralgabe> ChristopherA: we have people that haven't been in a W3C process before. we may want to give a recap of what it means to be in a FPWD, who can vote, and what this is ...
21:16:02 <Jay> Jay has joined #did
21:16:03 <kazoo> kazoo has joined #did
21:16:26 <Wip> \me thanks Ted
21:16:39 <decentralgabe> burn: there are several stages in the W3C rec track process. the first stage is called a First Public Working Draft. it begins the intellectual property disclosure process. when certain triggering events occur, this being one of them, you will review the document to make sure you do not have IP conflicts
21:17:03 <TallTed> s|\me thanks Ted||
21:17:04 <decentralgabe> ... please read the IPR policy. only invite experts and w3c members of this group can vote. please do not vote if you are not! we know there are sometimes guests.
21:17:07 <Wip> q?
21:17:15 <TallTed> RRSAgent, draft minutes
21:17:16 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
21:17:29 <Wip> ack TallTed
21:17:30 <decentralgabe> ... this is a 'continuing group' in a sense ... not everyone has participated so we are giving people context!
21:17:50 <bkardell_> bkardell_ has joined #did
21:18:02 <decentralgabe> TallTed: I added the revised proposal with the addition of 'DRAFT' -- it is proposed, then we vote, then it becomes resolved (or not)
21:18:03 <smccown> smccown has joined #did
21:18:20 <decentralgabe> Wip: hearing no objections to the current proposed text
21:18:21 <Wip> PROPOSED: Publish the DID Resolution specification (https://w3c.github.io/did-resolution/FPWD/2024/index.html) as a W3C First Public Working Draft with a target publication date of 2024-10-24 and a proposed short name of did-resolution
21:18:24 <manu_> +1
21:18:25 <JoeAndrieu> +1
21:18:27 <burn> +1
21:18:27 <decentralgabe> +1
21:18:28 <Wip> +1
21:18:36 <TallTed> +1
21:18:36 <markus_sabadello> +1
21:18:36 <bigbluehat> bigbluehat has joined #did
21:18:36 <dlongley> +1
21:18:36 <dmitriz> +1
21:18:36 <ChristopherA> +1
21:18:36 <shigeya> +1
21:18:36 <Wonsuk> +1
21:18:41 <smccown> +1
21:18:43 <JennieM> +1
21:18:47 <denkeni> +1
21:18:50 <danpape> +1
21:19:29 <Wip> RESOLVED: Publish the DID Resolution specification (https://w3c.github.io/did-resolution/FPWD/2024/index.html) as a W3C First Public Working Draft with a target publication date of 2024-10-24 and a proposed short name of did-resolution
21:19:31 <decentralgabe> burn: please vote 1 per org. do not want to have a disproportionate representation
21:19:47 <decentralgabe> ... we declare it resolved! Manu, would you like to make a proposal about echidna
21:19:50 <decentralgabe> q?
21:19:51 <bruno> bruno has joined #did
21:20:59 <decentralgabe> manu_: echidna is a document publishing system the W3C uses to automate the publishing process. it used to be a lot more of a complex process to publish new versions. this meant new versions were only published every few months. echidna was put in place so that any time the editors merge something to the main branch, echidna auto-publishes a version of that document.
21:21:00 <Geun-Hyung> Geun-Hyung has joined #did
21:21:12 <TallTed> for future... I would appreciate announcement of "one vote per member org" before or with the PROPOSED, as that can change my opinion of the wording.
21:21:24 <Geun-Hyung> present+
21:21:26 <JoeAndrieu> q+
21:21:31 <manu_> q+
21:21:34 <decentralgabe> ... this proposes the WG use echidna for all documents the WG publishes after the FPWD
21:21:35 <burn> ack JoeAndrieu
21:21:52 <decentralgabe> JoeAndrieu: I want to clarify, this echnida stops when we get to CR? then we have a different process?
21:21:53 <burn> ack manu_
21:22:32 <decentralgabe> manu_: echidna needs to be disabled at certain points in the process. we should enable it after FPWD. when we go to CR, we turn it off. then go to CR. then re-enable it to publish CR drafts. then turn it off before PR. etc.
21:22:57 <JennieM> JennieM has joined #did
21:23:10 <decentralgabe> ... re: pushing back on the proposed resolution amendment from Dan. hopefully this proposal works for all documents the group publishes, so that we do not need to agree to use echidna for future documents.
21:23:12 <burn> q+
21:23:17 <burn> ack burn
21:23:37 <ChristopherA> Q+
21:23:39 <decentralgabe> burn: that is fine. understanding that this is for the rubric and all other documents. I don't have an objection.
21:23:40 <burn> ack ChristopherA
21:24:00 <manu_> q+
21:24:03 <decentralgabe> ChristopherA: are there some documents we have inherited that we may not want to auto-publish. like the plain CBOR document. I don't think that's a good starting point.
21:24:07 <decentralgabe> q+
21:24:07 <burn> s/understanding/I want to make sure that everyone understands/
21:24:11 <burn> ack manu_
21:24:27 <decentralgabe> manu_: that's a good point ... we don't have to enable echidna ... we can be clear what we're talking about
21:24:28 <dlongley> could say echidna by default unless otherwise stated
21:24:31 <decentralgabe> q-
21:24:41 <JoeAndrieu> q+
21:24:58 <burn> ack JoeAndrieu
21:25:09 <PZ> PZ has joined #did
21:25:25 <decentralgabe> JoeAndrieu: the use case document could also go in there. for the VCWG we thought we were on echidna but we were not. it would be good to have an explicit list.
21:25:25 <manu_> q+
21:25:33 <Wip> ack manu_
21:25:44 <manu_> The list of WG deliverables are here: https://www.w3.org/2024/04/did-wg-charter.html
21:25:45 <JoeAndrieu> q+ to ask about registries & echidna
21:26:20 <bayfox> bayfox has joined #did
21:26:24 <manu_> q?
21:26:27 <decentralgabe> ChristopherA: the only one's we haven't mentioned are the plain CBOR representation and implementers guide. I will vote against the CBOR representation. the only one questionable is the implementers guide.
21:26:27 <burn> ack JoeAndrieu
21:26:27 <Zakim> JoeAndrieu, you wanted to ask about registries & echidna
21:26:41 <manu_> q+
21:26:44 <decentralgabe> JoeAndrieu: do we have any visibility into the interactions b/w echidna when it is a registry?
21:26:51 <burn> ack manu_
21:27:04 <decentralgabe> manu_: my expectation is that echidna should operate normally for a registry. it should auto-publish. don't see any reason why it wouldn't work like that.
21:27:25 <burn> q+
21:27:29 <decentralgabe> ... +1 to Christopher's proposal to not apply it to the CBOR representation or implementation guide until someone pushes it forward. it won't be auto-published until someone works on the documents.
21:27:33 <pchampin> q+
21:27:36 <burn> ack burn
21:28:16 <decentralgabe> burn: doesn't that mean .. anything not intended as a note can use echidna?
21:28:20 <decentralgabe> manu_: where is the use cases document?
21:28:20 <dlongley> "use echidna for everything except docs X and Y"
21:28:37 <decentralgabe> burn: let's list the docs it applies to.
21:29:29 <burn> ack pchampin
21:29:43 <decentralgabe> pchampin: we have precedence of registries using echidna, should be no problem with that
21:30:00 <decentralgabe> q?
21:30:31 <manu_> PROPOSED: The Working Group will use Echidna to publish the following documents: DID Extensions, DID Method Rubric, DID Core, and DID Resolution.
21:30:35 <decentralgabe> burn: any questions? recommendations for change? [ hear none ]
21:30:36 <manu_> +1
21:30:37 <JoeAndrieu> +1
21:30:37 <decentralgabe> +1
21:30:37 <burn> +1
21:30:39 <smccown> +1
21:30:39 <markus_sabadello> +1
21:30:40 <denkeni> +1
21:30:41 <Wonsuk> +1
21:30:41 <shigeya> +1
21:30:42 <TallTed> +1
21:30:42 <ChristopherA> +1
21:30:47 <Wip> +1
21:30:57 <dmitriz> +1
21:31:04 <decentralgabe> burn: resolved!
21:31:06 <manu_> RESOLVED: The Working Group will use Echidna to publish the following documents: DID Extensions, DID Method Rubric, DID Core, and DID Resolution.
21:31:24 <manu_> q+
21:31:25 <decentralgabe> ... is there anything else related to this topic of publication processes that needs to be addressed at this time?
21:31:25 <Wip> q+
21:31:28 <burn> ack manu_
21:31:30 <manu_> q-
21:31:56 <decentralgabe> manu_: ... is did use cases not in our charter?
21:32:00 <decentralgabe> pchampin: we can make new notes
21:32:26 <burn> ack Wip
21:32:35 <manu_> q+
21:32:38 <decentralgabe> decentralgabe: the use cases doc is currently an editors draft and will need to be changed https://w3c.github.io/did-use-cases/
21:32:47 <burn> ack manu_
21:32:48 <decentralgabe> Wip: I noticed some URLs are not working properly
21:32:52 <JoeAndrieu> There is a published Note of the use cases https://www.w3.org/TR/did-use-cases/
21:33:16 <Wip> https://www.w3.org/TR/did-extensions/
21:33:17 <HaoYuan> HaoYuan has joined #did
21:33:21 <manu_> other link is here: https://w3c.github.io/did-extensions/
21:33:43 <decentralgabe> manu_: maybe PA you know the answer to this ... there is a subdirectory structure, and when published through echidna it is not publishing the sub-directory stuff for extensions
21:33:54 <decentralgabe> ... the HTML5 is multi-document, so this should work
21:34:00 <decentralgabe> pchampin: I was not aware of this and will check.
21:34:15 <decentralgabe> manu_: in the editor's draft it works just fine. in TR space the links get broken.
21:34:18 <Wip> q+
21:34:30 <smccown> For clarification:  Use Cases are covered by the W3C process doc (https://www.w3.org/policies/process/#recs-and-notes) "Groups can also publish documents as W3C Notes and W3C Statements, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use. See §
21:34:30 <smccown> 6.4 The Note Track (Notes and Statements) for details."
21:34:50 <Wip> This old link still works - https://www.w3.org/TR/did-spec-registries/#extensions
21:35:07 <decentralgabe> ... TR means "Technical Report" which is the official home of a specification. when we publish something we pick a short name (like did-resolution). when we publish a document it is put on the w3c site under /TR/<short-name>
21:35:47 <burn> q?
21:35:48 <decentralgabe> ... it is continually published when we use echidna. we will publish to TR space .. then when the WG shuts down the document will in theory live there forever until a new WG comes along to update the document. there are some other ways this can change.
21:35:50 <burn> ack Wip
21:35:55 <Wip> https://www.w3.org/TR/did-spec-registries/#extensions
21:36:07 <decentralgabe> Wip: flagging the did spec registries link ... should it still resolve?
21:36:32 <decentralgabe> pchampin: the links in the section resolve to a 404. we will dig into it
21:36:50 <decentralgabe> burn: PA will take an action to resolve this
21:36:59 <decentralgabe> pchampin: does someone have a link to the HTML5 spec that follows this pattern?
21:37:41 <decentralgabe> burn: we are past our original half hour for the 5 min decision. anything else?
21:37:44 <JonesJ38> JonesJ38 has joined #did
21:38:05 <decentralgabe> ... our next topic is the DID Test Suite and Resolver Test suite. there are no slides. just discussion.
21:38:33 <decentralgabe> Wip: we touched on how we would test interoperability. it is connected. this is really - what actions are we taking as a group to sort out our test suite so we can demonstrate interoperability.
21:38:53 <cc> cc has joined #did
21:38:53 <decentralgabe> .. does anyone have context on what exists currently? I'd like to call on Benjamin since he runs the VC stuff
21:38:59 <manu_> q+ to speak to what test suite we have now
21:39:04 <markus_sabadello> q+
21:39:05 <shigeya> q+
21:39:07 <ChristopherA> @pierre https://github.com/w3c/did-extensions/issues/576
21:39:37 <decentralgabe> https://w3c.github.io/did-test-suite/
21:40:46 <ChristopherA> I assigned it to GitHub @pchampin
21:41:02 <shigeya> q-
21:41:16 <decentralgabe> manu_: here is a link to our current test suite (https://w3c.github.io/did-test-suite/). if you look at section 4.4.1 ... effectively the suite checks the DID and the Document. does the document conform? does the DID conform to the syntax we've defined?
21:41:20 <TallTed> RRSAgent, draft minutes
21:41:21 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html TallTed
21:42:07 <decentralgabe> ... we have 102 methods which submitted tests for this. for each method we can see if it passes a particular test for each normative statement in the specification. we are largely a data model specification ... which is what the tests cover.
21:42:31 <decentralgabe> ... section 4.2 covers the normative statements we are covering. not all methods have implemented all normative statements.
21:42:46 <burn> q?
21:42:49 <burn> ack manu
21:42:49 <Zakim> manu_, you wanted to speak to what test suite we have now
21:43:15 <decentralgabe> .. it is fairly comprehensive. not a lot of methods have problems in passing our test suite. in the future we want this to be far more interactive and dynamic. in the past we got a DID string and a document which we checked into a repository. who knows if these methods are still conformant or not.
21:43:22 <decentralgabe> ... in the VCWG we have made this more active.
21:43:29 <burn> ack markus_sabadello
21:43:56 <Wip> q+ to ask if it should be a requirement to pass the test suite as part of DID method registry submission
21:44:03 <decentralgabe> markus_sabadello: It is 102 test reports, not methods. there can be multiple reports per method. there is a separate DID resolution report in the CCG.
21:44:14 <markus_sabadello> https://github.com/w3c-ccg/did-resolution-test-suite
21:45:12 <decentralgabe> ... the resolution test suite we have goes beyond the data model. also tests the resolution and dereference function by using the HTTPS binding. connects to an endpoint, sends a DID resolution or dereference requests, and checks aspects of the responses. it hasn't received as much attention as the DID core test suite.
21:45:40 <decentralgabe> ... there are no automated test reports. it is possible to download it .. you can configure the repository to generate test reports locally. can be useful as a starting point.
21:45:46 <burn> ack Wip
21:45:46 <Zakim> Wip, you wanted to ask if it should be a requirement to pass the test suite as part of DID method registry submission
21:46:08 <JoeAndrieu> +1
21:46:08 <decentralgabe> Wip: should be a requirement to pass the test suite as part of DID method registry submission?
21:46:08 <JoeAndrieu> q+
21:46:10 <TallTed> q+
21:46:16 <burn> ack JoeAndrieu
21:46:22 <ChristopherA> q+
21:46:46 <decentralgabe> JoeAndrieu: we have talked about this. I think it is a really good idea. there is a burden on the editors, but if it is self-reported, and what we accept, maybe it reduces that burden. I don't know why we would put a DID method in a registry if it is not conformant.
21:46:50 <burn> ack TallTed
21:46:54 <decentralgabe> ChristopherA: which level of conformance?
21:47:21 <manu_> q+ benjamin
21:47:25 <manu_> q+ to speak to https://w3c-ccg.github.io/did-key-test-suite/#conformance (after Benjamin goes)
21:47:28 <decentralgabe> TallTed: we have talked about this before. it is a substantial burden on the editors. we do have a new group of editors who are maintaining the original registry. I am not on that team (for good reason). It is a substantial burden of time.
21:47:43 <bigbluehat> q+
21:47:48 <manu_> q- benjamin
21:48:11 <decentralgabe> ... getting the information that is requested is like pulling teeth. I don't feel like the burden is worth it. sometimes automatic tooling can help generate results. this could be a substantial burden as well.
21:48:12 <decentralgabe> q+
21:48:13 <burn> ack ChristopherA
21:49:21 <decentralgabe> ChristopherA: I am OK with some kind of field in the method section of the registry that someone can self-report. I do not believe it should be a requirement. I concur with Ted that it's a real burden on the approving team. It has downstream complications.
21:50:02 <decentralgabe> ... I would like to see a list of parties that conform to resolution. DID resolver conformance is not required. using a resolver or the API does not prohibit your use of a DID or DID Document.
21:50:02 <Wip> ack manu_
21:50:02 <Zakim> manu_, you wanted to speak to https://w3c-ccg.github.io/did-key-test-suite/#conformance (after Benjamin goes)
21:50:12 <manu_> q+ to speak to https://w3c-ccg.github.io/did-key-test-suite/#conformance (after Benjamin goes)
21:50:14 <decentralgabe> q-
21:50:15 <decentralgabe> q+
21:50:25 <decentralgabe> ack bigbluehat
21:50:47 <bigbluehat> https://github.com/w3c/vc-test-suite-implementations
21:51:30 <decentralgabe> bigbluehat: how the test suite is used is a great conversation which we should come back to. the W3C test suites are testing the spec's statements. they do that by testing implementations, but that is a secondary concern. that doesn't mean we can't turn them into something better. it is better to have an underpinning CG to maintain the suites long term.
21:52:16 <decentralgabe> ... the VCWG/CCG test suites, parallel to what we have here, do specification testing (MUST statements). the data model suite is up to date. shows all MUST statements, a link to the spec, and who passed. there is also an interop grid, where the suite was implemented through a minimal VC API.
21:52:59 <decentralgabe> ... there are live tests that run every Sunday, which is beyond the W3C requirements, but does mean we have up-to-date stats on how everyone is doing. the interop tests have gotten less attention than the spec tests. these move VCs in and out of issuers and verifiers to promote cross-consumption.
21:53:18 <manu_> https://canivc.com/reports/di-ed25519signature2020-test-suite/suites/data-integrity-issuer/
21:53:36 <decentralgabe> ... not sure how much will be applicable here. but this does go beyond a JSON-schema evaluation of the data model. this is something we built at Digital Bazaar to aggregate results to understand what implementers have covered.
21:55:19 <decentralgabe> ... there is a spider chart per implementation for issuers and verifiers. we can see across multiple specs how one implementation is doing. there are 15 or so implementations listed here. an aggregate of VCWG and CCG tests in one place. a useful tool to understand the ecosystem.
21:55:38 <TallTed> q+ to note that it's important to track *implementations*, not *companies*
21:55:48 <decentralgabe> ChristopherA: what does the dark blue mean?
21:56:07 <decentralgabe> bigbluehat: that it is unimplemented. you have to opt-in to the test. see it at https://canivc.com/.
21:56:33 <manu_> https://w3c-ccg.github.io/did-key-test-suite/#conformance
21:56:41 <yangsamy> yangsamy has joined #did
21:56:51 <decentralgabe> ... question for this WG ... how dynamic do we want the tests to be? there is a test suite that is semi-dynamic for did key. if there is a known way to do resolution we can test conformance more often.
21:57:40 <burn> q?
21:57:41 <decentralgabe> ... we have integration tools for mocha-js, for ocaps/zcaps. there are 2-3 community implementations in js, python, rust. can work even if you have static tests behind an API server
21:58:37 <manu_> q-
21:58:38 <decentralgabe> ... we are working on surfacing reporting better so that you know what went wrong. this is beyond what the W3C requires. but more implementations are better!
21:58:55 <decentralgabe> q-
21:59:16 <burn> ack manu_
21:59:25 <burn> ack TallTed
21:59:27 <Zakim> TallTed, you wanted to note that it's important to track *implementations*, not *companies*
21:59:36 <bigbluehat> q+
21:59:55 <burn> ack bigbluehat
21:59:58 <decentralgabe> TallTed: these are all company names, which is great. but also problematic. companies may have different implementations. it can have the company name but should also have the implementation name.
22:00:23 <decentralgabe> bigbluehat: there is a PR called 'implementation details' that I could use your help with, Ted, which adds additional information
22:00:48 <decentralgabe> ... there is also no link to the implementation. there should be a link to open source implementations so the community can use it. haven't had time to remodel it yet.
22:01:20 <manu_> q+
22:01:43 <bigbluehat> q+
22:01:47 <manu_> q-
22:02:08 <decentralgabe> Wip: how does this VC example apply to DIDs and DID Resolution? each method will implement resolution in their own way. we want to test the results of resolution. are we testing interop across DID methods?
22:02:19 <burn> ack bigbluehat
22:02:20 <decentralgabe> ... it would be great to get something similar for DIDs
22:02:33 <decentralgabe> q+
22:02:54 <manu_> scribe+
22:03:29 <decentralgabe> bigbluehat: one of the things we kicked around was using Docker containers. you can implement behind that container. resolution methods could hide implementations ... the container could do the resolution, which would be more dynamic than committing DIDs one time. we wouldn't have to implement resolvers for each method.
22:03:34 <markus_sabadello> q+
22:03:34 <burn> ack decentralgabe
22:03:35 <kaz> q+
22:03:45 <JoeAndrieu> q+ to suggest self attesting... clients to resolvers
22:03:53 <manu_> decentralgabe: Wondering if we could use the universal resolver to do this, it has a lot of docker containers for drivers for many methods.
22:03:54 <burn> ack markus_sabadello
22:04:41 <decentralgabe> markus_sabadello: yes, the universal resolver is at DIF. there is a docker container that exposes a HTTP endpoint for each method. each can be run locally and tested using this HTTP interface. it should be included in the testing. I would also argue that it is just one project/implementation.
22:04:45 <manu_> q+ to note that there are probably two test suites here?
22:05:15 <decentralgabe> ... even though the universal resolver is well known it should be treated as just one implementation. I do like the Docker approach. it illustrates that you do not need to rely on a remote resolver service. we do not need to require DID methods have a HTTPS endpoint.
22:06:02 <decentralgabe> ... local Docker images, for some methods, need heavy infra (like blockchains ... which you don't want to start locally), which raises a question of how you can trust a result. for example running a BTC node to test did:btcr. there are pros/cons.
22:06:03 <burn> ack kaz
22:06:27 <burn> ack JoeAndrieu
22:06:27 <Zakim> JoeAndrieu, you wanted to suggest self attesting... clients to resolvers
22:06:34 <decentralgabe> kaz: there is a possibility that multiple vendors can use the same codebase. we need to be able to see the codebase as well.
22:07:07 <burn> ack manu_
22:07:07 <Zakim> manu_, you wanted to note that there are probably two test suites here?
22:07:07 <decentralgabe> JoeAndrieu: people writing clients will be motivated to test which resolvers they interoperate with. there is also some client software which we need to test. e.g. is a wallet using the resolver spec correctly?
22:07:49 <decentralgabe> manu_: there are at least 2 classes of test suites here. 1 - it has to test the resolution interface (the resolver, parameters, MUST statements). 2 - the automation of DID methods and whether they're conformant to DID Core is another set of tests
22:08:13 <decentralgabe> ... we want to replace the current test suite that we have. it is static but does not guarantee continuous conformance.
22:08:33 <bigbluehat> q+
22:08:37 <Wip> q+
22:08:38 <decentralgabe> ... unfortunately these two test suites may be different. we are definitely testing two different things between core and resolution specifications. it is a significant amount of development effort.
22:08:45 <decentralgabe> ... we will be writing two brand new test suites
22:08:46 <burn> ack bigbluehat
22:09:02 <manu_> q+
22:09:05 <decentralgabe> bigbluehat: does anybody know if we add in resolution to the current test suite, even using static files?
22:09:09 <burn> ack manu_
22:09:13 <JoeAndrieu> q+ to say is there anything in did-core that isn't just syntax or the DID and data model of the did document?
22:09:40 <shigeya> q+
22:09:44 <decentralgabe> manu_: I think so ... from what I remember our current test suite is duct-taped together a bit. it needs some TLC. it just reads a DID Document from disk. instead it should be read from network/docker container.
22:09:46 <burn> ack Wip
22:10:36 <burn> ack JoeAndrieu
22:10:36 <Zakim> JoeAndrieu, you wanted to say is there anything in did-core that isn't just syntax or the DID and data model of the did document?
22:10:36 <decentralgabe> Wip: similar to this, we could apply a suite of tests to a DID method for it and its resolver. is that testing conformance to the resolution spec across methods ... maybe that is the same implementation of resolution
22:11:08 <decentralgabe> JoeAndrieu: re:Manu, are there tests that you anticipate that are not about syntax/the data model? I think there is a nice separation between the data model and resolution
22:11:10 <decentralgabe> manu_: exactly right
22:11:14 <burn> ack shigeya
22:12:04 <decentralgabe> shigeya: as an implementer of the original DID core tests ... it is a duct-taped thing. the restriction at the time was that the tests should be very static, not dynamic ... that was the assumption. the good news is that is very stable. of course we can plug in something dynamic.
22:12:19 <dlongley> once we have some "discovery" mechanism whereby a particular resolver implementation can specify which DID methods it can resolve, we can build a matrix where there is commonality to compare results when resolving the same DID URLs, perhaps even without having any particular restrictions/requirements on which DID methods to use/include in the test suite.
22:12:35 <decentralgabe> ... my observation is that the DID Core part of the test still requires static ... but also requires something dynamic like resolution. my gut says that the tests should be separated.
22:12:37 <burn> (nods in the room)
22:12:45 <Wip> q?
22:12:50 <ChristopherA> +1 to separation
22:13:11 <bigbluehat> q+
22:13:16 <burn> ack bigbluehat
22:13:18 <decentralgabe> Wip: maybe we should set up a CCG item to set up these flows? to manage the lifecycle past this group. Should this be on our roadmap?
22:13:41 <Wonsuk> Wonsuk has joined #did
22:13:47 <decentralgabe> bigbluehat: the WG is the only group that can officially sanction the test suite. it has to be delivered by the WG members according to the patent policy. then the CCG members can help out.
22:14:16 <burn> q+
22:14:50 <decentralgabe> .. make sure that it passes as we go to TR. 2+ impls have to pass each statement for those statements to stay in the spec. after that the CG can take it over and do what they want. the report that went up with the spec has to be stable. there are two modes of existence. depends on the WG/CG combo within the W3C. there are also web platform tests that run all the time.
22:15:03 <burn> ack burn
22:15:17 <bigbluehat> q+
22:15:46 <decentralgabe> burn: who owns the testing piece now? (which individuals?) Benjamin, do you have a recommendation of which steps we should take in which order based on the conversation we've had so we can assign people.
22:15:47 <burn> ack bigbluehat
22:16:50 <decentralgabe> bigbluehat: great we're having this conversation now as opposed to much later. I would recommend the group not lean heavily on a single provider. The VCWG has been a lonely, singular job. But it is under-reviewed. People don't care until they don't pass.
22:17:10 <decentralgabe> ... there have been lots of false-positives. It would be great to have multiple people involved.
22:17:11 <decentralgabe> q+
22:18:13 <decentralgabe> ... example of the test suite -- https://w3c.github.io/vc-data-model-2.0-test-suite/
22:18:53 <ChristopherA> q+
22:18:56 <JennieM> JennieM has joined #did
22:19:09 <decentralgabe> ... there is a way in respec to link from the spec back to the test suite. we can explore using web annotations to link back to the tested statements.
22:19:48 <decentralgabe> ... it should be multi-constituent. there are key decisions on how we do resolution (how dynamic/static). could be a good topic for special topic calls.
22:19:57 <burn> ack decentralgabe
22:20:19 <burn> q+
22:20:27 <bigbluehat> q+
22:20:28 <burn> ack ChristopherA
22:20:30 <manu_> decentralgabe: Editors should be responsible for contributing to the test suite. It's a risk to only have one compmany maintain them. My intuition is that Editors have an implementation that they're working on and part of that duty should be to contribute to the test suit.
22:20:37 <manu_> s/suit./suite./
22:21:23 <decentralgabe> ChristopherA: there are tests for core and resolution. we were talking yesterday that there are many interesting edges on resolution. we care most about the simpler cases where there isn't a test of rotation ... let's make sure we have the simpler set solid by the time we close.
22:21:32 <burn> q+ to talk about history, champion, and QA
22:21:55 <decentralgabe> ... the more complex tests are out of the scope. maybe there are a few lines of what we deliver with respect to the test suites. there is core, a subset of resolution, and then also supersets.
22:21:55 <burn> ack burn
22:21:55 <Zakim> burn, you wanted to talk about history, champion, and QA
22:22:53 <decentralgabe> burn: thanks Benjamin. what you've presented looks really great and what I've seen in other WGs that have been successful. there is an opportunity here ... I have seen businesses come out of this (testing opportunity). each group has a champion. it is great if we have multiple champions.
22:23:19 <burn> ack bigbluehat
22:23:22 <decentralgabe> ... please engage! I have seen a lot of success when quality assurance people in your organization participate. they are used to testing anyway. they are ideal for being sticklers for what's wrong/right.
22:23:23 <Wip> q+
22:24:17 <decentralgabe> bigbluehat: it's good if editors are not responsible. they are the ones that wrote it and may have a harder time spotting issuers. good to have others eyes on it! agree on having QA people.
22:24:19 <burn> ack Wip
22:24:22 <decentralgabe> +1 Benjamin great point
22:24:32 <Kyle> Kyle has left #did
22:25:14 <burn> q+ to say that someone sets up the infrastructure that everyone else uses
22:25:19 <burn> zakim, close the queue
22:25:19 <Zakim> ok, burn, the speaker queue is closed
22:25:28 <decentralgabe> Wip: it feels like the DID Core stuff is fairly ok. we can update the test cases, but what we have is OK. we can make some updates. for DID resolution ... we need updates. What tests are we going to create? Those test cases should be applicable to every resolver.
22:26:03 <burn> ack burn
22:26:03 <Zakim> burn, you wanted to say that someone sets up the infrastructure that everyone else uses
22:26:08 <decentralgabe> ... many can use the universal resolver. To Christopher's point--many DIDs will be more complex to resolve (multiple updates, rotations). We may have to categorize the types of DIDs people should be submitting and expectations of what we should be testing.
22:26:34 <Wip> q+
22:26:47 <decentralgabe> burn: everywhere I've seen this successful, there has been someone with setting up infrastructure. at some point that will need to happen. usually not by assigning, but by volunteering. that could be you and that would be positive. opening the queue for final comments.
22:26:49 <burn> zakim, open the queue
22:26:49 <Zakim> ok, burn, the speaker queue is open
22:27:04 <decentralgabe> Wip: Markus pointed to a link where we can start. do we need to start from scratch or can we iterate on that?
22:27:27 <decentralgabe> markus_sabadello: we can start with what we have. I will take it as a responsibility to check the current states. it needs some upgrades but not re-done from scratch.
22:28:03 <decentralgabe> burn: thank you all this is a good intro conversation for this serious topic
22:28:12 <decentralgabe> ... moving on to our next topic: CBOR/CBOR-LD representation
22:28:20 <decentralgabe> Topic:  CBOR/CBOR-LD Representation
22:29:17 <decentralgabe> ChristopherA: there has been demand in the past for a CBOR-based document. it might be interesting ... CBOR is binary, can be very concise when you do it correctly. it is self-describing. wide variety of platform and language support. it is standardized at the IETF.
22:29:31 <Kyle> Kyle has joined #did
22:29:55 <decentralgabe> ... we have been working extensively at the IETF with the CBOR group about 'what it means to be deterministic' there are drafts for dCBOR, CDE, cbor-packed, cbor-ld, gordian envelope.
22:30:32 <decentralgabe> ... it is not a triple store by default. self describing is not the same as context. so what's required for this group? the charter says we have a plain CBOR representation as an 'other deliverable' we can choose to not do it.
22:31:19 <decentralgabe> ... the draft we have is problematic. I do not think anyone has implemented it. originally it had an IPFS CBOR tag but that was taken out. everything is either hex or base64. it is neither concise nor binary. it is very inefficient. there are no deployments as far as I know.
22:31:36 <decentralgabe> ... CBOR-LD has had maturity and growth in the last couple years. it is deployed in some specific areas related to linked data.
22:31:38 <cc> cc has joined #did
22:32:06 <Wip> q?
22:32:29 <decentralgabe> manu_: [slides go into CBOR-LD] ... agree with what Christopher said about what we have on CBOR in here. doesn't feel like the right thing for us to do. A little on CBOR-LD - a generalized semantic compression mechanism. it will take a document like an LD document, compress that document into a CBOR representation
22:33:17 <decentralgabe> ... a CBOR document can be an LD document. you can apply CBOR-LD to it to compress it. ... what type of compression can we expect? we tried compressing a JSON-LD document in many ways (starting at ~1200 bytes).
22:33:19 <markus_sabadello> q+
22:34:04 <dlongley> "sc" stands for "semantic compression" on the CBOR-LD slides
22:34:06 <decentralgabe> ... the CBOR-LD compressed payload gets to about ~350 bytes from ~1200 bytes. and you can get smaller. it is a generalized semantic compression scheme.
22:35:00 <decentralgabe> ... most people use 'artisanal CBOR' and you could get a 10-20% improvement if you hand pick things. if you GZIP the output of CBOR-LD with semantic compression it actually gets larger. shows how efficient it is.
22:35:10 <decentralgabe> ... if you have questions ask Wes, he is working on the specification.
22:36:08 <decentralgabe> ... as an example we used it on a did:key document. it has 7 keys (ed25519) about 1kb in size. running it through standard CBOR-LD compression we can get it to 534 bytes. with GZIP it gets down to 129 bytes (lots of duplication in did:key).
22:36:20 <decentralgabe> ... the slide shows a CBOR diagnostic representation of the compression.
22:37:06 <decentralgabe> ... so, what would this group need to do? the pitch is not 'we should all use CBOR-LD' ... but we may want to use some form of CBOR. I know there are multiple people in the group that are doing CBOR things with DID Documents. they are good experiments to run and see the outcome.
22:37:36 <decentralgabe> ... the benefits of CBOR-LD is that is a generalized solution applied to DID Documents. there are other uses with disclosable DID Documents that can be compressed too.
22:37:40 <decentralgabe> q+
22:38:24 <burn> ack markus_sabadello
22:38:25 <decentralgabe> ... if we wanted to do CBOR-LD the group would have to establish a media type for it like applicatoin/did+cbor-ld. CBOR-LD will be standardized at W3C and available for us to use. all this group has to do is say this is a media type for us to use.
22:38:34 <ChristopherA> q+
22:39:16 <JoeAndrieu> q+ to speak to the goal of getting rid of the abstract data model
22:39:26 <decentralgabe> markus_sabadello: Manu, you said that the JSON-LD DID Document can be transformed, or the CBOR-LD doc is created from the JSON-LD doc. In theory we have an abstract data model...so we should not be converting JSON-LD to CBOR-LD, instead convert any conformant implementation to another.
22:39:37 <decentralgabe> q- later
22:39:44 <burn> ack ChristopherA
22:39:49 <decentralgabe> ... this could help us answer the open question on the abstract data model
22:40:04 <decentralgabe> ChristopherA: [to Manu] what language do you use for CBOR LD today?
22:40:21 <burn> ack JoeAndrieu
22:40:21 <Zakim> JoeAndrieu, you wanted to speak to the goal of getting rid of the abstract data model
22:40:22 <decentralgabe> manu_: right now it is JS. another company is working on a Java implementation.
22:40:40 <bigbluehat> Java CBOR-LD implementation https://github.com/filip26/iridium-cbor-ld
22:40:43 <burn> ack decentralgabe
22:40:55 <bigbluehat> JavaScript CBOR-LD implementation https://github.com/digitalbazaar/cborld
22:41:12 <decentralgabe> JoeAndrieu: I wasn't sure where Markus was going but I like how we finished. This is a good argument for how an abstract data model is working against us.
22:41:27 <bigbluehat> Rust CBOR-LD implementation https://github.com/spruceid/cbor-ld
22:41:30 <decentralgabe> decentralgabe: can we transform the note to support multiple CBOR representations?
22:41:36 <manu_> decentralgabe: I wanted to support using CBOR to encode DID Documents. We shouldn't pick one, we should provide options in the CBOR document.
22:41:41 <wes-smith> wes-smith has joined #did
22:43:00 <decentralgabe> ChristopherA: if we want to do so, yes, we do have some decisions to make ... I believe there is a Java not a TS impl, and a Ruby one. it has numeric reduction and unicode text (NFC). the advantage of numeric reduction is to remove concerns around numbering differences ... the same number will always be the same number based on ANSI math
22:43:06 <burn> q?
22:43:17 <decentralgabe> ... if you want to do math larger than what ANSI supports we do not support it
22:43:56 <JoeAndrieu> q+ to say you can't "use the abstract data model" for CBOR. CBOR uses a JSON data model. Which is not the abstract data model.
22:44:11 <decentralgabe> ... there are other formats that could be an IETF standard. there is a packed compression format. there is one with tags. and what Gordian envelopes does. The other option is to create a profile using Gordian Envelopes, which is already a dCBOR triple store.
22:45:00 <decentralgabe> ... it already has subject/predicate things and supports compression. it also adds radical new things like the ability to elide. but you don't have to do it. you can do just the abstract data model and Gordian Envelope.
22:45:15 <decentralgabe> ... I think we should do the LD one but if there is interest/demand in a non-LD model we can do it.
22:45:17 <burn> ack JoeAndrieu
22:45:17 <Zakim> JoeAndrieu, you wanted to say you can't "use the abstract data model" for CBOR. CBOR uses a JSON data model. Which is not the abstract data model.
22:45:38 <manu_> q+ to note "it doesn't have to be LD?"
22:45:45 <burn> ack manu_
22:45:45 <Zakim> manu_, you wanted to note "it doesn't have to be LD?"
22:45:48 <decentralgabe> JoeAndrieu: I do not think we can do it, Chris. The abstract data model is in JSON and CBOR uses a different data model. CBOR can work with any JSON.
22:46:30 <decentralgabe> manu_: just a note on CBOR-LD and the type of data it has. generally DID Documents are simple things. they store keys and some other information ... but in general the fields you have are limited. storing more is a bad idea.
22:46:54 <decentralgabe> ... we could create an artisanal format for the most basic things. it would be specialized but not hard to implement.
22:47:47 <decentralgabe> ... CBOR-LD is meant to be generalized for any JSON-LD document. but what about plain JSON stuff? you can use CBOR-LD. even for a JSON based document -> CBOR you can inject a context in and proceed with the compression.
22:48:11 <decentralgabe> ... it is possible to compress plain JSON documents using CBOR-LD before compression and reversing the process during decompression. a bit of a hack, but a way to do it.
22:48:36 <decentralgabe> ... doing the Linked Data stuff is important for extensions. but we have a core that will have massive compression but does not necessarily need linked data
22:48:42 <decentralgabe> +1 to artisanal CBOR
22:49:52 <decentralgabe> ChristopherA: so what does Gordian Envelope add to this? we already have a claim. you can put context information on any attribute. it already has an extension mechanism. you can add proprietary extension too. it is similar to other formats with salts, but has a merkle tree where each predicate set can have a salt.
22:50:17 <decentralgabe> ... the salt can be a small value (4 bytes) does not need to be 256 byte salts. this is better than the SD model with a single salt. you can salt individual items.
22:50:20 <JoeAndrieu> also +1 to supporting both CBOR-LD and supporting development of an artisanal version that works with WG defined properties
22:50:38 <manu_> q+ to ask about did:dht and what could be used there when we have larger key sizes and service descriptions.
22:50:48 <decentralgabe> ... there is value longer term in being able to offer elision. only reveal what the user/app needs. this could easily be something for DID 2.0 to support elision
22:50:48 <burn> ack manu_
22:50:48 <Zakim> manu_, you wanted to ask about did:dht and what could be used there when we have larger key sizes and service descriptions.
22:51:01 <decentralgabe> q+
22:51:43 <decentralgabe> manu_: for did:dht there is a limit on DID Document sizes (1000 bytes) ... there is concern when your DID Document grows past this. if we are using BBS keys or post quantum keys you can be much larger than 1KB. we could use elision for this!
22:52:06 <decentralgabe> ... Gabe, thoughts on what happens when we have larger keys or post-quantum keys? Has there been thought about this?
22:52:06 <burn> ack decentralgabe
22:52:52 <manu_> decentralgabe: Yes, we have a couple of thoughts today -- might be in spec -- chaining did:dhts together, chaining secondary documents together... or point to external resource that contains authenticated documented. Less familiar with elision mechanisms, good to explore that idea as well.
22:53:05 <dezell> dezell has joined #did
22:53:55 <decentralgabe> manu_: I do not think I heard anyone defending our current CBOR document. Maybe we should update it and put the current thoughts of the group into it. There is support for supporting multiple types of conversion to CBOR. some support for artisanal CBOR. defining that will get us well down the road. similar support for CBOR-LD.
22:53:58 <ChristopherA> Q+
22:54:11 <wes-smith> wes-smith has joined #did
22:54:22 <burn> ack ChristopherA
22:54:30 <decentralgabe> ... we would probably need a mechanism to signal which CBOR scheme you are using. it is a bit in the CBOR payload. we should explore Gordian Envelope and explore other elision mechanisms.
22:55:19 <decentralgabe> ChristopherA: we as W3C are very web oriented. we don't concern ourselves as much with difficulties of doing this in embedded hardware. I have been working with NFC cards...using a constrained subset of Java. With CBOR and embedded systems/chips, it's much easier to deal with this representation.
22:55:44 <decentralgabe> ... as our usage expands to embedded hardware or IoT devices I would like to see that community speak up. Very small sensors could have a DID.
22:55:50 <decentralgabe> burn: any other comments?
22:55:51 <denkeni> +1 to the use cases that could be expanded to the embedded system
22:56:11 <JoeAndrieu> +1 denkeni  agreed.
22:56:12 <decentralgabe> ... thank you for a good session. we are about to go on our last break of the day. we will have some announcements at the very end.
22:56:48 <decentralgabe> ... back at :25
22:56:56 <Kyle> Kyle has left #did
22:57:12 <denkeni> We actually have hardware vendors in Taiwan investigating DID solutions
23:24:10 <burn> burn has joined #did
23:26:33 <burn> present+
23:26:39 <Wip> Wip has joined #did
23:26:48 <Wip> present+
23:27:20 <Jay> Jay has joined #did
23:30:10 <decentra_> decentra_ has joined #did
23:30:29 <wes-smith> wes-smith has joined #did
23:30:34 <manu_> manu_ has joined #did
23:31:00 <JoeAndrieu> JoeAndrieu has joined #did
23:31:09 <burn> Topic: Minimum Criteria for DID Method Standardization at the W3C
23:31:57 <decentra_> present+
23:32:00 <ericaconnell> ericaconnell has joined #did
23:32:11 <wes-smith> present+
23:32:15 <smccown> smccown has joined #did
23:32:26 <JoeAndrieu> present+
23:32:40 <ericaconnell> present+
23:32:48 <smccown> present+
23:32:58 <TallTed> Zakim, who's here?
23:32:58 <Zakim> Present: denkeni, Wonsuk_Lee, TallTed, manu, manu_, burn, ChristopherA, markus_sabadello, dlehn, pchampin, decentralgabe, dmitriz, ericaconnell, JennieM, danpape, JoeAndrieu,
23:33:02 <Zakim> ... EricS, Geun-Hyung, Wip, decentra_, wes-smith, smccown
23:33:02 <Zakim> On IRC I see smccown, ericaconnell, JoeAndrieu, manu_, wes-smith, decentra_, Jay, Wip, burn, Geun-Hyung, bruno, bigbluehat, bkardell_, Zakim, dmitriz, markus_sabadello, kaz,
23:33:02 <Zakim> ... ChristopherA, dlehn, jets, dlongley, TallTed, RRSAgent, rhiaro, hyojin_, manu, denkeni, cwilso, jyasskin, hadleybeeman, shigeya, pchampin, cel, ivan
23:34:39 <Jay> present+
23:35:29 <shigeya> present+
23:35:59 <dlongley> present+
23:36:00 <burn> scribe+
23:36:02 <markus_sabadello> present+
23:36:09 <decentra_> Topic: Brett Banfe on BSV
23:36:17 <ChristopherA> present+
23:36:32 <hyojin_> present+
23:36:41 <Geun-Hyung> present+
23:36:43 <dmitriz> present+
23:36:49 <JennieM> JennieM has joined #did
23:36:55 <burn> Brett Banfi: enjoyed the session.  Hiring in our team to extract biz requirements that this group would be interested in implementing.  would love advisors on that, reach out to me if interested.  BSV Alliance.
23:37:03 <decentra_> Topic: Open Topics
23:37:05 <burn> Wip: remainder of session will be on open topics
23:37:13 <decentra_> Subtopic: Minimum Criteria for DID Method Standardization at the W3C (Manu)
23:37:19 <pchampin> present+
23:37:42 <burn> manu: asking the group if theer aer any opionins on which did methods should be standardized at W3C (in another group).
23:38:00 <danpape> danpape has joined #did
23:38:06 <danpape> present+
23:38:16 <burn> ... another group will be proposed tomorrow to do that.  Need predferred criteria to meet for standardization.  Think of this as antipatterns and patterns for what should go into W3c.
23:38:33 <burn> ... a blockchain based DID method would be hard to do heer because of some opposing member companies.
23:38:36 <HaoYuan> HaoYuan has joined #did
23:38:58 <burn> ... even if we proposed a well-done one, it would likely create formal objections.  So maybe not best to try that here.
23:39:03 <danpape> s/heer/here/
23:39:04 <burn> ... just one example.
23:39:08 <Wip> q?
23:39:14 <KevinDean> KevinDean has joined #did
23:39:37 <burn> ... wrt a good place, did:web or did:dtw use web tech.
23:39:38 <JennieM> present+
23:39:48 <KevinDean> present+
23:40:10 <burn> ... should have multiple implementations, well-vetted spec, broad deployment and production (ideally).  what does the group think?
23:40:11 <ChristopherA> I still want do see did:onion as a decentralized did:web
23:40:21 <burn> ... criteria for being standardized here.
23:40:25 <KevinDean> q+
23:40:27 <ChristopherA> Q+
23:40:32 <Wip> ack KevinDean
23:40:33 <TallTed> q+
23:40:41 <manu_> present+
23:41:52 <Wip> ack ChristopherA
23:41:52 <dezell> dezell has joined #did
23:41:53 <burn> KevinDean: 1. standardizing a did method with broad deployment. 2. idea of a quick start.  interested in VCs at GS1.  did:web was implemnteted knowing that for any production solution we needed soemthing better, but it was a quick sart.  Ease of implementatnion important.
23:41:59 <dezell> preent+
23:42:04 <dezell> present+
23:42:04 <decentra_> q+
23:42:25 <burn> ChristopherA: intrigude by antipattern comment.  several people looking for human-readable names, for example,  this is my interest area.
23:42:55 <Wip> ack TallTed
23:42:55 <burn> ... doing a did:web their own way (ignorantly)
23:42:57 <JoeAndrieu> q+ to say independent verification of proofs without reliance on a central party
23:43:10 <burn> TallTed: this would be a good use of the rubric.
23:43:30 <brent> brent has joined #did
23:43:30 <burn> ... tick off the things that are w3c-like as important.  Should be high on those scales, for example.
23:43:35 <brent> q?
23:43:54 <burn> ... don't think ease of implemeantint is in rubric, but that could still be important.
23:43:56 <Wip> ack decentra_
23:44:46 <burn> decentra_: agree with Ted.  Is it a mistake to standardsize ones that are not fully decenttralized, etc. unless part of a set of DID methods that meet different use cases.  For exampel,e did:key, did:web, did:tdw,
23:44:54 <brent> q+ to ask an impertinent question
23:44:57 <Wip> ack JoeAndrieu
23:44:57 <Zakim> JoeAndrieu, you wanted to say independent verification of proofs without reliance on a central party
23:44:58 <burn> ... opening ourselves up to critique if we only standard one or two of these
23:45:24 <burn> JoeAndrieu: independently verifying proofs without relying on sep'rate authority would be important.
23:45:54 <burn> ... are we looking for criteria for the group, or for the world?  uncomfortable setting up group that is curating this activity.
23:45:54 <manu_> q+ to speak to "categories that might work" -- and who is using this criteria? Group to curate activity?
23:45:54 <Wip> ack brent
23:45:55 <Zakim> brent, you wanted to ask an impertinent question
23:46:13 <burn> brent: are there many methods clamoring for this standardization?
23:46:27 <burn> ... doesn't seem to be an issue at the moment
23:46:28 <Wip> ack manu_
23:46:28 <Zakim> manu_, you wanted to speak to "categories that might work" -- and who is using this criteria? Group to curate activity?
23:47:12 <burn> manu_: if there is a new group just to stashalhie new metheds, w3C would likely object.  If we don't cover all bases, group will get rejected.
23:47:30 <burn> ... an antipattern would be a w3c group tht blesses and anoints did methods.
23:47:40 <burn> ... we are the ones who will use this info.
23:47:56 <burn> ... if there is a formal objection on the charter, that's useful info.
23:48:18 <ChristopherA> q+
23:48:23 <burn> ... brent's point is good.  How many methods actually have agreement?  only a handful
23:48:40 <burn> ... many showed up to a did method standardiation group meeting.
23:49:02 <burn> ... some are thinking they can get their method standardized despite no spec, no impl., etc.
23:49:04 <Wip> Zakim, close the queue
23:49:04 <Zakim> ok, Wip, the speaker queue is closed
23:49:24 <brent> q+ to say roughly what the categories have been
23:49:32 <burn> ... we know there are certain did methods in production with no vetting, etc.  nation states are lookinng for at least some vetting before using.
23:49:45 <burn> ... without official standardization they consder it a problem.
23:49:47 <Wip> ack ChristopherA
23:50:19 <burn> ChristopherA: a challege here is that w3c has not been considered a friendly venue.  Some went to IETF.  would love to see Keri back here.
23:50:50 <brent> minimum criteria: one's we can actually agree to standardize
23:50:50 <burn> manu_: would really love input from this group on what would make goodh criteria to help folks know whether it's worth doing the work here.
23:50:57 <ChristopherA> q+
23:51:05 <burn> ... if there is a better venue for some methods, definitiely go there
23:51:28 <burn> ... if you can think of a reason for a method not ot be done here, let us know.
23:51:44 <burn> Topic: Controller Property
23:51:54 <JoeAndrieu> When a controller property is present in a DID document, its value expresses one or more DIDs. Any verification methods contained in the DID documents for those DIDs SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are to be considered equivalent to proofs provided by the DID subject.
23:52:21 <burn> JoeAndrieu: ^ definition for controller property, likely without sufficient thought.  Maybe I wrote it.
23:52:42 <burn> ... Manu agreed that this is not how anyone uses the property.
23:52:52 <burn> ... we should discuss and figure out what to use it for
23:53:02 <burn> ... manu, whaht do you think it should have been
23:53:08 <ivan> q+
23:53:22 <brent> s/whaht/what/
23:53:26 <burn> manu_: we needed a way for the did document to express what other entity could make changse to it
23:53:35 <Wip> Zakim, open the queue
23:53:36 <Zakim> ok, Wip, the speaker queue is open
23:53:38 <burn> ... controller for the DID document, authorized to update and make changes
23:53:49 <burn> ... language makes no sense today!
23:54:22 <burn> JoeAndrieu: property we discussed today can't be used for certain methods.
23:54:52 <dlongley> q+ to say that the current language, while hard to parse, does do what manu says -- provided that the VDR supports updates via proofs created by the controller
23:54:55 <burn> ... there's a pattern in did:key where the did is put into the controller property, indicating it controls itself.  But that does'nt match th edefinition either
23:55:01 <burn> ... not sure how to proeed
23:55:14 <Wip> ack ivan
23:55:32 <burn> ivan: even more complex, that property is now specified in the VCWG, right?
23:55:49 <danpape> s/th edefinition/the definition/
23:55:50 <burn> ... in a way, it's in the other WG that we have to define it's meaning in a general way that would be usalbe for DID
23:55:56 <burn> ... this discussion is moot
23:55:59 <Wip> ack dlongley
23:56:00 <brent> q+
23:56:01 <Zakim> dlongley, you wanted to say that the current language, while hard to parse, does do what manu says -- provided that the VDR supports updates via proofs created by the controller
23:56:24 <burn> dlongley: this text is hard to read but does say what Manu says he wants, assuming VDHR accepts proofs
23:56:34 <burn> ... nothing says VDR has to accept proofs.
23:57:09 <burn> ... But if it does, it should accept ones that are created by the controller of the identifier of the documeunt.
23:57:21 <JoeAndrieu> q+ to say the language is more transclusion than alternate updaters
23:57:54 <burn> ... this language lets you do what we want, but if the VDR allows you to do proofs this way, it should allow the one listed in the controller property to do the updates.
23:58:08 <burn> ... we need to leave room for specialized implementations specific to a VDR.
23:58:21 <Wip> ack brent
23:58:37 <burn> brent: this is not moot, has not come up in VCWG
23:59:06 <burn> ... controller property as written allows control of the DID (as if you were the subject).  If we want to mae thath clear, we should
23:59:10 <Wip> ack JoeAndrieu
23:59:10 <Zakim> JoeAndrieu, you wanted to say the language is more transclusion than alternate updaters
23:59:26 <burn> JoeAndrieu: the subject is not involved in control of the document.
23:59:35 <dlongley> David = David Chadwick from the VCWG.
00:00:11 <burn> ... the language that confused Dave dosn't do what he thought.  Currently meant to do a transclusion, that verification sholud be treated as if in the document.
00:00:11 <brent> q+
00:00:14 <burn> ... probably bad security idea.
00:00:16 <Wip> ack brent
00:00:36 <manu_> q+
00:00:38 <burn> brent: (missed)
00:00:40 <dlongley> q+ to say i don't think it's a bad security idea nor do i think a VDR *has* to allow updates using proofs, but if it does allow proofs that way...
00:00:45 <manu_> q-
00:00:48 <Wip> ack manu_
00:00:53 <Wip> ack dlongley
00:00:53 <Zakim> dlongley, you wanted to say i don't think it's a bad security idea nor do i think a VDR *has* to allow updates using proofs, but if it does allow proofs that way...
00:01:25 <JoeAndrieu> q+
00:01:30 <burn> dlongley: not a bad security idea.  a vdr does not have to allow updates using proofs, but if it does, bad not to allow the controller of a did to update the document.
00:01:48 <brent> brent: there is no guarantee that the proof method in the controller's did, which may be a completely different method, is even one that the VDR can understand.
00:01:55 <manu_> q+ to note there are lots of options here, and that can be bad.
00:02:21 <Wip> ack JoeAndrieu
00:02:24 <burn> ... if you can create profos on behalf of the did, it's an antipattern to not allow that controller to do the updates
00:03:14 <Wip> ack manu_
00:03:14 <Zakim> manu_, you wanted to note there are lots of options here, and that can be bad.
00:03:14 <burn> JoeAndrieu: still talking past each other.  ew would want VDR to rpsect allowed to update. but if signed by did A and ... (joe, fill in)
00:03:32 <Wip> q+ to speak to btc1 and resolution
00:03:39 <danpape> s/ew/we/
00:03:44 <burn> manu_: we have alot of optionality we never planned for.  the subject can update the did doc.
00:03:46 <danpape> s/rpsect/respect/
00:03:49 <burn>  JoeAndrieu: disagree
00:04:38 <burn> manu_: sometimes the subject can update, sometimes not.  controller field gives someone control over did document.  dislke transclusion term.  it only says who can update it.
00:05:01 <burn> JoeAndrieu: we are talking about an auth method, going to the other did method and using that other proof
00:05:16 <manu_> q?
00:05:18 <burn> manu_: up to vdr to determine how to
00:05:31 <KevinDean> q+
00:05:39 <brent> brent has joined #did
00:05:42 <JoeAndrieu> q+
00:06:31 <burn> ... use thaht controller field.  in our impl. the VDR it lists who can update the doc.  he would have to generate proof that has one of his auth keys.  he is the one who creates an update, adds a proof, sendis to VDR, which confirms that his auth keys were used to create the proof, so valid.
00:06:37 <brent> present+
00:06:37 <Wip> ack Wip
00:06:37 <Zakim> Wip, you wanted to speak to btc1 and resolution
00:07:16 <burn> Wip: in BTC1, using controller property to invoke a proof to update the did.
00:07:36 <burn> ... resolution - how does it handle controller properties.  Maybe that needs to be addressed.
00:07:42 <Wip> ack KevinDean
00:07:58 <Wip> Zakim, close the queue
00:07:58 <Zakim> ok, Wip, the speaker queue is closed
00:08:10 <dlongley> -1 "update to the VDR what to do with the controller property" ...
00:08:21 <dlongley> i think manu was saying that how an update is performed to a VDR is up to a VDR
00:08:43 <burn> KevinDean: idea that it should be up to teh VDR to decide what te od with controller property is concerning.  'controller' to him means that it hs control of the did itself, not an ability to make st'tements about the did itsellf.
00:09:08 <burn> ... could have a did for each intety in company, but only one controller. Only the controller can update.
00:09:30 <burn> ... saying a controller means a verifier has to compare keys in a VC extends the definition too far.
00:09:35 <dlongley> we might want to limit this based on proof purpose.
00:09:43 <Wip> ack JoeAndrieu
00:09:45 <burn> ... maybe need a new attribute that someone can make a statmeent on my behlaf.
00:10:24 <dlongley> +1 the language is in the spec is weird! but is kinda right in the abstract but not really right concretely
00:10:28 <burn> JoeAndrieu: dave and manu were explaining how they thought the properyt worked.  I think the language in the spec has a different notion.  (transclusion).  And that's a security isseu and I want to get rid of it.
00:10:46 <burn> ... more work to d.
00:10:46 <ivan> q+
00:11:05 <burn> ... we have an issue on it, someone needs to try to write new laguage.  I will in the issue.
00:11:12 <burn> ... will try to move in your direction.
00:11:30 <burn> Topic: Primary on Decentralization
00:11:51 <Wip> s\Primary\Primer\
00:12:08 <burn> decentra_: the rubric has a lot of good content, but the structure doesn'  help
00:12:14 <Wip> s/Pimary/Primer/
00:12:15 <JoeAndrieu> +1 yes, it got muddied as we went beyond decentralization
00:12:18 <burn> ... maybe would be good to create a new doc
00:12:42 <burn> ... godo to define things that indicate decentralization, also that there are times when centralization is useful.
00:12:53 <brent> brent has joined #did
00:13:05 <JoeAndrieu> s/godo/good/
00:13:13 <burn> ... ex: establish id indepentetn of anything else.  an identifier in a centralized inisttition might not be good but needed
00:13:26 <burn> ... many methods is a facet of decentralization
00:13:49 <burn> ... custodial or centralized usage we can explain is not good
00:13:57 <Wip> q?
00:13:58 <manu_> q+
00:14:00 <burn> ... any interest in this kind of thing?
00:14:05 <Wip> ack manu_
00:14:10 <Wip> Zakim, open the queue
00:14:10 <Zakim> ok, Wip, the speaker queue is open
00:14:13 <denkeni> q+ for decentralization definition and solution for what
00:14:20 <burn> manu_: yes.  Would be good to summarize our lernings around d14n
00:14:27 <JoeAndrieu> q+ to +1
00:14:50 <dlongley> +1 to also talk about decentralization as a spectrum
00:15:24 <dlongley> (in addition to having many axes)
00:15:30 <burn> ... there are many axes here.  it can help W3C to talk about d14n themselves (say the TAG), and can have a section in the did core spec that mentions things you should know about d14n.  So we can pooint to that section.
00:15:32 <dlongley> (or dimensions)
00:15:40 <burn> ... this is something our group could contribute to the larger w3c
00:15:52 <Wip> ack denkeni
00:15:52 <Zakim> denkeni, you wanted to discuss decentralization definition and solution for what
00:16:03 <pchampin> also, interesting read about decentralization: https://www.rfc-editor.org/rfc/rfc9518.html
00:16:52 <dlongley> ^ thanks, was trying to remember that RFC... we should reference that and ensure not to repeat.
00:17:38 <burn> denkeni: we have projects (digital wallet) where they talk about d14n often. when people think about their API they think it is too centralized.  Govt issues VC and hosts verifictation service.  People think this is a probelm.  Also, some info has been put on blockchain, but not the VC or DID.  Only the trust registry of the issuers. But poeple
00:17:39 <burn> think it's not decentralized.
00:17:52 <Dingwei> Dingwei has joined #did
00:18:19 <wes-smith> wes-smith has joined #did
00:18:25 <burn> ... many ways to address single point of failure.
00:18:26 <Wip> ack JoeAndrieu
00:18:26 <Zakim> JoeAndrieu, you wanted to +1
00:18:46 <burn> JoeAndrieu: we need some sort of primer.  rubric good, end narrative insufficient.
00:18:51 <brent> +1 to referencing the RFC
00:19:09 <burn> ... in this doc we should celebrate that the web and DNS are decentralized in a nice way.
00:19:31 <Wip> q?
00:19:32 <burn> ... there were some central naming authorities established, we are trying to solve some of the final issues here.
00:19:40 <decentra_> q+
00:19:46 <Wip> ack decentra_
00:20:03 <burn> decentra_: sounds lie ther is interest.  I will put together some text and the group can decide where it belongs.  Thanks.
00:20:26 <decentra_> Topic: Future proofing to support MPC based multisig, in particular FROST.
00:21:11 <burn> ChristopherA: We have many assumptions based on 40 year old crypto tech.  If you keep your private key safe you can safely use your puiblic key.
00:21:40 <burn> ... property law says internet access is rented to you.  Only if you lock with private key do you have ownership.
00:22:22 <burn> ... but that's not true anymore.  new crypto challenges these assumptions.
00:22:49 <burn> ... for example.  with distridbuted keygen, we can have only one device be honest
00:23:11 <burn> ... we can still trust the key despite most devices being dishonest
00:23:39 <burn> ... do we realyl need a hardware locked device to secure a key when cooperating entities can make something stronger?\
00:23:39 <danpape> s/distridbuted/distributed/
00:24:02 <danpape> s/realyl/really/
00:24:27 <burn> ... your first identity is as a child.  that's an edge.  but now a public key can represen that edge.
00:24:44 <burn> ... advantages because we can say more complex things about relationships.
00:25:21 <burn> ... with FROST can have  large networks where a public key could represent mulitple enitties that cooperated, but you can't tell
00:25:38 <Wip> q+
00:25:56 <burn> ... in some cases the math protects us
00:26:27 <burn> ... multiparty compuation.  BBS is only a small subset of what is possibel.
00:27:03 <burn> ... merkle trees can be huge.  but now there is a ZKP that is 72 bytes to represent a whole path of the tree.
00:27:16 <burn> ... we are assuming a public key is a single prty in a single node
00:27:31 <burn> ... better not to lock ourselves into that concept
00:27:38 <Wip> ack Wip
00:27:40 <manu_> q+
00:28:03 <burn> Wip: want to be albe to support this new tech.  maybe they can.
00:28:04 <manu_> q+ to note that these are all useful things and I hope we're not preventing these use cases.
00:28:18 <JoeAndrieu> q+ to ask Chris for a reference to the ZKP merkle proof technique
00:28:28 <burn> ... eg did:ring can ????
00:29:03 <burn> ... (comments about ring signauters already being possible)
00:29:10 <manu_> s/????/There was work done to get DIDs to support ring signatures/
00:29:18 <Wip> ack manu_
00:29:18 <Zakim> manu_, you wanted to note that these are all useful things and I hope we're not preventing these use cases.
00:29:37 <burn> manu: yes we want to support them.  I don't think we prevent them toda.
00:29:39 <decentra_> https://developer.blockchaincommons.com/frost/
00:30:02 <dlongley> +1 to not prevent new interesting primitives ... but also noting that it's hard when we don't know or understand them all -- and there is always another new one :)
00:30:04 <burn> ... need to use the words "proof", "verigficaion method", etc.
00:30:21 <danpape> s/verigficaion/verification/
00:30:23 <burn> ... we should be allowing all of this to work.  MPC, multi-party keys, etc.
00:30:36 <burn> ... i think we support all of these options today, but am not sure of it.
00:30:50 <ivan> q+
00:30:51 <burn> ... does anyone know of something that is impos-ible to use today
00:31:09 <burn> ... eg some new zkevm thing that doess't fit into  proof
00:31:30 <burn> ChristopherA: subjects become more complex, esp. when edges.
00:31:38 <burn> ... no way to express that.
00:32:06 <burn> ... non-provability of voting one way or another. but sometimes you waunt accountability.
00:32:19 <Wip> ack JoeAndrieu
00:32:19 <Zakim> JoeAndrieu, you wanted to ask Chris for a reference to the ZKP merkle proof technique
00:32:19 <burn> ... what if it's multiple parties?
00:32:46 <wes-smith> q+
00:32:46 <burn> JoeAndrieu: do you have a reference for the zkp merkle proof?
00:32:51 <Wip> ack ivan
00:33:12 <wes-smith> q-
00:33:54 <burn> ivan: when you refer to relationships as an entity, this is exactly what RDF 1.2 will have.  A link has its own identity.  People working on how to reflect this in syntax, but that issue does have a path for us.
00:33:56 <Wip> q?
00:34:28 <burn> ChristopherA: also object capabilities.  the issuer has the choice to accept the keys.
00:34:47 <burn> ... or never requires talking with original issuer to verify.
00:35:12 <burn> ... more papers at blockchaincommons.com/frost
00:35:33 <burn> ... these libraries are becoming more mature and numerous, closer to deployability.
00:35:42 <burn> ... listen to the videos and transcripts there.
00:35:50 <Wip> q+
00:35:57 <Wip> ack Wip
00:36:33 <burn> Wip: with a schnorr key there is no way to know 1 of 1, 3 of 1, etc.  I can use the key but don't know how many keys secure it (for good or ill)
00:36:47 <burn> ... this can be useful, of course.
00:36:47 <Wip> q?
00:37:02 <manu_> scribe+
00:38:21 <manu_> burn: I enjoyed dinner last night, it was good. We should talk about repaying for dinner last night. Some paid out of the kindness of their hearts, they need to be repaid. If you had dinner last night, and you don't know who paid for you, you need to speak with some folks.
00:39:28 <manu_> burn: Please reimburse them.
00:39:48 <manu_> burn: It's traditional to not have regular meeting after this week. It's a tiring week, so no meetings next week.
00:40:22 <manu_> burn: What do we want to do for a F2F meeting next year? You get to stay however many days you want.
00:40:49 <manu_> burn: We can do that, rough idea of who thinks it might be valuable for such a meeting?
00:41:02 <manu_> danpape: In a year?
00:41:20 <manu_> burn: More like 6 months.
00:41:43 <manu_> ChristopherA: I know budgets are difficult now, travel is difficult, especially overseas.
00:42:24 <manu_> JoeAndrieu: There is a sample bias, those that could make it are here.
00:42:29 <manu_> ivan: Next TPAC is in Japan.
00:42:41 <manu_> burn: Next logical way to have this is in Europe.
00:43:07 <manu_> burn: Reason we're asking now is that you need to plan in advance -- cannot wait until 2 months before.
00:43:13 <manu_> burn: Thanks for the input.
00:43:17 <danpape> s/is in Japan/may be in Japan/
00:43:22 <dlongley> thanks everyone!
00:43:27 <manu_> decentra_: Thanks for coming!
00:43:35 <manu_> Everyone thanks the Chairs!!!
00:43:41 <manu_> rrsagent, draft minutes
00:43:42 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-did-minutes.html manu_
01:22:23 <Jay> Jay has joined #did
01:44:50 <Jay> Jay has joined #did