- From: Ryan Sleevi <sleevi@google.com>
- Date: Fri, 24 May 2013 10:06:08 -0700
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
On Fri, May 24, 2013 at 9:33 AM, Anders Rundgren <anders.rundgren@telia.com> wrote: > Well, you asked for input... > > I believe that Samuel Erdtman's excellent idea: Optionally adding an > "Origin Tag" to keys provisioned through other means than Web Crypto, This is not necessary - it's already implied. Mark's made it clear from past conversations that at least one embodiment includes allowing any origin to access request to certain "named" keys and either generating them on the fly or sharing their key material. There is no spec change needed to support such a use case. > in conjunction with a revamped Key Discovery draft offering > _Key_Enumeration_ (for keys with a matching origin tag) and > _Key_Attribute_Retrieval_ (for discovered keys) could easily > support Netflix' _and_ the "eID community's" use-cases. > > Named keys as specified in the current Key Discovery draft wouldn't > work for eID since every individual presumably have a unique name. This is not accurate. An eID key might be named "Sweden-eID", as a hypothetical example. There is absolutely nothing requiring the names be globally unique - indeed, there is strong incentive that they NOT be unique, and instead represent 'simple' names that can be agreed upon. > > Key Discovery should of course continue to be an add-on specification > so that browser vendors wouldn't have to implement it in order to be > Web Crypto compliant. Can you explain the value then? Who do you see as implementing the "eID community's" spec, if not browsers? > > Cheers, > Anders > >
Received on Friday, 24 May 2013 17:06:40 UTC