add representation property #348

talltree · 2020-07-15T07:15:59Z

Signed-off-by: Drummond Reed [email protected]

Signed-off-by: Drummond Reed <[email protected]>

talltree · 2020-07-15T07:44:18Z

While I would normally propose two new properties into two separate PRs, @brentzundel wisely suggested that both of these fit neatly as subsections of DID Subject under Core Properties. So I submitted them as one PR.

A suggestion to commenters: put sameAs or representation at the start of your comment so as to make it clear which property you are commenting on.

The representation property addresses issue #199 . Note that the PR references a proposed Appendix A that I will submit (hopefully tomorrow)as a separate PR.

The sameAs property addresses the need to able to assert semantic equivalence of two or more DIDs (i.e., that they all identify the same DID subject). This has been an issue since we put it in the Future Work section 3+ years ago. More recently it has been raised by @OR13 and @peacekeeper.

iherman · 2020-07-15T10:38:56Z

Reading the text with my Semantic Web hat on, the immediate question is "is this sameAs THE sameAs?". Ie, does the DID JSON-LD context map this term to owl:sameAs (just like type is mapped on rdf:type)?

I presume the answer is (or should be) 'no': it is a term defined for the sole usage in DID Documents for DID subjects. (E.g., I presume it is not acceptable to use sameAs to connect, say, key identifiers.) But, I believe, it is worth making this very explicit in the document to avoid people like me asking stupid questions...

(One could bikeshed on whether the term sameAs is, under the circumstances, a judicious choice for the aforementioned reasons. But it is difficult to find a better one.)

OR13 · 2020-07-15T15:11:55Z

index.html

+        <dt>sameAs</dt>
+        <dd>
+The value of <code>sameAs</code> MUST be a <a
+data-cite="INFRA#lists">list</a> where each item in the list is a <a>DID</a>


we might want to relax this to be a URI...

did:example:123 owl:sameAs https://example.com/person/456

@OR13 Per the other discussions on this topic, I changed the property name to sameSubject. For reasons I will explain in a new Appendix I am composing, I favor keeping the value of sameSubject restricted to DIDs.

OR13 · 2020-07-15T15:14:40Z

index.html

+        <dl>
+        <dt>type</dt>
+        <dd>
+        The <code>type</code> property MUST be a <a>URI</a> that asserts the


is this a URI? I would expect application/json, application/ld+json... prefer to see examples here.

@OR13 Yes, that's a relative URI. I updated the PR to include your suggestion that the value SHOULD come from the IANA media type registry.

I think @OR13 is stating that using type is the wrong property to use here?

OR13

This is excellent, I think we need to discuss:

should sameAs work with any IRI (I suggest yes).
should type be a value from this list: https://www.iana.org/assignments/media-types/media-types.xhtml

msporny

There is a very long discussion happening over here that should be taken into account in this PR -- w3c-ccg/security-vocab#45

I think there is general consensus to support limited "alsoKnownAs" use cases. I will argue very strongly against "owl:sameAs" use cases as I'm almost positive that they violate large swaths of the DID security model... we're playing with fire here. Just calling that out.

OR13 · 2020-07-15T20:06:30Z

I obviously disagree, see the comment manu linked :)

From the charter:

Recommend a data model and syntax(es) for the expression of Decentralized Identifier Documents, including one or more core vocabularies.

Not everyone thinks about linked data the same way... and there is absolutely nothing wrong with using OWL with DIDs... every triple in an RDF representation of a DID Document has the same security issues.... there is nothing different about sameAs... except that its from a vocabulary set thats already widely used...

all the statements about a subject in a did document are the same kind of thing... statements... made by a controller.

did:example:123 capabilityInvocation did:example:123#456
did:example:123 ccg:alsoKnownAs https://twitter.com/@Lord_Voldemort7
did:example:123 owl:sameAs https://twitter.com/@Lord_Voldemort7

Each of these is only as "trustworthy" as the DID Method + the DID Controller's opsec... anyone can claim anything in their decentralized identity document... thats the whole point of being free...

We are not "Solving Identity" on the Web... we can't make statements like "did:example:123 is/is not provably lord voldemort"... and we can't stop did:example:123 from claiming to be a dog, or a software package.... we can recommend for or against it...

