Re: CfC: Shelve Web Intents, Web Intents Addendum, Pick Media Intent, Pick Contacts Intent, respond by 17 May (next Friday) (resend)

2013-05-20 Thread Frederick.Hirsch
This CfC has completed with support for shelving the Web Intents Addendum, Pick 
Media Intent, and Pick Contacts Intent specifications.

Based on the CfC mail discussion (and DAP teleconference) we have also agreed  
to publish Web Intents as a W3C WG Note to complete work (for now).

As with all shelving (and Notes) the WG may decide to resume this work at any 
time with the current or a revised approach. 

Thanks to Jungkee for adding a note to the Pick Media Intent and Pick Contacts 
Intent specifications to mark them as shelved.  I have done the same for the 
Web Intents Addendum.

I have also  updated the DAP home page to note that Web Intents Addendum, Pick 
Media Intent, and Pick Contacts Intent  are shelved.

We will go ahead to arrange the publication of Web Intents as a W3C Note and 
then I will update the DAP page accordingly.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group





On May 8, 2013, at 4:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

 (resend to include Web Intents TF list and WebApps list for shelving Web 
 Intents spec, as well as DAP for all of specs)
 
 ---
 
 This is a Call for Consensus (CfC) to shelve the Web Intents, Web Intents 
 Addendum, Pick Media Intent, and Pick Contacts Intent specifications (4 
 specs).
 
 Shelving in this case means that we are not sure the specifications will 
 advance along the lines the drafts indicate. As a result we want to be clear 
 to everyone that we may not advance the specifications or that we may change 
 the approach.  This does not mean that we have decided not to advance them, 
 just that there is a question as to the direction and/or progression at this 
 point. 
 
 In order to advance this work we need support for the underlying technology, 
 which we have been assuming will be a combination of Web Intents and Web 
 Activities. This will require some sharing of proposals on the public list to 
 enable progress. It would be best if we can progress this on the public list 
 by September, so that we can have a meaningful result on the topic at a TPAC 
 F2F.
 
 If we have consensus to shelve the documents, this will have the following 
 immediate consequences:
 
 1. The editors will edit each document to add a warning statement before the 
 abstract.
 
 I suggest we use the following text (feel free to make suggestions):
 
 The Device APIs Working Group is currently not progressing the approach 
 outlined in this draft. Please treat this document with caution and do not 
 reference it or use it as the basis for implementation. The domain covered by 
 this document is still within the scope of the Working Group as defined in 
 its Charter. The Working Group may resume this work or adopt an alternative 
 approach depending on the interest of WG members and implementers.
 
 2. On the DAP home page we will move the specifications from the active 
 roadmap [1]  to the list of shelved specifications [2].
 
 I suggest we keep both the links to the latest published draft and editors 
 draft available when we do this. (I can volunteer to make this update if we 
 agree to this CfC).
 
 Please send all comments regarding this CfC to the public-device-a...@w3.org 
 mail list by 17 May (next Friday).   Silence will be considered as agreement 
 with the proposal. If you support this CfC, a positive response is preferred 
 and encouraged, even if a +1.
 
 Obviously any constructive work on the list regarding the underlying 
 technology would also be welcome.
 
 Thanks
 
 regards, Frederick
 
 Frederick Hirsch, Nokia
 Chair, W3C DAP Working Group
 
 
 [1] http://www.w3.org/2009/dap/#roadmap
 
 [2] http://www.w3.org/2009/dap/#shelved
 
 
 
 




CfC: Shelve Web Intents, Web Intents Addendum, Pick Media Intent, Pick Contacts Intent, respond by 17 May (next Friday) (resend)

2013-05-08 Thread Frederick.Hirsch
(resend to include Web Intents TF list and WebApps list for shelving Web 
Intents spec, as well as DAP for all of specs)

---

This is a Call for Consensus (CfC) to shelve the Web Intents, Web Intents 
Addendum, Pick Media Intent, and Pick Contacts Intent specifications (4 specs).

Shelving in this case means that we are not sure the specifications will 
advance along the lines the drafts indicate. As a result we want to be clear to 
everyone that we may not advance the specifications or that we may change the 
approach.  This does not mean that we have decided not to advance them, just 
that there is a question as to the direction and/or progression at this point. 

In order to advance this work we need support for the underlying technology, 
which we have been assuming will be a combination of Web Intents and Web 
Activities. This will require some sharing of proposals on the public list to 
enable progress. It would be best if we can progress this on the public list by 
September, so that we can have a meaningful result on the topic at a TPAC F2F.

If we have consensus to shelve the documents, this will have the following 
immediate consequences:

1. The editors will edit each document to add a warning statement before the 
abstract.

I suggest we use the following text (feel free to make suggestions):

The Device APIs Working Group is currently not progressing the approach 
outlined in this draft. Please treat this document with caution and do not 
reference it or use it as the basis for implementation. The domain covered by 
this document is still within the scope of the Working Group as defined in its 
Charter. The Working Group may resume this work or adopt an alternative 
approach depending on the interest of WG members and implementers.

2. On the DAP home page we will move the specifications from the active roadmap 
[1]  to the list of shelved specifications [2].

I suggest we keep both the links to the latest published draft and editors 
draft available when we do this. (I can volunteer to make this update if we 
agree to this CfC).

Please send all comments regarding this CfC to the public-device-a...@w3.org 
mail list by 17 May (next Friday).   Silence will be considered as agreement 
with the proposal. If you support this CfC, a positive response is preferred 
and encouraged, even if a +1.

Obviously any constructive work on the list regarding the underlying technology 
would also be welcome.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group


[1] http://www.w3.org/2009/dap/#roadmap

[2] http://www.w3.org/2009/dap/#shelved







Re: Rough summary of minutes from the face to face

2013-05-08 Thread Frederick.Hirsch
Chaals 

I think this is very helpful and useful. It makes the status, activity and 
important items very visible in a concise manner.

Much appreciated, thanks.

regards, Frederick

Frederick Hirsch
Nokia



