Re: Use case: Authenticate using eID

Ryan.

could you recommend me cross-origin solutions for the use cases (eID or
Korean Banking)?


On Thu, May 9, 2013 at 11:17 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On May 8, 2013 6:55 PM, "Mountie Lee" <mountie@paygate.net> wrote:
> >
> > Hi. Ryan.
> > I understand the risk with CORS.
> > my previous example of CORS was incorrect.
> >
> > also we can think CORS vice versa.
> >
> > If the Key-A has the origin "good.com",
> > then when the user visits "good.com", "good.com" allow Key-A can be
> shared with "company.com" with CORS header.
> > then "good.com" still has control for Key-A and "company.com" will
> share it.
>
> That is not how CORS works.
>
> >
> > CORS stands for Cross-Origin-Resource-Sharing.
> >
> > it is not just for remote resources, but for just resources.
> > local resources like cryptography keys can be in scope of CORS.
>
> That is not correct. Please read the spec again.
>
> Again, "resources" are a particular term of art in the web, and are not
> what you describe. This is very clear when you look at how CORS works, by
> setting *request* headers on outgoing responses.
>
> >
> > our cryptography Key's origin control is also URL based.
>
> This is also incorrect on many levels.
> - Origin != URL
> - We do not discover keys as URLs.
> - you do not access the API by making HTTP requests to a remote server.
>
> I'm sorry that you're having trouble understanding CORS, but it is not the
> mechanism relevant to this discussion.
>
> >
> > regards
> > mountie
> >
> >
> >
> > On Thu, May 9, 2013 at 10:06 AM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> On Wed, May 8, 2013 at 5:49 PM, Mountie Lee <mountie@paygate.net>
> wrote:
> >> > 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
> >>
> >> As several browser vendors explained during the F2F, this has no
> >> meaning - from a sense of interoperability and because of the general
> >> issue.
> >>
> >> Having a certificate chain up to a "trusted" CA (for which "trusted"
> >> differs for every UA) does nothing to assert that the site is not
> >> "evil". I can go get a DV cert from any CA and use that to host
> >> malware. I could also be a "legitimate" business interested in
> >> super-cookies by tracking your ID.
> >>
> >> It's equally grossly insufficient to say that the root of the server's
> >> certificate chain should or could be equal to the root of the client's
> >> certificate chain (as was proposed previously). When you consider
> >> national schemes like the bridge PKI, and you realize that a variety
> >> of commercial CAs also cross-sign national ID schemes for purposes of
> >> interoperability (again, whether server or client certs), it's not at
> >> all uncommon to see the 'blurring' of these domains.
> >>
> >> >
> >> > - 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.
> >>
> >> This will not work. Simply fill in the blanks for the origins to see
> why:
> >>
> >> If the Key-A has the origin "good.com", then when the user visits
> >> "attacker.com", the "good.com" key can be listed in the header of
> >> "attacker.com".
> >>
> >> Such a solution exposes Key-A to "attacker.com". This is insufficient.
> >>
> >> CORS is about URL requests (not strictly XHR, but certainly for
> >> *resources* accessed via uniform resource locators). It's not about
> >> securing or protecting native Javascript objects. Please do not
> >> confuse them.
> >>
> >> >
> >> > -------
> >> >
> >> > the cross-origin operation can be allowed with Certificate Chain and
> CORS
> >> > combinations.
> >
> >
> >
> >
> > --
> > 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
> >
>
>


-- 
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