Meeting minutes
scribe
Otto: reviewing agenda
DID Methods Charter - Special Topic Call
ottomorac: want to have a joint special topics call with DIF and other orgs to take place on July 9th
<Zakim> manu, you wanted to note we should mention it on the mailing lists.
manu: should give broad notice this week in all the regular DID communities and orgs, so that everyone is aware
DID Core Issue Processing
<ottomorac> https://
need TTL construct? #896
<ottomorac> w3c/
ottomorac: previous meeting discussed adding a validity period
manu: best way is to add a TTL, but may be beyond current charter. We could add a 'heads-up' that a TTL is coming to the DID spec in the next major iteration. This pre-note could describe how it will work, etc. We could re-charter and enumerate the TTL as a coming features
<Zakim> manu, you wanted to note we have /3/ potential parallel recharterings :)
Ivan: not looking forward to having 2 items that could have different development lengths under the same charter. Can we try to minimize the administrative difficulties? Can we leave CID where it is and not move it into documents?
manu: we might even have unto 4 recharters. realizes this is difficult. However, there are several specs / projects going to market and we need to coordinate on standardization, so the multiple efforts / communities are in-line and don't conflict. Concerned that "standards divergence" would be a strong negative. CID belongs in this group.
Discussion around CBOR-LD and where it should go. This impacts VC barcode spec. It's going out to 10M's of people and will affect interoperability. Multiple DID methods vs one DID Method discussion, etc. Need to coordinate all of these topics before large scale deployments happen. It would be good to re-charter in order to handle all of these
items under the same umbrella
Ivan: maybe this is a discussion for later with all the key participants. Once we enumerate all the problem issues, lets's minimize the administrative impacts.
<manu> +1 to not doing more work than necessary to fix the worst of these issues.
ottomorac: add a 'block by recharter' label on this PR for now. Then we can address it in the future
Unaddressed denial of service vector #897
<ottomorac> w3c/
manu: agreed. if there is a possibility of a cycle then it should be handled using traditional infinite loop detection methods. Some potential loop cases are errors and the resolution step should throw and error. This (& an example) should be added to the DID Resolution spec text under security issues. Should terminate when cycle detected and
return an invalid result. "any DID resolution that detects a cycle must return a cycle error"
Is percent encoding the fragment (#) really conformant with the URI RFC? #898
<ottomorac> w3c/
manu: example 6 is correct and don't think it goes against RFC. Changing to a hash mark would be wrong. The fragment must % encode the fragment. This is an esoteric example and will look at some improved descriptive text.
manu: this would be a class 2 change
DID Resolution PR Processing
<ottomorac> Remove language about "graph merge" for equivalentId and canonicalId. #158
<ottomorac> w3c/
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/