Chrome NPAPI support

[lennehendrickx]

Dear eid team,

A while ago google chrome announced they would drop NPAPI support (https://groups.google.com/forum/#!searchin/eid-applet/npapi/eid-applet/Fo06FXXSFJc/muoLgeXHn58J).

• In April 2015 (Chrome 42) NPAPI support will be disabled by default in Chrome and we will unpublish extensions requiring NPAPI plugins from the Chrome Web Store.
• In September 2015 (Chrome 45) we will remove the override and NPAPI support will be permanently removed from Chrome.

In this post (https://groups.google.com/forum/#!searchin/eid-applet/npapi/eid-applet/Fo06FXXSFJc/muoLgeXHn58J) on the old google code page you suggested that
"We are working on alternative ways to load the eID Applet for web browsers that no longer ship with the NPAPI layer."

What is the current status on this alternative?

Thank you in advance,

Lenne Hendrickx
Cegeka

[ThijsWouters]

Microsoft is also dropping NPAPI support (http://www.techrepublic.com/article/java-gets-browser-eviction-notices-from-spartan-and-chrome-42/).

[fcorneli]

Depending on the (non-)availability of a PPAPI Java plugin, we will enhance the eID services:
* eID Identity Provider: https://www.e-contract.be/eid-idp/
* Digital Signature Service: https://www.e-contract.be/dss/
with an alternative solution for Chrome.

For the moment, we default to what Oracle suggests:
https://java.com/en/download/faq/chrome.xml

[sophiekruijt]

Are there any plans for an alternative comparable with the eId applet that can be self hosted?, (in case it would become a serious problem if Firefox at some point also would decide to drop support)

[fcorneli]

What do you mean by self hosted?

[sophiekruijt]

With self hosted I mean, like right now being able to host the eid-applet on a server without depending on an external connection to e-contract.

[fcorneli]

That's never going to work within a web application context. You always need a trusted third party to validate the eID operation (identification, authentication or signature). You cannot simply trust, let's say a SAML assertion generated by some "self-hosted" eID component.
To quote Juvenal: Quis custodiet ipsos custodes?

The trust model behind the eID card is based on PKI. To reach a trustworthy eID authentication, a lot of crypto things need to be checked. To expect from each web application vendor to implement this entire validation logic is simply unreasonable. From an economic point-of-view it's easier to outsource all this trouble -and believe me, it fucking is- to a third party and to simply trust https://www.e-contract.be, or some SAML signing certificate's fingerprint. Even for my company, being at the center of eID in Belgium, it's hard work to achieve a good and secure solution. If eID and security is not your core business, don't try, it's just way to much work. I've spend +5 years as eID architect at FedICT and +10 years as security consultant to come up with these eID services. You cannot expect to simply replicate all this work 'over night'.

[sophiekruijt]

The reason why I asked this is because the customer I'm doing some work just wants to be able to read out the eID card and told me he didn't wanted to depend on e-contract.be.
Since there isn't much background information available about this whole Belgium system it's pretty hard for me (someone who doesn't live in Belgium and know anything about eID cards) to advice him whether it's reasonable to have that wish.

He prefered the e-id-applet since I had the idea (since I'm running that applet and stuff on my own wildfly application server), that no traffic goes to e-contract.be. At least that's what he told me.
But in case Firefox would also decide to stop to support Java, it might be a bad choice right now to start using the e-id-applet. For me personally I think it wouldn't be a bad thing at all to trust e-contract.be and use the eID-identity provider instead.
But before I can advice him I needed to know some things, and for an outsider (not into security or belgium eID cards) it's hard to get a feeling about what I should advice him. I want to deliver an application that works well (and also in the coming years in case Firefox also would drop support for applets).

[fcorneli]

Using the e-contract.be eID Identity Provider also releases you from all the possible future runtime issues, like browsers dropping Java support, etc. We will take care of all these things within the eID Identity Provider. Of course if your client does not want to use the e-contract.be services, it's up to you to manage this risk.

[ThijsWouters]

I tried the e-contract.be test servers (https://www.e-contract.be/eid-idp-sp/). But I noticed that they all work with an applet.

How will these work when java is no longer supported?

[lennehendrickx]

Frank,

I have tested taxonweb.be using chrome 42 with npapi disabled and I am able to authenticate using eid.

They are using the federal authentication service. Do you know what technical solution they use to avoid the need for npapi?

[fcorneli]

We will extend the eID services at e-contract.be with explicit support for Google Chrome by September 2015, if of course NPAPI will be permanently disabled within Google Chrome.

The Federal Authentication Service is not using Java. However, this is not an option for us, as we need to be able to create signatures within the Digital Signature Service. In the context of authentications, we also need to be able to read out the eID identity files and such.

[fcorneli]

We're also working on a Chrome Extension. We are going to open source our solution of course, just like the eID Applet. If you would like to subscribe for the beta testing of this new solutions, send an email to info@e-contract.be

[fcorneli]

Check out our new eID Chrome project:
https://www.e-contract.be/eid-chrome/eid-chrome.mp4

[CodingPeak]

Hi Fcorneli!

Is that eID Chrome project a Chrome Extension? Is there a more generic way to support more browsers that might in the future drop java support as well?

[fcorneli]

It's a combination of an eID Chrome Middleware and an eID Chrome Extension.
See also: https://www.e-contract.be/eid-chrome/eid-chrome-inline-install.mp4

A generic solutions is difficult to construct as we don't know yet which web browsers will follow the Google track, and what native binding they will provider.