On May 7, 2013, at 6:16 AM, ext Charles McCathie Nevile wrote:

 Hi,
 
 in line with the last item on this list, I committed to make a rough summary 
 of the meeting available to go with the raw minutes. The idea is that people 
 who aren't in the group and weren't there can actually understand what the 
 minutes mean. So here it is.
 
 Minutes for Thursday[2] and Friday[2] are available
 
 Notes on the topics listed in the minutes:
 
 Thursday
 =Dashboard / PubStatus
 Webapps maintains a wiki page[4] with the latest knowledge about the specs 
 the group is working on.
 
 =App Manifest
 This is a manifest for packaged (i.e. an installable zip) or hosted 
 (something like pages with an appcache manifest) apps, that provides 
 metadata, an icon, etc. It will be moved from the Sysapps group to the web 
 apps group, who already have it as an explicit charter deliverable. There is 
 a comparison chart[5] of Manifest formats available (but not 100% correct - I 
 believe contributions are welcome.
 
 =AppCache
 There are two initial proposals for fixing it, one from Mozilla[6], and one 
 expected from Google based on Navigation Controller[7]. A key question is 
 whether to have a declarative format (Jonas' proposal has a JSON format that 
 is more or less declarative, Navigation Controller is just script).
 
 NB Since the meeting we have started to collect use cases[8] in our Wiki
 
 =Indexed DB
 Hopefully version 1 will be finished in a few months. It seems the last point 
 of disagreement was resolved at the meeting, so we expect a new draft in a 
 couple of weeks that will be more or less the final one.
 
 =DOM3 Events - Status Update
 Keyboard events are known to be difficult to standardise. They don't have 
 enough tests to be confident that they have this part right, and want more. 
 Maybe they will be ready some time around the end of the year.
 
 =Web Components
 There are now 4 specifications that are being developed to allow the creation 
 of custom elements in HTML (and XHTML). The work is led by Dmitry Glazkov 
 from Google. There was an introduction to the various specs, where they fit 
 and where they are up to.
 
 =Web Components Security Model, CORS, CSP
 This was a brief discussion with the Web App Security working group, just 
 describing basic things and meeting the people.
 
 =IME
 This specification is meant to allow use cases including writing a custom IME 
 to replace the system one (like what we do for translate), to make sure that 
 it is easier to interact cleanly with IME when doing something like suggest, 
 etc. There was a joint meeting with an accessibility group, but they were 
 more concerned about building editors (which is very hard) than actual IME 
 (which is moderately hard, unless you can't interact with the native one 
 which makes it horribly hard).
 
 =File API
 Mozilla has a new proposal[9] (as of the morning of the meeting). FileAPI has 
 a few outstanding issues, and is likely to try and ship rather than updating 
 to use futures, ...
 
 =WebIDL
 This probably only matters for people writing specs. WebIDL level 1 is likely 
 to be finished in a few months, with level 2 work ongoing.
 
 Friday
 =Testing, Move to Github
 The Web needs more tests. There are occasional Test The Web Forward events 
 where people make them. W3C is moving its test infrastructure to use a single 
 github repository for everything.
 
 =Progress Events
 These are used by XHR, the img element, and the Sysapps messaging API. The 
 spec should be finalised in summer
 
 =XMLHttpRequest
 There will be a level 1 specification that describes the interoperable bits, 
 to be finalized this year. Work will continue on level 2, with CORS, 
 authentication, etc, aiming to be done by late 2014.
 
 =Coordination (TC39)
 There has been a discussion asking for more coordination with TC39 for things 
 like making sure that when new APIs are developed at W3C (e.g. in Webapps) 
 there is a notice to them so they can give an early review on things like 
 whether the API looks like normal Javascript, not something mostly designed 
 as if it were in C++ or some other language. The conclusion was Please do 
 more coordination.
 
 [1]  http://www.w3.org/wiki/Webapps/April2013Meeting
 [2]  http://www.w3.org/2013/04/25-webapps-minutes.html
 [3]  http://www.w3.org/2013/04/26-webapps-minutes.html
 [4]  http://www.w3.org/2008/webapps/wiki/PubStatus
 [5]  http://www.w3.org/community/webappstore/wiki/Manifest
 [6]  http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html
 [7]  https://github.com/slightlyoff/NavigationController
 [8]  http://www.w3.org/wiki/Webapps/AppCacheUseCases
 [9]  http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0382.html
 
 I'm interested in whether this was a useful 

Declarative invocation and progressing Web Intents

2013-01-22 Thread Frederick.Hirsch
Fred

I object to this being a resolution, since I never saw a formal Call for 
Consensus sent to the WebIntents list.  I saw an informal discussion of ideas 
and an offer to provide proposals, not a proposal to change where standards are 
delivered. I know the DAP WG has not had a chance to discuss or agree to this 
resolution.

In addition, currently members of DAP have work items to progress both  Web 
Intents  and Web Activities and we have not stopped this work - though we need 
to review the status.

I also am not clear on the IPR implications of work being done in the PUA CG 
versus/with a working group.

I suggest a change to what you propose. I would like to suggest that the PUA CG 
consider Declarative Invocation in cooperation with the WebIntents Task Force, 
and provide input  regarding Web Intents development, but not take over 
development of this standardization.  I suggest the standard remain a joint 
deliverable from DAP (and WebApps)  WGs as joint deliverables until we formally 
decide otherwise.

I think first steps for declarative invocation, however, might be documenting 
use cases and requirements.

What do others think?

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group





On Jan 21, 2013, at 7:15 PM, ext Fred Andrews wrote:

Given that there have been no objections, the PUA CG accepts the development of 
the 'Declarative Invocation' standard.  This technology has great potential for 
securing the users private UA state and is well aligned with the charter of the 
PUA CG.

Given that this will likely require a rewrite of the Web Intents proposal the 
PUA CG will also take over the development of a suitable replacement.  Members 
of the Web Intents Task Force are invited to join the PUA CG for further 
discussions.

cheer
Fred

Chair
Private User Agent Community Group


From: freda...@live.commailto:freda...@live.com
To: jhawk...@google.commailto:jhawk...@google.com
CC: public-web-inte...@w3.orgmailto:public-web-inte...@w3.org; 
public-...@w3.orgmailto:public-...@w3.org
Date: Wed, 9 Jan 2013 03:19:31 +
Subject: RE: Declarative invocation

Dear James,

The declarative invocation markup would ideally support multiple inputs from a 
webpage and multiple outputs back to the webpage.  There might be multiple 
intents supported on a page, and perhaps there might even be overlap between 
the inputs and outputs.

For example, a file input element could declare the mime type(s) accepted, and 
this could be used with a pick intent to return a blob (single output).  This 
blob might be then be usable as a further input to an 'image edit' intent that 
returns an updated blob (single input, single output).  Finally when the input 
form is submitted the blob is sent.  This could allow a webpage without JS 
enabled to upload an edited image captured from a device camera, all from 
within the web browser.  The user can use trusted web apps for the image 
capture and for the image editing without exposing the camera API and without 
sharing UA state via an image editing web app.

For example, a section of an input form with contact inputs (name, address, 
etc), could be used with an intent that can search a trusted 'contacts' web app 
using supplied fields to direct the search and returning the requested fields 
that are used to populate the input form (multiple input, multiple output).  
The user might make some changes to the address and invoke another web intent 
to save the new contact address (multiple input, no output?).

There may be some opportunity to coordinate the required markup with general 
'semantic web' markup, such a microdata.  The web browser could then implement 
the UI and invocation without the webpage needing to add the UI support, and 
this might be done in a manner that is less vulnerable to spoofing.  I would 
also be keen to explore how this could help accessibility of webpage input 
forms.

For example, a photo viewing webpage might markup a slideshow allowing a 
presentation web app, that is specifically adapted to a limited device, to show 
the slide show and this could be invoked via a web intent (multiple input, no 
output).

The direction to take with the webpage UI support for invoking web intents is 
not clear to me yet.  It would be good to support buttons that can invoke an 
intent, such as a 'share' intent button, and this would allow a webpage to 
voluntarily place and style invocation buttons.  Buttons might also by placed 
around form input elements, such as a text input form element.

Other options being explored are allowing a web app to take over an element or 
region of a webpage when invoked - for example could a web app invoked via web 
intents might take over a webpage text input form element within the page to 
offer a rich HTML editor.   Other options are to overlay a webpage region, or a 
popup?

Support is also needed for legacy webpages, without semantic markup and web 
intents 

Re: random numbers API

2012-11-16 Thread Frederick.Hirsch
The W3C Web Cryptography working group [1]  has a draft that seems to include a 
method to generate cryptographically random values [2].

I'm not sure how well that relates to what your use case requires but it might 
be worth looking at.

regards, Frederick

Frederick Hirsch
Nokia


[1] http://www.w3.org/2012/webcrypto/

[2] http://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues


On Nov 16, 2012, at 10:13 AM, ext Florian Bösch wrote:

Motivation: Web Applications enter the arena of interactive content 
creation/consumption (games, productivity software, etc.). A good PRNG would be 
desirable in many situations.

Web Applications that desire to use random numbers have a 4 problems with the 
existing Math.random function.

1) The implementation is not high quality in that the generated random 
numbers tend to be statistically poor compared to other higher quality PRNGs.

