Add sameAs

[OR13]

Add sameAs to security vocab.

Addresses: #44

Cross linking:

w3c/did-core#33

w3c/did-extensions#80

[msporny]

Concerned that we probably want something other than "sameAs" for the use case we've been contemplating.

[msporny]

Note that @talltree is currently adding this same property to the DID Core specification. Having it in the security vocabulary is dangerous because some developers might think it could be used to assert that a publicKey is the sameAs another public key (suggesting that all associated attributes can be merged together). sameAs is a dangerous property in OWL land... it means that two things are semantically equivalent. So, if I were to say #orie sameAs #manu -- I would say that Orie is exactly the same thing as Manu, which is problematic, from a DID perspective. We are probably going to want to dial back the OWL semantics, possibly using something else to avoid the sledgehammer that is sameAs. We probably want something closer to "supersededBy" or "replacedBy" to match the use case that I think the community wants.

To put it more concretely, one attack that sameAs enables is allowing the merging of compromised keys from an old DID to a new DID... because they're the same thing, right? (except they're not, and assuming they are opens us up to attack vectors).

-0.8 to this PR until we can ferret out the use case.

/cc @iherman @dlongley

[OR13]

well, its not assuming they are equivalent... the controller is saying the subjects are equivalent... if we don't trust the controller to make assertions about the subject... I fear we have made a mistake :)

Another thing to consider is that the strength of all RDF statements related to a subject is a function of the strength of the DID Method... so for example anyone with push access can add sameAs here: https://github.com/transmute-industries/did.actor/blob/master/alice/did.json#L3 ... whereas in did:v1, you would need private keys... however, assuming private key compromise is in some ways similar to assuming XSS... once its assumed, there are a whole bunch of other security issues... but in my opinion all of them flow from the XSS... similarly for private key compromise... the only reason you trust ANY assertion about the subject is that you believe that private key compromise HAS NOT occurred... once thats inverted, all the assertions (including sameAs) are worthless.

There is advantage, and danger in using OWL directly... but one thing for sure is that building on OWL is building on an existing standard, whereas not using OWL is making something up that is new / not in use / not standardized...

[iherman]

Note that @talltree is currently adding this same property to the DID Core specification. Having it in the security vocabulary is dangerous because some developers might think it could be used to assert that a publicKey is the sameAs another public key (suggesting that all associated attributes can be merged together). [...]

To put it more concretely, one attack that sameAs enables is allowing the merging of compromised keys from an old DID to a new DID... because they're the same thing, right? (except they're not, and assuming they are opens us up to attack vectors).

-0.8 to this PR until we can ferret out the use case.

/cc @iherman @dlongley

I am not a security expert but I share the concern of @msporny. For example:

well, its not assuming they are equivalent... the controller is saying the subjects are equivalent... (@OR13)

Yes, we can/should trust the controller. The issue is that RDF/OWL is based on an open world assumption; this means that a owl:sameAs statement can be made by anybody in the world, it does not have to be the controller. It can be you, Manu, or me publishing this statement on the open Web. A bona fide OWL reasoning process that gets hold of this extra triple can make deductions that we may not want.

As long as we remain within the DID world we are shielded from this because a DID processor is not expected to do any kind of OWL processing. I.e., this does not affect us. Introducing owl:sameAs into the DID world gets us closer to OWL, even if minimally, and this may have unexpected consequences that we may not fully understand right now. I would just prefer to be cautious.

As far as I can see the goal is to use owl:sameAs in a very very constrained environment, and I personally would be o.k. to introduce our very own identicalKey term (or whatever purposes we want to use sameAs). Our vocabulary is small, and the places where an identification may be necessary is even smaller, I would not think this would be very onerous.

[peacekeeper]

I think these would be the correct URIs?

[msporny]

@OR13 wrote:

If we don't trust the controller to make assertions about the subject... I fear we have made a mistake

That's not the point of contention... I don't think anyone is asserting that. The issue is as Ivan says:

@iherman wrote:

A bona fide OWL reasoning process that gets hold of this extra triple can make deductions that we may not want.

This is the attack. Using owl:sameAs will cause reasoners to treat one DID as exactly the same thing as some other DID. That's not the use case and that's not what we want, not only because it'll lead to strange graph merging, but because those graph merges could result in terrible security vulnerabilities that we have no control over.

