Re: Final countdown for NPAPI

On 2015-05-03 16:09, Jonathan Kingston wrote:
> I'm just really struggling to see what is missing in native web and what adding new closed web interfaces would bring to the table.

If we limit the scope a bit the native web does not offer a interface to traditional secure payment cards like EMV.  This was one of the things the failed WebCrypto.Next effort was supposed to address: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/

I do not suggest adding closed web interfaces but a standardized browser extension mechanism which can be used for creating proprietary as well as standardized web interfaces.  In contrast to standardization at the browser level,  such extensions can be defined and implemented by essentially anybody.

If this mechanism uses an expanded MessagePorts syntax or not is of no importance; the core is about reaching down in into the native layer where all the goodies are.  And of course do that in a way which doesn't create unresolvable security and/or privacy issues. If you have found such a thing you are EXTREMELY welcome to report it!  If I can verify such findings, I will immediately put the entire quest to rest!

Anyway, You consider this a bad idea.  That's OK.  I'm just saying that the W3C Web Payment initiative may find themselves in a rather awkward position they day the not yet defined WGs begin to take on browser-level payment APIs.

That the Google Wallet unlike most of the other Android software isn't open sourced is not a coincidence...

Anders


>
> On Sun, May 3, 2015 at 1:05 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2015-05-03 11:17, Jonathan Kingston wrote:
>     > I'm not really sure how NPAPI helps with implementing something like Apple pay here though?
>
>     Well, the primary mission with the original posting was showing that the browser vendors are out of touch with the development community.
>
>     NPAPI has indeed nothing to do with Apple Pay since Apple Pay isn't Web-based.  However, if you want to create a Web-based payment system, you should probably use Apple Pay as measuring stick and this requires interfaces that currently are missing.  With the deprecation of NPAPI & friends this suddenly becomes a critical part.
>
>
>
> Yes, I meant how would you implement Apple pay like functionality in those technologies that are now deprecated?
>
>     >  From what I understand is WebCrypto WG is mostly stalled by the TLS specification agreeing on the next crypto for TLS.
>
>     WebCrypto "v1" is almost ready and functional.  It was the continuation (.Next) with support for security hardware that failed:
>     https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html
>
>
> Yup and the result of that thread doesn't suggest they oppose FIDO so long as the patent agreements are in place. Also it was suggested that they are dependent on browser implementation which is happening.
>
>
>     > How is U2F only focusing on "super providers"? There is only one browser implementation that is stable and Yubikey have shown enough demos for anyone to integrate with that.
>     > Mozilla is implementing the same API which will be the production version.
>
>     This is a good question.  U2F is based on SOP (Same Origin Policy) which IMO doesn't scale particularly well since neither the Web nor U2F doesn't support a discovery mechanism.
>
>
> So how is that not possible with something like federated auth and U2F? Adding in a discovery mechanism seems completely out of scope here as lots of mechanisms already exist for site to site communication.
>
>
>     > I feel as if the web doesn't have a native crypto platform as you suggest however comparing that to apps which are designed for set hardware isn't comparable. MessagePorts could be leveraged with the right vendors to create the same sort of experience as Apple Pay however I suspect most are holding out for U2F support which is coming soon.
>
>     I'm rather waiting for a write-up how U2F is supposed to be the virtual credit cards of the future.  I have a feeling that this wasn't really on the "menu"... 
>
>
>     > There was a thread from early 2014 which you were on from the WG chairs which seemed to suggest an interest, again I don't really think it was dropped at all just in that up until very recently there as not been much progress with FIDO.
>     > Besides there are lots of examples of competing specifications, I don't think the W3C is shy about when they get it wrong either.
>     >
>     > How do non standardised apps help anything here?
>
>     I think the Web2Native Bridge presentation describes this pretty well:
>     https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf#page=5
>
>
> As mentioned this just expands MessagePorts which would be possible to be utilised for such a system.
>
>
>     > As mentioned earlier, the interface is setup to talk to these features already it is mostly getting the interest and standardising the API that is the issue here.
>
>     There is no proof whatsoever for such an interest among the browser-vendors which is why I suggest another way forward:
>     https://lists.w3.org/Archives/Public/www-tag/2015Apr/0053.html
>
>
> There is 'I think' no interest because it is a step back in time for the web not forwards. Open standards are improving daily and I have yet to be convinced there is anything you have suggested that is currently not possible using the open web.
> Creating new groups to have a bridge actually is pretty much the same issue as NPAPI has had, that and adoption is only going to be as slow as a native standard that plays nicely.
> If you need a discovery API then suggest it, rather than proposing a whole new realm of the closed web. Also if Google failed with Pepper then it is very unlikely this new group will get any adoption also.
> Also work like the Credential Management API is heading in that direction.
>
>     Anders
>
>     >
>     >
>     >
>     >     This really depends on what your ambition is and who you are targeting.
>     >
>     >     If (for example) you would be targeting the credit-card networks, it is simply put not technically feasible creating anything comparable to Apple Pay for the Web.
>     >
>     >     There was some hope that the WebCrypto.Next effort would address this but this activity failed and it appears that everybody nowadays has left the party.
>     >
>     >     The browser-vendors (and just about everyone else as well) lead by Google have rather fled to the FIDO Alliance and what's cooking there is hard to say since members have to sign NDAs.  Based on their initial deliverable, U2F, it seems that they are focusing on the needs of "SuperProviders", something which I believe is the opposite to what the world in general wants.
>     >
>     >     The W3C staff seem unable dealing with the fact that they lost to FIDO although there's an obvious way to regain the interest: Create technology for a distributed Web which effectively competes with FIDO.  OTOH, this would create considerable tension so I guess it won't happen in the W3C either.
>     >
>     >      From what I can see in the market and also have received privately as actual feedback, the world outside the (somewhat elitist and academic) W3C has no problems with "Apps".
>     >
>     >     Anders
>     > https://lists.w3.org/Archives/Public/www-tag/2015Apr/0053.html
>     >
>     >>
>     >>         Anders
>     >>
>     >>
>     >
>

Received on Sunday, 3 May 2015 14:46:17 UTC