Re: Possible solution for same origin policy problem in Web Certificate API

Hi Sangrae,

On Jul 5, 2013, at 4:02 AM, ���� wrote:

> Hi all,
>  
> I presented draft Web Certificate API in April F2F meeting and there were many questions about
> same origin policy problem in WebCert.
> The following is a possible solution for same origin problem in WebCert to consider.
>  
> PKI operates based on the concept of a circle of trust or trust domain with a Trusted Third Party. When a browser sends a digitally signed document to a web server, the server can verify the signature using a certificate sent from the browser. This can only be possible when two entities trust a CA server that issued the certificate. In this case, if the web server and CA server operates in the same domain, then PKI works fine under same origin policy (SOP). Otherwise it will not work unless cross origin policy (COP) is permitted.
> We can find an example how PKI used in the web environment without SOP. In SSL client authentication, a web server can send a trusted CA list to a web browser to indicate which certificate can be used for client authentication. This means that TLS/SSL protocol works in the absence of same origin policy.
>  
> From this example, I think that the SOP and COP can co-exist in a single web browser as follows.
> The Korean banking use case indicates that a user gets a certificate issued by a CA server and uses it to a bank for digital signature. The URL of two websites, CA server and bank, is totally different. So cross origin policy is strongly required to support for this use case.
> As it is used in SSL case, if a server sends no trusted CA list to a web browser, the same origin policy governs to access to a stored certificate and the key belongs to the origin server.


Can you take a look at https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#browserid-use-of-cryptography-for-identity-protocols and see it if addresses your use case?  I'm wondering whether BrowserID can serve as a role model for cross-origin crypto, using structured clones and cross-origin messaging.

The sample code could be rewritten to exploit structure clonability, although now it makes use of JWT.

-- A*