The solution is as Ivan states... be surgical about the property we're picking. I fear that we're defining a new thing, which is fine, but this property has some pretty dire security concerns and so we need to be very precise with the term we use. It /may/ be a security vocab thing, in fact, it probably is... but we need to constrain it so that OWL reasoners don't go haywire and unwittingly open up all sorts of key aliasing attacks.

[OR13]

@OR13 wrote:

If we don't trust the controller to make assertions about the subject... I fear we have made a mistake

That's not the point of contention... I don't think anyone is asserting that. The issue is as Ivan says:

@iherman wrote:

A bona fide OWL reasoning process that gets hold of this extra triple can make deductions that we may not want.

This is the attack. Using owl:sameAs will cause reasoners to treat one DID as exactly the same thing as some other DID. That's not the use case and that's not what we want, not only because it'll lead to strange graph merging, but because those graph merges could result in terrible security vulnerabilities that we have no control over.

The solution is as Ivan states... be surgical about the property we're picking. I fear that we're defining a new thing, which is fine, but this property has some pretty dire security concerns and so we need to be very precise with the term we use. It /may/ be a security vocab thing, in fact, it probably is... but we need to constrain it so that OWL reasoners don't go haywire and unwittingly open up all sorts of key aliasing attacks.

So in the case that I am already using OWL-RL and doing forward chain reasoning... you are suggesting that we prevent the reasoner from using owl:sameAs... because it might interpret it... correctly?

I'm confused here... we're starting to have security conversations about semantic reasoners... which like any reasoning system are function of their input.

If you feed a prolog program bad facts and rules... you get bad reasoning... if you feed an OWL-RL system triples containing sameAs (which anyone can construct), and they are not correct... you get bad reasoning...

What we need is layers here:

Layer 1 - Vocabulary and Definitions
Layer 2 - Semantic Assertions using Cryptography
Layer 3 - Semantic Reasoning

Imagine we remove layer 2.... the problem persist... You can still feed cat1 sameAs dog1 to any reasoner... and it will still lead to problems... its actually worse when there is no ability to authenticate the triple.

creating a new term does not solve the problem... because you can craft cat1 identicalTo dog1 just as easily....

We should be very careful creating duplicate terms to avoid conflicts with semantic reasoning systems... some people want to use those systems directly.... A system managing aliases for spies, or protecting the privacy of individuals who use multiple dids to defend against correlation might want to reason about the fact that did1 sameAs did2 is actually a true statement.

[dlongley]

I'm so far in agreement with @OR13, particularly with his last comment. Whether or not particular assertions are to be trusted is a separate layer from reasoning about them. I don't understand why the concern is that someone may make a statement that is untrusted -- that has always been possible. I also realize that we'd want bidirectional assertions to trust sameAs assertions about DIDs ... but, if we had that, why wouldn't we want to enable reuse of existing reasoners? If we invent a new "sameAs2" -- won't reasoners just have to be updated to support that?

I feel like there's a layering violation in the arguments I've seen so far against reusing "owl:sameAs". If reusing "sameAs" is not semantically correct for some reason, that's a good argument for a new term, but I can't see how whether or not we trust such an assertion is.

[David-Chadwick]

+1

…

On 7/6/20 3:30 PM, Dave Longley wrote: I'm so far in agreement with @OR13 <https://github.com/OR13>, particularly with his last comment. Whether or not particular assertions are to be trusted is a separate layer from reasoning about them. I don't understand why the concern is that someone may make a statement that is untrusted -- that has always been possible. I also realize that we'd want bidirectional assertions to trust |sameAs| assertions about DIDs ... but, if we had that, why wouldn't we want to enable reuse of existing reasoners? If we invent a new "sameAs2" -- won't reasoners just have to be updated to support that? I feel like there's a layering violation in the arguments I've seen so far against reusing "owl:sameAs". If reusing "sameAs" is not semantically correct for some reason, that's a good argument for a new term, but I can't see how whether or not we trust such an assertion is. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33R74XGZZCWHGPQXC7AMLR2HNXJANCNFSM4OPC5XYQ>.

[dmitrizagidulin]

👍 +1000, I endorse this product and/or statement.

ALTHOUGH. I'd much prefer it if we required it to be bi-directional (or at least, made that a part of the definition).

