3 ms·

I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I

I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example. And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/ https://remotestorage.io/). Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non-Goals.md https://github.com/portier/portier.github.io/blob/master/Non... At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.

StavrosK 9y ago
Portier basically uses WebFinger and OIDC under the hood, with some UX tweaks to make it easier on users to fall back on email auth. One of the best-case scenarios for Portier is if WebFinger/OIDC were to become widespread and Portier itself somehow obsolete. I am affiliated with the project but have been putting in much less time than I'd like, admittedly.
vertex-four 9y ago
> And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Except that you do - otherwise the user needs to tell every website their email address manually, and every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?". Both of these are dealbreakers for something that is supposed to solve the problem of identity on the web. The bit of Persona that was at all interesting was that it was to be integrated into the browser, Persona would remember identities, and it was a very simple API that didn't involve running a heavy server to handle. You could authenticate against Persona with a handful of lines of javascript and a handful more of PHP, and if the user was already logged in to their identity provider, it was one click to authenticate to a new website. Portier provides absolutely nothing interesting over an OpenID Connect client + fallback auth mechanism - it's a simple broker.
- lewisl9029 9y ago
  > otherwise the user needs to tell every website their email address manually Form autofill for email is available in just about every major browser, which makes this process as almost as seamless as clicking a Facebook sign-in button, when the user would like it to be, but still offers users the option to provide any arbitrary identity from any OpenID Connect provider for each site if they choose. > every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?" I'm not sure how this scenario can ever come about, since Portier is just a dynamic broker for OpenID Connect. Portier itself is only responsible for the "I'm trying to log into example.com" part of the flow, by associating the user's email to a OpenID Connect capable server responsible for performing authentication for that domain. The hypothetical "why is Google asking me to allow access to contoso.com?" part of the flow can only occur if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com", which has nothing to do with whether or not that server is running Portier itself. I feel like there may be some misunderstanding on what role Portier performs in the auth flow. But if not, we'll probably just have to agree to disagree on the assertions that the only interesting part of Persona was that it was integrated into the browser, and that Portier offers nothing interesting over static OpenID Connect providers + fallback. Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me, because it meant users can use any arbitrary identity provider they chose, without the developer having to explicitly implement support for every single one of them, as long as the identity providers spoke a common protocol (Persona Identity Provider for Persona, or OpenID Connect for Portier). And this is exactly the part of Persona that Portier is attempting to replicate, except with an already well-adopted protocol that works well without any explicit browser support.

StavrosK 9y ago

Portier basically uses WebFinger and OIDC under the hood, with some UX tweaks to make it easier on users to fall back on email auth. One of the best-case scenarios for Portier is if WebFinger/OIDC were to become widespread and Portier itself somehow obsolete. I am affiliated with the project but have been putting in much less time than I'd like, admittedly.

vertex-four 9y ago

> And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Except that you do - otherwise the user needs to tell every website their email address manually, and every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?". Both of these are dealbreakers for something that is supposed to solve the problem of identity on the web. The bit of Persona that was at all interesting was that it was to be integrated into the browser, Persona would remember identities, and it was a very simple API that didn't involve running a heavy server to handle. You could authenticate against Persona with a handful of lines of javascript and a handful more of PHP, and if the user was already logged in to their identity provider, it was one click to authenticate to a new website. Portier provides absolutely nothing interesting over an OpenID Connect client + fallback auth mechanism - it's a simple broker.

lewisl9029 9y ago
> otherwise the user needs to tell every website their email address manually Form autofill for email is available in just about every major browser, which makes this process as almost as seamless as clicking a Facebook sign-in button, when the user would like it to be, but still offers users the option to provide any arbitrary identity from any OpenID Connect provider for each site if they choose. > every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?" I'm not sure how this scenario can ever come about, since Portier is just a dynamic broker for OpenID Connect. Portier itself is only responsible for the "I'm trying to log into example.com" part of the flow, by associating the user's email to a OpenID Connect capable server responsible for performing authentication for that domain. The hypothetical "why is Google asking me to allow access to contoso.com?" part of the flow can only occur if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com", which has nothing to do with whether or not that server is running Portier itself. I feel like there may be some misunderstanding on what role Portier performs in the auth flow. But if not, we'll probably just have to agree to disagree on the assertions that the only interesting part of Persona was that it was integrated into the browser, and that Portier offers nothing interesting over static OpenID Connect providers + fallback. Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me, because it meant users can use any arbitrary identity provider they chose, without the developer having to explicitly implement support for every single one of them, as long as the identity providers spoke a common protocol (Persona Identity Provider for Persona, or OpenID Connect for Portier). And this is exactly the part of Persona that Portier is attempting to replicate, except with an already well-adopted protocol that works well without any explicit browser support.