Markus Sabadello: Discussion about did resolution and thought on bringing to did core spec ✪
... what are the inputs and outputs and expect from dereference, etc. continuing discussion from last time
Dmitri Zagidulin: I'd love to discuss stuff about paths from WG. ✪
... on origins of that discussion
Markus Sabadello: When did we discuss this last? ✪
Markus Sabadello: Might have been on the CCG call. what would you like to discuss? ✪
Topic: JSON Pointers in fragments
Tobias: concern about JSON pointers. spec stated should not exclude. what was the context? ✪
... if you use json pointer, need a preceeding '/'
Markus Sabadello: We have two different thread. paths and json pointers ✪
Dmitri Zagidulin: Strike that, let's come back to paths. ✪
Markus Sabadello: Let's talk about tobias point first ✪
Tobias: really just a point from F2F, we wanted a natural data model with lossless conversion between solution, and should not exclude json pointers ✪
... my concern is that if i have an element in the DID doc that has a fully qualified URI, if i use json pointers, need the full '/' before and not by the position if it is in an array. JSON-LD has a well-defined way to expand contract graphs.
... not sure how to have lossless conversion, any examples.
Markus Sabadello: I don't think it is about lossless conversion, but even if you can covert, you are really asking about the nature of the fragment after you deref the url. ✪
... and the nature of the frag is determined by the MIME type.
... if you have a DID URL in JSON-LD then it is well-defined. and not conducive to JSON-pointers.
... not sure if the conversion will work. if you use JSON application/json MIME type, there is something missing to imply semantics.
Tobias: that is also my concern, standardized way across syntax and is quite different. ✪
Justin Richer: Are links in the document, links across the DID. reading the DID spec, not sure how that are intepreted. ✪
Justin Richer: Defrencing the fragment is defined by the resource type as determined by the URI, like html, different in JSON, vs JSON-LD ✪
... IPLD can do something else.
Tobias: does that couple the identifier with the document? ✪
Justin Richer: Yes, and we could (DID WG) could define as universal way to use fragments across all difference document representation as there is not defined MIME type. ✪
Tobias: eventhough they represent same doc but in deferent syntax, you could losslessly convert. ✪
... i can see this turning into a mess
... just as a REST API expecting json
Jonathan Holt: Not getting deterministic results ✪
Markus Sabadello: Agree with tobias, concern about @id interpretation, depends on representation and how those options are passed to the resolver ✪
... even though in URI the MIME type, may require meta data. this may rule out JSON pointer as it may not make sense in other syntax. the abstract data model, with different syntax, have to define different @id and if they can be linked.
... they could be defined in each representations.
Jonathan Holt: IPLD uses multiformat etc, so that it's self-describing ✪
Markus Sabadello: So maybe some DID Methods will have strong opinions on the link format, but other methods, that don't have strong preferences, may negotiate with the DID Resolver for this ✪
Topic: DID Resolution contract
… I'd like to share some slides
… and I'd like some feedback
… Justin Richer has been talking about the contract (from the meeting notes of the DID face-to-face meeting)
… so, my understanding was - we want to define that when we have a DID (or DID URL), what are the operations that can be executed on that?
… what are the inputs/outputs of resolution?
… the current approach is -
… there are two abstract function, resolve() and dereference() (two corresponding chapters in the DID Resolution spec)
… and they talk about what the inputs to those functions are, and the results.
… the first slides summarize those in table form
… a DID is something that can be resolved - you can ask a Resolver to resolve a did.
… you pass in a DID url, and you get a DID and metadata
… similarly, you pass in a DID URL to dereference(), and you get back content and metadata
… So my question is - is this essentially what is meant by 'the contract'?
… that potentially will be included in the DID Core spec?
Jricher: yes, this is exactly the kind of thing I was talking about ✪
… and this goes to show some of the very important differences between resolve() and dereference()
… because the inputs are different, and the expected outputs are different
… then there's also the read() operation (that each DID Method spec needs to define)
… which seems to be the same contract (same i/o) that the resolve() function
Markus Sabadello: So that may mean that they're not different, that they're the same operation? ✪
Dmitri Zagidulin: The main deference is the read is basic and resolve is superset. the second output param is the diff [scribe assist by Jonathan Holt] ✪
Dmitri Zagidulin: The main difference between read() and resolve() is the type of metadata ✪
… read() returns method-specific meta, and resolve() returns method-specific metadata PLUS resolver-specific metadata
Tplooker: so if that's the only difference, maybe that points to that they're essentially the same? ✪
Markus Sabadello: (Discussion of DID Resolution spec section 3.2) ✪
Dmitri Zagidulin: Isn't the difference between read() and resolve() - the format of the did document? read() can return an intermediary format, and the Resolver transforms it into the DID Doc ✪
Markus Sabadello: I'm not sure I agree. I think the DID Core spec (or, each specific DID Method spec) requires that read() returns the canonical DID Doc ✪
… (discusses the third slide, which is another summary table of dereference() inputs and outputs)
Jonathan Holt: In my implementation, the path component is (in IPLD) what goes to the executable ✪
… (that does the resolution spec inherently)
… and then the fragment contains local (non-resolver) parameters (like the decryption key)
… for example, the path goes to IPLD, which is a self-describing executable
… although I'm not sure everyone will want to execute random data on a path
Markus Sabadello: I've always figured the path is defined by the did method (or controller) ✪
Dmitri Zagidulin: I think the semantics of the path fragment is specified only by the DID Method. although an individual method can specify it further, and say - in our method, the path semantics differ from controller to controller (depends on the authority component) ✪
Markus Sabadello: Justin, what were the other contracts in the meeting? ✪
Jricher: I vaguely recall a 3 part system, which defines the contracts between the two touch points in the system ✪
… so, the contract into and out of a resolver is 1 contract, and then potentially, the contract between the resolver and downstream (to the method) is the 2nd contract
… the important thing is that the contract (when I call a de-referencer or a resolver) needs to specify the inputs and outputs
.. This /has/ to be common across different resolvers ✪
Markus Sabadello: I understand now about these contracts, need to think about how to rewrite this for spec [scribe assist by Jonathan Holt] ✪
Jonathan Holt: .... But there is enough about these interfaces, what is convered in did core vs resolution. ✪