[wyc]

ALTHOUGH. I'd much prefer it if we required it to be bi-directional (or at least, made that a part of the definition).

I can imagine instances where it must be unidirectional, especially when the entity in reference is not the same as the DID controllers. For example, two investigators might have their own private internal representations of entity E via its public URI, and they may wish to trade their understanding with each other without the involvement of entity E.

[msporny]

If reusing "sameAs" is not semantically correct for some reason, that's a good argument for a new term

Reusing sameAs is not semantically correct -- we are not asserting that one DID is exactly the same as some other DID and you should merge their graphs together. We are stating that one DID is asserting that another DID supersedes it. At least, that's the use case I'm talking about. As I said above:

-0.8 to this PR until we can ferret out the use case.

So, what's the use case? I thought it was: "I was using DID X, and now I'm using DID Y and I want to note in DID X that people should use DID Y from now on." -- also, this creates havoc wrt. reasoning about VCs. Can DID Y provide VCs that were issued to DID X but sign them as DID Y? Doesn't this make the whole ecosystem more complex? Yes, we could use ZKPs for ABCs here, but remember that there are deep concerns about that approach.

We need a list of use cases that "sameAs" and "supersededBy" are supposed to solve. Hard to design a feature without those laid out. We're bound to miscommunicate until they are.

[dmitrizagidulin]

@msporny

We need a list of use cases that "sameAs" and "supersededBy" are supposed to solve.

The use cases are as follows.

