Re: any discussion thread for page encodings?

Hi. Ryan.
yes. I read in charter and use cases for "prevent and control"
but no details.

I remember someone mentioned "signed JS". but that is not acceptable for
wider use.

can we consider "arguments.callee" (but this is depreciated in ECMA-262)
plus hash?

If webcrypto api provide JS/DOM integrity checking feature in low level,
web developers can use it for many purpose including "prevent and control"

regards
mountie.

On Sun, Jul 29, 2012 at 4:39 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Sat, Jul 28, 2012 at 8:55 PM, Mountie Lee <mountie.lee@gmail.com>
> wrote:
> > Hi. Ryan.
> >
> > thanks for your answer.
> >
> > as my understanding, the initial requirement has include "sign with user
> > confirmation".
> > that means the sign data must be same to the message shown to user
> screen.
> > just with "sequence of bytes" are not enough for previous requirements.
> >
> > if it is handled in high level API,
> > my additional question is
> >
> > is their any mechanism for preventing secret key material changes or
> other
> > sensitive cryptographic values and settings changes?
> >
> > regards
> > mountie.
>
> Hi Mountie,
>
> Yes, any scheme which relies on user agents presenting data in some
> interpreted form is out of scope for the low-level API, and /may/ be
> in scope for the high-level API. Because such schemes are
> understandably complex (eg: PDF signatures, XMLsig,
> normalization/canonicalization, etc), these are currently not the
> focus of the working groups efforts, but may be in scope at a later
> time. The current focus is on the low-level API, which does not focus
> on such application-specific issues at this time, as even a low-level
> API is a very ambitious and broad endeavor for user agents to
> normalize.
>
> I'm not sure I understand your second question, but you may find it
> answered by the Working Group charter at
> http://www.w3.org/2011/11/webcryptography-charter.html , which states
> that the API shall prevent or control access to secret key material
> and other sensitive cryptographic values and settings.
>
> Regards,
> Ryan
>
> >
> >
> > On Sun, Jul 29, 2012 at 10:41 AM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> Hi Mountie,
> >>
> >> There were early discussions about page encodings and normalization,
> >> when the API included both a high-level and a low-level component.
> >> Following our recent Working Group face to face, the Working Group has
> >> resolved to focus on the low-level API and ensure that it's in a
> >> deliverable state, and then revisit the ideas for a high-level API.
> >>
> >> By virtue of being a low-level API, issues such as encoding are left
> >> to the application author. This can be seen also in the removal of
> >> DOMString (which is UTF-16) from being a valid input to the
> >> CryptoOperation.processData method, since that would have opened
> >> questions of "Is it a sequence of bytes or is it a string?"
> >>
> >> Right now, the API's interaction with data streams is accomplished via
> >> ArrayBuffer/ArrayBufferViews, which are treated as opaque sequences of
> >> bytes. Any further normalization or canonicalization should thus be
> >> done at an application layer.
> >>
> >> Does this answer your question?
> >>
> >> On Sat, Jul 28, 2012 at 5:25 PM, mountie.lee@gmail.com
> >> <mountie.lee@gmail.com> wrote:
> >> >
> >> >> Hi.
> >> >> I'm Mountie Lee from Korea.
> >> >>
> >> >> when I read http://www.w3.org/2012/webcrypto/WebCryptoAPI/ and
> searched
> >> >> archive at http://lists.w3.org/Archives/Public/public-webcrypto/
> >> >>
> >> >> I can not find discussion about page encodings.
> >> >>
> >> >> because WebCryptoAPI is Javascript dependent and developers have to
> >> >> consider page encodings always.
> >> >>
> >> >> many asian sites use local encodings (EUC-KR, Shift-JIS, GB2312 ...)
> >> >> and by the page encodings,
> >> >> the javascript operation result is different.
> >> >>
> >> >> please anyone inform me the discussio thread for page encodings.
> >> >>
> >> >> regards
> >> >> mountie.
> >> >>
> >> >> --
> >> >> Mountie Lee
> >> >>
> >> >> Tel : +82 2 2140 2700
> >> >> E-Mail : mountie@paygate.net
> >> >> Twitter : mountielee
> >> >
> >
> >
> >
> >
> > --
> > Mountie Lee
> >
> > Tel : +82 2 2140 2700
> > E-Mail : mountie@paygate.net
> > Twitter : mountielee
> >
> > =======================================
> > PayGate Inc.
> > THE STANDARD FOR ONLINE PAYMENT
> > for Korea, Japan, China, and the World
> >
>



-- 
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net
Twitter : mountielee

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