Meeting minutes
Announcement: Cancelling APAC calls for now
ottomorac: Will and I have been discussion what to do around APAC with participants from APAC
… For the next few months we are going to cancel the APAC calls
… We are exploring the possibility of organizing some APAC friendly events in the run up to TPAC
… We will be switching back to the usual time for those weeks
JoeAndrieu: Its a hard problem. Appreciate we tried the alternate time. Not sure there are any real good solutions. Appreciate the effort
Wip: Agree its a hard problem. We have been talking with Denken and Shigeya, we are looking at some ways to re-engage through CCG (in an APAC friendly time). Also looking to use TPAC as an opportunity for that.
ottomorac: We have reached out to Kim about the DIF APAC group. Kim mentioned they tend to be more use case focus. Might not get much interest.
… Once we have a clear plan of events we may be about to use DIF to distribute this further
<Wip> +1
<ottomorac> w3c/
DID Resolution Test Suite Special Topic Call
<ottomorac> w3c/
Wip: I have extracted the normative statements, approximately 80. Probably need a special topic call to deep dive into how to test the statements.
Wip: So that those interested can engage, we can review the statements and refine them as well as determining how to test them.
Wip: Candidate date is July 9th.
Possible denial of service issue
<ottomorac> w3c/
ottomorac: this issue is about a possible denial of service raised by Victor Dodds
… It regards to the potential for infinite resolution in his interpretation of how the controller property is used
Wip: suggest that folks read, it touches on the fact the controller property is used in various places in the spec and perhaps is not well understood.
JoeAndrieu: We did have language that embodied the algorithm described to use verification methods from DIDs
… This lead to an arbitrary and confusing security hole in the spec
… Hence removing it
… Right now the controller property does have some confusing bits about self referentiability and whether that makes sense
… The meaning of that is under specified.
… We also have a issue with the controller property in the verificationMethod
… A verificationMethod has a key specified and it also has a controller specified. What does it mean if these are not the same entities
KevinDean: I don't agree that we should be combining the verificaiton methods in anyway. This implies that the verification of the controller is intrisically part of the DID itself
… It is really more of a recursion
… It is not a append these arrays of verification methods from all controllers. Then verify
… First verify the controller, then verify the verificationMethods of the DID
ivan: I am a little worried about a layering. We are inheriting this document from the CID spec under the VCWG currently.
ottomorac: Wills comment is also agrees with this. If we have to update this it will be in the CID spec that the changes need to be made.
ivan: May need to raise an issue against the CID spec.
Wip: Yes I just wanted to raise attention to this issue...
Wip: I hear Joes point about some confusion with the controller and verification method... there is some language around it requiring dereferencing....
markus_sabadello: I agree with what Will said. Some DID methods use it, some dont
… This is also true for verificaiton methods in the DID document
… We have never required that verification methods in a DID document must be used to authorize updates
… in my mind the controller field has been mostly intended for applications that use DIDs and other technologies like VCs
… I don't really have an answer about the denial of service issue
JoeAndrieu: the main reason some DID methods can't use it, is because it can't represent that party as a URL. You can't always put in all the information you need in a URL
… Challenge your algorithm about verificationMethod lookup. Interested to see if in the spec. The verificationMethod has a key in there, if you have to dereference a controller property and check that the verificationMethod is still in there then this adds challenges. THe DID document might have rotated by then
… This might be a data integrity question to answer
TTL construct required?
<ottomorac> w3c/
ottomorac: Okay moving on
ottomorac: This an issue migrated from DID Resolution to DID Core. It is related to caching of DID Resolution results and how this could be managed in the form of some Time To Live (TTL) contruct akin to what DNS does. There was agreement in January that this is something that should be set by the DID Controller, and not something defined by the
DID method.
… There was agreement that this is something that should be set by the DID controller not something defined by each DID method
1+
Wip: Yes we moved from DID resolution to DID core, do we agree that this is still relevant to be addressed?
<Zakim> JoeAndrieu, you wanted to suggest a property somewhere
JoeAndrieu: we might be able to address this if we convince ourselves that it is a security fix
… It should be the controller who sets this. They are the best party to state the TTL of their DID
… This suggests to me we want a property somewhere. Probably a top level property in the DID document
… Happy to talk with Simone in the security interest group to see if he would view it as a security concern
markus_sabadello: I think we should have this. Agree this should be set by the DID controller
… Wonder if this would be a property in the DID document. Or a DID Document metadata property in DID resolution result
… This feels like it could fit in to this set of metadata properties
… This is also related to a parameter we have, no-cache
… This is also in DID resolution
… I am in favour of having this feature, just not sure DID core is the right place
Wip: Yes moved this issue from DID resolution but still unsure if it belongs here....
JoeAndrieu: echo what Will says. In did:btc1 method we don't have a meta layer to store something like ttl.
… Not sure how we would get it in the metadata in some of the methods
markus_sabadello: I agree with that too. We have a good understanding of how to update DID documents across DID methods. We don't have a good understanding of how to update DID Document metadata
… From a theoretical standpoint metadata would be the right place. TTL describes the DID document not the subject
… Just because we have never had a way for these metadata properties to be set, doesnt mean it isnt the right way for it to be done
… However can see that putting it in the DID document is a more practical approach
DID Core PR Processing
<ottomorac> https://
Add warning about comparing DID URLs containing query parameters. #895
<ottomorac> w3c/
ottomorac: This attempts to clarify that the DID core spec defines no normalization rules for query parameters and warning when comparing DID URLs.
… Just calling this out for review from folks
DID Resolution Issue Processing
<ottomorac> https://
Should the HTTPS binding be mandatory? #93
<ottomorac> w3c/
ottomorac: Discussion was held in January as to whether this is something that Resolvers or DID methods need to define and whether an https endpoint is mandatory.
… Also wondering if this belongs in did core
markus_sabadello: This should not be in DID core. It is DID resolution where we have the binding defined for resolution
… We just need to decide if it should be mandatory
<Zakim> JoeAndrieu, you wanted to say because DID methods need compatible resolvers.
JoeAndrieu: markus has a good point. What is important in DID core is that DID methods to be conformant must have at least one implementation of a resolver with a https binding
… THis is not a requirement on all resolvers
… This is a requirement on DID methods for compatibility
… It is the DID method that needs to provide this as a software component
Wip: If we agree that this is a requirement for the did method, which sounds reasonable to ask for an https binding, ideally this requirement might need to go into did-core... perhaps challenging because did-core is just in maintenance mode...
Is it graph merge or graph equivalence? #115
<ottomorac> w3c/
ottomorac: This related to the equivalentID term: https://
merge".
<Zakim> JoeAndrieu, you wanted to say this is a place where the properties in the DID document are not about the subject, but about the DID
JoeAndrieu: this depends on whether you read the JSON as JSONLD or not you have different interpretation
… I don't think anyone meant that "same as" means you should do a graph merge
… This is a statement that is much more about the subject. It is like having two different VCs about the subject. Whether you choose to trust those and merge them in your data set depends
… We should not do a merge in a way that is proposed here
markus_sabadello: I think at least a part of this issue is obsolete
… DID resolution results should be JSON and not JSONLD
… One of the discussion points was whether equivilantId should be the same as "same as". It is no longer an rdf property
… I don't know if we need to say anything about this
… We are saying something about equivalentId and what it means
… Each equivalentId value is logically equivalent to the id property and refers to the same subject
ottomorac: Wondering about the history of this green box clarification
<Zakim> JoeAndrieu, you wanted to mention security
JoeAndrieu: I think it was meant to be a report by the resolver for another way you can get to the same thing
… If we think about equivalentId as giving this intention that you are supposed to merge the graph in the DID document.
… This is back to the pattern where you are supposed to merge the controllers. All verification methods in both documents should be considered as proofs of either DIDs. We need to clarify that that is not what is meant here
… We need to be clear that from a security standpoint you do not want to merge the two sets of verificationRelationships
markus_sabadello: I remember why we have this. There were DID methods with multiple forms of a DID. The idea was always that you get back the same DID document for these two identifiers acccept that the identifer is in a different form
… From that perspective also a graph merge doesnt really make sense
… It is the same graph. Maybe it is more of a graph equivalence
… Again not sure if there is spec text that should be added
ivan: The important point from Markus is that equivalence means I get back exactly the same DID document
… There is no issue about graph merge
… There is this example about using lowercase and uppercase in the DID URL
… All the rest is confusing things
… From the DID resolver point of view, these two identifiers lead to the same DID document.
ottomorac: So we just simplify things.
ivan: The RDF point is moot, as we are not using RDF in DID resolution
ottomorac: Sounds like we have a proposal to simplify the language to make this point of the equivalence
ottomorac: Need someone to write a PR, but at least we have direction
Language clarification "A DID document is a representation of information describing a DID subject." #113
<ottomorac> w3c/
Wip: Yes this sentence was not striking of what a did-document is. To me a did identifies a did-document... and then we have the verification relationships in the did-document
<Zakim> JoeAndrieu, you wanted to say this has been a long standing disagreement
JoeAndrieu: I have always disagreed with Manu and Dave on this point
… When a DID document was treated as JSONLD you can't make a statment about the identifier
… THe identifier transmutes the statement to be about the subject
… Now that we are not in JSONLD we do not have this constraint.
… This illusion that this DID document is somehow about the subject
… I think it is really important that we should make it clear that you should not be putting statements about the subject in the DID document
… I would like to clarify this in the spec
ottomorac: I saw a proposal to try pull in working from the CID spec
JoeAndrieu: Wasn't clear what language we should add
m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/