sameAs: One DID is asserted to be equivalent as another by the DID controller. Importantly, both DIDs are available / resolvable, and either can be used interchangeably (so, for example, if they're being used for an identity-based access control system, authenticating as did A is equivalent to authenticating to the sameAs DID B). Bi-directional references are required for validation. Importantly: it DOES NOT imply that the graphs for the two DIDs can be merged.

supersededBy: The controller is migrating (or has migrated) from DID A to DID B. (DID A is being superseded by DID B). In this case, only DID B needs to be resolvable (in case DID A went away). Although bi-directional reference is preferred, if the "source" DID A is missing, this needs to be paired with a Verifiable Credential (signed by DID A), claiming that DID B is indeed the successor.

Typing this out, this very much seems that this PR should be to the DID Context, instead of the Security context, actually.

[iherman]

sameAs: One DID is asserted to be equivalent as another by the DID controller. Importantly, both DIDs are available / resolvable, and either can be used interchangeably (so, for example, if they're being used for an identity-based access control system, authenticating as did A is equivalent to authenticating to the sameAs DID B). Bi-directional references are required for validation.

Thanks for the example. A question: does it mean that the statements of the DID documents become all interchangeable? I.e., let us say the two DID-s are D_1 and D_2, with Doc_1 and Doc_2 as DID documents, respectively. Doc_1 defines, say, a service via the service predicate; are we sure that this service is valid for D_2, too (because that is what owl:sameAs would mean).

Another question, but from another point of view. owl:sameAs is, strictly on a fix URI. So if we say D1 owl:sameAs D2, that statement does not have any bearing on the respective DID URLs. I.e., if Doc_1 has a statement on, say, D_1#123, that does not mean that D_1#123 owl:sameAs D_2#123. Is that o.k., or may that be a problem?

[OR13]

@dmitrizagidulin we need to keep security vocab in sync... and its not going to get accepted into did spec registries if its not defined somewhere in sufficient detail...

we need sameAs defined in 3 places... here, did spec registries, and did core.

... in that order.

[msporny]

@dmitrizagidulin -- thanks for the use cases, now we just need all the ones from @OR13, @dlongley, @David-Chadwick, and at least everyone else in this thread.

Importantly: it DOES NOT imply that the graphs for the two DIDs can be merged.

Well, that's one of the points of contention, because that's exactly what owl:sameAs implies. So, owl:sameAs specifically does not solve the use case you stated because of the restriction made in your last sentence, right?

[David-Chadwick]

thinking more deeply about it, one DID is not the same as another DID even if both belong to the same controller. The controller is the same but the way of authenticating him/her/it is different. So maybe a different verb is needed such as belongsToSameAs kind regards David

…

On 7/7/20 6:20 PM, Manu Sporny wrote: @dmitrizagidulin <https://github.com/dmitrizagidulin> -- thanks for the use cases, now we just need all the ones from @OR13 <https://github.com/OR13>, @dlongley <https://github.com/dlongley>, @David-Chadwick <https://github.com/David-Chadwick>, and at least everyone else in this thread. Importantly: it DOES NOT imply that the graphs for the two DIDs can be merged. Well, that's one of the points of contention, because that's exactly what owl:sameAs implies. So, owl:sameAs specifically does not solve the use case you stated because of the restriction made in your last sentence, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33R75NSKCDUCMPWBI7OGDR2NKNHANCNFSM4OPC5XYQ>.

[dmitrizagidulin]

@msporny

So, owl:sameAs specifically does not solve the use case you stated because of the restriction made in your last sentence, right?

Hmm, does seem that way. Maybe need another term. did:sameAs.

[dlongley]

Hmm, does seem that way. Maybe need another term. did:sameAs.

If we find that the semantics are different (between what we want and owl:sameAs), let's not use the term sameAs at all, but something that would help make the semantics more clear. I'm not quite sure what we want -- and it does seem like we have more than one use case, or at least, @dmitrizagidulin has highlighted two different ones.

In the first use case, it seems like we want to be able to say there's an alternate DID that could be used to refer to the same subject. Sort of like "Subject Alternative Name" from X.509. It seems to just be informational and doesn't imply that one DID should be preferred over the other for any reason. Also, the "use case" is described more like a feature than like a use case ... so what's this feature for? Do we need to use the DID Document for it -- or could this be done another way ... and is that other way more appropriate?

In the second case, it seems there's a desire to sort of "decommission" an old DID and move to a new one. Again, the "use case" is described as a feature, but it's a bit more clear to me what a possible use case would be and why this could appear in a DID Document. Let's say that Pat has been using the DID did:example1:1234 to represent themselves on social media. They have built up some relationships using the old DID but now they want to switch to a new DID method "example2". They create a new DID did:example2:4567 but they don't want to have to notify everyone individually about the fact that they are decommissioning their old DID and adopting this new one as a replacement.

So, Pat uses the replacementIdentifier (bikeshed) feature by adding "replacementIdentifier": "did:example2:4567" to the DID Document for did:example1:1234. Now anyone resolving did:example1:1234 can see this information and use it to discover Pat's new DID.

[tplooker]

I would like to see a term that is not constrained to only equating did's, instead one being able to link say a did to a domain name, such as described here https://identity.foundation/specs/did-configuration/

[dmitrizagidulin]

What if we used ActivityPub's alsoKnownAs term? That spec specifically uses it for moving profiles (or linking equivalent ones).

[OR13]

Lets separate the desire to use owl:sameAs and the desire to use other identifiers... this PR is for those who wish to use owl:sameAs with existing semantic reasoners... so we don't need to modify them, here is a list of such reasoners:

https://github.com/semantalytics/awesome-semantic-web#reasoners

• Pellet
• openllet
• FaCT++
• HermiT
• ELK
• Whelk
• OWL-RL
• RacerPro
• Manchester List of Reasoners
• elephant-reasoner
• HyLAR
• ruby-rdf/rdf-reasoner
• cel -A lightweight Description Logic reasoner for large-scale biomedical ontologies.
• reasonable - OWL 2 Reasoner built on DataFrog

If your use case is "I want to not use semantic reasoners but also indicate some kind of equivalence"... you should open another pull request, and explain your use case, and provide vocabulary defintion for it....

[msporny]

This PR is for those who wish to use owl:sameAs with existing semantic reasoners.

Oh, then that makes this PR easy :) -- I would object to any use of owl:sameAs for at least the following two reasons:

• owl:sameAs is a foot gun when combined with cryptography/security... asserting equivalence between any two direct or linked cryptographic identifiers is just asking for a world of pain security vulnerabilities. Introducing this would violate a key lemma in cryptography -- cryptographic identifiers are unique.
• It takes us squarely into non-pragmatic, theoretical, academic ivory tower discussions about semantic reasoning... and we shouldn't waste the community's time with those discussions. Those discussions harmed the adoption of Linked Data for over a decade and many of us don't want to go back into the RDF dark ages.

I find it highly suspect that people are using semantic reasoners in anything other than an academic or experimental system. If people are doing that, I'd strongly advise them to stop playing with fire (owl:sameAs when applied to cryptographic primitives). If they continue to play with that fire, let's let them burn their lab down to the ground and not take the rest of us with it.

[OR13]

@iherman @msporny I was joking with OWL haters comment, but not about needing to document this clearly :)

