Re: [MINUTES] W3C Credentials CG Call - 2020-02-20 12pm ET

Quick note to clarify.. Despite what this automatic e-mail says, the
minutes below are actually from this week's DID Resolution Spec Weekly
Meeting
<https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/>,
not from the main CCG telecon
<https://www.w3.org/community/credentials/weekly-meeting-information/>.

Markus

On 2/20/20 11:43 PM, W3C CCG Chairs wrote:
> Thanks to Jonathan Holt and Dmitri Zagidulin for scribing this week! The minutes
> for this week's Credentials CG telecon are now available:
>
> https://w3c-ccg.github.io/meetings/2020-02-20/
>
> Full text of the discussion follows for W3C archival purposes.
> Audio from the meeting is available as well (link provided below).
>
> ----------------------------------------------------------------
> Credentials CG Telecon Minutes for 2020-02-20
>
> Agenda:
>   https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/
> Topics:
>   1. JSON Pointers in fragments
>   2. DID Resolution contract
> Organizer:
>   Christopher Allen and Joe Andrieu and Kim Hamilton Duffy
> Scribe:
>   Jonathan Holt and Dmitri Zagidulin
> Present:
>   Sumita Jonak, Jonathan Holt, Markus Sabadello, Dmitri Zagidulin, 
>   Justin Richer
> Audio:
>   https://w3c-ccg.github.io/meetings/2020-02-20/audio.ogg
>
> Jonathan Holt is scribing.
> 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.
> Tobias:  exactly my point.
> Dmitri Zagidulin:   My comment as well. the format of the links 
>   are determined by the representation, i.e. JSON, CBOR etc
> Tobias: sharing screen with examples. JSON samples.
>   ... first one is JSON-LD.
>   ... are we going to use @id in the JSON example?
> .. Example in JSON pointer using #
>   ... as compared to JSON-LD referenced.
> Jonathan Holt:   We use json pointers in IPLD
> Dmitri Zagidulin:   Since other things other than JSON-LD not 
>   sure how to do it.
> Justin Richer:   May be substantive contribution that needs 
>   discussing in WG of CCG?
> Tobias:  overlaying the namespace,
> 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.
> Dmitri Zagidulin:   This is interesting
> Tobias: i can raise an issue
> Dmitri Zagidulin is scribing.
> Markus Sabadello:  So maybe each DID Document needs to encode the 
>   link format?
> Jricher: that would mess with parsers, though - you need to know 
>   the format before parsing the document
> S/markus_sabadello: So/jonathan_holt: So/
> 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.
> Jonathan Holt: .... This was helpful
> Jonathan Holt: Ipld:  "<base64 of 'blob <size>\0<data>'>"
> Jonathan Holt:  Example of ipld link for self-resolving software 
>   in git multicodec need to parse atributed. [scribe assist by 
>   Jonathan Holt]
> Jonathan Holt: Zakim, end meeting
>
>