Re: Review of Use Cases | Re: W3C Web Crypto Use cases - next step ?

Hi Arun,

Some small comments after a quick review (sorry limited time right now) :

- is it on purpose that you are using "==" instead of "==="?

- Code sancity and ... :
     .then(function(digest) {if (ok)  {} else {get src}}, 
function(error) {get src})
     No?
     and get src should be https since you mention the origin is tls

- Webmail :

window.crypto.subtle.importKey("jwk", jwkKey,..) --> window.crypto.subtle.importKey("jwk", jwkKeyObject,...)

Regards

Aymeric

Le 15/07/2013 21:05, Arun Ranganathan a écrit :
> Dear Working Group,
>
> Review of the use cases is encouraged :)
>
> https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/5765a3364579/Overview.html
>
> Thanks to those who have already reviewed things.
>
> -- A*
> On Jul 12, 2013, at 3:42 PM, Arun Ranganathan wrote:
>
>> Hi Karen!  Thanks for your careful review.
>>
>>
>> On Jul 8, 2013, at 3:47 PM, Lu HongQian Karen wrote:
>>
>>> Hi Arun,
>>> Thanks again for putting this together. I have a few comments below:
>>> Banking transaction use case
>>> >Jae-sang presents the derived public key to GB
>>> Which derived public key?
>>
>>
>> It shouldn't say "derived."  Early drafts didn't distinguish 
>> sufficiently between key generation and key derivation.  I've fixed 
>> this now.
>>
>>
>>> >GB may then use a key exchange mechanism to exchange keys with the server over TLS
>>> Guess you mean GB client (running in the web browser) and GB server?
>>
>>
>> Right.  In every use case, I mean with a "user agent" as an 
>> intermediary.  So everytime I say "GB" I mean, an instrument such as 
>> a web page, iframe, or script hosted on GB's domain.  In this 
>> particular example, ALL transactions occur within GB's domain.
>>
>>
>>> >The signature is verified, and upon successful verfication, is decrypted.
>>> verfication -> verification
>>> is decrypted -> the encrypted message is decrypted.
>>
>>
>> Fixed.
>>
>>
>>> BrowserID use case
>>> >BrowserID
>>> Change to Persona?
>>
>>
>> Good nit!  So actually, any reference to the protocol itself is 
>> "BrowserID."  Persona, generally considered a product, is in fact an 
>> implementation of BrowserID.  Stricly speaking, that protocol spec 
>> lives here: https://github.com/mozilla/id-specs/tree/prod/browserid
>>
>>> >The signed assertion is then combined …
>>> May change to: The javascript ofPersona.org <http://Persona.org/>in 
>>> the iFrame combines the signed assertion…
>>
>> Sure!
>>
>>> Does Karen need to login to Persona before Persona can access her data?
>>
>>
>> Yes!  The flow is exactly as if you did this:
>>
>> 1. Visit http://myfavoritebeer.org/
>> 2. Log in using Persona
>>
>> What is happening between those websites is what the use case is.
>>
>>
>>> The verification part is confusing to me. Does PSS verifies on the 
>>> client side or the server side?
>>
>>
>> EVERYTHING happens on the client side.  PSS obtains the public key 
>> from https://persona.org/.well-known/browserid (which in fact uses a 
>> semi-legitimate form of JWK).
>>
>> -- A*
>

-- 
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
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com