I am very interested in the overlap between formal logic, reasoning systems and cryptographic proof systems.

Consider the value of a ZKP for owl:sameAs.

that being said, I agree with you both, that with great power comes great responsibility.

[OR13]

@iherman sorry for not responding to this directly.

sameAs: One DID is asserted to be equivalent as another by the DID controller. Importantly, both DIDs are available / resolvable, and either can be used interchangeably (so, for example, if they're being used for an identity-based access control system, authenticating as did A is equivalent to authenticating to the sameAs DID B). Bi-directional references are required for validation.

Thanks for the example. A question: does it mean that the statements of the DID documents become all interchangeable? I.e., let us say the two DID-s are D_1 and D_2, with Doc_1 and Doc_2 as DID documents, respectively. Doc_1 defines, say, a service via the service predicate; are we sure that this service is valid for D_2, too (because that is what owl:sameAs would mean).

yes, I think so... if your intention was for the service to only work with the D_1, you would not use owl:sameAs... You would only use it when you intended for predicates to work for both identifiers, or if you intended to use its presence or absence to construct refined data models, represented in RDF or other systems ...after all, owl:sameAs is just another statement made by a controller.... its interpretation is up to software systems... if one is really worried about dangerous RDF statements, one should perform some kind of input validation on did documents before processing them... just like checking for a script tag in text before saving it to a database.

Another question, but from another point of view. owl:sameAs is, strictly on a fix URI. So if we say D1 owl:sameAs D2, that statement does not have any bearing on the respective DID URLs. I.e., if Doc_1 has a statement on, say, D_1#123, that does not mean that D_1#123 owl:sameAs D_2#123. Is that o.k., or may that be a problem?

^ this is great news, it means that all the DID Document member objects remain separate (services and verification methods), which means that proofs are still tied to a specific URL.... i think this was @msporny @dlongley 's main concern.

[iherman]

Another question, but from another point of view. owl:sameAs is, strictly on a fix URI. So if we say D1 owl:sameAs D2, that statement does not have any bearing on the respective DID URLs. I.e., if Doc_1 has a statement on, say, D_1#123, that does not mean that D_1#123 owl:sameAs D_2#123. Is that o.k., or may that be a problem?

^ this is great news, it means that all the DID Document member objects remain separate (services and verification methods), which means that proofs are still tied to a specific URL.... i think this was @msporny @dlongley 's main concern.

That is fine. Let us not forget, however, that this is a fine point that is not necessarily realized by everyone. (Fundamentally, URL-s are, for better or for worse, completely opaque strings from RDF’s point of view.) By using owl:sameAs false expectations may be raised, and that is a potential problem, too.

[msporny]

^ this is great news, it means that all the DID Document member objects remain separate (services and verification methods), which means that proofs are still tied to a specific URL.... i think this was @msporny @dlongley 's main concern.

Wait... no :) -- I don't think @iherman is saying what you think he's saying... again, it's this subtleties that create the great concern around the use of owl:sameAs.

<D1> authentication <D1#key1> .
<D2> authentication <D2#key2> .
<D1> owl:sameAs <D2> .

The above could result in effectively this graph:

<D_merged> authentication <D_merged#key1> .
<D_merged> authentication <D_merged#key2> .

Thus, a compromise of D1 results in a compromise of D2 (unless we write a TON of new spec text into what you have to do to prevent that from happening).

[iherman]

@msporny correct. What I meant was that if one document says

<D1#key1> whateverterm whatevervalue

this will not mean

<D2#key1> whateverterm whatevervalue

in spite of

<D1> owl:sameAs <D2>

As you say, there are many subtleties that we may not realize at first glance.

[msporny]

<D1#key1> whateverterm whatevervalue

this will not mean

<D2#key1> whateverterm whatevervalue

As you say, there are many subtleties that we may not realize at first glance.

Yes, exactly, and all of these subtitles are the issue with owl:sameAs.

[OR13]

@msporny @iherman