I'm in favor of running towards this problem by using OWL, and addressing this issue directly, not creating a new kind of equivalence... which is again only as trustworthy as the controller and did method.

If my use case is I want to use OWL with DIDs... does my using owl:sameAs prevent you from using ccg:alsoKnownAs ?

AFAIK, this might be the first DID Document JSON-LD vocabulary term that is not primarily defined and maintained by the W3C CCG.

Its also fundamental to the public DID use cases that @csuwildcat and others are so excited about: https://rubenverborgh.github.io/WebFundamentals/semantic-web/#timbl-linked-data

See also:

I'm not opposed to supporting more than 1 kind of equivalence relationship... but specifically blocking support for existing semantic reasoning / software out of the gate feels like a bad move... OWL exists already... DIDs are new... let's build a bridge not an island.

talltree · 2020-07-15T20:32:15Z

First, I was not aware of the CCG Security Vocab thread on @OR13 's sameAs PR when I posted this PR. Thanks to @msporny for pointing it out.

As I posted there, I think I understand the concerns @msporny articulates on that thread. And I also appreciate @OR13 's desires to be able to pursue full owl:sameAs semantics.

So let me just clarify that the purpose of this PR (despite the proposed sameAs name for the property) was just to establish a standard way for a DID controllers to assert that one DID identifies the same DID subject as a different DID. Full stop. No additional semantics or DID document equivalence or RDF graph merging were implied.

So I'm wide open to giving this property a different name, and leaving sameAs for a separate PR for a separate property that would convey the full OWL semantic graph meaning (if @OR13 wants to pursue that).

Since I don't personally like the human semantics of the term "alsoKnownAs" (it feels too colloquial to me), I'd like to propose the property name sameSubject.

Thoughts?

talltree · 2020-07-15T20:46:52Z

This is excellent, I think we need to discuss:

should sameAs work with any IRI (I suggest yes).

@OR13 First I just want to clarify that my answer to your question assumes (per the comment I just posted) that we will split into two different properties—one called sameAs for the full OWL semantic graph equivalence that you are seeking and one called something else (I have proposed sameSubject) to assert only that two DIDs identify the same DID subject.

This PR only covers the latter (I will update it to the new property name as soon as we settle on it).

Now, in that context, my answer is "No" to allowing IRIs (or other URIs that are not DIDs) because I think it is very important to restrict the sameSubject property to identification by DIDs. Ironically, the reasons do in fact go deep into semantic web questions. But a full explanation demands more time that I can give this right now—I plan to address this with a proposed Appendix that I'm currently drafting. I'll update the comment thread as soon as I post it.

talltree · 2020-07-15T20:48:50Z

This is excellent, I think we need to discuss:

should sameAs work with any IRI (I suggest yes).

should type be a value from this list: https://www.iana.org/assignments/media-types/media-types.xhtml

@OR13 on #2, I agree that the value SHOULD be from that list. I'm wary of making it a MUST as a DID controller may have a reason to assert a type that has not yet been registered. What do you think?

talltree · 2020-07-15T20:53:18Z

I think there is general consensus to support limited "alsoKnownAs" use cases.

@msporny Would you be okay with sameSubject as the property name (vs. alsoKnownAs)?

OR13 · 2020-07-15T20:53:48Z

This is excellent, I think we need to discuss:

should sameAs work with any IRI (I suggest yes).

@OR13 First I just want to clarify that my answer to your question assumes (per the comment I just posted) that we will split into two different properties—one called sameAs for the full OWL semantic graph equivalence that you are seeking and one called something else (I have proposed sameSubject) to assert only that two DIDs identify the same DID subject.

This PR only covers the latter (I will update it to the new property name as soon as we settle on it).

Now, in that context, my answer is "No" to allowing IRIs (or other URIs that are not DIDs) because I think it is very important to restrict the sameSubject property to identification by DIDs. Ironically, the reasons do in fact go deep into semantic web questions. But a full explanation demands more time that I can give this right now—I plan to address this with a proposed Appendix that I'm currently drafting. I'll update the comment thread as soon as I post it.

interested to hear more about this, I would assume that such a restriction is not actually legal for JSON-LD / OWL / RDF...

https://www.w3.org/TR/json-ld11/#iris
https://www.w3.org/TR/owl-ref/#sameAs-def
https://w3c.github.io/did-core/#json-ld

