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