multiple origin key (by KM)

[vgalindo]

Section 4: Secure transaction and secure credential storage APIs Text: The Community Group is in parallel also working on the definition of a mechanism to allow an entity to use some keys generated by another entity, but this requires the definition of a new type of data, associated with a specific key, and this is for future deliverable. Note : all use cases are envisaged with a pre-existing key set. Comment: This contradicts earlier text where we were going to define APIs to enable use of keys issued by other entities.

[sbahloul]

May I kindly ask where you see the corresponding text ? We specifically add a sentence in the Problem Statement to notice that "Extensions will be added later to authorize various origins to use and manage a particular key."

[Ketan2016]

2nd and 3rd paragraph of Section 2, Problem Statement leads me to believe that this document will be addressing the identified limitation of Single Origin Policy.

"For example, Suppose that a domain foo.com issues a key. Because the key is not accessible by JavaScript API from another domain, we have to design a secure system where the domain bar.com is allowed to use this key."

[cyberphone]

@sbahloul @Ketan2016 Yes, this text is unclear. It also seems risky claiming that a future revision will address this limitation (which BTW is not called Single but Same Origin Policy). A future revision may address this issue since we currently have no idea how that would be achieved.

[sbahloul]

To be clearer, I propose the following rework of the corresponding paragraphs. Did you agree with it ?

[sbahloul]

The management of keys is associated with the problem of key usage. On the open web platform, the security principle that prevails everywhere is the Same Origin Policy. The corresponding mapping regarding keys would be that the service issuing the key should be the same the service using the key. But in many use cases, the service using the key should be different from the one that has initially issued it. So one main matter of interest of the hardware-based secure services community group members is how to protect key usage considering the special use case where the credentials are used outside their issuing origin. For example: Suppose that a domain foo.com issues a key. Because the key is not accessible by Javascript API from another domain, we have to design a secure system where the domain bar.com is allowed to use this key.

In this document, we assume that:

pre-existing keys and X509 certificates are under the full control of the end-user any API issued key MUST only be managed and used by its own origin So in this report, the mechanism to manage the various origins to use and manage a particular key is not defined. Corresponding extensions will be added later.

[Ketan2016]

You don’t need to make any changes to the document. I think we need to discuss this topic at the meeting.

[sbahloul]

ok, done