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

[brentzundel]

@pepoospina moved from CCG (w3c-ccg/did-spec#182)

[dlongley]

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.

[OR13]

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.

[OR13]

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

[talltree]

I agree with @OR13.

[dlongley]

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

[dmitrizagidulin]

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.

[dmitrizagidulin]

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

[dlongley]

@dmitrizagidulin,

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

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

[kdenhartog]

Let the bikeshedding commence:

I propose

1. synonymDID
2. sharedID
3. sameControllerDID

[OR13]

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

[dmitrizagidulin]

@OR13

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

+1, I was gonna propose sameAs as well.

[dmitrizagidulin]

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

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

[kdenhartog]

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.

[msporny]

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.

[dlongley]

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

[dmitrizagidulin]

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

[talltree]

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.

[agropper]

What does this have to do with Cheap DIDs?

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

[iherman]

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?

[OR13]

Attempts to move this ball forward are under way:

w3c-ccg/security-vocab#45
w3c/did-extensions#80

cc @peacekeeper @talltree @dmitrizagidulin @msporny

[OR13]

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.

[OR13]

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

[peacekeeper]

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.

[peacekeeper]

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.

[msporny]

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)

[iherman]

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.

[iherman]

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.

[dmitrizagidulin]

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.

[rhiaro]

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.

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

[dmitrizagidulin]

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

[OR13]

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.

[rhiaro]

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?

[OR13]

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.

[OR13]

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.

[dmitrizagidulin]

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)

[brentzundel]

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

[OR13]

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

[msporny]

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.

[kdenhartog]

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