Add alsoKnownAs property #355

talltree · 2020-07-22T17:26:57Z

This PR was originally part of PR #348 but was separated out for independent discussion.

Preview | Diff

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

kdenhartog

This one looks good. LGTM

dmitrizagidulin

👍 this is great.

dlongley · 2020-07-23T19:26:25Z

index.html

-to use with other Internet-based identifiers.
-      </p>
-    </section>
+typically URLs, or more generally, <a>URIs</a> (and in some cases specifically


Since this section is being cleaned up a bit, it seems we should say that "identifiers SHOULD be URIs" instead of this other non-enforceable language around "identifiers are typically URLs". And then we can give the advice that follows. Also, we may want to say that if an identifier is not a URI, then globally unambiguous interop is not possible.

agree... identifiers should be URIs.

dlongley · 2020-07-23T19:50:20Z

index.html

+        </section>
+
+        <section>
+        <h2>sameSubject</h2>


I think "alsoKnownAs" was a contender for the name, here, right? I think that would be better. I prefer the triple:

<did:example:123> alsoKnownAs <did:example:456>

Over:

<did:example:123> sameSubject <did:example:456>

Which reads strangely when you think about the fact that "sameSubject" is an attribute or property of the DID subject. So, as an example, if the DID subject is Drummond, it's like saying that Drummond has an attribute "sameSubject" of "github/tallTree". Drummond doesn't have a "same subject" of "github/tallTree". Rather, "github/tallTree" is another identifier for Drummond.

So, I'd rather say that Drummond is also known as "github/tallTree". Using "sameSubject" seems like we're bringing in contextual information that Drummond happens to have a DID Document of which he is the subject when we're just trying to talk about his attributes. It feels more like a metadata property to me: the subject of this DID Document is the same one as this other DID Document -- like we're conflating metadata about the DID Document with properties/attributes of the DID subject itself. I think we can avoid all that with a property name like "alsoKnownAs".

ChristopherA · 2020-07-23T21:58:56Z

I also prefer alsoKnownAs. I feel sameSubject requires an evidence proof, alsoKnownAs feel more like a hint.

dmitrizagidulin · 2020-07-23T23:11:45Z

+1 to preferring alsoKnownAs - I agree with @ChristopherA that it denotes more of a hint / suggestion, which is just the right balance to strike.

kdenhartog · 2020-07-24T02:09:40Z

+1 to renaming to alsoKnownAs as well.

talltree · 2020-07-24T19:34:40Z

"The populace has spoken." I shall rename the property to alsoKnownAs as soon as I can get back to this.

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

OR13 · 2020-07-27T13:54:32Z

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>. Implementers are strongly advised against the use of


I'm having some trouble with the phrasing of this last bit.... perhaps we mean to more generally warn against the use of OWL in any form with DID Documents?

... should this warning be applied to all non did core semantic vocabularies?

Is there any version of owl:sameAs where its intended defintion is compatible with DID Core?

@dlongley @iherman

perhaps we mean to more generally warn against the use of OWL in any form with DID Documents?

I do not have the right experience with DID documents in practice, but I could imagine cases when some OWL statement may be useful. RDFS+OWL is huge, so such a blank statement may go too far. We are hooked upon owl:sameAs because that is one of the most powerful statements in OWL, in fact... Maybe @dlongley has some examples for a proper usage of some OWL statements.

Note that, however, OWL is really used for the definitions of the ontologies and not the instance data (and a DID document is an instance data). Again, owl:sameAs is one of the rare exceptions. So the issue may not come up anyway.

Is there any version of owl:sameAs where its intended defintion is compatible with DID Core?

I do not understand the question. There are no different "versions" of owl:sameAs...

However I also have some trouble with the phrasing of the last bit.

In other words, it does not assert that two or more RDF graphs represented as DID documents can be merged. It only asserts that two or more DIDs identify the same DID subject.

Strictly speaking, owl:sameAs does not mean that one can merge RDF graphs. RDF graphs can me merged if and only if the ID-s of two notes are strictly identical, ie, bit-by-bit. What owl:sameAs does (as indeed OWL does in general) is to give a license to ~~kill~~ infer. It means that, conceptually, new triples can be added to an RDF Graph: all assertions involving one ID can be asserted with the other one. That is not merge.

That being said, I do not really know how to express that succinctly in the text. Maybe the best is to remove that sentence; people who understand owl:sameAs will know what it is, and people who do not (and/or do not care about OWL) would ignore this anyway.

By versions of owl:sameAs, I mean positive and negative examples.... let's prove its a valid / safe thing to do in some contexts, or show that it's not valid / safe to do in any context before making recommendations like the one in the note.

here is an example, I believe is valid and safe:

https://didme.me/did:meme:1zgswzdje885tzr8408m37sjmaa0sthw265ty6hmwzmau48kd809zzrgra4w5w owl:sameAs https://didme.me/did:meme:1zgsy0xdgwd66j8r2tvpfgq04gxkzvgzjh9jlgmlqtq47v34z2xnxzsq2h2t3z

I created both of these identifiers, and per the owl:sameAs defintion...

Such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity".

Both DIDs are for the same subject... I as that subject created the triple above to express it... If what I just did is valid OWL, and safe from a DID Core purpose... the text MUST be removed :)

