Re: [W3C WebCrypto API WG] Key discovery

Hi Nick,

I don't know if it's on purpose or not but maybe test.html could reflect 
more EventTarget (evt.target.result instead of object.result), and, 
small detail, ||'<li class="ui-widget-content">' + certificates[i] still 
looks strange.

Regards

Aymeric

Le 09/04/2013 12:47, Nick Van den Bleeken a écrit :
> Hi Aymeric,
>
> I've updated [1] by adding an abstract, a CertificateOperation 
> interface, and explaining that the 'available' certificates are origin 
> based made available in a user agent specific manner after requesting 
> permission to the user.
>
> I also clarified the use cases a bit at [2].
>
> If you have any other comments/remarks please give them ;)
>
> Kind regards,
>
> Nick Van den Bleeken
>
> 1: 
> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API
> 2: 
> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/UseCases
>
>
> On 08 Apr 2013, at 22:16, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>> Hi Nick,
>>
>> Apparently I missed the wiki for the use case, now, since there are 
>> different proposals with different use cases/ideas being written 
>> currently, the idea maybe is to adopt the same conventions (like the 
>> CertificateOperation interface if everybody agree, and certificate 
>> discovery should probably follow the same rules as key discovery 
>> since the job has been done already ) and then at the end everything 
>> can be merged together and/or interoperate.
>>
>> Regards,
>>
>> Le 08/04/2013 18:51, Nick Van den Bleeken a écrit :
>>> Thank you Aymeric,
>>>
>>> My answer is inline.
>>>
>>> On 8 apr. 2013, at 17:45, "America Vitte" <vitteaymeric@gmail.com 
>>> <mailto:vitteaymeric@gmail.com>> wrote:
>>>
>>>> Maybe I am misreading but looking at the API and test.html it seems 
>>>> to be more related to a certificate discovery proposal rather than 
>>>> a key-certificate-discovery one (in your example result is an array 
>>>> of certificates).
>>> It's about discovering certificates and their associated keys based 
>>> on certificate properties.
>>>>
>>>> And then I don't really understand why for example 
>>>> |X509CertificateSelector is a KeyOperation and not something like a 
>>>> CertificateOperation (like in [1] for example) implementing 
>>>> EventTarget (which you don't really use in your examples, 
>>>> and|||'<li class="ui-widget-content">' + certificates[i] + 
>>>> '</li>'|looks strange...), and then certificates discovery should 
>>>> follow the same SOP rules as key discovery.
>>>> |
>>> I will incorporate your comments. And add some more documentation 
>>> (there is a related paper about this work, but that one is not yet 
>>> public because it is submitted for WASH13).
>>> The available certificates will be configurable by the end user on a 
>>> per site basis (using a subtle UI, something like is done for the 
>>> location, webRTC, ...)
>>>> |
>>>> That's not critics but comments, probably it's as start as you 
>>>> mentioned, for your test your extract certificates and then sign 
>>>> them if I understand correctly, maybe you should add the use case 
>>>> in the proposal.
>>>> |
>>> There is already one use case documented(Document signing).
>>> Will add some more.
>>> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/UseCases
>>>> |
>>>> Regards,
>>>>
>>>> [1] https://gist.github.com/Ayms/d21bbab05361bd58c439
>>>> |
>>>
>>> Thank you for your constructive comments.
>>>> |
>>>>
>>>> |
>>>> Le 08/04/2013 12:12, Nick Van den Bleeken a écrit :
>>>>> Hi Mark,
>>>>>
>>>>> You might want to have a look at [1].
>>>>>
>>>>> I and a colleague of mine are working on a proposal for a key 
>>>>> discovery API using its associated X509 certificate. We are still 
>>>>> in an early phase, but started prototyping the API as native 
>>>>> browser extension. The API description[2] and code of the 
>>>>> prototype is available at github at [1].
>>>>>
>>>>> We started this project in the hope to keep the discussion about 
>>>>> getting access to smart cards and USB security tokens on the web 
>>>>> active. And possibly use it as starting point for a proposal for a 
>>>>> key/discovery API to the WG.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Nick Van den Bleeken
>>>>> 1: 
>>>>> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js
>>>>> 2: 
>>>>> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API 
>>>>>
>>>>>
>>>>> On 05 Apr 2013, at 02:25, Mark Watson <watsonm@netflix.com 
>>>>> <mailto:watsonm@netflix.com>> wrote:
>>>>>
>>>>>> Scope issues aside, on the technical side it's difficult to see h
>>>>>> ow this could be interoperable without further specification.
>>>>>>
>>>>>> Considering the use-case given, there would need to be a 
>>>>>> specification (somewhere) of the format of the Government-issued 
>>>>>> certificate which included details of how the various properties 
>>>>>> of that certificate were handled by the ( attribute name, value ) 
>>>>>> filter matching (i.e. what are the attribute names and how are 
>>>>>> their values derived from the certificate and how is the matching 
>>>>>> done), how the Issuer and isPrivate should be set and what kind 
>>>>>> of authentication was required.
>>>>>>
>>>>>> UA's could then know how to support that kind of certificate and 
>>>>>> applications would know what to look for.
>>>>>>
>>>>>> Typically in these kind of situations we have a chicken-and-egg 
>>>>>> problem. There is reluctance to specify a lookup capability in 
>>>>>> WebCrypto when we have no idea what kinds of things we're trying 
>>>>>> to look up. On the other hand, noone is going to write a "how to 
>>>>>> expose XYZ key in WebCrypto" specification if there is obviously 
>>>>>> no method in WebCrypto to do that.
>>>>>>
>>>>>> One way to resolve that problem is to signal intent with a simple 
>>>>>> API and define a registry for specifications that define how it 
>>>>>> is used. For example, if the getKeys() call included a "type" 
>>>>>> parameter, with a registry for type values, then implementors 
>>>>>> would know that to implement getKeys() they just have to look 
>>>>>> through the registry, get the specifications registered there and 
>>>>>> implement zero or more of those. There's no requirement to 
>>>>>> implement any of them.
>>>>>>
>>>>>> Typically, W3C has preferred people to come to W3C itself and 
>>>>>> write those specifications here. That has the advantage that the 
>>>>>> specifications fall under the W3C patent policy. The W3C has 
>>>>>> deviated from this only when it has been practically impossible. 
>>>>>> MIME types for media codecs would be an example of a type field 
>>>>>> with a registry operating in very much the way I described.
>>>>>>
>>>>>> However, the scope quoted by Ryan does seem to rule out that 
>>>>>> approach in the short term ...
>>>>>>
>>>>>> ...Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 4, 2013 at 4:37 PM, Ryan Sleevi <sleevi@google.com 
>>>>>> <mailto:sleevi@google.com>> wrote:
>>>>>>
>>>>>>     Issuer is underspecified, and as such, not possible to implement.
>>>>>>
>>>>>>     Further, this seems to directly conflict with the charter,
>>>>>>     which states:
>>>>>>
>>>>>>     "Out of scope: features including special handling directly for
>>>>>>     non-opaque key identification schemes, access-control mechanisms
>>>>>>     beyond the enforcement of the same-origin policy, and
>>>>>>     functions in the
>>>>>>     API that require smartcard or other device-specific behavior"
>>>>>>
>>>>>>     This requires both handling for non-opaque key identification
>>>>>>     scheme
>>>>>>     ("issuer") as well as an access control mechanism ("isPrivate")
>>>>>>
>>>>>>     As such, we do not support the WG taking on this item.
>>>>>>
>>>>>>     On Thu, Apr 4, 2013 at 4:21 PM, Lu HongQian Karen
>>>>>>     <karen.lu@gemalto.com <mailto:karen.lu@gemalto.com>> wrote:
>>>>>>     > Hi Mark,
>>>>>>     >
>>>>>>     > We would like to suggest expanding the key discovery
>>>>>>     specification by adding an API for discovering
>>>>>>     pre-provisioned cryptographic keys via any of their
>>>>>>     attributes. This gives web applications a mean to find
>>>>>>     pre-provisioned keys whose names are unknown to them.
>>>>>>     >
>>>>>>     > The contribution is attached for review.
>>>>>>     >
>>>>>>     > Regards,
>>>>>>     > Karen and Michael
>>>>>>     >
>>>>>>     >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Inventive Designers' Email Disclaimer:
>>>>> http://www.inventivedesigners.com/email-disclaimer
>>>>
>>>> -- 
>>>> jCore
>>>> Email :avitte@jcore.fr
>>>> iAnonym :http://www.ianonym.com
>>>> node-Tor :https://www.github.com/Ayms/node-Tor
>>>> GitHub :https://www.github.com/Ayms
>>>> Web :www.jcore.fr
>>>> Webble :www.webble.it
>>>> Extract Widget Mobile :www.extractwidget.com
>>>> BlimpMe! :www.blimpme.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Inventive Designers' Email Disclaimer:
>>> http://www.inventivedesigners.com/email-disclaimer
>>
>> -- 
>> jCore
>> Email :avitte@jcore.fr
>> iAnonym :http://www.ianonym.com
>> node-Tor :https://www.github.com/Ayms/node-Tor
>> GitHub :https://www.github.com/Ayms
>> Web :www.jcore.fr
>> Webble :www.webble.it
>> Extract Widget Mobile :www.extractwidget.com
>> BlimpMe! :www.blimpme.com
>
>
> ------------------------------------------------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com