2) The API does not support seeding whereas the same sequence of random numbers 
can be generated twice if so desired.

3) It is based on floating points which due to machine differences even in the 
presence of seeding could generate different numbers.

4) Alternative implementations in JS suffer even in the presence of 
sophisticated JITing VMs from the fact that mathematics is done in doubles (in 
the case of addition, subtraction, division and multiplication) and by 
converting double - int - double (in the case of bitshifts and modulo 
division). This makes it both harder to implement a reliable PRNG and it makes 
it slow.

I would propose an alternative native code random number API that has the 
following characteristic:

- The returned value is based on integers ranging from 0 up to a specified 
limit.
- It is initializable with a seed
- It makes a guarantee that no matter on what machine the random number is 
generated, that the sequence of random numbers to the same seed is identical.
- It selects a suitable PRNG algorithm to that end that satisfies a high 
standard of statistical qualities of PRNGs and exhibits good runtime 
performance.

It could look something like this for example:

var prng = new PRNG(seed);
var x = prng.random(limit);



Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2012-01-03 Thread Frederick.Hirsch
No I am not. 

Marcos took my email that expressed my hopes and turned it into a hard 
deadline, which I do not agree with.

I suggest we let  Rigo/Thomas continue this thread.

regards, Frederick

Frederick Hirsch
Nokia



On Jan 3, 2012, at 7:23 AM, Arthur Barstow wrote:

 On 12/29/11 11:18 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
 Marcos
 
 My expectation is that we should have a PAG update on progress in the first 
 week of January (hopefully) and a timeline like Rigo noted, with full 
 resolution of the iPR issue by March - but only the PAG chair knows the 
 reality since my expectations are as a customer of the PAG output. I 
 entirely agree with you that years is not appropriate.
 
 Are you saying that if the ECC PAG caused by RIM does not complete its work 
 by March, the XML Sec WG will do the factoring as Marcos describes below?
 
 -AB
 
 
 Apologies, here is the link: 
 http://lists.w3.org/Archives/Public/public-xmlsec/2011Dec/0026.html
 
 regards, Frederick
 
 Frederick Hirsch
 Nokia
 
 
 
 On Dec 29, 2011, at 10:22 AM, ext Marcos Caceres wrote:
 
 
 
 On Thursday, 29 December 2011 at 14:11, frederick.hir...@nokia.com wrote:
 
 As I said before, this action is premature and we should let the PAG 
 conclude (or at least wait for a status report) - the W3C Team may have 
 more to say, but if this is on the order of weeks I do not think making 
 work here to have apparent progress is useful. I have not seen a 
 definitive statement from the ECC PAG chair.
 That's fine. I guess as long as we don't have to wait one or two years (and 
 I say that with a serious face!).
 
 Did you read the message from Brian LaMacchia? If not, please read it, as 
 it provides additional argument against this proposed change.
 Pointer please?
 I am against revising XML Signature 1.1 until I understand the actual PAG 
 status and until we have XML Security WG agreement. This endless email 
 debate is not helpful and I'm not sure I understand the urgency related to 
 widgets apart from a desire to mark it as complete.
 The urgency is just that (getting it to Rec).
 
 But academically, the other arguments that were made are valid. Those were:
 * a /latest/ location
 * decupling algorithms, etc, from processing.
 
 
 -- 
 Marcos Caceres
 http://datadriven.com.au
 
 
 




Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-29 Thread Frederick.Hirsch
As I said before, this action is premature and we should let the PAG conclude 
(or at least wait for a status report) - the W3C Team may have more to say, but 
if this is on the order of weeks I do not think making work here to have 
apparent progress is useful. I have not seen a definitive statement from the 
ECC PAG chair.

Did you read the message from Brian LaMacchia? If not, please read it, as it 
provides additional argument against this proposed change.

I am against revising XML Signature 1.1 until I understand the actual PAG 
status and until we have XML Security WG agreement. This endless email debate 
is not helpful and I'm not sure I understand the urgency related to widgets 
apart from a desire to mark it as complete.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 21, 2011, at 9:35 AM, Arthur Barstow wrote:

 TLR, FH, XMLSecWG,
 
 On 12/21/11 6:03 AM, ext Marcos Caceres wrote:
  Lets go back an look at the options we have  to divorce Widgets/XML Dig Sig 
 from Elliptic Curve:
 
   1. Remove ECC from XML Dig Sig (in my opinion, the right thing to do™):
 
   pros:
  - frees both XML Dig Sig and Widgets Dig Sig to progress to REC at full 
 speed.
  - begins a pattern of divorcing signature algorithms from processing (a 
 good thing, which avoids this kind of mess!)
 
   cons:
  - new small spec needed
  - XML Dig Sig missing an important algorithm.
 
 Based on a quick scan of the XMLSec WG's mail archive [2], it appears that WG 
 has known about potential IP issues related to Certicom/RIM and ECC for 
 almost 3 years. As such, surely the WG has already discussed refactoring the 
 XMLSig spec in a way like Marcos and I proposed.
 
 Would you please explain why the WG objects to such refactoring (or provide a 
 link(s) to the related discussion)?
 
 As an FYI for the XMLSec WG members, note that another widget spec was 
 blocked for two years because of a PAG [1] so it's quite understandable that 
 having widgets-digsig blocked by YA PAG creates concerns for some WG members, 
 especially given the ECC PAG Chair's pessimistic view [3] of a quick PAG 
 resolution.
 
 -Thanks, AB
 
 [1] http://www.w3.org/2009/11/widgets-pag/pagreport.html
 [2] 
 http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=certicomindex-grp=Public_FULLindex-type=ttype-index=public-xmlsec
 [3] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1540.html
 
 




Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-29 Thread Frederick.Hirsch
Marcos

