14:50:10 <RRSAgent> RRSAgent has joined #did
14:50:10 <RRSAgent> logging to https://www.w3.org/2020/08/04-did-irc
14:50:17 <Zakim> Zakim has joined #did
14:50:25 <burn> rrsagent, draft minutes
14:50:25 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/04-did-minutes.html burn
14:51:00 <burn> Agenda: Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Jul/0024.html
14:52:39 <burn> present+
14:55:25 <JamesQU_> JamesQU_ has joined #did
14:58:22 <agropper> agropper has joined #did
15:00:17 <markus_sabadello> markus_sabadello has joined #did
15:00:43 <markus_sabadello> present+
15:01:30 <rhiaro> present+
15:02:15 <dmitriz> dmitriz has joined #did
15:02:21 <Orie> Orie has joined #did
15:02:27 <manu> present+
15:02:28 <agropper> present+
15:02:31 <Orie> present+
15:02:35 <dmitriz> present+
15:02:43 <wayne> present+
15:03:07 <jonathan_holt> jonathan_holt has joined #did
15:03:21 <manu> scribe+ wayne
15:03:26 <jonathan_holt> present+ jonathan_holt
15:03:29 <manu> scribe+ identitywoman
15:03:33 <dlongley> present+
15:03:43 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:03:47 <selfissued> selfissued has joined #did
15:03:52 <selfissued> present+
15:04:04 <wayne> burn: agenda is short, intro, re-intro, so on...briefly mention and give info about next topic call, then disussion
15:04:16 <wayne> burn: taking a break from issue review, discuss CBOR for majority of meeting
15:04:17 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:04:22 <wayne> burn: any other agenda items?
15:04:34 <wayne> burn: okay, good. is there anyone joining for the first time?
15:04:52 <wayne> burn: james, would you like to introduce yourself again, and possibly your question for the group?
15:05:01 <justin_r> justin_r has joined #did
15:05:23 <wayne> JamesQU_: worked for UBS and morgan stanley for more than 20 years, familiar with traditional banking. now i'm working for a blockchain company introducing DIDs into the blockchain ecosystem, asking my team to implement DIDs
15:05:52 <wayne> JamesQU_: my question is: things i try to contribute a bit, having worked for FIX protocol (financial info xchange), i find it difficult to catch up quickly
15:06:08 <wayne> JamesQU_: i'd like to get some advice from experts on what's the best way to get up to speed quickly and contribute? thanks
15:06:29 <identitywoman> identitywoman has joined #did
15:06:38 <oliver> oliver has joined #did
15:06:38 <wayne> burn: for the next 2 minutes, if you'd like to volunteer materials + pointers, please do
15:06:39 <identitywoman> present+
15:06:43 <oliver> present+ oliver_terbu
15:06:54 <identitywoman> I can scribe now
15:06:57 <manu> There is the DID Primer -- a bit out of date, but good background reading: https://w3c-ccg.github.io/did-primer/
15:06:59 <wayne> scribe+ identitywoman
15:07:09 <burn> Topic: Next Topic Call
15:07:14 <manu> ... and honestly, the intro portions of the spec are probably the best thing we have
15:07:18 <chriswinc> chriswinc has joined #did
15:07:32 <burn> https://github.com/w3c/did-core/labels/keys
15:07:56 <justin_r> https://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identity_is_Broken.pdf
15:07:58 <identitywoman> @burn topic call in 7 hours on keys
15:08:02 <chriswinc> present+
15:08:02 <wayne> another resource, intro by burn and brent: https://hackmd.io/ME8SfZymRfK1XtM69oBOcA?both
15:08:10 <wayne> (draft)
15:08:11 <burn> Topic: CBOR
15:08:21 <burn> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3ACBOR
15:08:24 <manu> q+ to do some intro
15:08:25 <identitywoman> @burn: main topic is on CBOR
15:08:36 <identitywoman> ... it is an open discussoin
15:08:47 <burn> ack manu
15:08:47 <Zakim> manu, you wanted to do some intro
15:09:06 <identitywoman> @manu: the goal for the call today is to try and figure out the direction we are taking
15:09:36 <identitywoman> ...data model can have several representations - JSON, JSON-LD, CBOR
15:10:08 <identitywoman> ... we have the most implementations in JSON-LD waiting on JSON - this call is to explore CBOR
15:10:21 <identitywoman> ...we are hoping to explore directions to go
15:10:39 <dmitriz> @JamesQU_ - I'd also recommend my slide deck on DIDs + existing domains (did:web method), which gives a historical overview of DIDs - https://docs.google.com/presentation/d/1wWI2qeQfgOgFdDp5Adt9hwHxVTt-ctG9naBEpNjOSTo/edit
15:10:42 <identitywoman> ...we are working on figuring out what should go in the specification
15:10:51 <burn> q?
15:11:08 <identitywoman> ...ideally what can we write so that it articulates it well so we can get through the candidate recommendation process
15:11:10 <wayne> q+
15:11:15 <burn> ack wayne
15:12:04 <manu> q+ to ask jonathan to do an intro on DAG-CBOR, Orie to do an intro on CBOR-Quads, and I can do an intro on CBOR-LD.
15:12:11 <burn> ack manu
15:12:11 <Zakim> manu, you wanted to ask jonathan to do an intro on DAG-CBOR, Orie to do an intro on CBOR-Quads, and I can do an intro on CBOR-LD.
15:12:15 <identitywoman> @wayne would like to understand more to help level set for discussion
15:13:00 <identitywoman> @manu: Would like Johnathan to give  a quick outline on CBOR DAG, Orie to talk about his implementation and i can talk about CBOR-LD
15:13:28 <Orie> q+ to cover cbor / dag cbor / nquad cbor
15:13:31 <identitywoman> @johnathan_holt: CBOR has batteries included - JSON strings to keys to Nats
15:13:39 <manu> Wikipedia has a decent intro to CBOR: https://en.wikipedia.org/wiki/CBOR
15:13:47 <identitywoman> ...jSON has this thing as un-ordered lists.
15:13:51 <manu> q+ to cover CBOR-LD
15:14:22 <identitywoman> ... Batteries included semantics with tags - fast good at machine parsing. Settled on CBOR and DAG-CBOR is natively supported in IPLD
15:14:24 <burn> q?
15:15:25 <identitywoman> ...the did document is represented as DAG and the base format is CBOR and DAG-CBOR for determanistic serialization - that will always happen the same way if you approach it with the same constraints. Remove all tags except 42 which is an IANA representation.
15:15:40 <dbuc> dbuc has joined #did
15:15:59 <dbuc> present+
15:16:09 <identitywoman> ...IPLD is stand alone and it just exists and you can resolve it. It is self describing and links are embeded in the hashes in a way that is a noncycilc aproach.
15:17:10 <identitywoman> ...it has to do with the sub section ___ did Document Naps must be strings integer types ... all floating points must be 64 bits. There is obviously conflict in the document - Naps must be strings - this flies in the face of conciseness.
15:17:36 <burn> s/Naps/Maps/g
15:17:40 <identitywoman> ...why not just put an interger instead of long names for key types. This is why it is compact.
15:17:42 <manu> This is the section of the spec that Jonathan is talking to: https://w3c.github.io/did-core/#cbor
15:17:48 <burn> q?
15:17:50 <identitywoman> ...I didn't represent that that is why I left the strings in there.
15:18:33 <identitywoman> ... I did spend the weekend reading the proposed CBOR-LD representation and I have lots of questions.
15:19:10 <identitywoman> ...nested objects and complex data types and the integrer transformations in a way that is dynamic - not going to any central repository or calling home for the at context.
15:19:19 <burn> ack Orie
15:19:19 <Zakim> Orie, you wanted to cover cbor / dag cbor / nquad cbor
15:20:09 <identitywoman> @orie: cool, i have been experimenting with various CBOR representaotins of the abstract model of a DID document. How can you get a structure that is bi-directionally transformative between CBOR and JSON.
15:21:43 <identitywoman> ...you transfer between CBOR and JSON I don't get it you don't have any size reductions. The other approach is DAG-CBOR it is the same size form Vanilla CBOR from JSON it is so much more valuable then vainlla CBOR - defined and implemented by the Protocol Labs folks and it is emerging - I have tremendous amount of respect for it there is an IANA registry for CBOR -
15:22:10 <identitywoman> ...so if you are planning to get the vanilla version of CBOR to be smaller then you have to register a million things to IANA.
15:22:17 <identitywoman> ...but the size reduction is not significiant.
15:22:47 <identitywoman> ...prior to CBOR being a thing I wrote a ___
15:23:15 <burn> q?
15:23:32 <identitywoman> ... this compressed nclods stuff that you put in - it is about 1/2 the side of CBOR and DAG-CBOR and JSON but you have to transform it to work on it but it has real size recution.
15:23:46 <burn> s/nclods/nquads/
15:24:06 <identitywoman> ...what else are you doing with CBOR-LD by directional transformation
15:24:37 <identitywoman> ...when considering the CBOR stuff 1) Bidirectional to compresesed representaiton
15:24:49 <identitywoman> ...2) ability to operate sematically on compressed
15:25:11 <identitywoman> ...3) ability to perform cryptograpic operations on compressed represntations
15:25:32 <identitywoman> ...someone else is going to talk about CBOR LD
15:25:36 <justin_r> present+
15:25:46 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:25:50 <identitywoman> they don't breath
15:25:52 <Eugeniu_Jolocom> present+
15:25:59 <burn> ack manu
15:26:00 <Zakim> manu, you wanted to cover CBOR-LD
15:26:39 <identitywoman> @Manu: hopefully folks are getting an idea that we have a number of different ways to do cBOR each one has different properties - I think Ories summary of the three things to look out for are great.
15:26:48 <identitywoman> ...some of them are important from a use-case prespective.
15:27:41 <identitywoman> ...cbor-LD is another representation that we are looking at that could give us a way to do express JSON-LD in a semantic binary formats to try and get these formats as small as possible .you care about the file size and you are trying to get it to be small.
15:28:18 <identitywoman> ...one of the big things you have a string "verifiable credential" you can convert that to a single number - what was single 16 bites you can get down to 1 bite - so huge reduction.
15:28:19 <justin_r> A small correction: this isn't just a compression thing, it's a speed/complexity of processing thing. Reading a string vs. a switch on a byte.
15:28:48 <identitywoman> ...this is why people are excited about CBOR - usually when we talk about it many of the CBOR formats that exist at IETF - the are kind of hand created - artisnal CBOR.
15:29:14 <pam> pam has joined #did
15:29:21 <burn> q?
15:29:44 <identitywoman> ...so the upside there - you maximize compression. up side it is a lot of compression downside you need to go through a long process - lots of entery into CBOR registry at IANA - the higher the number the less value to srink.
15:30:12 <jonathan_holt> q+
15:30:14 <identitywoman> ...trying to take data formats that have been worked with for years a general semantic compression algorithm to get them as small.
15:30:15 <manu> https://docs.google.com/presentation/d/199svsHQXt2j1GqcvEXHgpENZIk1AZ53tEcUWuEYSsp4/edit#slide=id.g866980c4a6_0_14
15:30:48 <identitywoman> ...this slide shows you the type of compression that you can show.
15:31:23 <identitywoman> ... the top bar the JSON-LD bar is big 1.2 KB  Did documents way in at about that.
15:31:25 <Eugeniu_Jolocom_> Eugeniu_Jolocom_ has joined #did
15:31:45 <identitywoman> ...if you look at the thing in red you can look at the thing how much it is compressed
15:32:10 <wayne> q+
15:32:13 <identitywoman> ...CBOR-LD is optimized to work on the type of documents that we are working on - tries to cmoplress as much as possibly can.
15:32:31 <identitywoman> ...you CAN operate on the compressed data.
15:33:17 <identitywoman> ...you can run code against it - because you don't have to decompress it. You can store 5x the number of DID docs and VCs in your system if you use this. It does have some interesting overlaps with DAG-CBOR
15:33:42 <identitywoman> ... we are considering some multi-values ____
15:34:18 <burn> ack jonathan_holt
15:34:33 <jonathan_holt> https://github.com/cabo/cbor-diag
15:34:39 <identitywoman> @johnathan_holt: compression wan't my motivation
15:34:47 <agropper> q+
15:35:14 <identitywoman> ...I really wanted determanistic mapping
15:35:16 <manu> q+ to note that I think that all of these formats can do deterministic mapping
15:35:29 <JoeAndrieu> JoeAndrieu has joined #did
15:35:34 <JoeAndrieu> present+
15:35:47 <identitywoman> ...I was imaginging the compaction and concisenss was a reach goal.
15:35:53 <burn> ack wayne
15:36:04 <manu> q+ to note that I think we all want a CBOR representation... the question is, to interop, do we have one, two, three?
15:36:05 <identitywoman> ...to get to a conocal represntation across encoding types.
15:36:40 <Orie> the canonical vanilla cbor representation is entirely controlled by IANA.... you can't get more centralized than handing control over your data model to them.
15:36:46 <dmitriz> q+
15:36:50 <identitywoman> @wayne: to me CBOR something inbetween stringy JSON thing - there are some other formats (missed them)
15:36:50 <manu> q- later
15:36:57 <manu> q+ to where is the line wrt. compaction
15:37:00 <burn> ack agropper
15:37:04 <identitywoman> ...did method specifying how to compact that like that.
15:37:13 <manu> q+ to and DID spec specifying.
15:37:32 <manu> q+ to respond to Adrian - CBOR not human readable
15:37:48 <burn> ack dmitriz
15:37:51 <identitywoman> @adrian: just wondering if that the encoding is not readable - how that would interact user-agents and situations and the verifier needs to trust to the control. There are benifits for Machine processing - are tehre issues in making it readable?
15:37:51 <wayne> wayne: spectrum of full JSON -> CBOR -> protocol formats like avro/protobuf, where do we draw the line?
15:39:15 <justin_r> q+
15:39:22 <manu> q- later
15:39:30 <justin_r> q+ to talk about the purpose of the section
15:39:32 <burn> ack justin_r
15:39:32 <Zakim> justin_r, you wanted to talk about the purpose of the section
15:39:33 <identitywoman> @dmitriz: I wanted to address the question that wayne had about protocol buffers. All compression methods that are relevent as dictionary compression. Does the method pass the dictionary with the object or does it not? __- they compress the with the object  protocol buffer by forcing you to do the dictionary out of band. What is remarkable about CBOR-LD that doesn't include the full compression dictionary but links to it instead. simil[CUT]
15:39:47 <identitywoman> ...buffer without the need to agree on dictionary
15:40:42 <identitywoman> @justin: I proposed that we we write this out in amsteradm. the purpose is a determanistic mapping - into and out of the abstract data model that IS a did document. What about protocol buffers we can define those the running joke we could have a linked data version of a PDF
15:41:13 <jonathan_holt> q+
15:41:18 <identitywoman> ... a protocol buffer encoding would have to specify as part of its definitions what that dictionary is and how to specify it - into and out of that specific format.
15:41:40 <burn> ack manu
15:41:40 <Zakim> manu, you wanted to note that I think that all of these formats can do deterministic mapping and to note that I think we all want a CBOR representation... the question is, to
15:41:44 <Zakim> ... interop, do we have one, two, three? and to where is the line wrt. compaction and to and DID spec specifying. and to respond to Adrian - CBOR not human readable
15:42:41 <identitywoman> @manu: +1 to what justin just said the part of the spec is how to go to and from CBOR in a determanistic way. There is a clear desire to have some CBOR representation - questoin is which one.
15:43:28 <identitywoman> ...the fundamental thing is deterministic mapping to and from. We may not need to discuss that - all of us want CBOR and we all wnat a determanistic mapping. Do we have 1,2, 3 representations that are interoperable.
15:43:36 <Orie> we don't need to discuss determinstic mappings... we have many ways to do this... it about what _other_ features do we get along with determinstic mapping, and who controls how the mapping is handled.
15:44:09 <identitywoman> ... to adrian's point about human redability - but honestly if we are exposing a DID document to a human we are failing. this is a layer above software will translate to human readable.
15:44:14 <Orie> CBOR is a trojan horse for centralization if not implemented correctly.
15:44:16 <dlongley> +1 to Orie, what's the *purpose* of using a particular concrete representation -- there should be some features/benefits for it.
15:44:37 <selfissued> q+
15:45:13 <burn> ack jonathan_holt
15:45:18 <identitywoman> ...the thing I would like to shift to discussing is whether or not we can go into articulating the format - my concern is that this work is very new and we don't have a lot of experience. It is going to be a lot of work for us to feel comfortable about it. Ways that we can get to agreement quickly - ways to keep it open to give this time to mature.
15:45:25 <Orie> For the record, my tests on CBOR / DAG_CBOR / ZLIB_NQUADS_CBOR are here.... https://github.com/transmute-industries/decentralized-cbor.... entirely experimental, for education purposes only.
15:45:53 <identitywoman> @johnathan_holt to respond to Adiran re human readability - will be addressed by
15:46:20 <identitywoman> ...mapped keys to get to short
15:47:20 <manu> q+ to raise a concern over what's in the spec right now wrt CBOR approach -- it may cut off our ability to do other CBOR formats, like CBOR-LD.
15:47:39 <identitywoman> ...vanilla CBOR and DAG CBOR and has an IANA tag name - facilitates the core representations that move between - it is as simple as that having a core representation in CBOR as Lossless. I did listen in on the CBOR-LD calls with IETF
15:47:59 <burn> ack selfissued
15:48:01 <identitywoman> ... it is straight forward to hang our hat on - I think what I have put in acomplishes that goal.
15:48:01 <agropper> q+
15:48:01 <Orie> .... we have 4 deterministic methods already :) and they are not interoperable.
15:48:51 <identitywoman> @mike: at an emotional level let CBOR be CBOR - you don't need external representations in the CBOR.
15:48:51 <justin_r> CBOR-LD could be a thing, but it should be separate from CBOR representation
15:49:04 <Orie> ^ same for DAG_CBOR
15:49:19 <Orie> and ZLIB_NQUADS_CBOR
15:49:24 <burn> ack manu
15:49:24 <Zakim> manu, you wanted to raise a concern over what's in the spec right now wrt CBOR approach -- it may cut off our ability to do other CBOR formats, like CBOR-LD.
15:49:41 <identitywoman> ... you define particular numbers in particular things. I would oppose trying to add linked data so CBOR if someone later wants to do CBOR-LD later as an extension then knock yourself out.
15:50:09 <Orie> lets just let IANA control every aspect of what a did document is... what could be more decentralized than having IANA control everything?
15:51:09 <burn> zakim, close the queue
15:51:09 <Zakim> ok, burn, the speaker queue is closed
15:51:14 <burn> q?
15:51:17 <identitywoman> @manu: stuff you wrote int he spec is fairly ready.  The way that is expressed let CBOR be CBOR it prevents DAG-CBOR and prevents CBOR-LD as a valid representation. we have three maybe 4 representation. We are being forced to choose DAG-CBOR based on the spec text.
15:51:21 <jonathan_holt> q+ to please see section 3.9 of the CBOR [RFC7049]
15:51:33 <Orie> we could have 4 representations in CBOR... its just doing to be an embarrassment from a standards perspective... as was argued for key representationss.
15:52:08 <identitywoman> ...I would like to put into the Spec text that we should put text that says we are working on it. We still have other things we need to do as a group. Put in some text that says we all want CBOR. Say that we are working on it.
15:52:09 <Orie> q+ to lets not shut the door
15:52:11 <burn> ack agropper
15:53:09 <burn> zakim, open the queue
15:53:09 <Zakim> ok, burn, the speaker queue is open
15:53:23 <manu> q+ jonathan_holt
15:53:25 <manu> q+ Orie
15:53:37 <identitywoman> @adrian: What I am hearing is that this is an extremely useful feature - it introduces privacy and security implications but they are on the negative side. WE need to be careful in the spec text - to provide some guidance. This overlaps with this discussion.
15:53:43 <burn> ack jonathan_holt
15:53:55 <identitywoman> @burn: trying to wrap up
15:54:44 <manu> q+ to note for those that want to learn more about CBOR-LD -- W3C CCG is having a call on it next... and then technical deep dive.
15:55:03 <identitywoman> @johnathan_holt: the math strings must be -  CBOR is so new and so many security concerns. It may be as simple as the integer representation lives in the registry without having to go to JSON-LD
15:55:09 <burn> ack Orie
15:55:15 <identitywoman> ...want it to semantically interoperble and secure
15:56:14 <burn> ack manu
15:56:14 <Zakim> manu, you wanted to note for those that want to learn more about CBOR-LD -- W3C CCG is having a call on it next... and then technical deep dive.
15:56:24 <identitywoman> @orie: CBOR introduces security and privacy - relies on registries which is an attack vector. Generally speaking there are privacy and security considerations associated with the registries -  note that it is ongoing work. Not close the door to representations.
15:57:03 <burn> q?
15:57:10 <identitywoman> @manu - we sure have a lot of questions about CBOR-LD net up at CCG we have a highlevel and deep dive. would be happy to go into those questions there.
15:57:15 <Orie> CCG call is happening in 3 minutes?
15:57:24 <identitywoman> @burn: we may be moving in a certain direction with what goes into the spec.
15:57:48 <identitywoman> ...thank you to those that present in different options.
15:58:03 <identitywoman> @burn: any final comments before ending call.
15:58:17 <pam> present+
15:58:25 <manu> rrsagent, draft minutes
15:58:25 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/04-did-minutes.html manu
15:58:27 <identitywoman> ...thank you everyone - thanks Kaliya its not easy to scribe this conversation
15:58:29 <manu> rrsagent, make logs public
15:58:30 <manu> rrsagent, draft minutes
15:58:30 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/04-did-minutes.html manu
16:25:10 <chriswinc> chriswinc has joined #did
18:20:20 <Zakim> Zakim has left #did