Closed brentzundel closed 3 years ago
I think this issue is largely out of scope. If we say anything, it should be some informative text indicating that DID methods may create these sorts of registries and specify that they must be used as part of their DID resolution rules.
https://www.w3.org/TR/did-core/#persistence
Although not included in this version, future versions of this specification might support a DID document equivID property to establish verifiable equivalence relations between DIDs representing the same subject on multiple DID registries.
I suggest tackling this with equivID, and not doing anything else.
I agree with @OR13.
+1 to tackling it with equivID
(but let's please bikeshed that term when we get there).
Discussed on the WG call on Feb 18, 2020. I agree with the above comments, and suggested that this issue can be closed, as aspects of it are already handled in other issues.
@dlongley btw, when can we start bikeshedding the equivID
term? :)
(There's a very real need for something like it.)
@dmitrizagidulin,
btw, when can we start bikeshedding the equivID term? :)
No one is stopping you from doing so whenever you want :)
Let the bikeshedding commence:
I propose
I propose sameAs (https://www.w3.org/TR/owl-ref/#sameAs-def)
@OR13
I propose sameAs (https://www.w3.org/TR/owl-ref/#sameAs-def)
+1, I was gonna propose sameAs
as well.
Although it would be really useful to express an ordering like - this DID is being deprecated, and that one is the new one.
My possible problem is that sameAs is for the same real-world “individual”. However, DIDs are not necessary only for individuals, and don’t always refer to real-world entities.
I'm actually quite in favor of this feature, but I think this property would fit as a perfect example for a property that goes in the extensions registry rather than making this a normative statement in did-core.
Let's not take this on in DID Core 1.0... it can be added as an extension, let's take it there, see if it's broadly adopted, and then we can tackle it in the next WG.
@ChristopherA,
My possible problem is that sameAs is for the same real-world “individual”. However, DIDs are not necessary only for individuals, and don’t always refer to real-world entities.
I think "individual" in the definition here refers to "thing" ... "sameAs" allows one to express that two (or more) identifiers refer to the same thing. An example from the definition of "sameAs" even includes making it clear that two concepts can be linked as the same via "sameAs": "a US soccer team" and a "football team".
So, currently, several things are at issue:
sameAs
).I am not convinced that we should put off sameAs
just because of the complexity issues. We did that in the original drafts of the spec before it went to W3C CCG and have held off since. But the question of establishing synonyms for DIDs across multiple verifiable data registries is now coming up frequently and I think that with broad adoption of DIDs, it will become much more in demand.
In addition, I believe it is vital that this property—whatever we end out calling it—should be defined in DID Core, because it's too important to be an extension.
So we may decide to put it off to a future version of the spec, but that should a very conscious decision—I would propose having a special call to discuss.
What does this have to do with Cheap DIDs?
https://www.w3.org/TR/owl-ref/#sameAs-def is an OWL statement, fairly heavy, and very much RDF related term. Because LD is only one of our alternatives, not clear how this would transfer to simple JSON, CBOR...
How does one use JSON or CBOR to represent the semantic concept of same as?.... there is a reason that OWL is useful.... given JSON and CBOR already make use of the same vocabulary defined in HTML in the spec registries, I see no better option.
How does one use JSON or CBOR to represent the semantic concept of same as?....
To be honest, the only way I see is to rigorously define sameAs ourselves.
An easy way to see definition of owl:sameAs
is as part of the OWL 2 RL Profile; you can look at the first 6 rules in Table 4.
Notes, however, that the definition is simple but the consequences are powerful, and we have to be very clear this is what we want: the rules say that in any relationships around the globe where one entity appears one can use the other one. Are we sure this is what we want here?
Attempts to move this ball forward are under way:
https://github.com/w3c-ccg/security-vocab/pull/45 https://github.com/w3c/did-spec-registries/issues/80
cc @peacekeeper @talltree @dmitrizagidulin @msporny
I left a comment on the PR to security vocab, but I want to restate it here for the group.
RDF statements have no trust / governance model.
DIDs do.
owl:sameAs
in a did document that requires multisig from hardware isolated keys... and owl:sameAs
in did:github
are not the same thing.... one assumes access to private key signing capabilities, the other requires push access to a github repo.
The trust in statements about a did subject IS ALWAYS a subset of trust in the DID Method and in the opsec
of the controller.
Can we trust any of the statements about this subject?
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://docs.element-did.com/contexts/sidetree/sidetree-v0.1.jsonld"
],
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg",
"publicKey": [
{
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"usage": "signing",
"publicKeyJwk": {
"crv": "secp256k1",
"y": "gnUxO29W9_Wglh1aPhQSTaJkv4hJZtfYVEnLP130cLc",
"kid": "636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"x": "qL-z32z8dJycwHgX1th6QTcF9xuveMBrI3Udi4zDQbw",
"kty": "EC"
},
"privateKeyJwk": {
"kty": "EC",
"crv": "secp256k1",
"d": "nw77p9FkUk7iwHABaI5aAD4zVwdXbZhM4Dhewwx0eL8",
"x": "qL-z32z8dJycwHgX1th6QTcF9xuveMBrI3Udi4zDQbw",
"y": "gnUxO29W9_Wglh1aPhQSTaJkv4hJZtfYVEnLP130cLc",
"kid": "636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc"
},
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg"
},
{
"publicKeyHex": "03a8bfb3df6cfc749c9cc07817d6d87a413705f71baf78c06b23751d8b8cc341bc",
"privateKeyHex": "9f0efba7d164524ee2c07001688e5a003e335707576d984ce0385ec30c7478bf",
"type": "EcdsaSecp256k1VerificationKey2019",
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#primary",
"usage": "signing",
"controller": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg"
},
{
"publicKeyHex": "031c7290fca628a3f88e0f959f8a7f61cca3c43423aab722c231b5259d46c5111c",
"privateKeyHex": "d08519c4eb2b2e4939a7d2cc162518c2504ca5c3bb2f535aeade7dfb36046127",
"type": "EcdsaSecp256k1VerificationKey2019",
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#recovery",
"usage": "recovery",
"controller": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg"
},
{
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "kw41Mbj9jVnNDrrQPMEK6iZzG5cjSjkxmr9u2V6igxL",
"privateKeyBase58": "CGBNshpXSvtfLLmqzCciiAFrU31VBfDxMDQZqBcKUwYgmSsuozbroEGZTCZWsns95UKUXFdbxrPicaLWAyZPF2U",
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#xqc3gS1gz1vch7R3RvNebWMjLvBOY-n_14feCYRPsUo",
"usage": "signing",
"controller": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg"
}
],
"capabilityInvocation": [
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#primary",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#recovery",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#xqc3gS1gz1vch7R3RvNebWMjLvBOY-n_14feCYRPsUo"
],
"authentication": [
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#primary",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#recovery",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#xqc3gS1gz1vch7R3RvNebWMjLvBOY-n_14feCYRPsUo"
],
"capabilityDelegation": [
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#primary",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#recovery",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#xqc3gS1gz1vch7R3RvNebWMjLvBOY-n_14feCYRPsUo"
],
"keyAgreement": [
{
"type": "X25519KeyAgreementKey2019",
"publicKeyBase58": "B84BJgNaP8RbkpatC6Q4KhbQbqsM6Y5rpdL24mYCdv4n",
"privateKeyBase58": "4pPYPDt3AUzDHtkiF6sCzXmBfXxjj3FcVWm14JzWVZFz",
"id": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#keyAgreement",
"usage": "signing",
"controller": "did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg"
}
],
"assertionMethod": [
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#636uaQJN8FKYI8vD-xIWEPDCsJzBxZfLxho3vzHT7Oc",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#primary",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#recovery",
"did:elem:ropsten:EiBJJPdo-ONF0jxqt8mZYEj9Z7FbdC87m2xvN0_HAbcoEg#xqc3gS1gz1vch7R3RvNebWMjLvBOY-n_14feCYRPsUo"
]
}
... no... the private keys are public... anyone can add sameAs here... anyone can add anything here... the entire did document cannot be trusted... even if you think you can trust the did method....
Every RDF statement related to DIDs suffers the same fate... if the controller has terrible opsec... the statements cannot be trusted... regardless of how decentralized / secure the did method is.
And before @talltree drops in here with the Trust Over IP pitch (which is very relevant)... nobody (especially not those bitcoin anarchists) is going to agree on governance, but everyone can still agree that the did document above cannot be trusted :)
I agree with the overall proposal to introduce "sameAs" for expressing equivalence.
@iherman:
https://www.w3.org/TR/owl-ref/#sameAs-def is an OWL statement, fairly heavy, and very much RDF related term. Because LD is only one of our alternatives, not clear how this would transfer to simple JSON, CBOR...
@OR13:
How does one use JSON or CBOR to represent the semantic concept of same as?
Don't we already have the same "problem" with id
and type
? We use them in the spec and basically assume that their semantics match those of the corresponding RDF/OWL concepts, even when we have a DID document in plain JSON, plain CBOR, XML, etc.
Let's just do this with "sameAs" too. We describe it in the spec to match the owl:sameAs property, but the meaning will simply be the same even in non-RDF-based representations.
Interestingly, Mastodon uses the property as:alsoKnownAs
for migrating accounts (but I'm still in favor of sameAs
for DIDs).
I'm still in favor of sameAs for DIDs
Unfortunately, we're now having this conversation in two places... see this for why sameAs
leads to concerning security vulnerabilities:
https://github.com/w3c-ccg/security-vocab/pull/45#discussion_r449168235
Don't we already have the same "problem" with
id
andtype
? We use them in the spec and basically assume that their semantics match those of the corresponding RDF/OWL concepts, even when we have a DID document in plain JSON, plain CBOR, XML, etc.
There is a HUGE difference between RDF(S) and OWL in terms of deductive power. The rules to implement an RDF(S) forward chaining reasoner can be put down on a single A4 sheet of paper, whereas, afaik, the full OWL is not even implementable with such a simple reasoning approach. And we only use a tiny fraction of RDF, namely typing and the fact that a resource (in RDF jargon) is identified by a URI.
There is a HUGE difference between RDF(S) and OWL in terms of deductive power. The rules to implement an RDF(S) forward chaining reasoner can be put down on a single A4 sheet of paper, whereas, afaik, the full OWL is not even implementable with such a simple reasoning approach.
I want to be fair in my arguments: there is a profile of OWL, called OWL-RL, that can be implemented via forward chaining rules.
As mentioned on the security vocab PR -- what if we use ActivityPub's alsoKnownAs
term, for this purpose? That spec specifically uses it for profile migration, very similar to our use case.
Interestingly, Mastodon uses the property
as:alsoKnownAs
for migrating accounts (but I'm still in favor ofsameAs
for DIDs).E.g. see tootsuite/mastodon@0f938ff#diff-3a3f1efd0fd25ad768a79fb685938c1d.
Unfortunately alsoKnownAs
is not a property in the ActivityStreams 2.0 or ActivityPub vocabs. Mastodon have glued the as:
prefix onto a bunch of terms that appear in neither spec. So to use this (or an equivalent term) we'd still need to define it somewhere ourselves.
I remain in favor of using owl:sameAs
... would like to actually use semantic reasoners, and don't want to teach them a new term.
@rhiaro
Unfortunately alsoKnownAs is not a property in the ActivityStreams 2.0 or ActivityPub vocabs.
Ah, no problem. I propose we define did:alsoKnownAs
in the did core vocab, or in the Security vocab.
@OR13
I remain in favor of using owl:sameAs... would like to actually use semantic reasoners, and don't want to teach them a new term.
I'd be reluctant to go with owl:sameAs
because that term encourages the merging of the graphs of the two "same" items. Which I think is explicitly not what we want, with DIDs.
who is "we"... I want to be able to reason that did:ethr:0x123 and did:ethr:456 are both the same accredited investor / operator of a darknet website... If you as the did controller don't want to add that to your did document... don't do it :)
My use case is that I want to use OWL without modification with DIDs.
My use case is that I want to use OWL without modification with DIDs.
In that case, wouldn't you just be able to add owl:sameAs
to your DID document without it being defined specifically in the DID spec?
awesome, so we agree that owl:sameAs
is one type of equivalence that exists in the wild today, is documented, and that people want to use.
And then there are other kinds of equivalence which are not documented, which people are proposing... now the hard question... will JSON-LD context make things easy for the people who want to use the documented property, or will we ask every did method that wants to use owl equivalence to use an extension?
Why not register did:sameAs
and define that it's, like owl:sameAs
but specifically doesn't work with semantic reasoners by design, and then us an extension to register it with did documents that don't want to work with semantic reasoners.
See also https://github.com/w3c-ccg/security-vocab/pull/45/#issuecomment-657742313
Trying to get this spec to work with existing semantic reasoners:
If your use case is "I don't want to use OWL".... don't use owl.... We can define multiple type of equivalence... but only one of them will work with the reasoners above.
Status update: There is ongoing work (Aug 25 2020 special topic call on Link Relations, and the subsequent call on Service Endpoints), that will resolve this issue. (Also see #368)
Has this been addressed by #355 such that it can be closed?
I think this thread should be closed, but the same discussion has now restarted here: https://github.com/w3c/did-core/issues/421
Marking this thread as pending close. It has not resulted in a concrete PR and there are other issues, such as #421 that are duplicates.
This has been around 11 days with no objections. Going to close this issue.
@pepoospina moved from CCG (https://github.com/w3c-ccg/did-spec/issues/182)