Meeting minutes
<Wip> rrsaget, draft minutes
<KevinDean> FYI, there's a trick you can use with bookmarks to jump into IRC with all fields pre-filled. https://
Agenda Review
Horizontal Review
manu: horizontal reviews take time. This can take 3-6 months to get a response. FIrst Public Working drafts done for DID v1.1. and resolution
manu: could include extensions and othet things we're working
manu: it goes to many groups. If sent now we'd hear back by Dec or fall
Manu: suggest we get on this now.
Will: preferred path probably a resolution to move it forward.
marcus: which version will they review if it takes so long given the spec will change during this waiting period
Manu: suggest we give them the latest editors draft. They'll do the initial review. when win candidate rec we can ask for a final review of the doc. That goes faster
Manu: give them editor's draft links to review
Will: manu would you draft a resolution proposal
Manu: yes, have we done one of these before?
Joe: no we haven't done an FPWD
Manu: we'll request read of active documents
Joe: haven't touched those docs. Phil Archer his co-editor
Joe: are there gaps, new editors needed, and work items needed
Will: will put those work items on next week's agenda
Will: Do we want to say giving editor's draft
Manu: don't need to do that (give editor's draft
Ivan: they may ask for more specificity
Ivan: intention is a resolution to go out for the request and then subsequently list the docs.
<Wip> PROPOSAL: Request horizontal review on our actively developed documents.
<manu> +1
<TallTed> +1
<ivan> +1
<Wip> +1
<ottomorac> +1
<markus_sabadello> +1
<JennieM> +1
<Phil> +1
<JoeAndrieu> +1
RESOLUTION: Request horizontal review on our actively developed documents.
<pchampin> +1
Proposal outcome is unanimous approval
TPAC 10 - 14th November in Kobe, Japan
Wip: how much time do we want to at TPAC on this?
<Zakim> manu, you wanted to suggest something.
Manu: if we hold a 2-day meeting and did methods group will split the community up if we hold a long meeting. Perhaps do a one day or half-day and share a 1/2 day with the did methods working group.
Manu: want to make sure with other WGs (DID methods of VC WG)
Wip: can use one day effectively - don't need more
Wip: Keep TPAC on your calendar
DID Core PR Processing
Wip one PR to review
w3c/did#883
manu: merged Wip's changes. One last proposal on some language. Asks that we remove normative "may" word. We're requesting spec requirements but if "may" we won't enforce. Change "may" to "can" so it conveys the same thing without normative language which requires a test suite
wil: this requires a verification but it doesn't mean you can control the did doc with that verification method
<manu> +1 to what Will just said.
TallTed: has a modification which TallTed will make shortly
DID Core Issue Processing
<Wip> https://
w3c/did#337
Wip: issues for discussion first issue: #337
wip: asking if you are referencing your verification method as a URL, should we drop those query parms for the comparison. Is the version ID in the proof supposed to match that you're trying to resolve
<JoeAndrieu> +1 it is the DID value that matters, not the DID URL
Manu: we should drop every parm and fragment. ID value needs to be the base value of the parameter.
manu: can argue differently, but we make clients become much more complicated when looking at a DID doc, know whether it's a historical doc or not, etc.
manu: identifier should be a bare identifier. Nothing more.
<Zakim> Wip, you wanted to ask about vm ids
<ottomorac> +1 agree with the proposal from Manu. did.document.id should be a bare identifier.
<Wip> https://
wip: ID can be did URL, what does that suggest?
<Wip> +1 to that
Manu: we need clarity when you are using the think and what process you're following. Just have no parameters or fragments. But doesn't mean you can't use those elsewhere.
Manu: use these parameters and queries where are needed and used as inputs to algorithms
Manu: the algorithm should state when they should have parms and queries
<Wip> https://
wip: if you're verification method is an identifier, and the controller doc is identifier minus the fragment. If it doesn't match an error will be made.
Wip: happens in that case?
Markus: we're not really dropping anything, we're following the algorithms requirements.
<Zakim> JoeAndrieu, you wanted to ask about how to profile v CIDs
Joe: +1 in general with Manu and Markus's comments. Need to profile against the CID. the integrity constraints on DID are different from controlled identifiers
manu: people can do crazy stuff with specs. Why would someone use a query parm to get to a CID? You can do that but why would you?
Manu: the algorithm will fail in the way Wip described it. It should fail there because we don't want that to work
Manu: pay attention to the algorithm you're using. Profiling would have to be in the DID spec. Not sure what we'd say there. Would like to resolve this to get to writing the PR
Manu: Could also say something like, do not put query parameters in fragment identifiers in DID identifiers - they aren't part of the DID identifer.
Manu: that sounds normative, but let's keep it simple.
<manu> +1 to what Will is saying.
wip: Agrees with Manu. Would expect the version ID query identifier is just for that point in time.
<Zakim> JoeAndrieu, you wanted to say most of us don't know why anyone would use CIDs in the first place
Joe: You can't put parameters in your DID. It doesn't meet DID requirements. CIDs were intended to take CIDs of the DID spec. Need to be careful about what those who want to use CIDs want to use them
Manu: Dangerous path to put parameters in the DID. Fragment identifiers need to be unique throughout all time. Use unique identifiers for your keys to avoid this.
Manu: if you put a version ID parameter in there, you're pushing a lot of complexity into the client. This complicates things enormously
DID Resolution PR Processing
<Wip> https://
w3c/did-resolution#122
wip: DID verification method brought across to the PR#122 Has this been checked at this point?
Markus: the PR is much better at this point. Not sure if you have to check if the identifier is the same as that in the dereferenced form.
wip: the verification method controller must equal the controller of the DID - is that always the case?
manu: if you allow authentication they can operate on your behalf but you can remove them from the write privs to your DID doc
Markus: checking the controller of the verification relationship should be checked if verification relationship option is present or not.
w3c/did-resolution#125
Wip: skipping PR#123 is ready to be reviewed.
Markus: This PR adds service type that lets you select services from the DID doc. Algorithm answers questions when service identifier is any URI. Fixes a bug in processing the relative reference parameter. Relatively big PR. Possibly more reviews would be useful, but it looks like it's in good shape now.
wip: would be good to get more reviews on this PR
w3c/did-resolution#135
Markus: fixes the term of the DID doc in the JSON-LD context. Preference to just use the JSON-LD structure.
Ivan: This goes beyond the PR itself. There are two discussions needed. 1) we shouldn't use JSON-LD for the sake of it. It makes sense when you have an environment when you are mixing vocabularies with other vocabs.
Ivan: This isn't the case with this resolution spec. May want here to say simply this is just JSON and use its terms
Ivan: if we want to use JSON-LD we are using linked data. Have to define a proper vocab in the RDF sense (in turtle, JSON-LD, etc.) this is not the same as th context file. IF we do this we need a voca document specification.
Ivan: there are two consequences. Need proper vocab specification. Ivan's happy to do this now that there's useful tool for doing so.
Ivan: do we want mutiple vocabularies. One with different uses with DID specific terms used by DIDcore and the resolution spec, etc.
Ivan: suggests just using a single one and not having multiple vocabularies.
Wip: helpful if Ivan can put this into an issue.