4 ms·

This should be v0.1 based on the actual utility of the spec, just because it's been incubated for so long doesn't magically make it useful. DIDs are fundamenta

This should be v0.1 based on the actual utility of the spec, just because it's been incubated for so long doesn't magically make it useful. DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture? All of the suggested "workarounds" to layer on privacy to DIDs are just lip service in the spec, there's zero technical requirements for an implementation. I worry that DIDs based on this spec will be deeply harmful if widely deployed with the multiple layers of abstraction, required dependencies on massively complex things like JSON-LD, and abundance of implementation-time choices. It's such an easy "spec" to embrace and extend by big tech, it has no teeth to prevent tracking abuse and it should develop those as hard normative implementation MUSTs before v1.0 versus the non-normative "Privacy _Considerations_" it has now. Identity is too important to have it done wrong.

naravara 5y ago
> DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture? Functionally, how different would this be from the status quo? Between the FAANGs basically already having near-universal identifiers for all of us and everyone's information being leaked in a variety of breaches to where it's essentially public knowledge to any black hats or state actors I'm not sure how down the downsides are?
- infominer 5y ago
  DIDs make use of public key encryption, which does not require storing private data on a public chain to be useful. All that's needed is a public key directory for public entities, everything else can be verified based on said pubkey of those entities who issue credentials a new identifier (pubkey) can be created for each organization you engage with OPs argument seems based on imagination has nothing to do with how DIDs are meant to work
witweb 5y ago
But what would be the solution? I've already played around with DIDs and Verifiable Credentials in the SSI-context and I like it from a tech perspective. I am also not sure if the spec should be held accountable to potential privacy misuses – the user should be. Additionally, you don't have to use the big tech solutions. The tech is inherently open, just look at the many DID methods. But what I am concerned of are consortium (identity) networks like Sovrin which are run by a hand full of companies. At least in Germany, the government is starting to like what they are doing which is horrible imo. The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have.
- rad_gruchalski 5y ago
  > The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have. It’s the same with gaia-x.
ghoshbishakh 5y ago
Well DID spec doesn't tell us to put identity or related keys in public. DIDs coupled with the VC model (https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/) allows identity credentials issued by any "trusted" issuer to be validated. Here trusted means whoever the user trusts, be it government or big tech or anything else.
- dwaite 5y ago
  The issue is not other identity information in the DID, it is the identifier mandate itself is antithetical to privacy. Having a global identifier as you go about the internet means that parties can correlate and share information about you. Trying to solve that by isolation (using a DID per party you want to interact with) negative affects their usability and privacy properties with verifiable credentials.
  - nine_k 5y ago
    Then there ought to be a way tp cheaply produce verified but ephemeral identities, which may be discarded after a particular transaction. User: I want to use this site. Site: we need your trusted identity. User: Trusted Third Party, please make an anonymous identity for me. TTP: I know you, user; here's your new identity. User: Site, look here, TTP which you trust says I'm legit. Site: OK, transaction completed. ' User: (destroys the identity's private key.) It's not very different from TLS certificates, or OAuth tokens, or even ephemeral credit card numbers. The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
    - gary_0 5y ago
      > The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough. Aye, there's the rub. What's to stop most sites from only allowing Google/Facebook as the Trusted Third Party? And you also need to worry about security breaches, or one company quietly buying up all the independents, or governments legislating in back doors, or every service you use ganging up behind the scenes to try and collate your "anonymous" public keys back into a single identity. Don't get me wrong, I do think there's a way forward, but it's not going to be easy.
tty7 5y ago
DIDs do not specify keys should be written to a public chain, another commented mentioned the VC spec. Another thing to look at is the did:peer method, it allows you to have a direct connection with a party for secure communication. Either party could root their did against a public key (eg a public organisation) but that is not required.
lalchandran 5y ago
The assumption that DID has to be in a public chain is flawed. You should really look at DID use as a mechanism to decentralised the use of certificates. In my mind its definitely not not very different from PKI based certificates or any token based solution like OAuth. The difference is its potential to be decentralised.

naravara 5y ago

> DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture? Functionally, how different would this be from the status quo? Between the FAANGs basically already having near-universal identifiers for all of us and everyone's information being leaked in a variety of breaches to where it's essentially public knowledge to any black hats or state actors I'm not sure how down the downsides are?

infominer 5y ago
DIDs make use of public key encryption, which does not require storing private data on a public chain to be useful. All that's needed is a public key directory for public entities, everything else can be verified based on said pubkey of those entities who issue credentials a new identifier (pubkey) can be created for each organization you engage with OPs argument seems based on imagination has nothing to do with how DIDs are meant to work

witweb 5y ago

But what would be the solution? I've already played around with DIDs and Verifiable Credentials in the SSI-context and I like it from a tech perspective. I am also not sure if the spec should be held accountable to potential privacy misuses – the user should be. Additionally, you don't have to use the big tech solutions. The tech is inherently open, just look at the many DID methods. But what I am concerned of are consortium (identity) networks like Sovrin which are run by a hand full of companies. At least in Germany, the government is starting to like what they are doing which is horrible imo. The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have.

rad_gruchalski 5y ago
> The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have. It’s the same with gaia-x.

ghoshbishakh 5y ago

Well DID spec doesn't tell us to put identity or related keys in public. DIDs coupled with the VC model (https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/) allows identity credentials issued by any "trusted" issuer to be validated. Here trusted means whoever the user trusts, be it government or big tech or anything else.

dwaite 5y ago
The issue is not other identity information in the DID, it is the identifier mandate itself is antithetical to privacy. Having a global identifier as you go about the internet means that parties can correlate and share information about you. Trying to solve that by isolation (using a DID per party you want to interact with) negative affects their usability and privacy properties with verifiable credentials.
- nine_k 5y ago
  Then there ought to be a way tp cheaply produce verified but ephemeral identities, which may be discarded after a particular transaction. User: I want to use this site. Site: we need your trusted identity. User: Trusted Third Party, please make an anonymous identity for me. TTP: I know you, user; here's your new identity. User: Site, look here, TTP which you trust says I'm legit. Site: OK, transaction completed. ' User: (destroys the identity's private key.) It's not very different from TLS certificates, or OAuth tokens, or even ephemeral credit card numbers. The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
  - gary_0 5y ago
    > The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough. Aye, there's the rub. What's to stop most sites from only allowing Google/Facebook as the Trusted Third Party? And you also need to worry about security breaches, or one company quietly buying up all the independents, or governments legislating in back doors, or every service you use ganging up behind the scenes to try and collate your "anonymous" public keys back into a single identity. Don't get me wrong, I do think there's a way forward, but it's not going to be easy.

tty7 5y ago

DIDs do not specify keys should be written to a public chain, another commented mentioned the VC spec. Another thing to look at is the did:peer method, it allows you to have a direct connection with a party for secure communication. Either party could root their did against a public key (eg a public organisation) but that is not required.

lalchandran 5y ago

The assumption that DID has to be in a public chain is flawed. You should really look at DID use as a mechanism to decentralised the use of certificates. In my mind its definitely not not very different from PKI based certificates or any token based solution like OAuth. The difference is its potential to be decentralised.