Meeting minutes
Agenda Review, Introductions
Gabe: review agenda: review special topic call
Special Topic Call in January
<decentralgabe> https://
decentralgabe: resolution path parameters in next special topic call, Jan 8th or 15th?
decentralgabe: this group meet next week, next special topic call Jan 8th
DID Core Updates
manu: controlled identifier spec doc is ready to go into CR1. However, need to review with all horizontal reviewers
manu: stability on the name & short name, features, and most of text. Will update DID Core doc with the presumption that it will get into CR
manu: will do that before addressing new PRs ... an editorial update, fix lang, etc.
DID Resolution Issue & PR Processing
open PRs
<decentralgabe> w3c/
<decentralgabe> https://
<decentralgabe> https://
markus_sabadello: Updates on PRs 99, 103, 96.
markus_sabadello: 103 adds detail to dereferencing. 1) did not found, 2) when did dereferences to a did doc
markus_sabadello: next PR describes what to do with did path, dereferencing algorithm should be explained in more detail
manu: PR 103: taking out abstract data model stuff from did core. Seems markup syntax is abstract or concrete representation?
markus_sabadello: need to update to show concrete representation
manu: is okay in examples for show_json
markus_sabadello: algorithm says if certain inputs, then these are the outputs ... will ponder more and revise
JoeAndrieu: +1 to make examples in JSON
<Zakim> manu, you wanted to note notation might suggest things other than JSON are ok?
JoeAndrieu: suggested language / details for did doc and VDR
manu: others have had strong negative reaction to abstract syntax. Should express as JSON to avoid confusion about how data is returned
markus_sabadello: happy to change / update. PR could be reviewed in terms of functionality and presentation of results. These are easy to update
<Zakim> manu, you wanted to set up .pr-preview
manu: will find docs about how to setup .pr-preview
<manu> Instructions on how to do that here: https://
<manu> Example in vc-data-model: https://
markus_sabadello: parameters in did core. did resolution alg only describes how to dereference some parameters. This PR adds placeholders to define how algorithm will process parameters.
<pchampin> markus_sabadello I just made a PR to configure PR-preview. Sorry I overlooked this earlier.
manu: looking through algorithm. At a high level algorithm seems fine. There is some discussion about fragment identifier processing. This seems about path / query params. do you feel algorithm is complete?
markus_sabadello: this is meant as preparation for special topic call. How to process path / query. one question, do we want to define parameters that we already have in did core?
<Zakim> manu, you wanted to note yes, include did core parameters
manu +1 to include those
manu: do we need text in did core that says if defining query parameters, then you need processing algorithm for them?
manu: if we revise params, then we need to revise algorithms in did resolution. Should we move the text to other specs?
markus_sabadello: yes. Alg in PR 104, alg copies all params in did core, the alg says that did methods may define how to process parameters. DID resolution spec wouldn't have to be updated every time
markus_sabadello: showing did-resolution algorithm dereferencing resource. Displaying examples (in the spec) of params and how they are to be processed. (described. more in special topic call).
@manu: do we need a step that says "you can run any alg on any query param?"
manu: concern that impression is that only a subset of params are processed
manu: may need to say that there *will* be an alg
JoeAndrieu: has significant concerns about how did methods may interpret what the did url means. We need to determine what the path part means regardless of did method implentation
markus_sabadello: found 6 issues, which may propose new params. do we want to add new params in did resolution spec that are not already in did core?
<Zakim> manu, you wanted to ask if we want to move all of that into did-resolution? Or separate specs?
markus_sabadello: examples: service parameter by name, type, etc. do we want to add this into did resolution or inform implementers to handle in their implementation
@manu: find to add new parameters into did method implementation. Wondering if did core is right place to do that. Definitions in did core, but normative in implementation?
manu: however we do it, they should be all in one place
markus_sabadello: could be, but could also be handled on a case by case basis
<Zakim> JoeAndrieu, you wanted to ask why not move them all to did resolution?
JoeAndrieu: why not move all to did resolution? are there params that shouldn't go there?
markus_sabadello: all params we're discussing are part of did resolution.
<Zakim> manu, you wanted to ask Joe if we can do that -- is it a class 3?
Issues around DID URL Dereferencing (85, 90, 39,40, 5, 43)
<decentralgabe> w3c/
manu: all params in did core are did resolution related. While we're not allowed to make class 3 changes, not clear if we can move normative features to a different spec. If we do that, do we modify 'normativeness' of features?
manu: would prefer to move param definitions to did-resolution
<pchampin> we are allowed to make class-3 changes...
markus_sabadello: sounds good. we've already moved some sections related to resolution
<Zakim> JoeAndrieu, you wanted to mention CID
JoeAndrieu: need to be able to refactor params and definitions
Ivan: question is, does it change / affect implementers, performance, etc. if yes, is class 3 change, if no, then not. Seems we're just moving normative things that don't affect implementers. To me, seems fine, but would need to ask lawyers
pchampin: moving statements seems okay. However, we are allowed to make class 3 ... just not class 4
Ivan: question is whether these changes are class 3 or 4
<manu> My read is that these changes would be a class 3 change -- moving parameters from did-core to did-resolution.
decentralgabe: decision that these are class 3 changes and not class 4
manu: we should make the changes (as class 3). Move params from did core to did resolution. Will adjust text accordingly.
markus_sabadello: if params are selected by service type, then support for did resolution.
<manu> +1 for serviceType
<decentralgabe> w3c/
markus_sabadello: PR #90 will allow parameter selection of verification by did doc
<Zakim> manu, you wanted to wonder if we need features for extracting portions of a DID Document?
manu: wondering how useful features are. if you get a did doc back, then its simple to dereference a property. Concern is: that too much messing with parameters might be too much
<Zakim> JoeAndrieu, you wanted to say I'd prefer a cleaner interface
JoeAndrieu: wanted to echo what manu said. There's a case for returning a subset / object, but usually should return did document as a whole
manu: typical case is to return full did doc, but some cases where partial can be returned. Concern is that complex path requests will make did methods too custom vs having a common interface
Wip: who's responsible for returning params vs did doc?
<Zakim> ivan, you wanted to ask about an absolutely administrative thing
markus_sabadello: we've already opened the door to return data objects vs full did document. These proposals are similar
<JoeAndrieu> markus_sabadello FWIW, I don't think that door is closed.
<pchampin> will look at it :-/
<Zakim> manu, you wanted to ask about DID Core FPWD
ivan: Looking at official W3C repos and these repos don't appear. Worried that someone just created a new repo in GitHub vs official W3C processes
Ivan: let's ensure we follow the official W3C processes for creating repos, docs, etc.