Both DIDs are for the same subject... I as that subject created the triple above to express it... If what I just did is valid OWL, and safe from a DID Core purpose

I believe, at first glance, that this is valid and probably safe because (I presume) you deliberately regenerated a DID for the same subject twice (or something like that). You, as the creator of the DID, know that they are safe and OWL cannot do harm. The Note is just a warning against relying on this feature, I do not think this invalidates the existence of the note itself...

Yes, i created 2 identifiers... I might create more, I should be able to use owl to communicate facts like the one above to a system I control.

If thats the case, and there is no argument, we can address the warning with the following proposed text:

Implementers are strongly advised to not use vocabularies like `OWL` with DIDs unless they are familiar with the use of the vocabulary, and the associated security implications. Due to the decentralized nature of many verifiable data registries, DID Documents are recommended to be considered untrusted user input. See <a href="https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html">OWASP Input Validation Cheat Sheet</a>.

In other words... if you are sure you don't want to process RDF statements related to OWL... thats for you to do in your application, not for DID Core to recommend against.... DID Core normative / informative statements are not a solution to input validation.

@msporny ^ perhaps this last comment better describes your objection... You intend to rely directly on https://www.w3.org/ns/did/v1 alone for input validation?... and including owl:sameAs would mean that you would need to validate the did document did not contain OWL statements and any subset of did core your application does not intend to support some other way?

In other words... if you are sure you don't want to process RDF statements related to OWL... thats for you to do in your application, not for DID Core to recommend against.... DID Core normative / informative statements are not a solution to input validation.

I am fine with that.

Not being an expert I cannot judge whether the reference to the owasp cheatsheet is the right one; I leave this decision to those who know more about this than I do.

OR13

We need to provide better guidance on how did core semantic vocabularies relate to external ones, such as https://www.w3.org/TR/activitystreams-core/ (where alsoKnownAs came from) and https://www.w3.org/TR/owl-ref/ (where sameAs came from)...

It seems like the general risk is that anyone can use another vocabulary to define security / identity concepts... and that semantic processors might get confused.

If we are going to recommend against support for established vocabularies like OWL, we should do so more directly than a passing editorial note :)

related: w3c/did-extensions#92

msporny · 2020-07-28T14:26:09Z

We need to provide better guidance on how did core semantic vocabularies relate to external ones, such as https://www.w3.org/TR/activitystreams-core/ (where alsoKnownAs came from)

Weeeelllll... funny story there... alsoKnownAs isn't actually in the Activity Streams Vocabulary (yet)... decentralized vocabulary extension being what it is... Mastodon just added it and shipped it to 2 million people -- (docs) https://docs.joinmastodon.org/spec/activitypub/#as and here (code): https://github.com/tootsuite/mastodon/blob/5d8398c8b8b51ee7363e7d45acc560f489783e34/app/lib/activitypub/adapter.rb#L14

I've formally requested that it is added to AS here:

w3c/activitystreams#511

We'll see what they say... even if they can't do it, we can follow in the footsteps of Mastodon as long as @Gargron and @cwebber don't think that's a horrible idea. Viva decentralized vocabulary extensions!

msporny

LGTM, very minor nit on reference to privacy/security considerations section.

msporny · 2020-07-28T14:28:47Z

index.html

+        method for doing this is to resolve the <code>alsoKnownAs</code> <a>DID</a>
+        to its own <a>DID document</a> and then verify that it contains the
+        inverse <code>alsoKnownAs</code> assertion, also known as a backpointer.
+        See the <a href="#security-considerations"></a> and


We'll want to point to a specific item in security/privacy considerations. Just generally pointing there isn't very useful.

dlongley · 2020-07-28T14:43:31Z

index.html

+        <dd>
+        The value of <code>alsoKnownAs</code> MUST be a
+        <a data-cite="INFRA#lists">list</a> where each item in the list is a
+        <a>DID</a> that conforms to the rules in Section <a href="#did-syntax"></a>.


Do we want to allow non-DID URLs as well?

It was discussed that we might want alsoKnownAs to be restricted to DIDs, and leave sameAs for IRIs.... alsoKnownAs has the same "type" signature as owl:sameAs... I will object to it, based on that being confusing for implementers.

Wouldn't that be weird from a (semantic) web perspective, saying that you have to use a different predicate just because the object identifiers are different?

yes... it would... thats an argument against using something other than sameAs imo.... i remain completely unconvinced that new terms are needed here.... especially when we can add clarity to existing ones....

msporny · 2020-08-24T01:20:48Z

This PR is waiting on a rewrite from @talltree based on the last discussion we had during a DID special topic call on this particular subject.

Also note that there is an ongoing conversation over here about the property: w3c/activitystreams#511

msporny · 2020-08-30T16:35:12Z

@rhiaro, spoke with @talltree last week -- he'd like you to take over the alsoKnownAs PR because you know the ActivityPub community best and are probably the most capable of writing a definition for the property that works for both the DID ecosystem and the ActivityPub/Mastodon ecosystem. Would you mind writing something based on the plan you proposed last week, please?