When I add these up... I feel like making a restriction to DIDs only for owl:sameAs... is a bad idea... but I could see such an argument for sameSubject ( which I am fine with, and also prefer over alsoKnownAs )

talltree · 2020-07-16T04:58:55Z

@OR13 to be clear, I'm not proposing to restrict sameAs to just DIDs. Only sameSubject.

I agree with you that if a sameAs property will have the same semantics as owl:sameAs, then the domain needs to be all IRIs as it is in RDF/OWL.

Signed-off-by: Drummond Reed <[email protected]>

talltree · 2020-07-21T06:38:44Z

I just revised the PR to change the name of the sameAs property to the sameSubject property. I also added a note to explain that the semantics of the sameSubject assertion are limited to asserting that two or more DIDs identify the same DID subject. They do NOT assert owl:sameAs semantics, i.e., the ability to merge the RDF graphs represented by the respective DID docs.

That's not to say that owl:sameAs semantics do not have value or should not be pursued by those who might need them, but that's out of scope for this PR.

msporny

Let's split this PR up into two PRs... one for sameSubject and another for representation... I expect they will progress on different timelines, with sameSubject being less controversial than representation.

msporny · 2020-07-21T13:13:21Z

index.html

+        <p class="note">
+        WARNING: A <code>sameSubject</code> assertion that two or more <a>DIDs</a>
+        identify the same <a>DID subject</a> does not prove this assertion is
+        true. A malicious <a>DID controller</a> may attempt to impersonate a


Suggested change

true. A malicious <a>DID controller</a> may attempt to impersonate a

true. A malicious <a>DID controller</a> might attempt to impersonate a

msporny · 2020-07-21T13:13:53Z

index.html

+        identify the same <a>DID subject</a> does not prove this assertion is
+        true. A malicious <a>DID controller</a> may attempt to impersonate a
+        <a>DID subject</a> by making a false <code>sameSubject</code> assertion.
+        Therefore it is STRONGLY RECOMMENDED that a requesting party obtain


Suggested change

Therefore it is STRONGLY RECOMMENDED that a requesting party obtain

Therefore it is strongly advised that a requesting party obtain

msporny · 2020-07-21T13:14:45Z

index.html

+        independent verification of a <code>sameSubject</code> assertion. One
+        method for doing this is to resolve the <code>sameSubject</code> <a>DID</a>
+        to its own <a>DID document</a> and then verify that it contains the
+        inverse <code>sameSubject</code> assertion (i.e., a backpointer). See


Suggested change

inverse <code>sameSubject</code> assertion (i.e., a backpointer). See

inverse <code>sameSubject</code> assertion, also known as a back pointer. See

msporny · 2020-07-21T13:17:20Z

index.html

+        <code>owl:sameAs</code> assertion. In other words, it does not assert
+        that two or more RDF graphs represented as <a>DID documents</a> can be
+        merged. It only asserts that two or more <a>DIDs</a> identify the same
+        <a>DID subject</a>.


Suggested change

<a>DID subject</a>.

<a>DID subject</a>. Implementers are strongly advised against the use of <code>owl:sameAs</code> when processing <a>DID documents</a> as its use could expand the attack surface in a way that was not considered by the Working Group.

msporny · 2020-07-21T13:21:54Z

index.html

+        </section>
+
+      <section>
+        <h2>representation</h2>


This property is begging to be abused from a GDPR perspective. :)

There are better and more specific properties in schema.org... image, url, etc. We shouldn't advise implementers to express this sort of information in the DID Document... it should be done externally.

Please split the representation PR into a separate PR... as the sameSubject PR is far less controversial. I'm concerned that this PR is going to be held up because of the representation PR... they should progress on different timelines.

msporny · 2020-07-21T13:22:13Z

index.html

+        </dl>
+
+        <dl>
+        <dt>uri</dt>


This should be id

msporny · 2020-07-21T13:23:18Z

index.html

+        </dl>
+
+        <dl>
+        <dt>type</dt>


type is being re-used in a way that is not compliant with the DID spec... this really should be mediaType and the value isn't a URI.

I agree with that, but also want to mention that this PR seems to serve a similar purpose as various web linking and discovery technologies such as JRD and the HTML <link> element. Both of those use type to declare a media type, not an RDF class.

