[HN Gopher] Decentralized Identifiers (DIDs) v1.0 (W3C draft)
___________________________________________________________________
Decentralized Identifiers (DIDs) v1.0 (W3C draft)
Author : mooreds
Score : 140 points
Date : 2021-06-22 16:04 UTC (6 hours ago)
(HTM) web link (www.w3.org)
(TXT) w3m dump (www.w3.org)
| j-pb wrote:
| So what does this solve that a 128bit random value doesn't?
| sedatk wrote:
| This one starts with "did:" so, distinguishable from other
| random numbers.
| bobthebuilders wrote:
| I think it's really just the fact that it's a standard.
| j-pb wrote:
| Apparently it also has bLoCkcHaIns.
| capableweb wrote:
| Nope, no blockchains _in_ DIDs. But do give reading the
| specification (draft) a try yourself to verify.
| coolspot wrote:
| Not in DID, no, but can refer to DLT which is defined as:
|
| > distributed ledger (DLT) A non-centralized system for
| recording events. These systems establish sufficient
| confidence for participants to rely upon the data
| recorded by others to make operational decisions. They
| typically use distributed databases where different nodes
| use a consensus protocol to confirm the ordering of
| cryptographically signed transactions. The linking of
| digitally signed transactions over time often makes the
| history of the ledger effectively immutable.
| coolspot wrote:
| I assume it is signed by decentralized trusted verifier who
| swears that this rando is older than 21, so you can sell them
| drugs.
| openthc wrote:
| This spec is awesome for us. Much of the cannabis space in USA
| depends on these government systems that require a central
| authority (read: government software) to generate IDs and lot-
| identifiers for items in the system (or they charge $0.40 for
| single-use RFID tags). And those systems are buggy, offline,
| broken, errors, etc, etc, etc.
|
| So, this distributed ID system would permit us to take the
| central generator OUT of the process -- and do so following a
| coming global standard (rather than the current attempts to try
| one-off "unique" methods).
|
| We were already doing something very similar to what is in this
| document -- which is nice, validates some of what we were already
| thinking. And I think it will be easier for us to bring others in
| with some "official" specifications. (I know it's draft only
| right now).
| ska wrote:
| If I recall correctly there is related work getting some
| traction in Canada too, which is on the whole further up the
| curve on some of this stuff due to federal legalization.
| Ken_Adler wrote:
| Especially in British Columbia. The government is way forward
| in implementing "TrustOverIP.org" type DID/VC/ETC systems for
| interacting with the government
| openthc wrote:
| You're both sorta correct; cannibis in Canada is covered by
| Health Canada who's still taking reports via CSV upload.
| It's like a 4k column thing. And no IDs
| ska wrote:
| It's going to be a mix of federal, provincial, maybe even
| municipal government systems (e.g. business licenses for
| cannabis retail). I imagine they'll have a hybrid of
| new-, old-, and low-tech like many other areas. Somehow
| people will muddle through.
| jarym wrote:
| Personally not in favour of using ':' as a separator since
| amongst other things it has to be escaped in HTTP query
| parameters.
| sedatk wrote:
| No, it doesn't? Colon is a special character only in the
| hostname part of a URI to signify the port number. It's free to
| use anywhere else without escaping.
| jeremie wrote:
| 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.
| ghoshbishakh wrote:
| 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/) 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 wrote:
| 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 wrote:
| 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.
| abzfd wrote:
| Where did you get the idea 'global' from? Have you seen
| Peer DIDs? Most specifications advise you to create limited
| purpose identities. Use a widely known one when it suits
| you, like a LinkedIn profile, or Twitter page.
| infominer wrote:
| That's incorrect. DID make use of pubkey cryptography to
| create a new identifier for every entity one operates
| with... this argument is based on imagination
| naravara wrote:
| > 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?
| witweb wrote:
| 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.
| Ken_Adler wrote:
| Generally speaking, In the model of VCs et al espoused by
| TrustOverIP... the user's "Did" is never publically exposed.
|
| The only DID that goes into some sort of Trust Registry is the
| DID of a PUBLIC ISSUER. (eg. GLIEF, Good Health Pass Coalition",
| etc._
|
| For the user's did, it is primarily exchanged off chain, in a
| unique pairwise manner. So the user has a different DID for each
| relationship, and that DID is not publically disclosed anywhere.
|
| Check out the Good Health Pass Interoperability Blueprint for one
| such Governance Framework which will publish by end of month.
| https://wiki.trustoverip.org/download/attachments/76241/GHPC...
| leshokunin wrote:
| Great to see some progress with the standard. We've been working
| on generating DIDs for our upcoming users. We're using IDX +
| Ceramic as our backend.
|
| For our use case (making web3 profiles like
| https://shokunin.dns.xyz), it's cool to have a DID as a chain
| agnostic ID. I'm curious what people here have been using DIDs
| for besides that.
| csense wrote:
| It sounds like you understand enough about DID's to start
| incorporating them into an actual product. You'll have a bunch
| of users, and you want to give each of your users a DID.
|
| Congratulations! I certainly wasn't able to get that level of
| understanding from the document.
|
| In Section 1.1, it says the DID
| "did:example:123456789abcdefghijk" resolves to a DID document.
|
| Would you then be running some software with all your users'
| DID's on some server identified by a subdomain, for example
| identity.dns.xyz? And then the DID for one of your users, let's
| call her Alice, would be
| "did:identity.dns.xyz:123456789abcdefghijk"?
|
| And then if I run a totally different company, and Alice wants
| to use my website, instead of registering a separate account
| with my website, she can instead type
| "did:identity.dns.xyz:123456789abcdefghijk" into my website?
| Does my site's software then contact identity.dns.xyz to ask it
| something? Or is all the information my site needs to do its
| thing contained in the DID itself?
|
| Is "123456789abcdefghijk" the hash of some document that's
| returned to my website by the identity.dns.xyz server? Or is
| Alice running some identity management browser extension that
| knows to present a document whose hash is
| "123456789abcdefghijk" to my website? Or instead of being the
| hash of a document, is "123456789abcdefghijk" the hash of a
| public key which signs something {returned by the
| identity.dns.xyz server | presented by Alice's software}? Or is
| "123456789abcdefghijk" just a string your webserver happened to
| generate to identify Alice uniquely that came from /dev/urandom
| or a PRIMARY KEY column in your database that has no
| cryptographic meaning?
|
| If Alice's DID document is cryptographically linked to her DID,
| how does she update it? If the DID is the hash of the document,
| does that mean Alice gets a new DID whenever she edits her
| profile on dns.xyz?
|
| What if Alice updates her dns.xyz profile because she
| accidentally pasted an Ethereum private key into a forum post,
| then generated a new address that wasn't compromised? How does
| my website know that the user presenting Alice's DID document
| is Alice sending her most up-to-date DID document, rather than
| Eve sending an outdated DID document with the compromised
| Ethereum address that once belonged to Alice, in an attempt to
| get my website to interact or send stuff to the compromised
| Ethereum address?
|
| Is a DID like a generalized Bitcoin address, a generalized IPNS
| name, a generalized email address, or something else entirely?
| cel wrote:
| Great questions, csense.
|
| It is preferable that users bring their own DIDs, rather than
| you assigning them DIDs as a service provider, to ensure user
| autonomy. However, you can create DIDs via websites as you
| are suggesting, using did:web [1].
|
| DIDs are structured or namespaced by DID Methods: the part
| after "did:" is called the DID Method name, and each Method
| has its own specification and implementations. There is a
| registry of DID Methods [2], although it is not a requirement
| that DID methods be registered. There is a document comparing
| some DID methods using a Rubric: [3].
|
| > [...] instead of registering a separate account with my
| website, she can instead type
| "did:identity.dns.xyz:123456789abcdefghijk" into my website?
|
| It can obviate account registration per website, yes.
|
| For usability reasons it is often considered desirable that
| users not have to know about DIDs, type them or see them. The
| functionality could instead be handled by the user's
| software. There is a browser standard and polyfill in
| development which can be used for this: Credential Handler
| API [4].
|
| > Does my site's software then contact identity.dns.xyz to
| ask it something? Or is all the information my site needs to
| do its thing contained in the DID itself?
|
| If you have "did:identity.dns.xyz:...", it would depend on
| what the "identity.dns.xyz" DID method is. If you don't know
| what the "identity.dns.xyz" DID method is, you could ask a
| DID resolver that you trust; but they might not know either.
| If instead you had "did:web:identity.dns.xyz:...", you would
| indeed contact `identity.dns.xyz` over HTTPS to request the
| respective DID document. If you instead have a "did:key:..."
| DID [5], you would indeed have all the information contained
| in the DID itself, as did:key encodes the public key. In
| other kinds of DID methods, you may need to contact a peer-
| to-peer network to resolve the DID.
|
| > Is "123456789abcdefghijk" the hash of some document that's
| returned to my website by the identity.dns.xyz server?
|
| It depends on the DID method. If you are using did:web, which
| is based on HTTPS as mentioned, there is no hash, although
| this could be handled using hashlinks [6], which is mentioned
| in the did:web specification as a TODO. In other DID methods,
| the method-specific-id (the "123456789abcdefghijk" part) is a
| hash which might refer to some static data or initialization
| state.
|
| > Or is Alice running some identity management browser
| extension that knows to present a document whose hash is
| "123456789abcdefghijk" to my website?
|
| Possibly, depending on the DID method and how it is
| implemented. But DIDs are generally expected to be public,
| globally resolvable, and highly available.
|
| > [...] is "123456789abcdefghijk" the hash of a public key
| which signs something
|
| Could be, again depending on the DID method. Some DID methods
| are based on decentralized ledger technologies where the
| method-specific-id represents an account id derived from
| public key hash, e.g. did:ethr [7] and did:tz [8].
|
| > [...] {returned by the identity.dns.xyz server | presented
| by Alice's software}?
|
| Yes, if you are authenticating the user with a DID, generally
| you would ask them to sign a challenge using authentication
| key material from their DID document. The DID document is
| what the DID resolves to, and it includes public keys. In the
| case of did:key, the DID document contains a single key as
| encoded in the DID. In the case of a DID method based on a
| public key hash, the public key must be provided or looked up
| somehow, or the signing algorithm must support public key
| recovery [9].
|
| > Or is "123456789abcdefghijk" just a string your webserver
| happened to generate to identify Alice uniquely that came
| from /dev/urandom or a PRIMARY KEY column in your database
| that has no cryptographic meaning?
|
| The DID method determines the structure and meaning of the
| method-specific-id (the "123456789abcdefghijk" part). If you
| are using did:web, the string is not cryptographic but
| corresponds to a HTTPS URL.
|
| > If Alice's DID document is cryptographically linked to her
| DID, how does she update it?
|
| She performs a DID document update operation [10]. If the DID
| method is based on a decentralized ledger technology (e.g.
| btcr [11], ethr, tz), she might publish a transaction to the
| corresponding network or make a call on a "smart contract".
| in the case of a did:key, the DID document cannot be updated.
|
| > If the DID is the hash of the document, does that mean
| Alice gets a new DID whenever she edits her profile on
| dns.xyz?
|
| If the DID method is static (basing the DID on the document
| hash entirely), it would probably have to be a new DID, but
| if it is only an initial document hash, the DID method could
| provide for verifying and applying updates somehow. There are
| also some properties for indicating equivalence between DIDs
| which might be useful [12].
|
| A DID document could also be updated while still using hashes
| for integrity protection and referencing if the DID method
| uses the hash as the DID document version ID. A DID can be
| resolved at a given version ID using the versionId parameter
| [13].
|
| For privacy, generally DID documents should not include
| personal data [14]. Edits to a profile on would then only
| affect DID documents if they are updating keypairs, or
| indicating relationships with other DIDs (e.g. using
| alsoKnownAs), or updating service endpoints, etc.
|
| For decentralization and user autonomy, users should be able
| to update their DID documents with their software directly,
| rather than having a website in control of their DID and
| having to ask the website to update it. In the web context
| that may mean a browser extension or key management API. But
| there are institutional use cases where the website is
| expected to have control.
|
| > How does my website know that the user presenting Alice's
| DID document is Alice sending her most up-to-date DID
| document, rather than Eve sending an outdated DID document
| with the compromised Ethereum address that once belonged to
| Alice [...]
|
| Often DIDs are resolved publicly or by contacting a network
| rather than via asking the user (did:peer [15] is a different
| case). But the concern still applies. Updating a DID document
| to remove a compromised key is called revocation [16]. The
| DID method should have some protocol for how updates are
| performed, which may include how they are ordered, such as by
| being witnessed or confirmed by some entity or network. The
| question of the valid state of a DID document should be
| abstracted by your DID resolver [17].
|
| > Is a DID like a generalized Bitcoin address, a generalized
| IPNS name, a generalized email address, or something else
| entirely?
|
| More like a generalized Bitcoin address I think, although
| there are comparisons to be made with the others. Another
| idea: generalized PGP keys. It is primarily about identity,
| rather than about communication, storage or payments.
|
| For more info I recommend checking out the Decentralized
| Identity Foundation (DIF)'s FAQ: "What is a DID?" [18].
|
| [1] https://w3c-ccg.github.io/did-method-web/
|
| [2] https://www.w3.org/TR/did-spec-registries/
|
| [3] https://w3c.github.io/did-rubric/
|
| [4] https://w3c-ccg.github.io/credential-handler-api/
|
| [5] https://w3c-ccg.github.io/did-method-key/
|
| [6] https://datatracker.ietf.org/doc/html/draft-sporny-
| hashlink
|
| [7] https://github.com/decentralized-identity/ethr-did-
| resolver/...
|
| [8] https://did-tezos.spruceid.com/
|
| [9] https://crypto.stackexchange.com/questions/18105/how-
| does-re...
|
| [10] https://www.w3.org/TR/did-core/#method-operations
|
| [11] https://w3c-ccg.github.io/didm-btcr/
|
| [12] https://www.w3.org/TR/did-core/#equivalence-properties
|
| [13] https://www.w3.org/TR/did-core/#did-parameters
|
| [14] https://www.w3.org/TR/did-core/#keep-personal-data-
| private
|
| [15] https://identity.foundation/peer-did-method-spec/
|
| [16] https://www.w3.org/TR/did-core/#verification-method-
| revocati...
|
| [17] https://www.w3.org/TR/did-core/#dfn-did-resolvers
|
| [18] https://identity.foundation/faq/#what-is-a-did
| leshokunin wrote:
| Thanks so much for taking the time to write a detailed
| answer. I was going to do this after work, but you've
| completely outdone what I would have said.
|
| What project are you working on?
| bumblefudge wrote:
| this man is a god. not just a did-god, but an actual god.
| cel wrote:
| You're too kind.
|
| Top contributors to DID Core can be seen on GitHub:
| https://github.com/w3c/did-core/graphs/contributors
| hanniabu wrote:
| Idk, maybe it's just because I've already gotten used to ENS
| addresses, but I'd rather not have something that works become
| fragmented because w3 who's been asleep at the wheel on this
| feels left out and wants to remain relevant.
|
| How would DNS work with this? If it's chain agnostic then it
| doesn't seem possible to register names like you can now with
| them on Ethereum.
| witweb wrote:
| DIDs are not meant to compete with ENS addresses. They solve
| different problems.
| lightgreen wrote:
| Unless I miss something, this looks like a solution to
| nonexistent problem?
| mooreds wrote:
| See also
| https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
|
| The European Commission is thinking about these problems too.
| 7steps2much wrote:
| Correct me if I am wrong, but most of these services, such as
| the electronic signature, the electronic seals and the
| document exchange functionality outlined on that website are
| all dependent on a central authority are they not?
|
| Your signature certificate is issued by your government (or
| an organisation working for said government). The seals are
| created with certificates that are, once again, created by a
| central authority.
|
| The document exchange is really just a fancy way to store
| files on your device and send them.
|
| As far as I can tell none of this is decentralised? I don't
| really see why they would want to decentralise it either,
| your digital identity as a citizen only exists because a
| central authority, a nation in this case, validated you to be
| a citizen ...
|
| As mentioned, correct me if I am wrong, but as far as I can
| see all of these EU plans are basically just giving each EU
| citizen a cert that is issued by their government and some
| nice applications that build around those certs?
| ska wrote:
| > Unless I miss something, this looks like a solution to
| nonexistent problem?
|
| The generalizable answer to this is that almost always if some
| group of people has spent a good chunk of effort but you don't
| "get it", you have missed something.
|
| The less you know about the domain, the larger and more diverse
| the group and the bigger the effort, the more likely this is to
| be true.
|
| Of course there are exceptions, but they are rare.
| WoodenChair wrote:
| > The general answer to this is that almost always if some
| group of people has spent a good chunk of effort but you
| don't "get it", you have missed something.
|
| Sure, but that doesn't mean that the group of people has
| cogently explained their work for their target audience. In
| this case, the target audience would be developers, whom it
| seems from the comments are confused.
| ska wrote:
| That's true, but I think it's a different problem. It's not
| clear that a spec should be expected to contain all the
| context needed.
| nerdponx wrote:
| _Specifically, while other parties might be used to help enable
| the discovery of information related to a DID, the design
| enables the controller of a DID to prove control over it
| without requiring permission from any other party._
|
| Sounds like a PGP replacement in some ways.
|
| Also possibly an alternative to SSN (for Americans).
| dboreham wrote:
| The same as the X.501 PKI we've had for decades.
| nerdponx wrote:
| Good point. How much do the X.501 and DID use cases
| overlap? I always wondered why X.501 wasn't used for more
| things.
| bawolff wrote:
| Because all the X.500 standards are terrible designed by
| commitee things that try to be everything but end up
| doing nothing specific well.
| dboreham wrote:
| DID is pretty much the same thing re-packaged in modern
| buzzwords and encoding.
| Communitivity wrote:
| Another area where this will be needed is digital identifiers
| for digitally owned and transferrable objects in AR/VR. The DID
| family of specs is designed to help make this a reality.
|
| Full disclosure: I worked on the XDI and XRI specifications
| that paved the way for DID, and also very slightly on the DID
| specs (contributing thoughts and inputs, I did not author any
| part of the DID specs).
|
| It's a good set of specs, written by people that know identity
| and have a good vision.
| smoldesu wrote:
| That's probably what someone would have said if they saw
| Facebook 20 years ago.
|
| The intention here is to get out in front of FAANG before they
| can make their own, proprietary standards for ID. As terrifying
| as it is, personal identification is going to become a huge
| part of the next 10 years of computing, and potentially
| radically change the way we interact with the web.
| bawolff wrote:
| > That's probably what someone would have said if they saw
| Facebook 20 years ago.
|
| This is just a variation on the URN idea afaict. RFC2141 is
| more than 20 years old. There's been plenty of time to get
| out in front of fb, et al.
| refulgentis wrote:
| I'm, sadly, old enough to remember this absolutist argument
| about OAuth.
|
| I'm curious, what's the risk here?
| uberdru wrote:
| In my view, it's actually a move toward the PKI/trust layer
| that we should have implemented at the outset.
| dboreham wrote:
| It was implemented. Nobody used it.
| uberdru wrote:
| I'd put it slightly differently. The infrastructure went
| part of the way. It needed several more iterations. The
| UX, as you point out, never went anywhere. At least now
| people are getting comfortable with the idea of using a
| private key, even if no one has yet cracked the problem
| of crypto UX.
| dboreham wrote:
| When I say it was implemented, I mean at Netscape around
| 1999 we had projects with banks where they issued smart
| cards, used with USB readers, that facilitated SSL client
| cert auth. Similar to today's FIDO2/U2F. I don't know why
| these schemes were never widely adopted but it wasn't
| because the implementation was lacking.
| [deleted]
| smoldesu wrote:
| "The risk" is a weird, ambiguous ghost in the machine.
| Maybe it's a result of digital paranoia setting in over the
| past decade, or maybe it's our response to digital rights
| abuse. In any case, it's always a good thing when mission-
| critical infrastructure is democratized like this.
| _jal wrote:
| If FB or some other big actor were to define identity
| standards, the standards would at least be friendly towards
| their operations, if not optimized for it.
|
| Risks would include, privacy concerns, from obvious to not
| yet identified; the standards not being good at things
| other interested parties may like; mechanisms that
| encourage/require normal users to delegate some functions
| to private third parties; mechanisms that make it hard for
| normal users to use their identities as they choose;
| mechanisms that place more burdens on the user for retail
| fraud ("identity theft", for instance); the list goes on.
|
| For more, consider the ways that ID is used against people
| today. Now apply automation and a world-wide attack
| surface, and do not consider mitigations that might have an
| effect on some big actor's bottom line.
| dwaite wrote:
| The basis for identity is that the receiving party has to
| make a decision based on some sort of trust relationship.
|
| Everything really winds up being direct, indirect, or
| brokered, eg. : - direct: you have a pre-existing account
| on a website. - indirect: you have an account with a
| Company, and I let that company's employees sign in with
| SAML etc - brokered: certificate authorities issuing
| certs based on domain/email/etc validation, and I accept
| those certs by accepting those authorities
|
| We won't see the indirect model get any broader than it
| already has - nobody is going to accept Sign in with
| Apple in lieu of a birth certificate.
|
| What we _do_ see is the platforms (like iOS and Android)
| becoming wallets for identities issued by _others_ based
| on the indirect and brokered models. Adding mobile
| drivers licenses is upcoming for both mobile platforms.
|
| but the reality is that for indirect/brokered, you have
| an issuer and you have parties who have made a decision
| to trust the identity. If Apple/Google mandate properties
| the issuers don't like, the issuers won't use it. If the
| issuers mandate behavior the verifiers don't like, they
| won't accept it.
|
| And thats the same for any "user-centric" or "self-
| sovereign" identity system too. If bringing my own DID
| means that the issuer can't meet their identity
| verification/authentication mandates, they won't support
| it. If me using my own wallet means that a retailer is
| not getting identity assurance or is otherwise taking on
| additional risk, they won't accept it.
|
| And obviously the people who do not like the overall
| properties will choose not to consume it.
|
| What you imply is some nefarious function of big actor
| desires being baked into standards, I would just call
| 'understanding market requirements'.
| [deleted]
| jchrisa wrote:
| The distinctive capability is offline auth. I guess we are
| still holding out that eventually it will get easy enough to
| write offline (aka p2p, user-agent only, interconnected apps)
| that having an auth standard becomes an accelerator.
| dboreham wrote:
| Not missing anything.
| jFriedensreich wrote:
| its really hard for me to understand this document, it would be
| nice to have a section with better examples and relationship to
| things that are more widely known. how does this relate to http
| and similar protocols to get the documents, how is it related to
| foaf+ssl and webid. how is the cryptography part really done and
| what is the relationship to pgp. i know all these things are
| completely different but i could not explain in what way...
| uberdru wrote:
| You should have a look at this doc: https://w3c.github.io/did-
| spec-registries/#did-methods
|
| Lots of concrete examples of how DIDs are being implemented.
| Ceramic is particularly interesting and advanced in their
| thinking.
| jFriedensreich wrote:
| and regarding ceramic : i tried finding out what the heck
| that was and had the same amount of luck as with did. is this
| written for a different species of developers? they seem to
| try solving the same problems of ipfs pubsub and ipns but
| without any hint how they solved it.
| jFriedensreich wrote:
| that explains a lot but also how would this even work? every
| solution that relies on generic did s would have to implement
| all supported methods? or is every method an incompatible
| namespace in which case what is even the point of did? i
| really don't get it...
| dwaite wrote:
| TL;DR it remains to be seen if DIDs create more problems
| than they solve.
|
| I think you got it correctly. "DID" is basically a
| qualifier for identifiers which can have metadata resolved
| about them using 'some mechanism', and there are 100+
| mechanisms (DID methods). These all have varying technical
| and non-technical differentiating factors, partially
| described in the DID Rubrick https://w3c.github.io/did-
| rubric/ .
|
| DID methods will not have consistent features nor will the
| metadata resolved by them consistently meet your data
| requirements, so you will be limited both in terms of
| methods you can accept for your use case, and DIDs you can
| accept within that.
|
| One if the base ideas is that it puts users in control of
| their identity by "owning" a DID, presumably with a lot of
| local software assistance. This is likely not a single DID,
| both for interoperability and privacy reasons.
|
| It is also likely the DID will be "controlled" by others in
| some cases - e.g. if a employer or bank accepts DIDs as an
| authentication system, they will want to be able to
| guarantee the authentication meets their
| standards/regulatory requirements.
| mikhael28 wrote:
| Why has this come back up again, this month? DiD's are not very
| useful right now, and self sovereign identity has not even
| figured out data backups.
___________________________________________________________________
(page generated 2021-06-22 23:00 UTC)