Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Closed
brentzundel opened this issue Sep 23, 2019 · 43 comments
Assignees
Labels
pending close Issue will be closed shortly if no objections

Comments

@brentzundel
Copy link
Member

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

@msporny msporny added the discuss Needs further discussion before a pull request can be created label Oct 1, 2019
@dlongley
Copy link
Contributor

dlongley commented Oct 8, 2019

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
Copy link
Contributor

OR13 commented Feb 18, 2020

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
Copy link
Contributor

OR13 commented Feb 18, 2020

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

@talltree
Copy link
Contributor

I agree with @OR13.

@dlongley
Copy link
Contributor

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

@dmitrizagidulin
Copy link

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
Copy link

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

@dlongley
Copy link
Contributor

dlongley commented Mar 5, 2020

@dmitrizagidulin,

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

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

@kdenhartog
Copy link
Member

Let the bikeshedding commence:

I propose

  1. synonymDID
  2. sharedID
  3. sameControllerDID

@OR13
Copy link
Contributor

OR13 commented Mar 11, 2020

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

@dmitrizagidulin
Copy link

@OR13

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

+1, I was gonna propose sameAs as well.

@dmitrizagidulin
Copy link

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

@ChristopherA
Copy link
Contributor

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.

@iherman iherman added needs special call Needs a special topic call to make progress and removed needs special call Needs a special topic call to make progress labels May 12, 2020
@kdenhartog
Copy link
Member

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
Copy link
Member

msporny commented May 12, 2020

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
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

What does this have to do with Cheap DIDs?

@brentzundel brentzundel added the needs special call Needs a special topic call to make progress label Jun 16, 2020
@iherman
Copy link
Member

iherman commented Jun 16, 2020

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
Copy link
Contributor

OR13 commented Jun 16, 2020

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
Copy link
Member

iherman commented Jun 17, 2020

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
Copy link
Contributor

OR13 commented Jul 2, 2020

Attempts to move this ball forward are under way:

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

cc @peacekeeper @talltree @dmitrizagidulin @msporny

@OR13
Copy link
Contributor

OR13 commented Jul 2, 2020

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
Copy link
Contributor

OR13 commented Jul 2, 2020

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

msporny commented Jul 3, 2020

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
Copy link
Member

iherman commented Jul 3, 2020

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
Copy link
Member

iherman commented Jul 3, 2020

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
Copy link

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
Copy link
Member

rhiaro commented Jul 13, 2020

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
Copy link
Contributor

OR13 commented Jul 13, 2020

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
Copy link

dmitrizagidulin commented Jul 13, 2020

@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
Copy link
Contributor

OR13 commented Jul 13, 2020

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
Copy link
Member

rhiaro commented Jul 13, 2020

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
Copy link
Contributor

OR13 commented Jul 13, 2020

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
Copy link
Contributor

OR13 commented Jul 13, 2020

See also w3c-ccg/security-vocab#45

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.

@dmitrizagidulin
Copy link

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)

@msporny msporny removed the needs special call Needs a special topic call to make progress label Sep 10, 2020
@brentzundel
Copy link
Member Author

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

@OR13
Copy link
Contributor

OR13 commented Oct 8, 2020

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

@msporny
Copy link
Member

msporny commented Nov 1, 2020

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.

@msporny msporny added pending close Issue will be closed shortly if no objections pre-cr-p3 and removed discuss Needs further discussion before a pull request can be created labels Nov 1, 2020
@kdenhartog
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending close Issue will be closed shortly if no objections
Projects
None yet
Development

No branches or pull requests