22:03:01 <RRSAgent> RRSAgent has joined #did-topic
22:03:01 <RRSAgent> logging to https://www.w3.org/2021/05/11-did-topic-irc
22:03:05 <manu> present+
22:03:16 <manu> Meeting: DID Special Topic Call
22:03:30 <shigeya> present+
22:03:48 <brent> rrsagent, make logs public
22:03:55 <markus_sabadello> markus_sabadello has joined #did-topic
22:03:57 <brent> zakim, this is did
22:03:57 <Zakim> got it, brent
22:03:59 <markus_sabadello> present+
22:04:02 <brent> present+
22:04:13 <brent> chair: brent
22:04:40 <brent> brent has changed the topic to: DID WG Special Topic Call - Implementation Guide
22:05:41 <drummond> drummond has joined #did-topic
22:05:44 <drummond> present+
22:05:47 <drummond> scribe+
22:06:19 <manu> q+
22:06:26 <Geun-Hyung__> Geun-Hyung__ has joined #did-topic
22:06:36 <brent> ack manu
22:06:45 <Geun-Hyung__> present+
22:06:46 <drummond> Our topic today is the DID Implementation Guide
22:06:50 <manu> https://w3c.github.io/did-imp-guide/
22:07:06 <drummond> manu: the last time we checked in on the implementation guide, it was an "empty husk"
22:07:14 <manu> https://github.com/w3c/did-imp-guide/pull/3
22:07:21 <drummond> ...Orie has since make a PR request with his thoughts about implementation
22:07:21 <markus_sabadello> q+
22:07:33 <drummond> ...there are concerns about some of the language in the guide
22:07:50 <drummond> ...however it does add quite a bit of useful content
22:07:55 <brent> q+
22:08:00 <manu> https://github.com/w3c/did-imp-guide/pull/3
22:08:11 <drummond> ...so it would be helpful today to figure out how to incorporate the non-controversial content
22:08:20 <brent> ack markus_sabadello
22:08:20 <drummond> there are 113+ comments on that thread
22:08:27 <Orie> Orie has joined #did-topic
22:08:48 <drummond> markus_sabadello: there is a lot of content in the PR and the vast majority is non-controversial
22:08:54 <TallTed> present+
22:08:56 <Orie> I removed the controversial content and left the link to the issue.
22:08:59 <brent> ack brent
22:09:06 <Orie> present+
22:09:11 <drummond> ...so I want to propose to simply pull out the controversial sections and accept the rest of the PR
22:09:30 <brent> q?
22:09:31 <drummond> brent: If there is any way to merge this PR, it would be very helpful
22:09:38 <markus_sabadello> q+
22:09:39 <Orie> q+
22:09:43 <drummond> ...especially as it would give us two editors for the guide
22:09:46 <brent> ack markus_sabadello
22:10:02 <brent> ack Orie
22:10:14 <drummond> markus_sabadello: He believes Orie has also agreed to remove the controversial parts
22:10:28 <manu> q+
22:10:32 <brent> ack manu
22:10:32 <drummond> Orie: I thought the recommendation was to mark the controversial parts
22:10:53 <drummond> markus_sabadello: To clarify, would prefer to remove the controversial sections
22:11:18 <drummond> manu: wants to make sure that the Implementation Guide does not need the same level of consensus as the main spec
22:11:26 <brent> +1 to not needing consensus
22:11:57 <markus_sabadello> q+
22:11:58 <Orie> q+
22:12:03 <drummond> ...it is perfectly fine to putting something in the document that does NOT have consensus, and then point to another section of the document that represents and alternative view
22:12:17 <brent> ack markus_sabadello
22:12:18 <drummond> ...so his recommendation is to accept the PR and then add more content
22:12:34 <manu> q+ to note "same issue" @context
22:12:48 <drummond> markus_sabadello: This is the same issue that we have discuss many times about having "@context" in a plain JSON document
22:12:56 <Orie> its not the same issue, because an implementation guide is different than a spec or a registry.
22:13:10 <drummond> ...so I'm concerned about providing explicit guidance saying that
22:13:23 <brent> ack Orie
22:13:31 <drummond> ...so I would want to submit a PR that says the exact opposite
22:13:35 <agropper> agropper has joined #did-topic
22:13:42 <brent> ack manu
22:13:42 <Zakim> manu, you wanted to note "same issue" @context
22:13:43 <Orie> https://github.com/w3c/did-imp-guide/issues/5#issuecomment-839223719
22:13:49 <agropper> present+
22:13:55 <drummond> Orie: I have removed the paragraph with that proposed language, so urge a re-review
22:14:20 <drummond> manu: I don't think that's necessary, but in any case, let's go ahead and merge
22:14:56 <drummond> ...it is worth documenting the controversies in the Implementation Guide. It should carry both points of view.
22:15:00 <brent> q?
22:15:02 <brent> q+
22:15:15 <drummond> ...it is okay to document both positions in the Implementation Guide.
22:15:26 <markus_sabadello> q+
22:15:28 <brent> ack brent
22:15:38 <drummond> ...we should be documenting what are the most important philosophical disagreements
22:15:39 <Orie> imp guide has to be aware of tooling, security, etc... its not about "spec purity" its about "the dirty reality of concrete implementation advice and reality..."
22:15:48 <drummond> brent: Huge +1 from me
22:15:55 <manu> +1, let's merge it right now.
22:15:58 <brent> ack markus_sabadello
22:16:04 <drummond> ...let's have that conversation after we merge this PR -- even live on this call
22:16:08 <Orie> who can merge a PR?
22:16:15 <Orie> for did imp guide generally?
22:16:22 <drummond> markus_sabadello: Since Orie removed the offending content, I'm fine with merging this PR
22:17:02 <drummond> ...I am surprised to hear that an Implementation Guide should carry completely opposing points of view, but now that I understand that, I'm fine with it.
22:17:19 <drummond> brent: Markus, would you be okay with merging the PR?
22:17:26 <drummond> markus_sabadello: Yes, will review now
22:17:29 <manu> q+ to merge.
22:17:33 <drummond> brent: I will also do that.
22:17:49 <brent> ack manu
22:17:49 <Zakim> manu, you wanted to merge.
22:18:10 <Orie> I don't care about merge history.
22:18:23 <drummond> manu: I can squash and merge or just do a merge, but rather just ask Orie. You can also rebase. What do you prefer?
22:18:25 <Orie> squash and merge
22:18:32 <Orie> preserves commits in the message
22:18:58 <drummond> manu: I will squash and merge, Orie.
22:19:19 <drummond> Orie: I don't have permissions to merge.
22:19:34 <drummond> brent: Orie, will accept the position of editor of this document?
22:19:49 <drummond> Orie: I want to complete the conversation between Manu and Markus.
22:20:04 <drummond> brent: But if you are willing to be an editor, we can give you the permissions.
22:20:45 <drummond> ...and I expect you'd have another co-editor soon from a new WG member.
22:20:48 <Orie> q+ t
22:21:02 <brent> ack t
22:21:09 <drummond> ...next up is discussing the question about "@context"
22:21:42 <manu> q+
22:21:52 <drummond> Orie: This is a case where it feels like "@context" is the bad guy, but the real problem is how dereferencing happens across different representations.
22:21:53 <manu> q+ to note that @context is going to end up in did+json
22:22:15 <drummond> ...dereferencing is representation-specific
22:22:48 <drummond> ...for example, if you dereference a content stream differently, you can get strange behaviour
22:22:52 <markus_sabadello> q+
22:23:13 <drummond> ...so dereferencing must be handled consistently
22:23:34 <drummond> ...it depends on a document loader, and if that happens in different ways/times, you get different results
22:23:45 <brent> ack manu
22:23:45 <Zakim> manu, you wanted to note that @context is going to end up in did+json
22:23:55 <drummond> ...it works differently for JSON and JSON-LD, and it might work differently for other representations
22:24:02 <manu> https://www.w3.org/TR/vc-imp-guide/#benefits-of-jwts
22:24:08 <manu> https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs
22:24:25 <drummond> manu: The way we've dealt with that before was described in the Implementation Guide and decide for themselves.
22:24:46 <drummond> ...different readers can have different interpretations of these positions
22:25:24 <Orie> to be clear, you should never put @context in did+json... especially if you do not to intend to support did+ld+json.
22:25:31 <Orie> :)
22:25:32 <drummond> ...at a minimum I'm expecting this topic (putting "@context" in a plain JSON representation) to be covered in the Implementation Guide
22:25:58 <drummond> ...putting on my Digital Bazaar hat, we will definitely putting "@context" in plain JSON documents
22:26:12 <drummond> ...it is a reality of the ecosystem, and therefore documenting it makes a lot of sense
22:26:19 <brent> ack markus_sabadello
22:26:22 <Orie> the only reason we put it in both is that we intend to support both did+json and did+ld+json, at leasts for some of our did methods.
22:26:22 <drummond> ...and therefore we should document it
22:26:45 <drummond> markus_sabadello: Now that I know that it's okay to have opposing views in an Implementation Guide, let's do it.
22:27:15 <drummond> I will be happy to write up why I believe it's a bad idea to include "@context" in a plain JSON representation
22:27:37 <Orie> imagine if dereferencing did+json returned different json that did+ld+json...
22:27:59 <Orie> q+
22:28:02 <brent> ack Orie
22:28:20 <markus_sabadello> q+
22:28:28 <manu> q+ to note that people mess up MIME types all the time.
22:28:41 <drummond> Orie: if you are using a document loader as part of dereferencing, you are guaranteed to get a different result
22:29:18 <drummond> ...so those kinds of considerations are important for implementers. They are going to take a tool like JSON Parse and just use it.
22:29:36 <brent> ack markus_sabadello
22:29:36 <drummond> ...so if it breaks easily, that's a problem we should try to help with.
22:29:57 <drummond> markus_sabadello: I still don't understand what dereferencing has to do with it.
22:30:06 <Orie> documentLoader = JSON-LD dereferencer..
22:30:07 <drummond> ...document loaders are JSON-LD tooling
22:30:16 <manu> q+ to provide schema.org application/json JSON-LD Context as an example.
22:30:29 <Orie> but what happens when a documentLoader accidentally requests did+json?
22:30:39 <drummond> ...but the issue in my mind is the mistake of running JSON-LD toolset against a plain JSON document
22:30:42 <brent> ack manu
22:30:42 <Zakim> manu, you wanted to note that people mess up MIME types all the time. and to provide schema.org application/json JSON-LD Context as an example.
22:31:32 <Orie> again, i really think folks should not put @context in did+json UNLESS they intend to also support did+ld+json.
22:31:37 <drummond> manu: A real-word reason why Digital Bazaar always puts an "@context" in plain JSON documents. Schema.org served JSON-LD documents using plain JSON mime types
22:32:05 <Orie> When that happens....
22:32:11 <drummond> ...so JSON-LD documents get served with plain a JSON mime type
22:32:13 <markus_sabadello> q+
22:32:41 <Orie> SHOULD != MUST also.... I agree that its not a requirement.
22:32:42 <drummond> ...while it would be nice to say that "the system shouldn't do that", it just creates problems
22:33:06 <drummond> ...that's why many systems out there treat both of them the same way, and we're trying to recognize that
22:33:28 <drummond> ...this mechanism we're talking about right now is the reasons X-HTML failed
22:33:41 <drummond> ...it had to be perfect markup to work
22:34:03 <drummond> ...but rather than forcing compliance, it created a splinter group to created HTML 5
22:34:24 <Orie> i'm in favor of documenting both recommendations, especially interested to see the pro's con's for each.
22:34:25 <drummond> ...so that's an example of being practical about the mistakes that developers make
22:34:28 <brent> ack markus_sabadello
22:34:53 <drummond> markus_sabadello: In that case, shouldn't we drop the plain JSON representation and go back to the plain JSON-LD model?
22:35:04 <drummond> ...I would love to see that because it would make everything simpler
22:35:05 <drummond> q+
22:35:07 <TallTed> q+
22:35:18 <brent> ack drummond
22:35:23 <manu> scribe+
22:36:04 <manu> drummond: I've heard this broken record many times before -- I hear Manu's frustration, but I also know that the reason for plain JSON is that there are simply communities that want to use plain JSON that do not want to use JSON-LD and not include @context, and we've made that possible in the spec.
22:36:23 <markus_sabadello> q+
22:36:31 <manu> drummond: The discussion about the implementation guide -- there will be communities that use plain JSON, JSON Schema, they won't be affected by this, their tooling will be set up for that purpose.
22:36:41 <brent> ack TallTed
22:36:42 <Orie> +1 there is an error you can throw called "representationNotSupported"
22:36:59 <Orie> you should throw errors when you don't intend to support a representation.
22:37:56 <drummond> TallTed: I think the key here as Orie has put in the thread a number of times is that we are advising the people who are using JSON-LD but are using plain JSON mime types and don't want to use a JSON-LD mime type
22:38:23 <brent> ack markus_sabadello
22:38:25 <drummond> ...in that case, there's no harm in adding a JSON-LD "@context" statement as it won't break any plain JSON tooling
22:39:33 <drummond> markus_sabadello: The issue I am concerned about is that if you include @context in a plain JSON document, a JSON-LD processor will understand the semantics and do one thing and a plain JSON processor will do another thing
22:39:52 <drummond> ...I tried to describe that problem in the comment thread but there was no response
22:40:44 <drummond> ...so I feel we should keep a clear separation between plain JSON and JSON-LD.
22:40:44 <Orie> In a world where we really use the ADM, i would expect YAML and XML flavors to have similar recommendations as JSON flavors
22:41:12 <brent> q?
22:41:13 <drummond> ...I don't buy the argument that there is no harm in adding "@context" to a plain JSON document that is not intended to use it
22:41:29 <drummond> ...however I am fine with including both of these perspectives in the Implementation Guide.
22:41:34 <markus_sabadello> q+
22:41:38 <brent> ack markus_sabadello
22:41:40 <drummond> brent: I think we have a way forward now.
22:41:52 <Orie> q+
22:41:54 <manu> q+
22:42:00 <brent> ack Orie
22:42:12 <drummond> markus_sabadello: Question: If there is ever going to be an XML or YAML representation, will Digital Bazaar add "@context" to those?
22:43:04 <drummond> Orie: YAML does have a number of advantages, and Transmute would indeed be adding @context to YAML so that it can be processed as JSON-LD when needed.
22:43:26 <drummond> ...we want to have those semantics even if those other representations do not support it
22:43:41 <brent> ack manu
22:44:17 <markus_sabadello> q+
22:44:24 <drummond> manu: Speaking from Digital Bazaar perspective, yes, we would put an "@context" in the YAML documents
22:44:32 <drummond> ...we want to keep the same data structure consistently
22:44:48 <drummond> ...CBOR-LD was a running joke until it became a real thing
22:45:00 <drummond> ...YAML-LD is also poised to become a real thing
22:45:14 <drummond> ...XML-LD has been talked about for years but don't know if it will happen
22:45:34 <drummond> ...the whole goal is to get an "@context" expressed in whatever syntax is available to you
22:45:40 <brent> ack markus_sabadello
22:45:41 <drummond> ...that's the argument for including it
22:46:16 <drummond> markus_sabadello: I think that's fine, but in that case it should be included as a core property
22:46:29 <drummond> q+
22:46:42 <brent> ack drummond
22:47:08 <manu> drummond: As much as I agree on how that would be nice -- that would be a different type of hari kari and types of arguments... I don't think that's an option, as much as it might look attractive, I don't want to go through that firefight again.
22:47:39 <drummond> brent: We can continue discussing this or move on to next steps for the Implementation Guide
22:47:40 <Orie> q+
22:47:48 <brent> ack Orie
22:47:54 <drummond> ...so we will go to next steps for the Implementation Guide
22:48:46 <drummond> Orie: I want to comment on how to handle another open issues with DID Core. I recommend adding sections for each major difference of opinion.
22:49:01 <drummond> ...another issue area is key representations
22:49:29 <manu> q+ to propose a concrete path forward.
22:49:37 <drummond> ...I went to try to update our libraries to use mulitcodec and I could not do it in the same DID document
22:49:51 <manu> q?
22:50:07 <brent> ack manu
22:50:07 <Zakim> manu, you wanted to propose a concrete path forward.
22:50:07 <drummond> ...we will have the issue that there is no multibase representation for certain types of keys
22:50:24 <drummond> manu: to try to head off the "spicy working group drama"...
22:50:37 <Orie> here is one for secp256k1 i did this weekend
22:50:37 <Orie> https://github.com/multiformats/multicodec/pull/210
22:50:59 <drummond> ...we already have a multibase public key representation and we could add a private key representation
22:51:17 <drummond> ...the only controversial area is: where do we put private key multibase?
22:51:18 <Orie> q+ to note the DID WG decided not to punt this
22:51:48 <drummond> ...but it should not go into the public context file so that people don't accidentally express a private key when they are putting together a DID document
22:51:59 <drummond> ...I think JWK made a huge mistake doing that
22:52:21 <drummond> ...I know Orie has that opinion and others may share that, so I advocate trying not to turn them into footguns
22:52:29 <brent> ack Orie
22:52:29 <Zakim> Orie, you wanted to note the DID WG decided not to punt this
22:52:59 <drummond> Orie: DID Core does not define public key multibase and other key types and verification methods.
22:53:33 <drummond> ...that's why this is a call for contributors to the Implementation Guide to make recommendations about what they should be using
22:53:51 <manu> q+ to note that the LD Security WG will probably pick that item up.
22:54:06 <drummond> ...because the DID WG decided not to define key representations, then the CCG is where that work is going on
22:54:17 <drummond> ...so that's an area of the Implementation Guide that needs some help
22:54:33 <drummond> ...we need to explain the relationship of the CCG work to the W3C DID Working Group and the DID spec
22:54:34 <brent> ack manu
22:54:34 <Zakim> manu, you wanted to note that the LD Security WG will probably pick that item up.
22:55:01 <drummond> manu: To add to that, the LD Signatures WG (planned) will become the place to discuss these items in the next few months
22:55:16 <Orie> but the LD Sec WG only defines LD representations?
22:55:22 <drummond> ...so we expect we'll have an official LD Signature WG which will be the place to do the work
22:55:32 <Orie> ohh wait... did+json uses those same terms
22:55:39 <Orie>  /s :)
22:55:41 <drummond> ...but in the meantime I absolutely agree with Orie that this should be written up in the Implementation Guide
22:56:00 <drummond> brent: I agree. Is there an issue that is tracking that work? If not, could we open one?
22:56:06 <drummond> manu: I will open one right now.
22:56:19 <Orie> lets do testsuite
22:56:41 <drummond> brent: Are there other issues on the Implementation Guide to be raised now? Or should we wait for another call?
22:57:02 <drummond> ...not hearing any, we'll end today's call.
22:57:10 <drummond> ...grateful to all for the work you do.
22:57:38 <brent> zakim, who is here?
22:57:38 <Zakim> Present: manu, shigeya, markus_sabadello, brent, drummond, Geun-Hyung__, TallTed, Orie, agropper
22:57:40 <Zakim> On IRC I see agropper, Orie, Geun-Hyung__, drummond, markus_sabadello, RRSAgent, Zakim, brent, TallTed, cel, rhiaro, manu, wayne, shigeya, ChristopherA, dlongley
22:57:58 <brent> zakim, end the meeting
22:57:58 <Zakim> As of this point the attendees have been manu, shigeya, markus_sabadello, brent, drummond, Geun-Hyung__, TallTed, Orie, agropper
22:58:01 <Zakim> RRSAgent, please draft minutes
22:58:01 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/11-did-topic-minutes.html Zakim
22:58:04 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
22:58:10 <Zakim> Zakim has left #did-topic
22:58:18 <brent> rrsagent, make logs public
22:58:25 <brent> rrsagent, bye
22:58:25 <RRSAgent> I see no action items