if we have an opportunity to pick a better name, we should... id and type are used all over the place... +1 for not continuing to overload them.... Content-Type isn't type... https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

Waiting on this to be resolved to do a re-review of this PR.

msporny · 2020-07-21T13:24:52Z

index.html

+      </dl>
+
+        <p>
+        If both the <code>uri</code> property and the <code>value</code>


Hrm, no, we should be using data URIs if we want to embed values directly... and we should put that value in id (see above). Also see https://en.wikipedia.org/wiki/Data_URI_scheme for explanation on data URIs.

brentzundel · 2020-07-21T14:36:36Z

index.html

+        <a>DID subject</a> by making a false <code>sameAs</code> assertion.
+        Therefore it is STRONGLY RECOMMENDED that a requesting party obtain
+        independent verification of a <code>sameAs</code> assertion. One method
+        of doing this is to resolve the <code>sameAs</code> <a>DID</a> to its


Suggested change

of doing this is to resolve the <code>sameAs</code> <a>DID</a> to its

of doing this would be to resolve each <code>sameAs</code> <a>DID</a> to its

index.html

brentzundel · 2020-07-21T14:42:01Z

index.html

+        The <code>value</code> property contains a <a>representation</a> of
+        the <a>DID subject</a>. This value MUST first be encoded in the MIME
+        type indicated by the <code>type</code> subproperty. If necessary, the
+        value MUST then be re-encoded according to the requirements of the


an example of this would be very helpful

talltree · 2020-07-21T16:08:01Z

Let's split this PR up into two PRs... one for sameSubject and another for representation... I expect they will progress on different timelines, with sameSubject being less controversial than representation.

@msporny Agreed. I probably should have done that at the outset. I will try to do that by EOD tomorrow (Wed 22 July).

I'll wait to do the new PR before responding to some of your comments on representation (all of which I believe there are good answers to).

Signed-off-by: Drummond Reed <[email protected]>

talltree · 2020-07-22T17:35:06Z

Revised PR to remove the sameSubject property, which is now addressed by PR #355.

Co-authored-by: Brent <[email protected]>

kdenhartog

Please ignore my original approval. I thought I was reading the sameSubject property addition and saw it was moved to PR #355

For the representation property can, I'm not really sure I'm following the purpose of this. The only thing I'm coming up with is when the DID Subject is a online resource, but in that case I'm not understanding the advantages of using a DID rather than something like a URN. Could you provide me any additional use cases for this so I can understand it and reason about it better?

talltree · 2020-07-23T08:23:12Z

For the representation property can, I'm not really sure I'm following the purpose of this. The only thing I'm coming up with is when the DID Subject is a online resource, but in that case I'm not understanding the advantages of using a DID rather than something like a URN. Could you provide me any additional use cases for this so I can understand it and reason about it better?

@kdenhartog You nailed it—the whole reason for this PR is that a DID can, in certain cases, be much better than a URN. Just take every use case for a URN, and add these advantages of a DID:

No centralized registry required. Almost all URNs require centralized or federated registry services (the exception is URNs like UUIDs that are not resolvable at all).
Cryptographically verifiability. The DID controller of the immutable object that serves as a DID subject—for example a schema—is able to publish a series of versions of that schema that each can be cryptographically verified as published by that same DID controller. While not all persistent digital objects need that (there is a whole class of immutable objects the Decentralized Semantics folks call "ungoverned objects" that are just "fire and forget" and are never versioned). But if you need verifiable provenance of an immutable object, a DID is perfect.
Standardized resolution. First of all, not all URNs are resolvable (e.g., UUIDs). But if they are resolvable, DIDs have a significant advantage because every URN scheme needs to define not just its URN identifier format and resolution protocol, but also its own metadata format. Check out the IANA URN Namespaces registry for a sense of how many resolution protocols and metadata formats are involved.

While it is true that each DID method also has its own concrete resolution protocol, the abstract DID resolution contract—and most importantly the resolution result (a DID document)—is standardized for all DIDs.

That's a major advantage over URNs. Furthermore, with the representation property, we are uniting persistent, resolvable, cryptographically verifiable identification of the world of digital objects (what the Semantic Web folks call "information objects") with persistent, resolvable, cryptographically verifiable identification of the world of all non-digital objects. So we can use one comprehensive standard for both.

