Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alsoKnownAs property #355

Closed
wants to merge 5 commits into from
Closed

Add alsoKnownAs property #355

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e9c2ed4
new sameAs and representation properties
talltree Jul 15, 2020
6450184
renamed sameAs to sameSubject
talltree Jul 21, 2020
0bffad2
removed representation property
talltree Jul 22, 2020
db7e80c
incorporated Manu suggestions
talltree Jul 22, 2020
7ae715c
renamed sameSubject to alsoKnownAs
talltree Jul 24, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 60 additions & 13 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1238,27 +1238,25 @@ <h1>Core Properties</h1>
including whether these properties are required or optional.
</p>

<section>
<h2>
Identifiers
</h2>
<p>
<p class="note">
Identifiers are used in the data model to identify specific instances of people,
organizations, devices, keys, services, and things in general. Identifiers are
typically URLs, or more generally, <a>URIs</a>. Non-<a>URI</a>-based identifiers
are not advised because, while the data model supports them, they are not easy
to use with other Internet-based identifiers.
</p>
</section>
typically URLs, or more generally, <a>URIs</a> (and in some cases specifically
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree... identifiers should be URIs.

<a>DIDs</a>). Non-<a>URI</a>-based identifiers are not advised because, while
the data model supports them, they are not easy to use with other Internet-based
identifiers.
</p>

<section>
<h2>DID Subject</h2>

<section>
<h2>id</h2>

<p>
The <a>DID subject</a> is denoted with the <code>id</code> property. The
<a>DID subject</a> is the entity that the <a>DID document</a> is about. That is,
it is the entity identified by the <a>DID</a> and described by the
<a>DID document</a>.
<a>DID subject</a> is the entity identified by the <a>DID</a> and described by
the <a>DID document</a>.
</p>

<p>
Expand Down Expand Up @@ -1288,6 +1286,55 @@ <h2>DID Subject</h2>
property. The value of <code>id</code> in the resolved <a>DID document</a> is
expected to match the <a>DID</a> that was resolved.
</p>
</section>

<section>
<h2>alsoKnownAs</h2>
<p>
A <a>DID controller</a> MAY assert that two or more <a>DIDs</a> identify
the same <a>DID subject</a> using the <code>alsoKnownAs</code> property.
This property is OPTIONAL.
</p>

<dl>
<dt>alsoKnownAs</dt>
<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>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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....

</dd>
</dl>
<p>
From a semantic standpoint, the <a>DID controller</a> is asserting that
each <a>DID</a> in the list identifies the same <a>DID subject</a> as
the <a>DID</a> described by the <a>DID document</a> (i.e., the value of
the <code>id</code> property).
</p>
<p class="note">
WARNING: An <code>alsoKnownAs</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> might attempt to impersonate a
<a>DID subject</a> by making a false <code>alsoKnownAs</code> assertion.
Therefore it is strongly advised that a requesting party obtain
independent verification of a <code>alsoKnownAs</code> assertion. One
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<a href="#privacy-considerations"></a> sections for more information.
</p>
<p class="note">
A <code>alsoKnownAs</code> assertion is not the same as an
<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
Copy link
Contributor

@OR13 OR13 Jul 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Contributor

@OR13 OR13 Jul 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>.

Copy link
Contributor

@OR13 OR13 Jul 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@OR13 OR13 Jul 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

<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.
</p>
</section>

</section>

<section>
Expand Down