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

[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
> 
> 
> 
> 

Re: Rough summary of minutes from the face to face

[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://l

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

[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

Declarative invocation and progressing Web Intents

[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.com
To: jhawk...@google.com
CC: public-web-inte...@w3.org; 
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 
i

Re: random numbers API

[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?

[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?

[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?

[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=subject&hdr-1-query=certicom&index-grp=Public_FULL&index-type=t&type-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?

[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: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

[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?

[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?

[Frederick.Hirsch]

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: Consolidating charter changes

[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

[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

[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,   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

[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,   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

[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.  wrote:
>> On 6/20/11 8:37 AM, "Marcos Caceres"  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

[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

[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

[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

[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

[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 
mailto: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

[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)"  
>> 
>> Date: May 17, 2010 10:48:05 AM EDT
>> To: "cha...@w3.org" 
>> Cc: "Hirsch Frederick (Nokia-CIC/Boston)"  
>> , "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: > 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/
>> .
>> 
>> reg