My expectation is that we should have a PAG update on progress in the first 
week of January (hopefully) and a timeline like Rigo noted, with full 
resolution of the iPR issue by March - but only the PAG chair knows the reality 
since my expectations are as a customer of the PAG output. I entirely agree 
with you that years is not appropriate.

Apologies, here is the link: 
http://lists.w3.org/Archives/Public/public-xmlsec/2011Dec/0026.html

regards, Frederick

Frederick Hirsch
Nokia



On Dec 29, 2011, at 10:22 AM, ext Marcos Caceres wrote:

 
 
 
 On Thursday, 29 December 2011 at 14:11, frederick.hir...@nokia.com wrote:
 
 As I said before, this action is premature and we should let the PAG 
 conclude (or at least wait for a status report) - the W3C Team may have more 
 to say, but if this is on the order of weeks I do not think making work here 
 to have apparent progress is useful. I have not seen a definitive statement 
 from the ECC PAG chair.
 
 That's fine. I guess as long as we don't have to wait one or two years (and I 
 say that with a serious face!). 
 
 Did you read the message from Brian LaMacchia? If not, please read it, as it 
 provides additional argument against this proposed change.
 
 Pointer please?  
 I am against revising XML Signature 1.1 until I understand the actual PAG 
 status and until we have XML Security WG agreement. This endless email 
 debate is not helpful and I'm not sure I understand the urgency related to 
 widgets apart from a desire to mark it as complete.
 
 The urgency is just that (getting it to Rec). 
 
 But academically, the other arguments that were made are valid. Those were: 
 * a /latest/ location 
 * decupling algorithms, etc, from processing.
 
 
 -- 
 Marcos Caceres
 http://datadriven.com.au
 
 
 




Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-14 Thread Frederick.Hirsch
oops, wrong explain, instead see 
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/explain.html 6.1, 6.2*, 
6.3.1, 6.4.2 (e.g. move away from SHA-1)

regards, Frederick

Frederick Hirsch
Nokia



On Dec 14, 2011, at 2:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

 Art
 
 I think switching the dependency to XML Signature 1.0 is a bad idea, noting 
 that 1.1 has fixed errors, and addressed security vulnerabilities, including 
 updates to algorithms (other than ecc) to address known weaknesses.
 
 details in http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/explain.html, 
 5.1, 5.5.1, 5.8, 6.6-6.8
 
 I think the W3 team is actively working on the PAG issue but have no idea 
 when we will see the result - one hope was before year end. 
 
 regards, Frederick
 
 Frederick Hirsch
 Nokia
 
 
 
 On Dec 13, 2011, at 1:14 PM, Arthur Barstow wrote:
 
 Hi All,
 
 The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 months 
 now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this PAG has just 
 started its unspecified length Fishing Expedition seeking some unspecified 
 level of funds to pay for some type of analysis that will take some unknown 
 amount of time to complete ...
 
 Given this, and not wanting to block on the ECC PAG any longer, what are the 
 options to move widgets-digsig to REC ASAP?
 
 Some options:
 
 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would 
 require a new 3-week LC but the CR could be zero-length, presumably no 
 re-testing would be required, and the only thing blocking PR-REC is the 
 length of the new CfE that would be needed.
 
 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so XMLSig1.1 
 is not affected by the PAG and XMLSig1.1 can then continue on the REC track.
 
 3. Others?
 
 (#2 seems dead simple so I'm probably missing some things.)
 
 -AB
 
 [W-DigSig] http://www.w3.org/TR/widgets-digsig/
 [XMLSig1.1] http://www.w3.org/TR/xmldsig-core1/
 [ECC-PAG] http://www.w3.org/2011/02/xmlsec-pag-charter.html
 
 




Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-14 Thread Frederick.Hirsch
I'm suggesting we let the XMLSec  PAG  conclude before taking that step (or 
another possibility), but obviously that depends on the PAG  timeline going 
forward.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 14, 2011, at 2:08 PM, Arthur Barstow wrote:

 So what about option #2 below? -AB
 
 On 12/14/11 2:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
 Art
 
 I think switching the dependency to XML Signature 1.0 is a bad idea, noting 
 that 1.1 has fixed errors, and addressed security vulnerabilities, including 
 updates to algorithms (other than ecc) to address known weaknesses.
 
 details in http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/explain.html, 
 5.1, 5.5.1, 5.8, 6.6-6.8
 
 I think the W3 team is actively working on the PAG issue but have no idea 
 when we will see the result - one hope was before year end.
 
 regards, Frederick
 
 Frederick Hirsch
 Nokia
 
 
 
 On Dec 13, 2011, at 1:14 PM, Arthur Barstow wrote:
 
 Hi All,
 
 The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 months 
 now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this PAG has just 
 started its unspecified length Fishing Expedition seeking some unspecified 
 level of funds to pay for some type of analysis that will take some unknown 
 amount of time to complete ...
 
 Given this, and not wanting to block on the ECC PAG any longer, what are 
 the options to move widgets-digsig to REC ASAP?
 
 Some options:
 
 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would 
 require a new 3-week LC but the CR could be zero-length, presumably no 
 re-testing would be required, and the only thing blocking PR-REC is the 
 length of the new CfE that would be needed.
 
 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so XMLSig1.1 
 is not affected by the PAG and XMLSig1.1 can then continue on the REC track.
 
 3. Others?
 
 (#2 seems dead simple so I'm probably missing some things.)
 
 -AB
 
 [W-DigSig] http://www.w3.org/TR/widgets-digsig/
 [XMLSig1.1] http://www.w3.org/TR/xmldsig-core1/
 [ECC-PAG] http://www.w3.org/2011/02/xmlsec-pag-charter.html
 




Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-14 Thread Frederick.Hirsch
this seems logical, in that any outcome for ECC (ranging from continued 
inclusion to removal) would have no impact on widget signature given this  lack 
of specific dependency.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 14, 2011, at 2:12 PM, ext Marcos Caceres wrote:

 
 
 On Tuesday, December 13, 2011 at 9:14 PM, Philippe Le Hegaret wrote:
 
 On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
 
 An other one was for the Director to decide to move the document forward
 anyway because W-DigSig doesn't depend on ECC.
 
 Thomas, any suggestion?
 
 
 I personally think this is the route of least pain. Widgets Dig Sig just says 
 to do whatever XML Dig Sigs says to do, and it has no explicit dependency on 
 ECC. Furthermore, no widget engine supports ECC to my knowledge and no 
 content has been signed with ECC to my knowledge. Using ECC is certainly not 
 something that is explicitly recommended in Widgets Dig Sig: 
 
 [[
 The recommended signature algorithm is RSA using the RSAwithSHA256 signature 
 identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
 The recommended key lengths are: 4096 bits for RSA.
 The recommended digest method is SHA-256.
 The recommended canonicalization algorithm is Canonical XML Version 1.1 
 (omits comments). 
 The recommended certificate format is X.509 version 3 as specified in 
 [RFC5280]. 
 ]]
 
 
 




Re: Consolidating charter changes

2011-11-10 Thread Frederick.Hirsch
+1 , separate mail list, task force, joint deliverable,  participation of 
members of both WGs.  Is there any problem remaining?

but use DAP instead of DAPI in your communications, Art :)

