Re: Use case: Authenticate using eID

Hi.
eID in EU and personal certificate in KR is almost same.
we also need cross-origin exceptions from current API.

when I think the "bridge" between origin-specific and cross-origin policies,
following bridges can be considered.

- Certificate Trust Chain
if the certificate is valid up to UA's trusted root CA, allow cross-origin
operation with some restrictions

- CORS
currently CORS is for remote resources.
but we also can use CORS policy for our origin specific key issue.

if the key-A has the origin-A,
when user visit origin-B, the origin-A can be listed in the header of
origin-B.

-------

the cross-origin operation can be allowed with Certificate Chain and CORS
combinations.



On Wed, May 8, 2013 at 8:54 PM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

> Arun,
>
> >> 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*
> >
>
> Nick
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World