rhiaro · 2020-08-31T11:02:00Z

@msporny @talltree Will do. This PR can probably be closed?

talltree · 2020-09-11T04:46:53Z

@rhiaro If you have (or are planning to) create a new PR, then yes, we can close this one. I'm happy to mark it pending close as soon as you confirm what your plan is.

rhiaro · 2020-09-11T07:54:10Z

@talltree new PR is #389

talltree · 2020-09-11T15:09:12Z

@rhiaro Excellent. Because this PR is entirely superseded by #389, I'm marking it as Pending Close.

msporny · 2020-09-14T14:51:01Z

This PR was superceded by #389, which has now been merged. Closing this one.

talltree added 4 commits July 15, 2020 00:11

new sameAs and representation properties

e9c2ed4

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

renamed sameAs to sameSubject

6450184

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

removed representation property

0bffad2

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

incorporated Manu suggestions

db7e80c

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

talltree mentioned this pull request Jul 22, 2020

add representation property #348

Closed

kdenhartog approved these changes Jul 22, 2020

View reviewed changes

dmitrizagidulin approved these changes Jul 23, 2020

View reviewed changes

dlongley reviewed Jul 23, 2020

View reviewed changes

renamed sameSubject to alsoKnownAs

7ae715c

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

talltree changed the title ~~Add sameSubject property~~ Add alsoKnownAs property Jul 24, 2020

talltree requested review from dlongley, msporny, OR13 and peacekeeper July 24, 2020 23:51

OR13 reviewed Jul 27, 2020

View reviewed changes

OR13 requested changes Jul 27, 2020

View reviewed changes

msporny mentioned this pull request Jul 28, 2020

Add alsoKnownAs property to AS vocabulary w3c/activitystreams#511

Open

5 tasks

msporny requested changes Jul 28, 2020

View reviewed changes

dlongley reviewed Jul 28, 2020

View reviewed changes

talltree mentioned this pull request Aug 11, 2020

Proposed Appendices on DID Identification Architecture #373

Closed

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 7, 2020

Define alsoKnownAs property #389

Merged

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

msporny closed this Sep 14, 2020

brentzundel mentioned this pull request Sep 25, 2020

Cheap DIDs and the option to migrate DIDs between ledgers using standard DID Deprecation Registries #33

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add alsoKnownAs property #355

Add alsoKnownAs property #355

talltree commented Jul 22, 2020 •

edited by pr-preview bot

Loading

kdenhartog left a comment

dmitrizagidulin left a comment

dlongley Jul 23, 2020

OR13 Jul 27, 2020

dlongley Jul 23, 2020

ChristopherA commented Jul 23, 2020

dmitrizagidulin commented Jul 23, 2020

kdenhartog commented Jul 24, 2020

talltree commented Jul 24, 2020

OR13 Jul 27, 2020 •

edited

Loading

iherman Jul 27, 2020

OR13 Jul 27, 2020

iherman Jul 27, 2020

OR13 Jul 27, 2020 •

edited

Loading

OR13 Jul 27, 2020 •

edited

Loading

OR13 Jul 27, 2020 •

edited

Loading

iherman Jul 28, 2020

OR13 left a comment •

edited

Loading

msporny commented Jul 28, 2020

msporny left a comment

msporny Jul 28, 2020

dlongley Jul 28, 2020

OR13 Jul 28, 2020

peacekeeper Aug 10, 2020

OR13 Aug 10, 2020

msporny commented Aug 24, 2020 •

edited

Loading

msporny commented Aug 30, 2020

rhiaro commented Aug 31, 2020

talltree commented Sep 11, 2020

rhiaro commented Sep 11, 2020

talltree commented Sep 11, 2020

msporny commented Sep 14, 2020

Add alsoKnownAs property #355

Add alsoKnownAs property #355

Conversation

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

kdenhartog left a comment

Choose a reason for hiding this comment

dmitrizagidulin 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

ChristopherA commented Jul 23, 2020

dmitrizagidulin commented Jul 23, 2020

kdenhartog commented Jul 24, 2020

talltree commented Jul 24, 2020

OR13 Jul 27, 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

OR13 Jul 27, 2020 • edited Loading

Choose a reason for hiding this comment

OR13 Jul 27, 2020 • edited Loading

Choose a reason for hiding this comment

OR13 Jul 27, 2020 • edited Loading

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 commented Jul 28, 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

msporny commented Aug 24, 2020 • edited Loading

msporny commented Aug 30, 2020

rhiaro commented Aug 31, 2020

talltree commented Sep 11, 2020

rhiaro commented Sep 11, 2020

talltree commented Sep 11, 2020

msporny commented Sep 14, 2020

talltree commented Jul 22, 2020 •

edited by pr-preview bot

Loading

OR13 Jul 27, 2020 •

edited

Loading

OR13 Jul 27, 2020 •

edited

Loading

OR13 Jul 27, 2020 •

edited

Loading

OR13 Jul 27, 2020 •

edited

Loading

OR13 left a comment •

edited

Loading

msporny commented Aug 24, 2020 •

edited

Loading