Re: Use case: Authenticate using eID


>> Get access to government applications that require authentication based on your real identity using your eID card (e.g.: to fill in taxes, retrieve birth certificate, ...). Including the option to sign out.
>> Requirements:
>> * Identify an appropriate key (issued by the government) -> query facility
>> * Export the certificate, including its certificate chain (the website has to validate that the public key was issued by the government)
>> * Use the private key to perform basic cryptographic operations
> Looks like Ryan's already asked the questions I had.  IF the answer is that arbitrary origins that cannot enter into a "code agreement" (caller/callee) drive this use case, then I'm not sure we're working on technology that can cater to this use case.  I do think that a subset of this use case can be achieved with a cross-origin model, which is why I think it may be one of our more compelling use cases (and I'm optimistic we'll have a "flagship" cross-origin use case that illustrates what can be done outside origin-restricted use of this API).
Our initial Use case was indeed 'available to any arbitrary web application (without a specific list of origins that should have access, nor any other element that limits access besides the end-user giving access). During the FtF I had a lot of good and interesting discussions related to this use case with multiple people. Those discussions also uncovered areas that required further investigation to asses the privacy and security impact for those areas. Which started to convince me that this use case may indeed be out of scope for the first version of the API. I still think that it is a compelling and important use-case, but probably one bridge to far for now. I do think that this may change in the near future, because multiple browser based operating systems are popping-up, and they surely need a solution for this.

That being said, we are internally evaluating those two possibilities (list of origins and other elements that limits access besides the end-user giving access), we will also try to setup a  meeting with one of the card-providers to get their opinion about it.

> In general, I'll create a  "documented for posterity" section in the use cases document, provided we make it clear that we're not pursuing a solution to those use cases within our API.
> -- A*



Inventive Designers' Email Disclaimer:

Received on Wednesday, 8 May 2013 11:55:34 UTC