thanks

regards, Frederick

Frederick Hirsch
Nokia



On Nov 10, 2011, at 8:36 AM, ext Arthur Barstow wrote:

 On 11/10/11 4:36 AM, ext Robin Berjon wrote:
 Hi,
 
 On Nov 9, 2011, at 00:25 , James Hawkins wrote:
 Under 'Additions Agreed':
 * Web Intents - this will be a joint deliverable with DAPI WG
 
 Pedantically, not politically: My recollection is that the agreement was 
 only to add Web Intents to the Webapps charter (neither accepting nor 
 denying a joint deliverable with DAPI).  The status of the joint 
 deliverable is still a possibility, just technically not agreed upon as of 
 yet.  It may be best to reword this to state that the possibility still 
 exists, so those not in attendance don't get the idea that we agreed to a 
 joint deliverable at the meeting.
 My recollection, which seems to be supported by the minutes, is that Chaals 
 supported moving this to DAP, Google (collectively) wouldn't object to a 
 joint deliverable, Maciej said Apple couldn't join DAP as-is but I don't 
 recall issues with joint work. Rough consensus seemed to drift towards joint 
 work. At the DAP meeting, where the notion of a joint deliverable was 
 accepted, Jonas (amongst several others) specifically requested that this 
 happen on a separate mailing list. So unless we are keen to rathole on 
 politics I'd suggest we just go with that, no? An additional plus is that 
 doing it jointly means we can start right now and not wait for WebApps to 
 recharter.
 
 I'll have a joint TF proposal out here very soon.
 
 As the discussion on October 31 was ending, I asked if anyone objected to a 
 joint deliverable and no one did [1]. Given DAP is agreeable with cooperating 
 with WebApps on Web Intents, it seems like the most expeditious and practical 
 way forward is to create a list for related discussions.
 
 -AB
 
 [1] http://www.w3.org/2011/10/31-webapps-minutes.html#item06
 
 
 
 




Re: Reference to the HTML specification

2011-09-06 Thread Frederick.Hirsch
Hi Marcos

Are you and Ian suggesting we eliminate the publication of WD versions on the 
way to Rec and just keep the editors draft in TR space? 

A major implication relates to IPR licensing obligations, which serve to 
protect implementers. These obligations are incurred relative to steps in the 
process, e.g. First public WD publication etc.  Have you figured out  how 
editors draft in TR space would work with the W3C patent policy (maybe not an 
issue if you are saying we have both published drafts as well as editors draft 
in TR space).

The risk of not following the W3C process and not publishing FPWD is that there 
is no IPR protection for implementers of the editors draft and that members 
might drop from the WG before becoming obligated (e.g. there might be a time 
window risk here) , and in fact there may never be IPR protection if the 
editors draft never enters the W3C process. Maybe IPR is no longer an issue for 
implementers in this area of work, but I'd be surprised, given its ongoing 
importance elsewhere.

Without a process, it is not very clear who exactly has agreed to what with the 
editors draft. At a minimum we need clarity for readers that an editors draft 
is a draft and may include changes by an editor that are either mistaken, do 
not have WG agreement, or might be reverted for other reasons. 

We should review why W3C has a process - I believe in addition to IPR it 
includes a means to obtain consensus and make sure everyone is heard. Will this 
continue if we were to change along the lines you suggest? 

An alternative (and maybe this is what is under consideration) is to publish 
the editors draft in TR space in addition to the  W3C process drafts (FPWD, WD, 
LC, CR etc) and make for clarity regarding the relationship and status. In this 
case we might also consider focus on the editors draft with perhaps a different 
mechanism for linking to snapshots for W3C states (e.g. use CVS/Subversion etc 
snapshots and link from the editors draft via a process status page).

regards, Frederick

Frederick Hirsch
Nokia



