Re: Suggestions on high-level API - perhaps a meeting next week?

Hi.
in Here (Korea)
some developers were discussed about what we can do with WebcryptoAPI
and agreed following lists

* Electronic ID : Identify user identify with webcrypto API and the
certificate issued by face to face verification.
* PKI : using webcrypto API as part of public key infrastructure.
* Crypto : using webcrypto API for legal cryptography operation (end to end
encryption or others)
* Browser Security : enhancing browser security
* Regulation : what the API will impact to current regulations and what we
have to change.

also
I hope to solve the multi origin issues as soon as possible.
as the result of it, the model can be differentiated.

regards
mountie.

On Fri, Sep 28, 2012 at 4:24 AM, David Dahl <ddahl@mozilla.com> wrote:

> As far as use cases are concerned, I can think of 2 offhand, and I think
> they cover many sites/developer needs:
>
> 1. Zero-knowledge cloud-storage of data: messages, documents, etc. - in
> the event of a server compromise, the attacker has nothing.
>
> 2. Locally-encrypted data stored in browser storage - in the event of a
> lost laptop, the user's data will be more protected than if the web storage
> data was in plain text. Another benefit is site operators will not have to
> store sensitive PII on the server.
>
> Nearly every web developer I have chatted with about this API has these 2
> use cases in mind.
>
> Cheers,
>
> David
>
>
> ----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: "Harry Halpin" <hhalpin@w3.org>, "Emily Stark" <estark@mit.edu>,
> "Wan-Teh Chang" <wtc@google.com>, public-webcrypto@w3.org, "GALINDO
> Virginie" <Virginie.GALINDO@gemalto.com>
> Sent: Thursday, September 27, 2012 1:06:51 PM
> Subject: Re: Suggestions on high-level API - perhaps a meeting next week?
>
> Do we have any use cases that intend to make use of the high-level
> API, beyond the understandably obvious overlap with the JOSE use
> cases?
>
> The feedback I saw largely came from the cryptographic community, who
> wish to see safer crypto encouraged. I can understand and deeply
> appreciate that motivation, and I think it's a good thing. However, I
> also want to make sure we're actually solving developers' problems and
> addressing their needs, and I think in order to do that, we'll want to
> make sure we're actually capturing use cases.
>
> I also mention this because, whether low-level or high-level, the
> API's utility is bounded by the security model and expectations of
> both end users and developers. Provably secure crypto is useless if
> it's going to be used to address a problem that fundamentally cannot
> be addressed in the web security model, which is why it is all the
> more important to be able to capture these use cases.
>
> I have great respect for those suggesting we should, either
> exclusively or immediately, ship a high-level API, but I want to make
> sure we're solving problems, and not simply providing an ideological
> solution in search of a problem.
>
> On Thu, Sep 27, 2012 at 9:39 AM, David Dahl <ddahl@mozilla.com> wrote:
> > +1
> >
> > A high-level API is also perceived to be the only kind of API that is
> usable by the majority of web developers. I agree we should not put this
> off to long.
> >
> > Cheers,
> >
> > David
> >
> > ----- Original Message -----
> > From: "Harry Halpin" <hhalpin@w3.org>
> > To: "GALINDO Virginie" <Virginie.GALINDO@gemalto.com>
> > Cc: "Ryan Sleevi" <sleevi@google.com>, "Emily Stark" <estark@MIT.EDU>,
> "Wan-Teh Chang" <wtc@google.com>, "David Dahl" <ddahl@mozilla.com>,
> public-webcrypto@w3.org
> > Sent: Thursday, September 27, 2012 11:18:35 AM
> > Subject: Re: Suggestions on high-level API - perhaps a meeting next week?
> >
> > On 09/27/2012 03:46 PM, GALINDO Virginie wrote:
> >> Harry, and all,
> >>
> >> Good to know that this high level API is not a lost topic.
> Nevertheless, the WG participants made a decision to treat later the high
> level API. As such, I think that before re-opening this item - which may be
> tricky as mentioned Ryan - we should try to finalize what we have started,
> meaning a stable low level API. Having said that, I see no problem for
> having a call dedicated to discussing qualities of the high level APIs you
> have mentioned, in order to build our common background. Lets scheduled
> this topic for one of our Monday conf call after our next F2F meeting
> somewhere mid-Nov.
> >
> > It seems the main feedback we have from the general public is that a
> > "high-level" API is necessary. Although in our original survey we had a
> > slight majority in favour of the low-level, I think it would disappoint
> > the people watching this work if we did not have a very "drafty"
> > high-level API included in the next Working Draft.
> >
> > To stabilize the low-level API would mean to go through all the open
> > issues. I think having another two months to go through those open
> > issues would be great, but we should reserve some meetings for a
> > high-level API discussion. We may want to introduce the topic sooner
> > rather than later.
> >
> > And yes, +1 to having the high-level API be essentially an API for the
> > JOSE formats.
> >
> >     cheers,
> >       harry
> >
> >>
> >> David, Emily, Ryan, Wan-Teh,
> >> would this timing be suitable for you ?
> >>
> >> Regards,
> >> Virginie
> >>
> >>
> >> -----Original Message-----
> >> From: Ryan Sleevi [mailto:sleevi@google.com]
> >> Sent: lundi 24 septembre 2012 22:51
> >> To: Harry Halpin
> >> Cc: public-webcrypto@w3.org
> >> Subject: Re: Suggestions on high-level API - perhaps a meeting next
> week?
> >>
> >> On Mon, Sep 24, 2012 at 1:44 PM, Harry Halpin <hhalpin@w3.org> wrote:
> >>> Looking at various discussions about the Web Crypto API, it seems that
> >>> most of the concern is the "footgun" problem, i.e. we are giving
> >>> developers a gun to shot themselves in the foot. Most of the concern
> >>> seems to be over the JS environment as a whole, but there is
> >>> considerable concern over the larger issues related to the Web
> >>> Security Model (i.e. CSP.). I'll draft some text on how the Web Crypto
> API only solves a limited part of the problem (i.e.
> >>> primitives for re-implementing existing work, random number
> >>> generation, key storage). However, it would behoof us by our next WD
> >>> release to actually
> >>> *address* these concerns. The primary concern seems to be having a
> >>> high-level APIs (which would require pushing on the discovery
> algorithm).
> >>>
> >>> Thus, my suggestion is that we start at least collecting examples of
> >>> good high-level APIs and comparing their functions, and see if we can
> >>> get a clear consensus. These three come up off top of my head:
> >>>
> >>> 1) DOMCrypt - This is David Dahl, who is one of co-editors and a
> >>> member of our WG.
> >>>
> >>> 2) Stanford Crypto API - Dan Boneh, Mike Hamburg, and Emily Stark (who
> >>> is on our WG)
> >>>
> >>> 3) KeyCzar - this is Steve Weis/Ben Laurie from Google. Shall we ping
> them?
> >>> @Rsleevi and @wtc?
> >>>
> >>> We could get a call devoted to this topic, and maybe invite some of
> >>> the folks that aren't in our WG. I'd be happy to go for this next week
> >>> unless we want to prioritze other issues!
> >>>
> >>>     cheers,
> >>>       harry
> >>>
> >>> [1] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> >>> [2] http://crypto.stanford.edu/sjcl/
> >>> [3] http://www.keyczar.org/
> >>>
> >> There is also NaCl (pronounced "salt") - http://nacl.cr.yp.to/ - Which
> is Daniel J. Bernstein (djb), Tanja Lange, and Peter Schwabe.
> >>
> >> However, the issue with SJCL, Keyczar, and NaCl is that they define
> both APIs *and* message formats. That is, a message protected under SJCL is
> not, AFAICT, exchangeable with a message protected under keyczar.
> >>
> >> As we discussed on our telecon today, and as raised by Mike Jones, it
> seems equally appropriate that we point to and encourage the IETF JOSE
> work, which is (presently) focused solely on a message format and not on an
> API.
> >>
> >> The issue with the "high-level API" is two-fold. The only way to
> replace the footgun is to do the crypto for them, and if you're going to do
> the crypto for them, it needs to be interoperable between user agents. I
> think JOSE's message format does this much better, in terms of public
> engagement and in addressing the cryptographic concerns, that it may be
> suitable to instead look at the high level API as perhaps simply an API for
> JOSE.
> >>
> >
> >
>
>
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World