I interpreted it comment correctly, but maybe I didn't clearly communicate why I think thats valuable to define.... consider:

https://w3c-ccg.github.io/security-vocab/#Ed25519VerificationKey2018

parent class = owl:Thing

{
  "id": "did:example:123#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG",
  "type": "Ed25519VerificationKey2018",
  "controller": "did:example:123",
  "publicKeyBase58": "6wvt6gb9mSnTKZnGxNr1yP2RQRZ2aZ1NGp9DkRdCjFft"
}

did:example:123#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG controller did:example:123
did:example:123 sameAs did:example:456

Seems good that:

did:example:123#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG controller did:example:123
did:example:456#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG controller did:example:123

remain distinguishable... don't you agree?

[iherman]

did:example:123#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG controller did:example:123
did:example:456#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG controller did:example:123

Yes, those are distinguishable, ie, an OWL reasoner will not, conceptually, "merge" those two statement. (I leave this to you guys to decide whether that is good or bad:-)

[msporny]

Yes, those are distinguishable, ie, an OWL reasoner will not, conceptually, "merge" those two statement. (I leave this to you guys to decide whether that is good or bad:-)

Sure, but that's not the attack we're concerned about. :)

[OR13]

Yes, those are distinguishable, ie, an OWL reasoner will not, conceptually, "merge" those two statement. (I leave this to you guys to decide whether that is good or bad:-)

Sure, but that's not the attack we're concerned about. :)

@msporny please provide exact triples of the attack you are concerned about.

[msporny]

@msporny please provide exact triples of the attack you are concerned about.

I did in #45 (comment)

[OR13]

@msporny <D_merged> does not exist, thats not an actual example....

DID1 sameAs DID2
<DID1> <https://w3id.org/security#authenticationMethod> <DID1#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<DID2> <https://w3id.org/security#authenticationMethod> <DID2#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .

DID 1

<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6LScqmY9kirLuY22G6CuqBjuMpoqtgWk7bahWjuxFw5xH6G> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#X25519KeyAgreementKey2019> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6LScqmY9kirLuY22G6CuqBjuMpoqtgWk7bahWjuxFw5xH6G> <https://w3id.org/security#controller> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6LScqmY9kirLuY22G6CuqBjuMpoqtgWk7bahWjuxFw5xH6G> <https://w3id.org/security#publicKeyBase58> "2AbNdSuzFSpGvsiSPBfnamcKzk9Q3WRRpY2EToHZEuKW" .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2018> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#controller> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#publicKeyBase58> "dbDmZLTWuEYYZNHFLKLoRkEX4sZykkSLNQLXvMUyMB1" .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#assertionMethod> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#authenticationMethod> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#capabilityDelegationMethod> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#capabilityInvocationMethod> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#keyAgreementMethod> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6LScqmY9kirLuY22G6CuqBjuMpoqtgWk7bahWjuxFw5xH6G> .
<did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> <https://w3id.org/security#publicKey> <did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP#z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP> .

DID 2

<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#EcdsaSecp256k1VerificationKey2019> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#controller> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#publicKeyBase58> "d5cW2R53NHTTkv7EQSYR8YxaKx7MVCcchjmK5EgCNXxo" .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#assertionMethod> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#authenticationMethod> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#capabilityDelegationMethod> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#capabilityInvocationMethod> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .
<did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> <https://w3id.org/security#publicKey> <did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .

[msporny]

@msporny <D_merged> does not exist, thats not an actual example....

Yes, it does. That's what owl:sameAs does in a reasoner, it's pure equivalence:

( a1 , a2 ) ∈ IEXT(I(owl:sameAs)) | iff | a1 = a2

SameIndividual( a1 ... an ) | (aj)I = (ak)I for each 1 ≤ j ≤ n and each 1 ≤ k ≤ n

Also, note what I'm having to link to to even have this discussion... this is why I want to avoid owl:sameAs -- very few people have the sort of math background to even interpret those specs I'm linking to. Even I'm starting to hit my limit... I had to stare at the specs for a good 30 minutes and remind myself of even how to interpret OWL statements:

https://www.w3.org/TR/2012/REC-owl2-direct-semantics-20121211/#Interpretations

It's not straightforward. How many people will be able to even read that section above? This is just really dangerous ground...

[OR13]

