Hacker News new | ask | show | jobs
by lightgreen 1828 days ago
Unless I miss something, this looks like a solution to nonexistent problem?
6 comments

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.

> 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.

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.
I'm, sadly, old enough to remember this absolutist argument about OAuth.

I'm curious, what's the risk here?

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.

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'.

In my view, it's actually a move toward the PKI/trust layer that we should have implemented at the outset.
It was implemented. Nobody used it.
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.
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.
"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.
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.

See also https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...

The European Commission is thinking about these problems too.

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?

Sorry, I should have clarified. The EU commission is focused on digital identity. I haven't dug deeply, but yes, I suspect that they are not as interested in decentralized identity (as the original link was).

> 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?

Sure, but wouldn't that ubiquity be a game changer?

> 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.

> 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.

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.
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).

The same as the X.501 PKI we've had for decades.
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.
Because all the X.500 standards are terrible designed by commitee things that try to be everything but end up doing nothing specific well.
DID is pretty much the same thing re-packaged in modern buzzwords and encoding.
Not missing anything.