Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

w3.org

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#101

Post by leaflets2 »

ryukafalz wrote: post #77
cowtools wrote: post #73

Earlier quoted context omitted.

I don't buy this idea that average people can't manage a keypair. Humans already manage secrets in the form of passwords, it's not that much different. In the worst-case scenario in which users defer to some weak/centralized system, how is that categoricially worse than the centralized systems we already have?

> Humans already manage secrets in the form of passwords, it's not that much different. Humans are bad at this which is why we recommend password managers. That said, I do think keypairs are the way forward, I just also think they need either strong integrated software support in whichever device is being used, or strong external hardware support. (Yubikeys are nice because they kind of extend the “key” metaphor that…

> but I wish they shipped with a paired backup key that was provisioned with the same key material

Two identical keys, is less secure, for those who would otherwise have bought many different keys.

If you instead buy two different keys, then, when you lose the first, you can know it's safe to continue using the second one. And you can block the first one, without locking yourself out.

Maybe getting two different keys would be a good idea

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#102

Post by m33k44 »

t_mann wrote: post #10
m33k44 wrote: post #5

This relies on public-key cryptography? If that is the case, then who is responsible for maintaining the private key? If that responsibility is with the user, then what happens if the user loses the private key? Does the user loses the identity as well? Is there a way to recover that?

There'll surely be custodial services if this takes off.

Okay, it is not truly decentralised then.

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#103

Post by freeone3000 »

leaflets2 wrote: post #101
ryukafalz wrote: post #77

Earlier quoted context omitted.

> Humans already manage secrets in the form of passwords, it's not that much different. Humans are bad at this which is why we recommend password managers. That said, I do think keypairs are the way forward, I just also think they need either strong integrated software support in whichever device is being used, or strong external hardware support. (Yubikeys are nice because they kind of extend the “key” metaphor that…

> but I wish they shipped with a paired backup key that was provisioned with the same key material Two identical keys, is less secure, for those who would otherwise have bought many different keys. If you instead buy two different keys, then, when you lose the first, you can know it's safe to continue using the second one. And you can block the first one, without locking yourself out. Maybe getting two different keys…

It is! GitHub suggests this, Gmail requires it. Yubikey has a 2-pack discount that's nearly as cheap as a single key.

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#104

Post by geoah »

alipitch wrote: post #100

Which did method supports rotation? did:key Not Supported did:web ??? Do only Proof-of-work methods (e.g. blockchains) support rotation? did:ion Are there no did method based on keybase like tech? https://www.w3.org/TR/2022/REC-did-core-20220719/#verificati... 9.7 Verification Method Rotation Not all DID methods support verification method rotation. https://github.com/w3c-ccg/did-method-key/blob/f511ed730f7d2... The…

KERI Supports rotation, check it out, it's pretty nice actually https://identity.foundation/keri/did_methods/

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#105

Post by leaflets2 »

echelon wrote: post #56
radicalbyte wrote: post #36

Earlier quoted context omitted.

That's the list of methods; and yes, there is very much a land grab going on right now. No, there's nothing stopping you making your own methods. But will anyone actually use it?

> there is very much a land grab going on right now. Where and how? Edit: I just saw the list. It's very land grabby feeling.

Where is the list?

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#106

Post by kimhd »

gregmac wrote: post #27

So I've just scanned over this stuff, maybe someone can fill in some gaps for me. There's a list of DID methods "in development" [1]. Is this the list of methods, or is there a centralized registry, or are these just "known" methods? If there's a centralized registry -- then this isn't really "decentralized" is it? On top of that there's a land-grab that's already begun for the method names, and isn't that going to k…

That method registry is simply self-service way to register DID methods, so it functions like the latter -- "known" methods.

There's no editorial/curation aspect to this registry; that's out of scope. The requirements are simply basic DID method conformance -- specify how the create/read/update/write methods are implemented, security considerations, and so on.

The land grab concern you mention is real, but would likely not be addressed at this level (again, it would be considered out of scope), but could happen in a different standards group.

Some relevant work includes defining criteria by which to evaluate DID methods -- i.e., does it support update operations (e.g., did:key doesn't), does it rely on a blockchain and if so, is it permissioned, and numerous other factors. Probably the most comprehensive treatment of these are the DID method Rubric [1]

With Verite, our considerations were mostly around no/low cost, interoperable/open source implementations for the open source implementation (although anyone can use any method they like). The ones we're most likely to add open source implementations for next are did:pkh and did:ion.

[1] https://www.w3.org/TR/did-rubric

[2] https://verite.id/verite/patterns/identifier

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#107

Post by ryukafalz »

leaflets2 wrote: post #101
ryukafalz wrote: post #77

Earlier quoted context omitted.

> Humans already manage secrets in the form of passwords, it's not that much different. Humans are bad at this which is why we recommend password managers. That said, I do think keypairs are the way forward, I just also think they need either strong integrated software support in whichever device is being used, or strong external hardware support. (Yubikeys are nice because they kind of extend the “key” metaphor that…

> but I wish they shipped with a paired backup key that was provisioned with the same key material Two identical keys, is less secure, for those who would otherwise have bought many different keys. If you instead buy two different keys, then, when you lose the first, you can know it's safe to continue using the second one. And you can block the first one, without locking yourself out. Maybe getting two different keys…

The trouble with this is that you need the second key present each time you need to enroll it to an account, meaning you can’t stash it in a safe deposit box as a backup. And you have to remember to add it to each and every account or it’s not really functional as a backup.

Yes, two different keys are more secure, but they have some pretty severe usability problems.

Re: Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation

#108

Post by radicalbyte »

jgerrish wrote: post #88
radicalbyte wrote: post #53

Earlier quoted context omitted.

That's exactly the same comparison I've been making regards the W3C VC and DID specifications - we're basically repeating the bad parts of the WS specifications.

Somebody up above mentioned the land grab smell of the DID spec. So what's different this time? gRPC, protobuf and GraphQL are out there vs. SOAP or CORBA? Some new thing about to rev up? Just plain old loss aversion? Lambda? We need a FrontPage or Macromedia ColdFusion for that... I guess that's it, somebody else from the Roblox generation can pick that up.

The difference this time is that there are quite a number of blockchains who are very non-transparently attempting to become rent seekers.

There's a chance for someone to earn $x per ID card or verifiable credential issued; you're essentially becoming a TLD operator only with something 95% of the population of developed countries will use.

Post reply on HN