W3C home > Mailing lists > Public > public-credentials@w3.org > February 2020

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

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Thu, 20 Feb 2020 14:43:08 -0800 (PST)
Message-ID: <5e4f0b7c.1c69fb81.a246f.400e@mx.google.com>
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
Received on Thursday, 20 February 2020 22:43:23 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 20 February 2020 22:43:25 UTC