Cheap DIDs and the option to migrate DIDs between ledgers using standard DID Deprecation Registries about did-core HOT 43 CLOSED

I propose sameAs (https://www.w3.org/TR/owl-ref/#sameAs-def)

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

from did-core.

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?

from did-core.

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.

from did-core.

Has this been addressed by #355 such that it can be closed?

from did-core.

I think this thread should be closed, but the same discussion has now restarted here: #421

from did-core.

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.

from did-core.

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.

from did-core.

I suggest tackling this with equivID, and not doing anything else.

from did-core.

I agree with @OR13.

from did-core.

+1 to tackling it with equivID (but let's please bikeshed that term when we get there).

from did-core.

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.

from did-core.

@dlongley btw, when can we start bikeshedding the equivID term? :)
(There's a very real need for something like it.)

from did-core.

@dmitrizagidulin,

btw, when can we start bikeshedding the equivID term? :)

No one is stopping you from doing so whenever you want :)

from did-core.

Let the bikeshedding commence:

I propose

1. synonymDID
2. sharedID
3. sameControllerDID

from did-core.

@OR13

I propose sameAs (https://www.w3.org/TR/owl-ref/#sameAs-def)

+1, I was gonna propose sameAs as well.

from did-core.

Although it would be really useful to express an ordering like - this DID is being deprecated, and that one is the new one.

from did-core.

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.

from did-core.

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.

from did-core.

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

from did-core.

So, currently, several things are at issue:

1. Should this functionality be supported?
2. Should this functionality be supported in this WG / in DID Core 1.0. (It's this part that is the most controversial.)
3. If it should be supported, which property name do we bikeshed? (Current proposal is: sameAs).

from did-core.

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.

from did-core.

What does this have to do with Cheap DIDs?

from did-core.

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

from did-core.

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.

from did-core.

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?

from did-core.

Attempts to move this ball forward are under way:

w3c-ccg/security-vocab#45
w3c/did-spec-registries#80

cc @peacekeeper @talltree @dmitrizagidulin @msporny

from did-core.

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.

from did-core.

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

from did-core.

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.

from did-core.

Interestingly, Mastodon uses the property as:alsoKnownAs for migrating accounts (but I'm still in favor of sameAs for DIDs).

E.g. see mastodon/mastodon@0f938ff#diff-3a3f1efd0fd25ad768a79fb685938c1d.

from did-core.

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:

w3c-ccg/security-vocab#45 (comment)

from did-core.

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.

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.

from did-core.

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.

from did-core.

Interestingly, Mastodon uses the property as:alsoKnownAs for migrating accounts (but I'm still in favor of sameAs 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.

from did-core.

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.

from did-core.

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

from did-core.

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.

from did-core.

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.

from did-core.

See also w3c-ccg/security-vocab#45

Trying to get this spec to work with existing semantic 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 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.

from did-core.

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)

from did-core.

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.

from did-core.

This has been around 11 days with no objections. Going to close this issue.

from did-core.