is a1 === did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP ?

because a1 != a2 for:

a1 == did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP && a2 == did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX

However, if a reasoner would logically accept the following triple after merging:

<DID1> <https://w3id.org/security#authenticationMethod> <DID2#zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX> .

I still see no problem with this... in an open world, representations of information are not restricted in any manner... anyone can create such a structure, and IF they desired to use OWL, leverage the behavior of OWL reasoners...

The argument against OWL is equivalent to arguing that integrals should be banned because students don't always compute them correctly.

I'm fine with that as long as we make it clear that w3id.org/security is of the opinion that consumers are incapable of comprehending OWL and using it correctly... however, relying on owl:Thing as a base class for Ed25519Verification2018 contradicts this assertion....

Picking and choosing when to allow OWL will lead to more confusion not less.... better not to use it at all, or use it consistently.

Here are some proposals:

PROP 1

Retain OWL in w3id.org/security and define sameAs, and warn about this behavior / feature.

PROP 2

Remove OWL from w3id.org/security entirely, do not include sameAs.

PROP 3

Retain OWL in w3id.org/security and don't define sameAs, wait for someone to shoot themselves in the foot.

I take it you remain in favor of PROP 3.

I would be in favor of PROP 1 and then PROP 2 in that order, PROP 3 is unacceptable to me.

[iherman]

@OR13 @msporny can someone give me a link to the current vocabulary we are talking about? @OR13, I have difficulties to parse your proposals, and I would like to see what we are talking about... Thx

[OR13]

@iherman

A few of the vocabulary terms in https://w3id.org/security that rely on owl:Thing

https://w3c-ccg.github.io/security-vocab/#Ed25519VerificationKey2018
https://w3c-ccg.github.io/security-vocab/#Digest
https://w3c-ccg.github.io/security-vocab/#Bls12381G1Key2020
https://w3c-ccg.github.io/security-vocab/#Key

Consider that DID Core reuses these vocabulary definitions, as evidenced by the N-Quads above... they are generated from the following JSON-LD... https://github.com/transmute-industries/did-key.js/blob/master/packages/ed25519/src/__fixtures__/index.ts#L60

[iherman]

@iherman

A few of the vocabulary terms in https://w3id.org/security that rely on owl:Thing

https://w3c-ccg.github.io/security-vocab/#Ed25519VerificationKey2018
https://w3c-ccg.github.io/security-vocab/#Digest
https://w3c-ccg.github.io/security-vocab/#Bls12381G1Key2020
https://w3c-ccg.github.io/security-vocab/#Key

Thanks. If I understand it right, the only reason you refer to OWL (apart from owl:sameAs) is that you refer to owl:Thing. But that leads to a bunch of questions:

• Why do you need owl:Thing in the first place? What is the statement you want to express with this?
• Is Ed25519VerificationKey2018 indeed a class in the OWL sense (as is suggested in the English text)? Ie, is it a collection of individuals? What are those individuals that are of type Ed25519VerificationKey2018 (this question may simply reflect my limited knowledge)? If it is a class, why don't you use owl:Class (ie, typing the stuff as a class)?
• Why do you use the OWL vocabulary for this in the first place? Why not use rdfs:Resource or, if needed, rdfs:Class?

The third set of questions is probably the most important. While, when looking at JSON-LD from an RDF point of view, the RDF(S) vocabulary is an integral part of the environment, referring to OWL pulls in a sledgehammer. One should not do that unless it is necessary. I do not personally agree with the strong anti-OWL sentiment that is sometimes present among Linked Data people, but it is correct that one should try to stay simple, ie, use RDF(S) only, if possible.

Coming back to your question, I am firmly in PROP 2 above. If a specific vocabulary or applications needs to use complex ontologies and would, therefore, pull in OWL, that is perfectly all right, possible, and justified. But there is no reason to do that from the start by introducing it in the core vocabulary definition.

[OR13]

@iherman thanks for your comments!

I did not make these choices, I am trying to be consistent with the choices made before I joined the WG, I would be fine with PROP 2.

[msporny]

I did not make these choices

The existence of owl:Thing is a copy-paste from over a decade ago... :P