How cool is that?

msporny

Waiting for other folks to weigh in on this PR... I personally feel it's a bit misguided -- the use case seems too generic -- but I may not understand the use case. Even if it isn't misguided, the PR uses uri and type in strange ways. Waiting for the PR to get revised or for the PR submitter to provide a clarifying use case and/or to review the use of uri, type, and value.

msporny · 2020-07-28T13:24:23Z

index.html

+        </dl>
+
+        <dl>
+        <dt>type</dt>


Waiting on this to be resolved to do a re-review of this PR.

msporny · 2020-07-28T13:25:02Z

index.html

+        <dl>
+        <dt>type</dt>
+        <dd>
+        The <code>type</code> property MUST be a <a>URI</a> that asserts the


I think @OR13 is stating that using type is the wrong property to use here?

kdenhartog · 2020-07-28T23:40:49Z

For the representation property can, I'm not really sure I'm following the purpose of this. The only thing I'm coming up with is when the DID Subject is a online resource, but in that case I'm not understanding the advantages of using a DID rather than something like a URN. Could you provide me any additional use cases for this so I can understand it and reason about it better?

@kdenhartog You nailed it—the whole reason for this PR is that a DID can, in certain cases, be much better than a URN. Just take every use case for a URN, and add these advantages of a DID:
1. **No centralized registry required.** Almost all URNs require centralized or federated registry services (the exception is URNs like UUIDs that are not resolvable at all).

2. **Cryptographically verifiability.** The DID controller of the immutable object that serves as a DID subject—for example a schema—is able to publish a series of versions of that schema that each can be cryptographically verified as published by that same DID controller. While not all persistent digital objects need that (there is a whole class of immutable objects the Decentralized Semantics folks call "ungoverned objects" that are just "fire and forget" and are never versioned). But if you need verifiable provenance of an immutable object, a DID is perfect.

3. **Standardized resolution.** First of all, not all URNs are resolvable (e.g., UUIDs). But if they are resolvable, DIDs have a significant advantage because every URN scheme needs to define not just its URN identifier format and resolution protocol, _but also its own metadata format_. Check out the [IANA URN Namespaces registry](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) for a sense of how many resolution protocols and metadata formats are involved.
While it is true that each DID method also has its own concrete resolution protocol, the abstract DID resolution contract—and most importantly the resolution result (a DID document)—is standardized for all DIDs.

That's a major advantage over URNs. Furthermore, with the representation property, we are uniting persistent, resolvable, cryptographically verifiable identification of the world of digital objects (what the Semantic Web folks call "information objects") with persistent, resolvable, cryptographically verifiable identification of the world of all non-digital objects. So we can use one comprehensive standard for both.

How cool is that?

