W3C overrules objections by Google, Mozilla to decentralized identifier spec The World Wide Web Consortium (W3C) has rejected Google's and Mozilla's objections to the Decentralized Identifiers (DID) proposal, clearing the way for the DID specification to be published a W3C Recommendation next month. The two tech companies worry that the open-ended nature of the spec will promote chaos through a …
If you're using JavaScript & trust in the same sentance without a "will never earn any" inbetween, you're not paying attention. There is no trust in JS unless the only JS you run is the locally stored, locally vetted, & locally secured code you've written yourself. Everyone else's JS code, especially if stored/run from a 3rd party server, is no longer secure nor trusted.
I know I'm insane, my Dried Frog Pills say as much, but if *I* think using JS is a bad idea, why aren't supposedly saner heads not putting the concept out of it's misery with extreme prejudice?
Money talks - louder than you...
Seriously: How else can you create those bells and whistles which will dazzle the victim while you run off with his wallet? JavaScript is the only random code people routinely download from the internet, and willingly run on their computers hoping for some "awesome" singing/dancing gizmo feature. If you remove this, Web 2.0 is dead and we're back to Web 1.0: Hipsters will drown themselves in their double venti organic, chocolate brownie, caramel frappucchinos.
If Flash for Web could get killed, how long it will take until we get a HTML that can do most things Javascript for Web can and finally kill this abomination?
It was like "Oh this new HTML can play audios and videos and run some simple games" and then... progress stopped.
What the heck happened?
Seems most of the working group belong to companies involved in online identity so I guess they were there to push their own solution and nobody agreed on anything, other than they wanted the browser makers to make it magically work.
And thus defeat is snatched from the jaws of victory and we're still stuck with usernames and passwords or "Log in with Google/Facebook/Apple/etc...".
You're right. There's no way on earth you could change your ISP router or use a 2nd router in bridging mode. It's a good thing that the W3C didn't give any person or business the option to self-host their online identities because that crappy ISP router scenario would make it unworkable for everyone on the planet who tried to do this.
/s
You're absolutely right, nobody in the entire history of the internet ever logged in as user@server.domain.com.
It would be absolutely impossible to query server.domain.com to authenticate user. You could never trust server.domain.com with DANE and you could never trust the user with a certificate instead of a password.
It's utterly unworkable. We must stick with crackable passwords and "Log in with Bigcorp".
Ah, I guess there's no way your crap tin-can-and-string last mile connection can go down when it rains, or when it's sunny, or when it's windy, or when there's a bird sitting on the line, or when there *isn't* a bird sitting on the line, or when the line has been eaten by a random tiger, or because it's a day ending in "y", or....
Right, because your average netizen is going to do just that. Maybe even set up a microtik so they can administer it remotely too! /s
Residential network connections aren't reliable enough to really, really depend on them. Especially if we're talking about public at large. Nobody is going to get two network connections, router beefy enough to be able to handle failover and a cellphone backup! Hardly anybody is replacing their ISP provided routers already.
I recently switched ISPs. The new connection doesn't have an external IP address.
Yes, that's actually true - it's 5G-based, and the IP is in use by a number of different people in the area. It's not possible to have a public-facing server without setting up a VPN through some other company just to get an IP. Not worth it.
That's normal now. IPv4 addresses are too scarce, and IPv6 is such a badly-written fustercluck that it doesn't make matters any better, just more filling and less secure. So residential clients get NAT addresses and work around their disadvantages, which most people don't notice. And residential ISP agreements usually discourage setting up servers anyway; that's what cloud services are for.
I was thinking something similar. Since the developers of Firefox and Chrome objected, and there was resistance from the developers of Safari and Edge, it sounds like the story is that the W3C shot themselves in the foot with this one and (missing my metaphors) the “recommendation” is dead in the water.
Yes, but most authentication these days happens in interactive HTTP user agents – browsers. Browsers refusing to support DID will likely slow adoption. In practice, there will be a thousand DID Javascript libraries in npm by the end of the year, only 998 of which will be either horribly insecure or actively malicious, so we'll be seeing DID support in lots of web apps; but browser resistance will still be a drag on adoption.
I haven't looked at DID closely yet, but it seems fairly stupid on casual inspection. And, of course, we already have technologies deployed for identities that aren't tied to a single vendor and can be decentralized. Those (OpenPGP keys, X.509 in non-hierarchical PKIX arrangements) are also terrible, but they're the terrible we know.
Identity is a hard problem, and "mumble mumble something plus half-assed baby Merkle graphs!" is not likely to be a good solution.
Was just about to post something similar. What happens if Firefox and Chrome, which make up like 95%+ of the browser market -- including Chromium based browsers -- just refuse to support it? And if Apple decides not to add it to Safari in iOS/iPadOS, that probably brings the total up to around 99% of all browser users. It may technically be part of the spec, but no one can do anything with it unless they go out of their way to use a browser that supports it, and everyone else visiting that specific site also goes out of their way to find a supporting browser.
Then either the W3C goes back and addresses the concerns of the browser makers or just accepts that their pet project is stillborn.
What makes it so difficult to give people what they want? Time and time again another spec gets forced down our collective throats. Nobody listens anymore - companies think that they are far too important to actually listen to anyone who knows what they are talking about - from program features to security to ease of use. Especially security.
I was in on this discussion on the W3C mailing list, this summary is fairly accurate. The objection of Mozilla, Google (you forgot Apple, who also made a formal objection), along with bunch of others who waded in, was essentially that the DID people were asking the W3C to rubberstamp a specification which was going to launch with no interoperability. And with 150 odd "schemes", analogous to URL schemes (http, ftp etc) it doesn't look like interop was going to be forthcoming any time soon.
As a technical argument this made a lot of sense to me, and I got the clear impression it comes from the W3C being much less inclined to put its stamp on specifications which are at idea stage than it was 20 years ago. Now, they want testcases, they want interop across vendors, they want practical examples and I agree with all of that. However the DID folk came back and said this should to be approved as a standard first, with schemes to follow. Ultimately it's a judgement call, and this one favoured the DID folk. They had clearly worked hard on it, the objections were just that it needed a bit more first and what was the rush for a publication? But good luck to them I suppose. I hope they make something useful of it. And if it dies on it's arse for being too handwavy, it won't be the first spec that's gone that way.
A parallel side debate was whether the W3C should be approving anything based on proof-of-work. Fortunately what was approved this week has not sanctioned that, but it's a fight we're going to see again in the W3C - some very principled and entrenched positions were on display, and in my opinion some very blinkered ones too. One for another day.
"I'm glad to hear they didn't approve proof-of-work. In this day and age, it shouldn't be on the table."
Maybe I'm missing something, but isn't proof of work as implemented in Bitcoin insanely computationally expensive because the algorithm increases the processing difficulty every time it starts becoming too easy? Is it possible to have a proof of work algorithm where the work proof needed to be done can be done in a reasonable non-planet melting computational time? Or does that then undermine the security?
Yeah, proof-of-work is ice-cap meltingly expensive. The solution is proof-of-stake - Google tells me Etherium is on track to switch later in the year or early next year - and that will reduce the energy cost. And I can't see why you would be designing new systems around proof-of-work.
This post has been deleted by its author
This post has been deleted by its author
This post has been deleted by its author
> …but how does this improve on PGP's web of trust?
It doesn't. The PGP web of trust means you actually trust (albeit indirectly in many cases) the other party.
Because this new system is blockchain driven, you're not actually being asked to trust that someone is who they claim to be, just being asked to accept that they got control over the 'name' they're using first and can prove it via the BC.
Interesting article, Meta may be pleased on the introduction of Web3 by stealth.
However not bad news, the once safe walled gardens of meta are opening the door to the Web3 hell, hopefully Zuk will be a bad memory in the times to come.
For instance a crypto bank based on Metaverse was already hacked, lost 3.8 M USD in ETH.
And things are getting better, is somebody remembers DIEM (formerly Libra and now formerly NOVI)? https://web3isgoinggreat.com/?id=meta-hammers-another-nail-into-the-coffin-of-libra-announcing-the-shutdown-of-their-novi-project
Any serious organisation needs to stay away of the crypto madness, is not just hacking is reputation too.
Not to be that guy but when something approaching half the working group on decentralized identity management appear to be directly and explicitly linked to the Chinese state shouldn't we be asking some fundamental questions about whether working groups are even fit for purpose? Regardless of the technical acumen of the individuals, absolutely no weight whatsoever should be given to the state-sponsored views of state-sponsored actors from overtly authoritarian and illiberal states, and that applies doubly when dealing with a specification inherently linked to user privacy, user tracking and balkanization of the internet by identity provider. What a lunatic state of affairs.
"What Google and Mozilla object to is that the DID method is left undefined not controlled by Google."
I am conflicted on this. On the one had, it seems good that Google, et al, were opposing what appears to be a rabbit hole of a standard. On the other hand, I have no doubt that if this idea had originated at Google and they had some crazy idea of how to use it to push more ads, they'd be smoothing over all the cracks and promising the same exact things that these DID folks are promising.
I'm honestly way over my head technically, but this sounds like yet another Internet disaster in the making. I'm just printing out anything critical on paper and waiting for the inevitable day when the whole mess comes crashing down around us.
Besides, I'm also working on the assumption that, like damn near everything else on-line, this scheme will somehow demand that you have a smartphone to make it work.
Three-factor Authentication! Here we come!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