I'm fine w/ it being removed, but not for the reason @OR13 is suggesting. It's perfectly fine to pick and choose which parts of the Linked Data ecosystem to use if it makes sense for your use case. In this case, I think having owl:Thing is fine, but also agree with @iherman that we should use simpler things if we can get away with it, and in this use case, we can.

I would be fine with PROP 2.

+1, let's go with PROP 2.

[OR13]

@msporny what is a more generic base class that we might use, that would not invite folks to keep trying to use OWL?

regarding the assertion that its fine to pick and choose, for your use case.... i totally agree, but this is shared security vocab, and you clearly are not ok with me picking owl:sameAs... and I am not ok with retaining other OWL stuff, especially if its because of a copy paste error from 10 years ago.

Picking and choosing vocabulary that is different than w3id.org/security/v2 will result in non interoperable linked data signatures... maybe those vocabularies would be better documented, more internally consistent, make use of existing ontologies better, instead of defining a new vocabulary.... But I'd rather share a well documented security vocab that I don't 100% love, then go off and create my own version based on my aesthetic preferences....

My hope is that others will feel the same about w3id.org/security eventually and that they will help us keep relying on it for interoperability, as all of the VC Data Model and DID Core Linked Data community already is :) ...

I would say that encouraging picking and choosing in this case, might lead to competing versions of w3id.org/security/v2 that would cripple the interoperability we have for DID Core and VC Data Model... I wrote tests to confirm this a while back here:

https://github.com/decentralized-identity/context/blob/master/use-security-context.js

I was able to get all the Universal Resolver DID Documents to include no undefined properties, by mutating them to use a DIF context which defined all their properties... but in the process, I broke compatibility with W3C DID Core and W3C VC Data Model....

If https://w3id.org/security#assertionMethod changes, the canonical representation of DID Documents and VC Proofs changes... in ways that would probably be breaking for everyone.

All this to say, I take maintenance of the security vocab very seriously, and I see it s a critical dependency for both W3C DID Core and W3C VC Data Model :)

[iherman]

rdfs:Resource is a general base class, essentially like owl:Thing. But if we have something defined as a class, then it seems to be enough that this is of type rdfs:Class.

[msporny]

rdfs:Resource is a general base class, essentially like owl:Thing. But if we have something defined as a class, then it seems to be enough that this is of type rdfs:Class.

What @iherman said.

regarding the assertion that its fine to pick and choose, for your use case.... i totally agree, but this is shared security vocab, and you clearly are not ok with me picking owl:sameAs... and I am not ok with retaining other OWL stuff, especially if its because of a copy paste error from 10 years ago.

That's fine, I said let's do PROP 2 (above), which has us removing owl:sameAs... fine w/ using rdfs:Class as a base class instead of owl:Thing as well. I haven't had a chance to go line-by-line yet... but in general, fine w/ using rdfs:* instead of owl:* -- noting that these statements aren't processed at all and have no bearing on the existing security libraries today. We'd just be doing it to be more formally correct, which is fine (and why it hasn't been a priority until now).

[OR13]

@msporny @iherman awesome, thanks for your patience on this, I will close this PR and open a new one to remove owl and rely on rdfs.

[OR13]

Adopting PROP 2, opened #59 closing this PR.

[OR13]

@TallTed based on your comments here: w3c-ccg/traceability-vocab#152

You might be interested in this thread.

FWIW, we also discussed this issue in did core:

w3c/did-core#348

I personally would have loved to see more support and direction for integrating OWL into JSON-LD / LD Security.

[TallTed]

@OR13 -- Is there a particular piece of this megathread you think I should see?

I've read a chunk, and most of it appears to come down to a misunderstanding of what owl:sameAs means, which is simply that any two IRIs in an owl:sameAs relation identify the same referent, the same entity; in other words, owl:sameAs is a relation of coreference.

I don't know what need there was or is to "integrate OWL into JSON-LD / LD-Security". Neither do I see any barrier to using these things together without such "integration", whatever that might mean in this context.

[OR13]

@TallTed mostly just the background as it may relate to VCs that attempt to assert coreference.

You are right that you can 100% use owl:sameAs without it being included in sec-v2 / v3 or did core.

The main argument was that any presence of owl:sameAs was dangerous in DIDs / VCs... did core ended up using alsoKnownAs from activity streams instead:

https://www.w3.org/ns/did/#properties

Which was considered less dangerous.