On Sep 3, 2011, at 4:14 PM, ext Marcos Caceres wrote:

 
 
 On Saturday, 3 September 2011 at 20:54, Ian Hickson wrote:
 
 On Mon, 29 Aug 2011, Philippe Le Hegaret wrote:
 
 But, the WHATWG HTML links to the editor's drafts and does not link to  
 the TR one. While documents on the REC-track should link to other  
 documents on the REC tracks, this doesn't apply to editor's draft, which  
 have no special status anyway. So, you can link to both versions in the  
 editor's draft if you prefer.
 
 Well, the editor's drafts have one special status: they're the most  
 correct drafts, unlike the TR/ drafts, which are often obsolete as soon as  
 they're published (in the case of the HTML spec, they're obsolete _before_  
 they're published, since the publication process takes several days). So  
 it's not entirely true that they have no special status.
 I agree with Ian. The W3C process is really harmful in not giving Editor's 
 Drafts special status in the process. Ideally, Working Groups should be able 
 to choose if their specs are frozen or live documents on TR.  
 
 I've made this proposal several times to the W3C (pointing out how harmful 
 this has been, particularly when other consortia or implementers use W3C 
 status as an indicator of stability), and I'm hoping we can all have a 
 fruitful discussion about this during TPAC.  
 
 Can we please arrange a formal forum for this discussion and debate during 
 TPAC? I've said this a number of times, but I am getting to the point where I 
 no longer want to put anything on TR because I've seen how harmful that can 
 be (if I end up writing another spec at the W3C, I will not choose to publish 
 it on TR without HTML5-like BIG RED WARNING and only to meet the IPR 
 requirements… and continue to only link to editor's drafts).  
 
 Kind regards,
 Marcos  
 
 




Re: Indicating certificate order in XML Dig Sig

2011-07-01 Thread Frederick.Hirsch
Marcos

I have added a comment in our tracker tool regarding addition of an informative 
reference and link to XML Signature Best Practices to Introduction/References 
of XML Signature 1.1 (and implicitly XML Signature 2.0 as well).

See LC-2504 : 
http://www.w3.org/2006/02/lc-comments-tracker/42458/CR-xmldsig-core1-20110303/2504

I've also recorded and marked as resolved the issue related to certificate 
order, LC-2503, 

http://www.w3.org/2006/02/lc-comments-tracker/42458/CR-xmldsig-core1-20110303/2503

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Jun 28, 2011, at 6:16 PM, ext Marcos Caceres wrote:

 HI Fredrick, XML Sec WG,
 
 On Tue, Jun 28, 2011 at 8:43 PM,  frederick.hir...@nokia.com wrote:
 Marcos
 
 The XML Security WG discussed your proposed addition regarding certificate 
 ordering at our teleconference today [1].
 
 The Working Group does not agree to change the core XML Signature 
 specification as these would not be normative changes to that specification. 
 The XML Signature specification focuses on the details of signing but  as a 
 design choice does not detail generic PKI considerations (or details related 
 to the various KeyInfo materials that have schema places in the 
 specification) [2].
 
 
 Understood.
 
 The sense of the Working Group is that a  profile of XML Signature, such as 
 Widget SIgnature would be an appropriate place to note practices or 
 restrictions important to that specification.
 
 
 I will add this non-normative note to the Widget Signature specification.
 
 However, the XML Security WG does have a non-normative XML Signature Best 
 Practices document [3] and could add material such as this to it, which 
 would probably also make sense. Would you be able to craft language for a 
 best practice (the document uses a format of expressing the issue, a short 
 statement of the practice and then details).
 
 
 I'd be happy to proposed some text. I'll just send you whatever ends
 up in the Widget Sig specification.
 
 Additionally, it is great that the XML Security Working Group has
 created a best practices document. I would encourage the Working Group
 to link to the best practices from the Introduction of the
 specification or as a non-normative reference. Or add it under the
 Editors as a link in the header of the document, so it can be quickly
 and easily found.
 
 Again, I speak from having dealt with numerous (~7) companies trying
 to implement XML Dig Sig 1.1 + the Widgets Signature spec. There is *a
 lot* of confusion about this stuff out there and a lot of frustration
 because its super hard to find any useful guidance or information
 easily.
 
 I urge the working group, please: this is a pretty good technology and
 it's not that hard to use once you understand what is going on. The
 more guidance this working group can provide, the better. I'll do my
 bit on the Widget Dig Sig side, but you guys also have a
 responsibility to make XML Dig Sigs a pleasant experience to use (from
 a specification, implementation, and author perspective). At least
 linking to the best practices guide from the spec is a step in the
 right direction, even if you don't include a non-normative note about
 it.
 
 Kind regards,
 Marcos
 -- 
 Marcos Caceres
 http://datadriven.com.au




Re: Indicating certificate order in XML Dig Sig

2011-06-29 Thread Frederick.Hirsch
Marcos

It also occurred to me that we should have a link to the Best Practices 
document from XML Signature, so people are aware of it.
Thanks for the excellent suggestion. We will follow up on this in the XML 
Security WG.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 28, 2011, at 6:16 PM, ext Marcos Caceres wrote:

 HI Fredrick, XML Sec WG,
 
 On Tue, Jun 28, 2011 at 8:43 PM,  frederick.hir...@nokia.com wrote:
 Marcos
 
 The XML Security WG discussed your proposed addition regarding certificate 
 ordering at our teleconference today [1].
 
 The Working Group does not agree to change the core XML Signature 
 specification as these would not be normative changes to that specification. 
 The XML Signature specification focuses on the details of signing but  as a 
 design choice does not detail generic PKI considerations (or details related 
 to the various KeyInfo materials that have schema places in the 
 specification) [2].
 
 
 Understood.
 
 The sense of the Working Group is that a  profile of XML Signature, such as 
 Widget SIgnature would be an appropriate place to note practices or 
 restrictions important to that specification.
 
 
 I will add this non-normative note to the Widget Signature specification.
 
 However, the XML Security WG does have a non-normative XML Signature Best 
 Practices document [3] and could add material such as this to it, which 
 would probably also make sense. Would you be able to craft language for a 
 best practice (the document uses a format of expressing the issue, a short 
 statement of the practice and then details).
 
 
 I'd be happy to proposed some text. I'll just send you whatever ends
 up in the Widget Sig specification.
 
 Additionally, it is great that the XML Security Working Group has
 created a best practices document. I would encourage the Working Group
 to link to the best practices from the Introduction of the
 specification or as a non-normative reference. Or add it under the
 Editors as a link in the header of the document, so it can be quickly
 and easily found.
 
 Again, I speak from having dealt with numerous (~7) companies trying
 to implement XML Dig Sig 1.1 + the Widgets Signature spec. There is *a
 lot* of confusion about this stuff out there and a lot of frustration
 because its super hard to find any useful guidance or information
 easily.
 
 I urge the working group, please: this is a pretty good technology and
 it's not that hard to use once you understand what is going on. The
 more guidance this working group can provide, the better. I'll do my
 bit on the Widget Dig Sig side, but you guys also have a
 responsibility to make XML Dig Sigs a pleasant experience to use (from
 a specification, implementation, and author perspective). At least
 linking to the best practices guide from the spec is a step in the
 right direction, even if you don't include a non-normative note about
 it.
 
 Kind regards,
 Marcos
 -- 
 Marcos Caceres
 http://datadriven.com.au




Re: Indicating certificate order in XML Dig Sig

2011-06-28 Thread Frederick.Hirsch
Marcos

The XML Security WG discussed your proposed addition regarding certificate 
ordering at our teleconference today [1].

The Working Group does not agree to change the core XML Signature specification 
as these would not be normative changes to that specification. The XML 
Signature specification focuses on the details of signing but  as a design 
choice does not detail generic PKI considerations (or details related to the 
various KeyInfo materials that have schema places in the specification) [2].

The sense of the Working Group is that a  profile of XML Signature, such as 
Widget SIgnature would be an appropriate place to note practices or 
restrictions important to that specification.

However, the XML Security WG does have a non-normative XML Signature Best 
Practices document [3] and could add material such as this to it, which would 
probably also make sense. Would you be able to craft language for a best 
practice (the document uses a format of expressing the issue, a short statement 
of the practice and then details).

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

For tracker this should complete ACTION-815

[1] 
http://lists.w3.org/Archives/Public/public-xmlsec/2011Jun/att-0058/minutes-2011-06-28.html

[2] http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/

[3] http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100831/

On Jun 27, 2011, at 1:05 PM, ext Marcos Caceres marcosscace...@gmail.com wrote:

 On Mon, Jun 20, 2011 at 3:21 PM, Cantor, Scott E. canto...@osu.edu wrote:
 On 6/20/11 8:37 AM, Marcos Caceres marcosscace...@gmail.com wrote:
 Is there some means to explicitly indicate the order in which
 certificates in an xml dig sig file should be processed? The problem
 is that if you screw up the certificate order in the xml file, the
 validator (e.g,. xmlsec) does not know which cert is the end-entity.
 
 BP is EE first, the rest after (and technically the order of the rest
 isn't supposed to matter).
 
 Can I get an assurance from the XML Sec working group that a
 non-normative note will be added to the XML Dig Sig specification wrt
 to this best practice? Please consider this comment implementer
 feedback on the CR.
 
 -- 
 Marcos Caceres
 http://datadriven.com.au






Re: Indicating certificate order in XML Dig Sig

2011-06-20 Thread Frederick.Hirsch
Marcos

No there is currently no such definition of certificate order in XML Signature.

I believe this question was answered correctly on the aleksey xmlsec 
development list in the message after the one you quoted, which is why I didn't 
join the discussion:

http://www.aleksey.com/pipermail/xmlsec/2011/009175.html

This is not part of the XML Security specifications but rather how certs are 
defined and used. The cert itself can indicate its purpose.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 20, 2011, at 8:37 AM, ext Marcos Caceres wrote:

 Hi,
 Is there some means to explicitly indicate the order in which
 certificates in an xml dig sig file should be processed? The problem
 is that if you screw up the certificate order in the xml file, the
 validator (e.g,. xmlsec) does not know which cert is the end-entity.
 
 See also the following from Aleksey Sanin's, which provides a bit more detail:
 
 http://www.aleksey.com/pipermail/xmlsec/2011/009174.html
 
 TLR, Frederick, or members of XMLSec, maybe you could comment?
 
 Kind regards,
 Marcos
 
 -- 
 Marcos Caceres
 http://datadriven.com.au




Re: [widgets] Dig Sig Spec ready for pub

2011-05-23 Thread Frederick.Hirsch
Editorial comments, section 9 #4 typo Optionaly, also  formatting in  section 
9 item 3 number 7.

You might want dates for the SIgnature 1.1 and Signature Properties References?

Relying on XML Signature 1.1 for normative algorithm requirements is sensible 
in my personal opinion.

regards, Frederick

Frederick Hirsch
Nokia



On May 23, 2011, at 6:46 AM, ext Marcos Caceres wrote:

 Hi,
 I would like to republish the Widgets Dig Sig specification as LC (in 
 preparation for moving it to PR):
 
 http://dev.w3.org/2006/waf/widgets-digsig/
 
 I have also recreated the test suite to match the new specification:
 
 http://dev.w3.org/2006/waf/widgets-digsig/test-suite/
 
 Kind regards,
 Marcos
 




Re: [widgets] Dig Sig spec

2011-04-29 Thread Frederick.Hirsch
Marcos 

I'd suggest you first send an email with the top 10 substantive changes to the 
list, e.g. which algorithms change from mandatory to optional or optional to 
mandatory etc, which processing rules you are relaxing, etc

this would take less time for you and be much clearer to all.

thanks

regards, Frederick

Frederick Hirsch
Nokia



On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote:

 On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote:
 Well, you started with a relatively ambiguous characterization of a need 
 to eliminate redundancies and inconsistencies and now I see you think 
 the spec as written has resulted in willful violations of the spec and 
 of course those are quite different.
 Correct. But one really led to the other. The reality is that very few people 
 who implemented the spec really read the spec in detail. Most people seemed 
 to have been working from the examples. This is normal and to be expected. 
 Cleaning it up a bit should make it easier to follow. 
 
 Since this spec is in the Candidate state (and as such, perhaps already 
 deployed), I think it would be helpful if you would please flesh out all 
 the changes and bug(s) you propose must be fixed ^1. Then we should be 
 able to have a more informed discussion re if it's OK to have a go at 
 rewriting.
 I'm ok with that, but would prefer to do it like this: 
 
 1. make a mirror copy of the spec. 
 
 2. make all the edits I think need to be made. It's not many, as the spec is 
 relatively small (~14 pages). 
 
 3. make a diff of the two documents to build the list of changes.
 
 4. propose the complete list of changes to the group. 
 
 5. let the group decide which changes they accept or reject or need further 
 discussion. If the new spec is take wholesale, then great. Otherwise, it's 
 easy to backtrack on proposed changes. 
 
 This is how I've done this kinds of changes in the past and it's always 
 worked out ok. 
 
 
 
 




Re: [admin] TPAC2011 Oct 31-Nov 4 in Santa Clara

2011-03-17 Thread Frederick.Hirsch
DAP is planning to meet Thursday/Friday, 3-4 November.

regards, Frederick

Frederick Hirsch
Nokia



On Mar 17, 2011, at 10:44 PM, ext Arthur Barstow wrote:

 The W3C staff is trying to determine which WGs will meet f2f during the Oct 
 31 - Nov 4 TPAC meeting week in Santa Clara, CA US.
 
 The general format for the week is the same as TPAC 2011:
 
 [[
 Schedule for the week:
Group Meetings: Monday, Tuesday, Thursday, Friday
Plenary Day: Wednesday
AC Sessions: Tuesday afternoon, Wednesday Plenary and Thursday morning
 
 *There will be a small registration fee of 50 USD per day to defray a portion 
 of the meeting costs.* Please see the Meeting Overview page for additional 
 details:
 
  http://www.w3.org/2011/11/TPAC/
 ]]
 
 My inclination is to request one room for WebApps for Monday and Tuesday and 
 to fill in specific agenda items in advance and to also allocate time for 
 un-conference style, ad hoc topics (i.e. same format and schedule as TPAC 
 2010).
 
 Mike, Maciej - do you know if the HTML WG will meet that week and if so, the 
 days they will meet?
 
 All - besides the HTML WG, which I assume we do not want to overlap, are 
 there any other high priority WGs we want to either explicitly avoid 
 overlapping or explicitly overlap e.g. to facilitate joint meetings?
 
 Naturally, we will try our best to avoid scheduling conflicts with other high 
 priority WGs but the overall format of the meeting week does impose 
 constraints on the scheduling options.
 
 -Art Barstow
 
 




Re: [WebSQL/IndexedDB] Privacy issues in the wild

2010-09-23 Thread Frederick.Hirsch
Jeremy


http://dev.w3.org/html5/webstorage/#user-tracking and 
http://dev.w3.org/html5/webdatabase/#user-tracking already addresses EXACTLY 
this.  I don't think there's anything to do from a spec standpoint.

It doesn't address it from the end-user perspective . The spec says There are 
a number of techniques that can be used to mitigate the risk of user tracking, 
thus if nothing is implemented the potential end-user concern remains.

More could be done in the specification by making certain techniques mandatory 
to implement to help users avoid such tracking. Whether that is appropriate or 
would be effective is a decision to be made (or already has been).

It is useful that the issue and potential techniques are mentioned. Maybe at 
some point threats and countermeasures need to be reviewed with the various 
HTML5 specifications considered together.

regards, Frederick

Frederick Hirsch
Nokia



On Sep 8, 2010, at 5:51 AM, ext Jeremy Orlow wrote:

On Tue, Sep 7, 2010 at 7:51 PM, Nathan Kitchen 
w...@nathankitchen.commailto:w...@nathankitchen.com wrote:
Hi all.

Stumbled across this article on Ars Technica regarding the abuse of the WebSQL 
spec. I thought I'd share it here for a couple of reasons:

 1.  Someone might want to point out that it's part of the Offline Storage 
Spec, not strictly HTML5.

HTML5 is a buzz word.  Like AJAX or LAMP.  Very few people in this world 
(should) care about precisely what spec something came from.

 1.  Security implications may inform some aspects of the spec.

http://dev.w3.org/html5/webstorage/#user-tracking and 
http://dev.w3.org/html5/webdatabase/#user-tracking already addresses EXACTLY 
this.  I don't think there's anything to do from a spec standpoint.

Article: Advertisers get hands stuck inside HTML5 database cookie jar 
(http://arstechnica.com/apple/news/2010/09/rldguid-tracking-cookies-in-safari-database-form.ars)

Thanks.

Nathan




Re: RfC: Three Last Call WDs by the XML Security WG; deadline 11-May-2010

2010-05-20 Thread Frederick.Hirsch
Minor correction, the  Last Call period ends 10 June. 

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On May 17, 2010, at 11:03 AM, ext Arthur Barstow wrote:

 Below is a request to the WebApps WG for comments on 3 LCWDs produced  
 by the XML Security WG:
 
 [[
 This is a first Last Call for XML Encryption and Generic Hybrid  
 Ciphers specifications.
 
 This is a second Last Call for XML Signature 1.1, with the only  
 substantive changes being the result of Last Call feedback, as noted  
 in the status section of that document.
 ]]
 
 The comment deadline is June 11 and comments should be sent to:
 
  public-xml...@w3.org
  http://lists.w3.org/Archives/Public/public-xmlsec/
 
 -Art Barstow
 
 Begin forwarded message:
 
 From: Hirsch Frederick (Nokia-CIC/Boston)  
 frederick.hir...@nokia.com
 Date: May 17, 2010 10:48:05 AM EDT
 To: cha...@w3.org cha...@w3.org
 Cc: Hirsch Frederick (Nokia-CIC/Boston)  
 frederick.hir...@nokia.com, t...@w3.org t...@w3.org
 Subject: Transition Announcement: Last Call WD of XML Encryption  
 1.1, XML Security Generic Hybrid Ciphers and XML Signature 1.1
 Archived-At: http://www.w3.org/mid/3DDBC759- 
 e95c-4935-96be-1464cbc4e...@nokia.com
 
 1) This is a Last Call Working Draft transition announcement for  
 three Recommendation track specifications.
 
 This is a first Last Call for XML Encryption and Generic Hybrid  
 Ciphers specifications. This is a second Last Call for XML  
 Signature 1.1, with the only substantive changes being the result  
 of Last Call feedback, as noted in the status section of that  
 document.
 
 (2) Document title, URIs.
 
 2a) XML Encryption Syntax and Processing Version 1.1
 
 http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/
 
 2b) XML Security Generic Hybrid Ciphers
 
 http://www.w3.org/TR/2010/WD-xmlsec-generic-hybrid-20100513/
 
 2c) XML Signature Syntax and Processing Version 1.1
 
 http://www.w3.org/TR/2010/WD-xmldsig-core1-20100513/
 
 (3) Instructions for providing feedback.
 
 If you wish to make comments regarding these documents, please send  
 them to public-xml...@w3.org. The list is archived at http:// 
 lists.w3.org/Archives/Public/public-xmlsec/
 
 (4) Review end date.
 
 This Last Call period is for four weeks and will end 10 June 2010.
 
 (5) A reference to the group's decision to make this transition.
 
 The XML Security agreed to making this Last Call transition at its  
 teleconference on 11 May 2010, see http://www.w3.org/2010/05/11- 
 xmlsec-minutes.html#item06
 
 (6) Evidence that the document satisfies group's requirements.  
 Include a link to requirements
 
 The XML Security Working Group believe this document satisfies the  
 XML Encryption and XML Signature requirements as outlined in the   
 XML Security 1.1 Requirements and Design Considerations  document,  
 see http://www.w3.org/TR/2010/WD-xmlsec-reqs-20100204/
 
 (7) The names of groups with dependencies, explicitly inviting  
 review from them.
 
 7a) Web Applications Working Group (WebApps), http://www.w3.org/ 
 2008/webapps/
 
 The Web Applications Working Group  Digital Signatures for  
 Widgets specification has a dependency on XML Signature 1.1,  
 however the
 substantive changes in XML Signature 1.1 are for features not used  
 by  that specification ( http://www.w3.org/TR/2010/WD-widgets- 
 digsig-20100511/
 ). The XML Security Working Group requests review from the Web  
 Applications WG of the XML Signature 1.1 Last Call specification,
 
 7b) Efficient XML Interchange Working Group (EXI), http:// 
 www.w3.org/XML/EXI/
 
 The XML Security WG has made changes to the XML Encryption 1.1  
 specification to clarify use with EXI formats. The XML Security  
 Working Group requests EXI WG review of XML Encryption 1.1 Last  
 Call specification.
 
 (8) Report of any Formal Objections
 
 The Working Group has received no formal objections.
 
 The Working Group has noted the following in the Status of the  
 Document in XML Signature 1.1 and XML Encryption 1.1:
 
 This Last Call Working Draft includes the ECDSAwithSHA256  
 signature  algorithm, which is ECDSA over the P-256 prime curve  
 specified in  Section D.2.3 of FIPS 186-3 [FIPS-186-3] (and using  
 the SHA-256 hash algorithm), as a mandatory to implement algorithm.  
 The Working Group  may request transition to Candidate  
 Recommendation with this feature  marked as at risk. If issues  
 about deployment of this feature are raised during Candidate  
 Recommendation, the group may elect to make this feature optional.
 
 (9) A link to a patent disclosure page.
 
 http://www.w3.org/2004/01/pp-impl/42458/status
 
 The WG is also publishing an update to the XML Security Algorithm  
 Cross-Reference, intended to become a Working Group Note, http:// 
 www.w3.org/TR/2010/WD-xmlsec-algorithms-20100513/
 .
 
 regards, Frederick
 
 Frederick Hirsch, Nokia
 Chair XML Security WG