anderslemke
It would be possible to not save the map, and then use some kind of hashing to infer user ids for each site. I chose not to do this, to be able to guarantee no collisions. This might be silly, though. But the thought of people with colliding user ids makes me giddy.
The data stored looks something like this: { "ids": { "example.com": { "07c5c163-875f-424c-a659-a4f99e74eb12": "default" }, "other-example.com": { "ab38b2a6-d560-43d3-b2a3-9148cd91d1b4": "default" } } }
Worth noting is, that there is no personally identifiable information (PII) here.
But we have to have the discussion if this is "too much" data to keep about a user. AFAIK this is the bare minimum of data needed, to be able to guarantee no collisions of user ids. If there is another way to do it, we should do that!
If a site needs to contact the user, it's reasonable to ask for eg. an email. But now the intent of asking for an email has to be crystal clear, which makes you and them more aware of what data you are actually giving them.
Apple sure is doing some good stuff with their authentication solution and their efforts to help people with healthier passwords habits. I'm still not too fond of having such fundamental infrastructure owned by a private company. Would you be comfortable handing over DNS to Apple?
I totally understand what makes IndieAuth is a good solution. And it seems really easy. For me. But I have no idea how I would go about explaining it to, let's say, my mom.
Apple is offering something very similar to what Promise does. The difference is that Apple is a commercial corporation. Which means they're in the game to make money. Promise will be in the game to make authentication easy, secure and private.
In many ways I compare the goal of Promise, with the goal of DNS. Take a commodity and make it available globally in a reliable way. Yes, it will be a single point of failure. So the job of Promise will in large be, to keep the platform secure and reliable.
Just like the DNS can block users, Promise can ban users and relying parties.
This is not something Promise should take lightly, but the fact that almost everyone has a say in Promise, unlike Google, where almost no one has a say, makes me full of hope that this can be solved in a transparent way.
Internet identity could maybe be a layered thing where one layer takes care of authentication, which is where Promise lives. The next layer could handle information like name and email. And finally a layer that handles your verified identity by an authority. That last layer is where the danish NemID fits in.
But most of all, what I'm missing is at least one good option on the sign-in screen. And using a password manager is not it.
It's not exactly a SSO, though.
Only by being pseudonymous can it provide the level of privacy that should be expected from the global authentication infrastructure that Promise wants to be.
What makes OIDC a "non starter"?
I see OIDC as an implementation detail, and have no strong opinions about it.
I hate it, when I type my email and password (correct, that is), and get an error saying "You already have an account. You need to sign in". OK. But would you please just sign me in then. Everything you need is there.
So I chose to make it one. This might be more confusing than anything else... And I might be missing some other point for this to make more sense...
And yes, let's get that widespread adoption
I see it this way, that Promise makes it possible for all its relying parties leverage WebAuthn by implementing it once, so they don't have to.
On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Which then redirects you back to the relying party you want to sign in to. So it is possible to decentralize if that is what you want
On the other hand, I'm not sure it's a good idea to do it. Centralizing gives a lot of benefits. User experienc being one, but also being able to roll out eg. security updates quickly. But sure, centralization also creates problems.
But until now, I have a feeling that the problems with centralization, can be solved by other measures than going decentralized. Eg. being a non-profit organisation owned by the relying parties. This would guard against a lot of the problems with being centralized.
And I'm still to encounter a decentralized solution with a reasonable user experience for most people. OpenID, IndieAuth, SQRL, re:claimID, I'm looking at you. Sorry.
And it works.
It's a bold choice of words, I acknowledge that. And the proof is only as strong as my abilities to write software.
This is yet another reason why Promise needs a movement behind it. To strengthen the proof. To strengthen security.
But how did we end up in this horrible state of authentication? Why don't we have something as easy to use as the DNS, but for authentication?
Imagine what authentication would look like, if we all started running is the same direction, instead of implementing our own authentication again and again. If we had something open source, that would allow you to sign in to all the sites you use, while completely protecting your privacy, so none of them know who you are.
This dream can come true. Technically at least. I've taken the the first baby steps with https://promiseauthentication.org which proves that this is possible.
But, for this to become a reality, we really need to start running in the same direction. A collective movement towards a sane, privacy-first Single Sign-On provider that's easy to use for everybody.