Meeting minutes
Agenda Review, Introductions (5 min)
Today we are going to review a few issues...
then review PRs but we want to focus on DID path discussion...
Also Manu will be out today...
DID Issues \[1\] (10 min)
<Wip> close item
<Wip> https://
Wip: would like to discuss these issues... but first would like to highlight that I have reviewed the TAG isssues...
DID Resolution Issues \[2\] (15 min)
Wip: I noticed a few points that were missed and that needed to be handled via issues...
w3c/did-resolution#226
Wip: This is another one from Jeffrey regarding incosistent resolution...
Wip: I think we have talked about this before but it seems the confusion is around version id and version time....
<swcurran> Amen
Wip: There are some DID parameters like version ID and version time that are part of the resolution process...
Wip: Please see the comment I added there about this
Wip: I think we also discussed this at TPAC right Joe?
JoeAndrieu: Yes, I think this more of a communication problem I think...
JoeAndrieu: I think I need some time to analyze this
JoeAndrieu: The issue is that some parameters are resolution specific and some are did method specific...
<swcurran> 100% Joe
Wip: ok thanks
Wip: I guess the piece that is confusing, having a DID URL dereferencer (there is currently a term in the spec for this) but we don't use it consistently... sometimes we instead to a DID resolver as doing de-referencing
<dmitriz> +1 agree, re getting rid of 'dereferencer' term
Swcurran: I 100% agree, but talking to Markus he doesn't think that should be the path....
Swcurran: I was confused by this, in my change I refer mainly to DID URL de-referencing...
JoeAndrieu: I think we should not get rid of the URL de-referencing terminology....
JoeAndrieu: Maybe we should clarify how this works, there is consensus here that the DID Resolver does not do de-referencing itself....
Wip: Yes I don't think we should get rid of DID URL de-referencing generally, but just the specific term of "DID URL de-referencer"
<dmitriz> (agreed, dereferencing is fine, it's the -er part that we should drop)
Swcurran: Yes I think that the purpose of the spec is that what is returned could be did doc or a modified did doc, or a list of URLs, or even an error....
Swcurran: but we need to clarify the ways in which this is returned....
JoeAndrieu: Yes it is kind of fuzzy...
JoeAndrieu: I think the cannon is that URLs should always return a resource...
TallTed: I think that having an analogous process might help....
Tallted: When you are programming there is a memory location, you resolving the reference to the location, and then you get the resource in memory....
w3c/did-resolution#274
Wip: Jeffrey is saying there is a statement in the spec that mentions proofs but is not clear....
Wip: I wonder if they best way to handle this is just to remove this statement from the spec in section 7
JoeAndrieu: Yes I think this statement is incorrect...
JoeAndrieu: We don't have a standard way to put a proof in DID doc... so yes remove it...
JoeAndrieu: the security model you have is to trust the resolver...
JoeAndrieu: some of this will come out in the Threat Modelling section...
Wip: Yes I think the best way is to just remove this statement....
w3c/did-resolution#277
Wip: Raised by Joe about removing proxy resolvers, seems like we have some discussion on it...
… maybe you can tell us your perspective on it?
JoeAndrieu: I think this mostly downstream of the Threat Modelling, when you have a proxy you then have these threats.....
JoeAndrieu: I think the challenge is getting discussion framework so that speak on the same terms... the threat model should help us on that
w3c/did-resolution#283
Wip: this is another one from Jeffrey, he is asking if the did documents extension should use W3C or IANA registry mechanism?
JoeAndrieu: Unfortunately we did just pass a resolution that we need a formal registry, but we havent addressed this work yet... we should have started on this some time ago
Wip: I think we can communicate that back to Jeffrey, that we do intend to address it but we just haven't able to get to it...
w3c/did-resolution#284
Wip: this is related to the language of DID parameters.... Jeffrey points to a few changes we should do....
Wip: Also there is a sentence that I find confusing that I pointed out there in the issue...
Wip: Do people agree we should do these changes?
JoeAndrieu: I think there is a strange conflation here...
JoeAndrieu: related to the oppacity of URLs, it changes if you know how to construct a URL
JoeAndrieu: we dont have a good way to manage this complexity
TallTed: Yes I think you are going in the right direction...
TallTed: When you are server-side you know what all parameters mean...
TallTed: however when you provide this to someone outside the organization they may not know the meaning of these params...
TallTed: versionID and versionTime may not mean the same....
TallTed: This is why they should be treated as oppaque
<Wip> act JoeAndrieu
TallTed: The entity that is serving the DID and DID doc they can do whatever they like, but the person that is resolving and de-referencing....
<Zakim> JoeAndrieu, you wanted to say this is the same Q as resolution/dereferencing
TallTed: that is just the nature of the problem
JoeAndrieu: I think there are parts that cannot be resolved, but we can still have better language
JoeAndrieu: please assign this issue to me
Avoid Duplicate Terms \[3\] (5 min)
w3c/did-resolution#285
Wip: this is about avoiding duplicate terms...
ottomorac: This addresses issue #232. Some changes were first required in DID core.
… This PR removes all duplicate terms from DID resolution
… The only terms I have not removed are resource and representation
… I saw two comments, one from Will related to DID service endpoints
… Another suggestion from Ted, which I adopted to use captials for DID
Wip: I think its fine, it would be better to perhaps have a more generic way of referencing to just "service endpoint", instead "DID Service Endpoint"
DID Path PR \[4\] (15 min)
w3c/did-resolution#260
Swcurran: I summarized it on my comment there...
Swcurran: now after some conversations I have decided to move it merge it with the previous section #8
Swcurran: Now this hopefully matches the way the algorithm says
Swcurran: I think this should be in good shape, just wondering what happens to the JSON LD context with the introduction of "base path"?
Swcurran: Would appreciate if folks can read through the change
Swcurran: I need some help to clarify that part about JSON LD, I am not very familiar with that
Wip: yeah perhaps we need to check with Manu or Ivan on this...
Wip: Yeah would appreciate reviews, also did you check with Markus?
Swcurran: Yes I did talk to him, he doesn't like that some of this can be done with serviceType and relativeRef already
Swcurran: He doesn't like that we have 2 ways of doing that
<dmitriz> +1 stephen
Swcurran: I think however this might be a better way
Swcurran: I think most implementers will choose this DID path way of doing it...
w3c/did-resolution#150
Wip: This issue raised by Joe, I wonder what is your perspective about this in relation to the DID Path changes from Stephen?
JoeAndrieu: I think some of the changes from Stephen are addressing this...
JoeAndrieu: we are moving towards a canonical way of solving it....
JoeAndrieu: did-core and did-resolution would offer this canonical way now....
Wip: yes agree since the specs would mandate this...
Swcurran: I think did methods don't have to change, but did resolvers should probably change....
<Zakim> JoeAndrieu, you wanted to clarify that pretty much all DID methods have implemented some form of resolution
<swcurran> +1 to Joe
JoeAndrieu: Every did method that is implemented in software, then they have implemented resolution....
Wip: I think 90% of did methods out there will need to update their resolve interface...
<dmitriz> I mean, if nobody else implements resolution, it's the _spec_ that's gonna need to change :)
Next time (5 min)
Wip: Yes please note that next tuesday that we will be in the security interest group, talking to Simone about did resolution...
<Zakim> JoeAndrieu, you wanted to mention diagram and initial threats
Wip: we want Simone to be familiar so that they can do an initial analysis without having a full threat model done...
<Wip> This is the meeting calendar item - https://
JoeAndrieu: I hope to be there
JoeAndrieu: I will try to show some ideas around a diagram for this....
JoeAndrieu: but we would also like to start the threat model discussion
Wip: it would be great if we can also discuss this in the call next Thursday hopefully
Wip: please if you are available join that meeting
Wip: thanks all!
<Wip> m2gbot, link issues with transcript