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

Payment Request API

w3.org

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Payment Request API

#111

Post by AdieuToLogic »

marksomnian wrote: post #59
AdieuToLogic wrote: post #43

Earlier quoted context omitted.

The problem it solves is reducing friction on checkout. One of the problems it creates is increasing the attack vector on an account holder by storing sensitive transaction information locally.

Not necessarily, depending on the method. For example, Apple/Android Pay is stored securely. Raw credit card data may be stored encrypted by the browser and decrypted at runtime or with the OS keychain, although I'm not sure if this is done now or not.

  For example, Apple/Android Pay is stored
  securely.
See this comment[0] for a more detailed description of Apple Pay (and I'm pretty sure Android Pay). In short, account holder information is not stored on client devices. Instead, a server-generated encrypted token usually is.

0 - https://news.ycombinator.com/item?id=15276574

Re: Payment Request API

#112

Post by Rafert »

pfg wrote: post #26
StavrosK wrote: post #18

So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?

The W3C is working on this in the Web Authentication (webauthn) working group.

Link for the curious and/or lazy https://www.w3.org/TR/webauthn/

Re: Payment Request API

#113

Post by jrochkind1 »

AdieuToLogic wrote: post #109
jrochkind1 wrote: post #103

Earlier quoted context omitted.

Like browser auto-fill for CC fields, which is already supported by most browsers?

I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example). Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those…

Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present.

I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?

Re: Payment Request API

#114

Post by jancsika »

colejohnson66 wrote: post #62
jancsika wrote: post #42

Earlier quoted context omitted.

For certain decisions that seems like a false choice. For example, no amount of contribution would have stopped Netflix et al from pushing through EME as a web standard.

As bad as DRM is, EME is a good step towards killing Flash. And because of that, Netflix needs a replacement, and the studios aren’t just going to remove DRM requirements because Netflix says they won’t support DRM. I’m almost certain that if Netflix tried to remove DRM, the studios would balk and pull their content.

That goes against what throwaway284534 was implying.

If everyone is a "peer" and an enormous number of those peers make a succinct, persuasive argument that EME is incompatible with W3C's mission statement of "Web for All" and "Web for Rich Interaction"[1], one would think that would make a difference in the direction the W3C takes.

Instead I'm eating popcorn watching players with deep pockets choose tactics in their battle to control an industry. And that battle is what shapes this web API.

So the claim of, "your peers are listening and they value your feedback," is about as convincing as a hold message from Comcast.

[1] https://www.w3.org/Consortium/mission

Re: Payment Request API

#115

Post by vertex-four »

lewisl9029 wrote: post #104
vertex-four wrote: post #102

Earlier quoted context omitted.

The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given…

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…

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

Re: Payment Request API

#116

Post by Vinnl »

lewisl9029 wrote: post #97
vertex-four wrote: post #88

Earlier quoted context omitted.

Mozilla Persona suffered from the problem that its developers abandoned it shortly after releasing it, rather than making any attempt to get it into browsers. The pop-up dialog wasn't how it was supposed to work, that was a fallback (and apparently a slightly confusing one) - there was supposed to be a little login widget in your address bar that you'd interact with, and it'd be fully integrated into your browser's U…

I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona: https://www.youtube.com/watch?v=3dDGkLHOldw In it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further: Persona had a "…

I wasn't aware of Portier, but that looks excellent - thanks for sharing!

Re: Payment Request API

#117

Post by devrandomguy »

HugoDaniel wrote: post #93
noway421 wrote: post #27

Earlier quoted context omitted.

This became a thing lately: https://developers.google.com/web/updates/2016/04/credential...

chrome only

> It's a standards-track proposal at the W3C...

Gotta start somewhere. Proposals that come with a working prototype probably fare much better than those that are purely theoretical.

Re: Payment Request API

#118

Post by jimktrains2 »

lsaferite wrote: post #95
jimktrains2 wrote: post #32

Earlier quoted context omitted.

I've seen both. When I wrote the post all the docs from the gateways I had access to called then iin with a historical note on bin. I done have access to those docs anymore though.

I don't doubt you, but as an example, the recent notification of BIN/IIN prefix additions for Mastercard uses BIN 19 times and IIN 2 times. https://www.mastercard.us/en-us/issuers/get-support/2-series...

Interesting, maybe I should update that page then.

Re: Payment Request API

#119

Post by lewisl9029 »

vertex-four wrote: post #115
lewisl9029 wrote: post #104

Earlier quoted context omitted.

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…

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

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

Re: Payment Request API

#120

Post by vertex-four »

lewisl9029 wrote: post #119
vertex-four wrote: post #115

Earlier quoted context omitted.

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

> 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 ne…

> if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com"

No, because in this case, Portier is running on contoso.com and the website I'm actually trying to auth to is example.com - from the target server's perspective, contoso.com is the site trying to auth against it.

> Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me

OpenID Connect does this as well.[0] If IDPs don't support it, why would they support Portier?

[0] http://openid.net/specs/openid-connect-discovery-1_0.html

Post reply on HN