Re: Final countdown for NPAPI

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.

On Sun, May 3, 2015 at 1:05 PM Anders Rundgren <
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
> >>
> >>
> >
>
>