In this case, I'd put myself at a +0 then. I'm not thinking we'll (Mattr) use this for resource descriptions at this point, but I expect that down the road it will be useful for implementers who are expanding on the ways in which DIDs are used. I'd be much more willing to move to a +1 if we saw more use cases adopting DIDs in this manor. Do you know of any implementations already doing this (I was thinking the rich schemas might go in that direction, but I haven't see that happen yet.)

OR13 · 2020-08-13T13:15:30Z

index.html

+<code><a>serviceEndpoint</a></code>.
+      </li>
+      <li>
+<code><a>created</a></code>: defined in <a href="#created"></a>.


did we agree that created and updated go in the did document? I recall strongly objecting to that.

We did not agree to put created and updated in the DID Document. We left it open that some DID Methods may choose to do that, but if they do, it's a statement asserted by the controller of said document.

Signed-off-by: Drummond Reed <[email protected]>

talltree · 2020-08-14T03:20:00Z

I just pushed a rewrite of this property based on input from this thread and the discussion on today's DID WG special topic call on the proposed DID Appendices (see #373). This rewrite removes any direct references to those proposed Appendices so it can now stand on its own (though the proposed Appendices may still be helpful for understanding this property).

talltree · 2020-09-29T04:31:03Z

This PR has been superseded by the proposed type property in #410. I am going to mark this PR "pending close".

brentzundel · 2020-10-09T13:10:50Z

No comments since marked pending close, closing

new sameAs and representation properties

e9c2ed4

Signed-off-by: Drummond Reed <[email protected]>

talltree requested review from msporny, peacekeeper and brentzundel July 15, 2020 07:15

talltree self-assigned this Jul 15, 2020

OR13 reviewed Jul 15, 2020

View reviewed changes

OR13 requested changes Jul 15, 2020

View reviewed changes

msporny requested changes Jul 15, 2020

View reviewed changes

talltree mentioned this pull request Jul 15, 2020

Add sameAs w3c-ccg/security-vocab#45

Closed

renamed sameAs to sameSubject

6450184

Signed-off-by: Drummond Reed <[email protected]>

talltree changed the title ~~new sameAs and representation properties~~ new sameSubject and representation properties Jul 21, 2020

msporny requested changes Jul 21, 2020

View reviewed changes

brentzundel reviewed Jul 21, 2020

View reviewed changes

talltree mentioned this pull request Jul 22, 2020

Add alsoKnownAs property #355

Closed

removed sameSubject property

80094eb

Signed-off-by: Drummond Reed <[email protected]>

talltree changed the title ~~new sameSubject and representation properties~~ add representation property Jul 22, 2020

Update index.html

1ba5bac

Co-authored-by: Brent <[email protected]>

kdenhartog approved these changes Jul 22, 2020

View reviewed changes

kdenhartog reviewed Jul 23, 2020

View reviewed changes

msporny requested changes Jul 28, 2020

View reviewed changes

talltree mentioned this pull request Aug 11, 2020

Proposed Appendices on DID Identification Architecture #373

Closed

Merge branch 'master' into repprop

49cfaf8

OR13 reviewed Aug 13, 2020

View reviewed changes

rewrite of property per comments

0c92a62

Signed-off-by: Drummond Reed <[email protected]>

brentzundel mentioned this pull request Aug 18, 2020

Clarification on what DIDs might identify #199

Closed

msporny added the do not merge Do not merge - waiting on resolution to issue label Aug 27, 2020

rhiaro mentioned this pull request Sep 21, 2020

Add type property #410

Closed

talltree added the pending close Issue will be closed shortly if no objections label Sep 29, 2020

brentzundel closed this Oct 9, 2020

	true. A malicious <a>DID controller</a> may attempt to impersonate a
	true. A malicious <a>DID controller</a> might attempt to impersonate a

	Therefore it is STRONGLY RECOMMENDED that a requesting party obtain
	Therefore it is strongly advised that a requesting party obtain

	inverse <code>sameSubject</code> assertion (i.e., a backpointer). See
	inverse <code>sameSubject</code> assertion, also known as a back pointer. See

	<a>DID subject</a>.
	<a>DID subject</a>. Implementers are strongly advised against the use of <code>owl:sameAs</code> when processing <a>DID documents</a> as its use could expand the attack surface in a way that was not considered by the Working Group.

	of doing this is to resolve the <code>sameAs</code> <a>DID</a> to its
	of doing this would be to resolve each <code>sameAs</code> <a>DID</a> to its

add representation property #348

add representation property #348

Conversation

talltree commented Jul 15, 2020 • edited by pr-preview bot Loading

talltree commented Jul 15, 2020

iherman commented Jul 15, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 left a comment • edited Loading

Choose a reason for hiding this comment

msporny left a comment

Choose a reason for hiding this comment

OR13 commented Jul 15, 2020 • edited Loading

talltree commented Jul 15, 2020

talltree commented Jul 15, 2020

talltree commented Jul 15, 2020

talltree commented Jul 15, 2020

OR13 commented Jul 15, 2020 • edited Loading

talltree commented Jul 16, 2020

talltree commented Jul 21, 2020

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peacekeeper Jul 24, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

talltree commented Jul 21, 2020

talltree commented Jul 22, 2020

kdenhartog left a comment

Choose a reason for hiding this comment

talltree commented Jul 23, 2020

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog commented Jul 28, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

talltree commented Aug 14, 2020

talltree commented Sep 29, 2020

brentzundel commented Oct 9, 2020

talltree commented Jul 15, 2020 •

edited by pr-preview bot

Loading

OR13 left a comment •

edited

Loading

OR13 commented Jul 15, 2020 •

edited

Loading

OR13 commented Jul 15, 2020 •

edited

Loading

peacekeeper Jul 24, 2020 •

edited

Loading

kdenhartog commented Jul 28, 2020 •

edited

Loading