date:20090319

Ok, here is my first crack at specifying this...If you prefer to read
it in the spec (so you can follow any cross references, etc), then
please check out:

http://dev.w3.org/2006/waf/widgets/#element-based-content-localization

[[
==Element-based Content Localization==
This specification defines the notion of element-based content
localization, which allows authors to use the xml:lang attribute as a
means to localize the content of certain XML elements that are part of
the configuration document.

As part of their definition, the XML elements of the configuration
document are marked as being localizable via xml:lang with the keyword
"yes" or "no".

If an element is marked as being localizable with the "no" keyword
(meaning that it is not localizable via element-based localization),
the user agent must not attempt to do any localization of that element
in the manner described in this section regardless of whether the
element contains an xml:lang attribute.

Note: Some elements marked as not being localizable via xml:lang, such
as screenshot and icon elements, are localizable via folder-based
content localization.

If an element is marked as being localizable with the "yes" keyword,
the user agent must attempt to match one or more elements against the
user agent's locale. To perform element matching for the purpose of
localization, the user agent must use the lookup mechanism as defined
in section 3.4 of [RFC4647] (part of [BCP47]) to match, in document
order, one of the language ranges in the ua-language list to one or
more element in the configuration document. How matching is performed
by the user agent depends on whether one element is allowed per
language or whether elements are grouped by language, as defined
below.

=One element is allowed per language=
This means that only one element of this type is allowed per language,
so the user agent must only use the first element, in document order,
that matches the user agent's locale and ignore any subsequent
repetitions of the element that contain a matching xml:lang value
(even if the content of any proceeding matching element is different).

For example, assume the user agent's locale is "en-us" (English as
used in the United States). As only one instance of the description
element is allowed per language, in the following code the user agent
would match the first description element but would ignore the second
(and any other subsequent) description element.

http://www.w3.org/ns/widgets";>

  This element would be used.

  This element would be ignored.

  This element would be used if the user agent's
  locale does not match any localized description
  elements.

However, if the user agent's locale was "*", or did not match any of
the localized description elements, then the user agent would match
the third description element above.

=Elements are grouped by language=
This means that the user agent must match all elements of a particular
type that match the user agent's locale.

For example, assume that the user agent's locale is "pt-br"
(Portuguese as used in Brazil). As multiple instance of the preference
element are allowed per language in the configuration document, so the
user agent would match the third and fourth preference elements below.

http://www.w3.org/ns/widgets";>

However, if the user agent's locale was "*", or did not match any of
the localized preference elements, then the user agent would match the
fifth and sixth preference elements above.

]]

Kind regards,
Marcos
On Thu, Mar 19, 2009 at 5:21 PM, Marcos Caceres  wrote:
> On Thu, Mar 19, 2009 at 5:07 PM,   wrote:
>> The reason why the I18N BP document frowns upon this is because if you have
>> the material sent for translation, it might (or most probably will) be
>> translated by different people in different places. So it makes coordination
>> a little difficult when all the different language texts are in the same
>> file. That is a big problem if you have substantial amounts of text in the
>> file. In the case of widgets, there might not be such huge amounts of text
>> in the config file, so that’s a mitigating circumstance for this horrible
>> negligence. :-)
>
> I see.
>
>> Let’s assess how much translatable text there would be in a config file in
>> the worst case, and then decide if we know well enough to break the best
>> practice or not.
>>
>> Marcos came up with the following list:
>>
>> The following elements would be localizable:
>>
>> widget (but no id or version, derived from root config, if available)
>>  name
>>  description
>>  author
>>  license
>>  icon
>>  content
>>  preference
>>  screenshot
>>
>> (BTW Marcos, are you sure “content” and “preference” should be there? Also
>> maybe author should be dropped. License I can understand, but probably not
>> to be used to present different versions of a license, just translations of
>> the same license.)
>
> I'm ok to drop author.
>
>

Re: [CORS] Charset in content type

2009-03-19 Thread Giovanni Campagna

2009/3/19 Jonas Sicking :
> [...]
>
> Two things that I think we need to watch out for:
>
> 1. Someone doing
>    xhr.setRequestHeader("Content-Type", "text/plain; application/xml");
>
> 2. Someone doing
>    xhr.setRequestHeader("Content-Type", "text/plain;
> somewierdthing=application/xml");
>
> Especially the first might be tricky since we don't know which
> mimetype the server will use. I was going to make our implementation
> require that there is only one "empty" parameter, and optionally a
> charset.

Actually both of them are invalid per RFC2616 and thus should raise SYNTAX_ERR.
Or actually, they don't per current spec, but I think they should.
(and anyway RFC2616 is not very clear about the field-value production)

> [...]
>
> / Jonas
>
>

Giovanni

Re: [CORS] Charset in content type

2009-03-19 Thread Jonas Sicking

On Tue, Mar 17, 2009 at 6:40 AM, Anne van Kesteren  wrote:
> On Mon, 16 Mar 2009 11:12:01 -, Anne van Kesteren 
> wrote:
>>
>> On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov 
>> wrote:
>>>
>>> I think that the algorithm can only compare MIME types, not the full
>>> Content-Type string.
>>
>> I guess that makes sense.
>
> I made this change now (defined in the "simple header" definition), but I
> left the ASCII case-insensitive comparison for now. If we really want
> normalization we should do that for XMLHttpRequest in general I think.

Two things that I think we need to watch out for:

1. Someone doing
xhr.setRequestHeader("Content-Type", "text/plain; application/xml");

2. Someone doing
xhr.setRequestHeader("Content-Type", "text/plain;
somewierdthing=application/xml");

Especially the first might be tricky since we don't know which
mimetype the server will use. I was going to make our implementation
require that there is only one "empty" parameter, and optionally a
charset.

As for where the normalization is done, I don't really care. But since
every spec using CORS will have to do the same normalization it seems
like doing that in the CORS spec makes more sense.

/ Jonas

Re: [XHR2] Upload progress events and simple cross-origin requests

2009-03-19 Thread Alexey Proskuryakov



19.03.2009, в 21:00, Jonas Sicking написал(а):


While I agree that there are other ways of doing this, I think I'd
have a really hard time selling a feature that explicitly allows port
scanning to our security team. Especially when there is an easy
remedy.



The price comes mainly in the form of developer time - first, they  
will be inconvenienced by arbitrary restrictions on when they can  
install event listeners, and then (but more significantly), they'll  
have to implement OPTIONS server-side, even if they didn't need it  
otherwise. There is also some price in performance due to making a  
preflight request, although I guess it's negligible in cases when  
upload progress events will be used. Finally, there can potentially be  
a compatibility problem if some proxy is not configured to pass  
OPTIONS requests, but I do not have any data on whether that's likely.


That said, I don't care too much either way.

- WBR, Alexey Proskuryakov

Re: [XHR2] Upload progress events and simple cross-origin requests

2009-03-19 Thread Jonas Sicking

On Thu, Mar 19, 2009 at 12:29 AM, Ian Hickson  wrote:
> On Thu, 19 Mar 2009, Alexey Proskuryakov wrote:
>>
>> In fact, it seems very likely that even timing of preflight requests
>> makes port scans possible, but I don't have any data to support this
>> theory.
>
> Port scans are already possible with unscripted HTML using  elements
> and , and are certainly already possible with
>  elements and onload=""/onerror="" events. We lost this particular
> battle a decade and a half ago when nobody was looking.

While I agree that there are other ways of doing this, I think I'd
have a really hard time selling a feature that explicitly allows port
scanning to our security team. Especially when there is an easy
remedy.

/ Jonas

Re: [widget-digsig] Editorial update of Widget Signature

Awesome! thanks. I'll do the cleanup ASAP.

On Thu, Mar 19, 2009 at 5:17 PM, Frederick Hirsch
 wrote:
> Completed additional changes to Editorial note in section 6, added links to
> XML Security WG home page, list of comments on FPWD and mailto link for
> comments on XML Signature 1.1.
>
> Also fixed editorial nit, "final set" to "a final set"
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Mar 19, 2009, at 11:45 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
>
>> I have completed the following editorial update of Widget Signature [1]:
>>
>> 1. Added proposed change to 7.1
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0827.html
>>
>> also added minor change in response to review comment from Mark:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0853.html
>>
>> 2. Added editorial note to section 6, algorithms
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0851.html
>>
>> with some editorial tweaks (expanding acronyms etc)
>>
>> 3. Added new section 9, "Draft update to XML SIgnature Properties"
>>
>> This section records new sections in the current XML Signature
>> Properties editors draft that are not reflected in the First Public
>> Working draft of that document. They are included here so reviewers
>> can see the referenced material. The section includes an editors note
>> explaining the status of the section.
>>
>> The WG agreed earlier that we would add this material.
>>
>> 4. Changed "Security Policy" to lowercase as appropriate.
>>
>> This should complete all my editorial actions before publication.
>> Please review and  let me know of any corrections or noted omissions.
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>> [1] http://dev.w3.org/2006/waf/widgets-digsig/
>>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 5:07 PM,   wrote:
> The reason why the I18N BP document frowns upon this is because if you have
> the material sent for translation, it might (or most probably will) be
> translated by different people in different places. So it makes coordination
> a little difficult when all the different language texts are in the same
> file. That is a big problem if you have substantial amounts of text in the
> file. In the case of widgets, there might not be such huge amounts of text
> in the config file, so that’s a mitigating circumstance for this horrible
> negligence. :-)

I see.

> Let’s assess how much translatable text there would be in a config file in
> the worst case, and then decide if we know well enough to break the best
> practice or not.
>
> Marcos came up with the following list:
>
> The following elements would be localizable:
>
> widget (but no id or version, derived from root config, if available)
>  name
>  description
>  author
>  license
>  icon
>  content
>  preference
>  screenshot
>
> (BTW Marcos, are you sure “content” and “preference” should be there? Also
> maybe author should be dropped. License I can understand, but probably not
> to be used to present different versions of a license, just translations of
> the same license.)

I'm ok to drop author.

Content I think we should keep because you might need different start
files for different langs to achieve particular layouts.

Preferences i don't feel too strongly about, but I can see use cases
for having localized preferences.

License, I agree, but there is obviously no way to check if it is a
translation, but we could certainly put in a Authoring Guideline.

> All of these seem to have a fairly limited amount of translatable /
> localizable content, so would the ease of processing and the general
> simplification warrant the possible inconvenience in having the text
> translated? The license seems to be the biggest block of translatable text,
> and therefore potentially the biggest problem.

I guess as it is one element, it should not bee too much drama.

> (NOTE: A system for widget authoring that is connected to the back-end of
> the vendor’s translation memory / CMS could generate the config file
> automatically, eliminating the need to translate the actual config files by
> hand. Translations and other localized material can be assembled into the
> CMS prior to generating the config file.)

Agreed.


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widget-digsig] Editorial update of Widget Signature

Completed additional changes to Editorial note in section 6, added  
links to XML Security WG home page, list of comments on FPWD and  
mailto link for comments on XML Signature 1.1.


Also fixed editorial nit, "final set" to "a final set"

regards, Frederick

Frederick Hirsch
Nokia



On Mar 19, 2009, at 11:45 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

I have completed the following editorial update of Widget Signature  
[1]:


1. Added proposed change to 7.1

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0827.html


also added minor change in response to review comment from Mark:

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0853.html


2. Added editorial note to section 6, algorithms

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0851.html


with some editorial tweaks (expanding acronyms etc)

3. Added new section 9, "Draft update to XML SIgnature Properties"

This section records new sections in the current XML Signature
Properties editors draft that are not reflected in the First Public
Working draft of that document. They are included here so reviewers
can see the referenced material. The section includes an editors note
explaining the status of the section.

The WG agreed earlier that we would add this material.

4. Changed "Security Policy" to lowercase as appropriate.

This should complete all my editorial actions before publication.
Please review and  let me know of any corrections or noted omissions.

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/

Re: [widgets] Further argument for making config.xml mandatory

2009-03-19 Thread Jere.Kapyaho

On 19.3.2009 17.43, "ext Marcos Caceres"  wrote:

On Thu, Mar 19, 2009 at 4:36 PM, Andrew Welch  wrote:
>> To be clear, the proposal is:
>> http://www.w3.org/ns/widgets";>
>>   Mon widget
>>   My Widget
>>   Widget
>> 
>
> heh... be careful that looks very similar to this "Best Practice":
>
> "Avoid document formats that store multiple localized versions of
> content within the same document."
>
> http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc
>
> :)

That's exactly what I was talking about when I said "even thought the XML i18n
guidelines say it's bad practice,'. However, Addison Phillips, the
Chair of i18n core, said the following in the formal feedback
representing the i18n WG's LC comments for the spec [1]:

"Section 7.4 (Widget) The various language bearing elements such as
, , etc. are of the zero-or-one type. However, it
is typically better to allow any number of these elements to occur,
provided that none share the same xml:lang. This allows for
localization (which is part of the point in allowing xml:lang on the
element)."

So we have been blessed by them to do this... umm this somewhat
questionable, yet problem solving thing :)

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html

The reason why the I18N BP document frowns upon this is because if you have the 
material sent for translation, it might (or most probably will) be translated 
by different people in different places. So it makes coordination a little 
difficult when all the different language texts are in the same file. That is a 
big problem if you have substantial amounts of text in the file. In the case of 
widgets, there might not be such huge amounts of text in the config file, so 
that's a mitigating circumstance for this horrible negligence. :-)

Let's assess how much translatable text there would be in a config file in the 
worst case, and then decide if we know well enough to break the best practice 
or not.

Marcos came up with the following list:

The following elements would be localizable:
widget (but no id or version, derived from root config, if available)
 name
 description
 author
 license
 icon
 content
 preference
 screenshot

(BTW Marcos, are you sure "content" and "preference" should be there? Also 
maybe author should be dropped. License I can understand, but probably not to 
be used to present different versions of a license, just translations of the 
same license.)

All of these seem to have a fairly limited amount of translatable / localizable 
content, so would the ease of processing and the general simplification warrant 
the possible inconvenience in having the text translated? The license seems to 
be the biggest block of translatable text, and therefore potentially the 
biggest problem.

(NOTE: A system for widget authoring that is connected to the back-end of the 
vendor's translation memory / CMS could generate the config file automatically, 
eliminating the need to translate the actual config files by hand. Translations 
and other localized material can be assembled into the CMS prior to generating 
the config file.)

Any further thoughts?

--Jere

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch  wrote:
>> That's exactly what I was talking about when I said "even thought the XML 
>> i18n
>> guidelines say it's bad practice,'.
>
> Ahh very sorry, I just saw the email after that containing the code
> sample, and gmail collapses the quoted parts my bad.
>
>
>> However, Addison Phillips, the
>> Chair of i18n core, said the following in the formal feedback
>> representing the i18n WG's LC comments for the spec [1]:
>>
>> "Section 7.4 (Widget) The various language bearing elements such as
>> , , etc. are of the zero-or-one type. However, it
>> is typically better to allow any number of these elements to occur,
>> provided that none share the same xml:lang. This allows for
>> localization (which is part of the point in allowing xml:lang on the
>> element)."
>>
>> So we have been blessed by them to do this... umm this somewhat
>> questionable, yet problem solving thing :)
>>
>> [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html
>
> That's interesting, because xml:lang seems pretty redundant otherwise!

Alright, lets see a show of hands for this approach! Who supports us
just having a single config.xml with a bunch of repeated elements, but
with different xml:langs?

Advantages here are:
  *  we only need to make very small modifications to the parsing model.
  *  no more searching for config docs in locale folders
  *  no multiple parsing of config files

Disadvantages:
 * large, and, if not careful, hard to maintain config files

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

2009-03-19 Thread Andrew Welch

> That's exactly what I was talking about when I said "even thought the XML i18n
> guidelines say it's bad practice,'.

Ahh very sorry, I just saw the email after that containing the code
sample, and gmail collapses the quoted parts my bad.


> However, Addison Phillips, the
> Chair of i18n core, said the following in the formal feedback
> representing the i18n WG's LC comments for the spec [1]:
>
> "Section 7.4 (Widget) The various language bearing elements such as
> , , etc. are of the zero-or-one type. However, it
> is typically better to allow any number of these elements to occur,
> provided that none share the same xml:lang. This allows for
> localization (which is part of the point in allowing xml:lang on the
> element)."
>
> So we have been blessed by them to do this... umm this somewhat
> questionable, yet problem solving thing :)
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html

That's interesting, because xml:lang seems pretty redundant otherwise!



-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

[widget-digsig] Editorial update of Widget Signature


I have completed the following editorial update of Widget Signature [1]:

1. Added proposed change to 7.1

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0827.html

also added minor change in response to review comment from Mark:

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0853.html

2. Added editorial note to section 6, algorithms

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0851.html

with some editorial tweaks (expanding acronyms etc)

3. Added new section 9, "Draft update to XML SIgnature Properties"

This section records new sections in the current XML Signature  
Properties editors draft that are not reflected in the First Public  
Working draft of that document. They are included here so reviewers  
can see the referenced material. The section includes an editors note  
explaining the status of the section.


The WG agreed earlier that we would add this material.

4. Changed "Security Policy" to lowercase as appropriate.

This should complete all my editorial actions before publication.  
Please review and  let me know of any corrections or noted omissions.


regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:36 PM, Andrew Welch  wrote:
>> To be clear, the proposal is:
>> http://www.w3.org/ns/widgets";>
>>   Mon widget
>>   My Widget
>>   Widget
>> 
>
> heh... be careful that looks very similar to this "Best Practice":
>
> "Avoid document formats that store multiple localized versions of
> content within the same document."
>
> http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc
>
> :)

That's exactly what I was talking about when I said "even thought the XML i18n
guidelines say it's bad practice,'. However, Addison Phillips, the
Chair of i18n core, said the following in the formal feedback
representing the i18n WG's LC comments for the spec [1]:

"Section 7.4 (Widget) The various language bearing elements such as
, , etc. are of the zero-or-one type. However, it
is typically better to allow any number of these elements to occur,
provided that none share the same xml:lang. This allows for
localization (which is part of the point in allowing xml:lang on the
element)."

So we have been blessed by them to do this... umm this somewhat
questionable, yet problem solving thing :)

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html

-- 
Marcos Caceres
http://datadriven.com.au

Re: [widget-digsig] Editors note to be added to widget signature

On Thu, Mar 19, 2009 at 2:57 PM, Frederick Hirsch
 wrote:
> revised to be as follows, now that I look at it more closely:
>
> Note:
>
> The Web Applications WG is seeking feedback on required  algorithms for
> widget signatures, in particular which algorithms should be required in
> addition to RSAwithSHA256. The WG has not yet agreed on final set of
> required algorithms.

"on final set" -> "on a final set"

> This Widget Signature specification relies on XML SIgnature 1.1 which
> introduces new and stronger algorithms to XML Signature. The XML Security WG
> has not yet achieved consensus on required  algorithms in XML SIgnature 1.1,
> in particular whether to mandate
> ECDSAwithSHA256. The XML Security WG is also requesting feedback on the
> FPWD of XML SIgnature 1.1.
>

Looks good to me.


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

2009-03-19 Thread Andrew Welch

> To be clear, the proposal is:
> http://www.w3.org/ns/widgets";>
>   Mon widget
>   My Widget
>   Widget
> 

heh... be careful that looks very similar to this "Best Practice":

"Avoid document formats that store multiple localized versions of
content within the same document."

http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc

:)


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:30 PM, Marcos Caceres  wrote:
> On Thu, Mar 19, 2009 at 4:22 PM,   wrote:
>> I still think that more than one config document is the most confusing
>> aspect of this. Having just one (mandatory) config document, with the
>> localized parts tagged with xml:lang attributes would be the simplest.
>> However, as I understand it, the separate config files were recommended by
>> the W3C I18N group.
>>
>> If this decision would be reversed, then anything in the config document
>> that could (as per the schema) have an xml:lang attribute would by
>> definition be localizable/localized. Others (like id, version etc.) would
>> not be. That would also free the implementation from collecting all the
>> various config documents, just to create and store an intersection of the
>> elements. If you have two values for the same element, then who wins? The
>> most specific (from the config in the localized folder), or the least
>> specific (the default/fallback one from the root)?
>>
>> Proposal (feel free to ignore, due to pressure to be feature complete): make
>> the config file mandatory, but allow it only in the root, then allow
>> multiple elements with unique xml:lang attributes for those elements that
>> are localizable.
>>
>
> True, that would solve this whole mess. Even thought the XML i18n
> guidelines say it's bad practice, Addison Phillip of the i18n WG
> suggested we do this in the LC feedback. I emailed them about a month
> ago asking them if that is the right way to go, but never got a
> response. So I say we go with Jere's proposal here.
>

To be clear, the proposal is:
http://www.w3.org/ns/widgets";>
   Mon widget
   My Widget
   Widget


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:22 PM,   wrote:
> I still think that more than one config document is the most confusing
> aspect of this. Having just one (mandatory) config document, with the
> localized parts tagged with xml:lang attributes would be the simplest.
> However, as I understand it, the separate config files were recommended by
> the W3C I18N group.
>
> If this decision would be reversed, then anything in the config document
> that could (as per the schema) have an xml:lang attribute would by
> definition be localizable/localized. Others (like id, version etc.) would
> not be. That would also free the implementation from collecting all the
> various config documents, just to create and store an intersection of the
> elements. If you have two values for the same element, then who wins? The
> most specific (from the config in the localized folder), or the least
> specific (the default/fallback one from the root)?
>
> Proposal (feel free to ignore, due to pressure to be feature complete): make
> the config file mandatory, but allow it only in the root, then allow
> multiple elements with unique xml:lang attributes for those elements that
> are localizable.
>

True, that would solve this whole mess. Even thought the XML i18n
guidelines say it's bad practice, Addison Phillip of the i18n WG
suggested we do this in the LC feedback. I emailed them about a month
ago asking them if that is the right way to go, but never got a
response. So I say we go with Jere's proposal here.

-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 4:20 PM, Andrew Welch  wrote:
>>> Other suggestions are of course welcome!
>>>
>>> One alternative would be to separate out the non-localisable data into a 
>>> separate document, eg manifest.xml... But this is also likely to irritate 
>>> implementers :(
>>>
>>
>> No, the WG are saving manifest.xml for an actual manifest format. Lets
>> keep it in the config. How was that list of localizable elements
>> working for you?
>
> The way JavaFx does it might be of interest, for example a simple
> hello world message:
>
> ##[greeting]"Hello, World."
>
> The value in ##[  ] is the key which is looked up against traditional
> resource bundle files that are named and stored in standard ways, and
> the "Hello World" is the default value if the key doesn't exist for
> the given locale.
>
> The key part is optional, so you can just have "Hello World".
>
> So perhaps the localizable values in the main config could use that
> syntax, rather than you have specify a list of "localizable elements"

We looked at that a while back. We don't like that a developer needs
to pollute their code with various document.write or element.innerHTML
calls/hooks to achieve localization.  Having said that, the current
localization model does not preclude authors from using that
localization method.

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

2009-03-19 Thread Jere.Kapyaho

I still think that more than one config document is the most confusing aspect 
of this. Having just one (mandatory) config document, with the localized parts 
tagged with xml:lang attributes would be the simplest. However, as I understand 
it, the separate config files were recommended by the W3C I18N group.

If this decision would be reversed, then anything in the config document that 
could (as per the schema) have an xml:lang attribute would by definition be 
localizable/localized. Others (like id, version etc.) would not be. That would 
also free the implementation from collecting all the various config documents, 
just to create and store an intersection of the elements. If you have two 
values for the same element, then who wins? The most specific (from the config 
in the localized folder), or the least specific (the default/fallback one from 
the root)?

Proposal (feel free to ignore, due to pressure to be feature complete): make 
the config file mandatory, but allow it only in the root, then allow multiple 
elements with unique xml:lang attributes for those elements that are 
localizable.

--Jere

On 19.3.2009 16.24, "ext Marcos Caceres"  wrote:

On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group
 wrote:
> Hi Marcos, All,
>
> I would like to raise a comment in support of making the configuration
> document at the root of the widget mandatory.
>
> The localisation model currently described by [1] allows for multiple
> configuration documents; zero or one at the root of the widget and zero or
> one at the root of each locales folder.
>
> While we support the approach of allowing localisation of the configuration
> document (with the addition of the fallback mechanism that has been
> previously discussed), one concern we had with such an approach was that it
> doesn't make sense to localise some of the information in the
> configuration document, for example: the feature element, (the replacement
> for) the access element, the license element, the id and version attributes
> (and maybe others?). In fact in some cases, allowing different values
> could present security risks.
>
> Previously we (Vodafone) had considered an approach of requiring user agents
> to, for example, create a list of all feature elements present in any valid
> configuration document. We had not yet thought how to handle the case in
> which the different configuration documents contain different id attribute
> values.
>
> However, now that there is a proposal to make the configuration document at
> the root of the widget mandatory, I would like to propose that a better
> (although not pretty) solution would be specify which attributes and
> elements are localisable. The non-localisable attributes / elements would
> only be valid if included in the configuration document at the root of the
> widget.
>
> Thoughts?

Proposal: not localizable:
's id and version attributes.
 and its 

The following elements would be localizable:
 widget (but no id or version, derived from root config, if available)
 name
 description
 author
 license
 icon
 content
 preference
 screenshot

FWIW, I think this will confuse authors... and irritate the poor souls
who need to implement this :)

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

2009-03-19 Thread Andrew Welch

>> Other suggestions are of course welcome!
>>
>> One alternative would be to separate out the non-localisable data into a 
>> separate document, eg manifest.xml... But this is also likely to irritate 
>> implementers :(
>>
>
> No, the WG are saving manifest.xml for an actual manifest format. Lets
> keep it in the config. How was that list of localizable elements
> working for you?

The way JavaFx does it might be of interest, for example a simple
hello world message:

##[greeting]"Hello, World."

The value in ##[  ] is the key which is looked up against traditional
resource bundle files that are named and stored in standard ways, and
the "Hello World" is the default value if the key doesn't exist for
the given locale.

The key part is optional, so you can just have "Hello World".

So perhaps the localizable values in the main config could use that
syntax, rather than you have specify a list of "localizable elements"



-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

Re: [widgets] s on s

Hi, here is a draft of for the option element... which I've renamed
param ("inspired" by HTML5;))

=The param Element=
The param element defines a parameter for a feature. A parameter is
name-value pair that a user agent must pass to the corresponding
feature for which the parameter is declared for. The relationship of a
parameter to a feature is established by having a param element as a
direct child of a feature element.

Outside the context of a feature element, a param element does not
represent anything and a user agent must ignore it.

Context in which this element may be used:
  As a child of the feature element.
Content model:
 Empty.
Occurrences:
  Zero or more.

==Attributes==
name
 Required. A string, which may be empty, that denotes the name of this
parameter.
value
 Required. A string, which may be empty, that denotes the value of
this parameter.

Kind regards,
Marcos

On Thu, Mar 19, 2009 at 11:26 AM, Marcos Caceres  wrote:
> Hi Robin,
>
> On Thu, Mar 19, 2009 at 7:34 AM, Marcos Caceres  wrote:
>> On Thu, Mar 19, 2009 at 7:27 AM, Robin Berjon  wrote:
>> Will fix required. Required denotes if a feature is absolutely needed
>> for the widget to function (i.e., without this feature, the widget
>> serves no purpose.)
>>
>
> I've simplified the  element a bit (removed feature fall back
> behavior, which we may reintroduce in 1.1 or 2.0 or whatever). I tried
> to make the definition of the required attribute more clear.  The new
> def is as follows:
>
> [[
> =The feature Element=
> A feature is a runtime component (e.g. an API) that is not part of the
> standard set provided by the Widgets 1.0 family of specifications.
> Using a feature element denotes that, at runtime, a widget may attempt
> to access the feature identified by the feature element's name
> attribute.
>
> Note: the feature element is not a means to import javascript
> libraries or other resources available on the Web. The feature element
> should be viewed as a standardized way to request the binding of an
> (URI) identifiable runtime component to a widget for use at runtime.
>
> Context in which this element may be used:
>   In the widget element.
> Content model:
>  Empty.
> Occurrences:
>  Zero or more.
>
> ==Attributes==
>
> name
>  Required. A URI attribute that identifies a feature that may be
> needed by the widget at runtime (such as an API).
>
> required
>  Optional. A boolean attribute that indicates whether or not this
> feature must be available to the widget at runtime. In other words,
> the required attribute denotes that a feature is absolutely needed by
> the widget to function correctly, and without the availability of this
> feature the widget serves no useful purpose or won't execute properly.
> The default value when this attribute is absent is true, meaning that
> the feature is must be made available to the widget by the widget at
> runtime.
>
> ==Usage example==
> This example demonstrates a widget that would like to use a fictional
> geolocation API feature, but would still be able to function if the
> feature cannot be made available to the widget by the user agent.
>
> http://www.w3.org/ns/widgets";>
>   http://example.org/api.geolocation";
>            required="false"/>
> 
>
> ]]
>
> --
> Marcos Caceres
> http://datadriven.com.au
>



-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 3:54 PM, Priestley, Mark, VF-Group
 wrote:
>>FWIW, I think this will confuse authors... and irritate the
>>poor souls who need to implement this :)
>
> Other suggestions are of course welcome!
>
> One alternative would be to separate out the non-localisable data into a 
> separate document, eg manifest.xml... But this is also likely to irritate 
> implementers :(
>

No, the WG are saving manifest.xml for an actual manifest format. Lets
keep it in the config. How was that list of localizable elements
working for you?

-- 
Marcos Caceres
http://datadriven.com.au

RE: [widgets] Further argument for making config.xml mandatory

>FWIW, I think this will confuse authors... and irritate the 
>poor souls who need to implement this :)

Other suggestions are of course welcome! 

One alternative would be to separate out the non-localisable data into a 
separate document, eg manifest.xml... But this is also likely to irritate 
implementers :(  
 

>-Original Message-
>From: marcosscace...@gmail.com 
>[mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres
>Sent: 19 March 2009 14:25
>To: Priestley, Mark, VF-Group
>Cc: public-webapps@w3.org
>Subject: Re: [widgets] Further argument for making config.xml mandatory
>
>On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group 
> wrote:
>> Hi Marcos, All,
>>
>> I would like to raise a comment in support of making the 
>configuration 
>> document at the root of the widget mandatory.
>>
>> The localisation model currently described by [1] allows for 
>multiple 
>> configuration documents; zero or one at the root of the widget and 
>> zero or one at the root of each locales folder.
>>
>> While we support the approach of allowing localisation of the 
>> configuration document (with the addition of the fallback mechanism 
>> that has been previously discussed), one concern we had with such an 
>> approach was that it doesn't make sense to localise some of the 
>> information in the configuration document, for example: the feature 
>> element, (the replacement
>> for) the access element, the license element, the id and version 
>> attributes (and maybe others?). In fact in some cases, allowing 
>> different values could present security risks.
>>
>> Previously we (Vodafone) had considered an approach of 
>requiring user 
>> agents to, for example, create a list of all feature 
>elements present 
>> in any valid configuration document. We had not yet thought how to 
>> handle the case in which the different configuration 
>documents contain 
>> different id attribute values.
>>
>> However, now that there is a proposal to make the configuration 
>> document at the root of the widget mandatory, I would like 
>to propose 
>> that a better (although not pretty) solution would be specify which 
>> attributes and elements are localisable. The non-localisable 
>> attributes / elements would only be valid if included in the 
>> configuration document at the root of the widget.
>>
>> Thoughts?
>
>Proposal: not localizable:
>'s id and version attributes.
> and its 
>
>
>The following elements would be localizable:
> widget (but no id or version, derived from root config, if 
>available)  name  description  author  license  icon  content  
>preference  screenshot
>
>FWIW, I think this will confuse authors... and irritate the 
>poor souls who need to implement this :)
>
>Kind regards,
>Marcos
>--
>Marcos Caceres
>http://datadriven.com.au
>

Re: [widget-digsig] changed widget signature files processing rule in section 4

I think the current text is clearer since it make clear which  
direction to process the list, which would be ambiguous otherwise.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 19, 2009, at 9:40 AM, ext Priestley, Mark, VF-Group wrote:


Hi Frederick,

Small comment. I would change the sentence:

"Process the digital signatures in the signatures list in descending  
order, with distributor signatures first."


to

"Process the digital signatures in the signatures list in list order  
starting with the first file-entry." or something similar


(They should already be in descending order, with distributor  
signatures first, as list has been sorted in previous steps.)


Thanks,

Mark



From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org 
] On Behalf Of Frederick Hirsch

Sent: 18 March 2009 21:07
To: WebApps WG
Cc: Frederick Hirsch
Subject: [widget-digsig] changed widget signature files processing  
rule in section 4


I have updated the latest Widget Signature editors draft section 4  
(locating and processing digital signatures) to no longer require  
the first signature to be processed.


http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

The language is now (numbering ok in draft):

•
Process the digital signatures in the signatures list in descending  
order, with distributor signatures first.


The decision of which (if any) distributor signatures are to be  
validated and whether the author signature is validated is out  
of scope of this specification. This may be determined by the  
Security Policy used by the user agent.


The ordering by widget file name can be used to allow consistent  
processing and possible optimization.


	• Every signature that is validated MUST be validated according to  
Signature Validation defined in this specification.

Please indicate any comment or correction.

The latest draft also changes all usage of "widget user agent" to  
"user agent".


regards, Frederick

Frederick Hirsch
Nokia


On Mar 16, 2009, at 4:46 PM, ext Priestley, Mark, VF-Group wrote:

[mp] My view is that whether zero, one or more signatures is  
processed
is up to the widget user agents security policy therefore we don't  
need
to say anything about which signatures (if any) must be processed.  
The
purpose of sorting the distributor signatures into ascending order  
is to

allow some optimisation of signature processing under certain
conditions. Maybe good to further clarify - I can try and come up  
with

something if you'd like (and of course if you agree)?

Re: [widgets] Further argument for making config.xml mandatory

On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group
 wrote:
> Hi Marcos, All,
>
> I would like to raise a comment in support of making the configuration
> document at the root of the widget mandatory.
>
> The localisation model currently described by [1] allows for multiple
> configuration documents; zero or one at the root of the widget and zero or
> one at the root of each locales folder.
>
> While we support the approach of allowing localisation of the configuration
> document (with the addition of the fallback mechanism that has been
> previously discussed), one concern we had with such an approach was that it
> doesn't make sense to localise some of the information in the
> configuration document, for example: the feature element, (the replacement
> for) the access element, the license element, the id and version attributes
> (and maybe others?). In fact in some cases, allowing different values
> could present security risks.
>
> Previously we (Vodafone) had considered an approach of requiring user agents
> to, for example, create a list of all feature elements present in any valid
> configuration document. We had not yet thought how to handle the case in
> which the different configuration documents contain different id attribute
> values.
>
> However, now that there is a proposal to make the configuration document at
> the root of the widget mandatory, I would like to propose that a better
> (although not pretty) solution would be specify which attributes and
> elements are localisable. The non-localisable attributes / elements would
> only be valid if included in the configuration document at the root of the
> widget.
>
> Thoughts?

Proposal: not localizable:
's id and version attributes.
 and its 


The following elements would be localizable:
 widget (but no id or version, derived from root config, if available)
 name
 description
 author
 license
 icon
 content
 preference
 screenshot

FWIW, I think this will confuse authors... and irritate the poor souls
who need to implement this :)

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms


Mark

I'll change the sentence to read

"The ds:Signature MUST be produced using a key of the recommended key  
length or stronger."


Probably should change term from "recommended key length" to "minimum  
key length".


Later when we update algorithms we probably should review whether we  
need key length defined for each algorithm but can defer for now.


Will this change of sentence work ?

Thanks

regards, Frederick

Frederick Hirsch
Nokia

(for some reason this message of yours did not reach my personal  
inbox, but it was on the list)


Hi Frederick, I agree with all of your changes with two comments. The  
sentence: "The Signature  MUST be produced using a key of the  
recommended key length  " is still problematic given that we allow (although discourage)  
key lengths less than the recommended key length, and probably don't  
want to rule out the use of longer keys. Suggest changing to: "The  
Signature SHOULD be produced using a key of the recommended key length  
 .  
The Signature MUST comply with Signature method algorithm requirements  
in the Algorithms section of this document" I also think we need to  
link recommended key length to algorithms now we allow other  
algorithms to be used, ie if ECDSA is used it would be OK to use  
shorter keys. Thanks, Mark _

[widgets] Minutes from 19 March 2009 Voice Conference

2009-03-19 Thread Arthur Barstow

The minutes from the March 19 Widgets voice conference are available  
at the following and copied below:


 

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before 26 March 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.


-Regards, Art Barstow


   [1]W3C

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

   - DRAFT -

   Widgets Voice Conference

19 Mar 2009

   [2]Agenda

  [2] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0815.html


   See also: [3]IRC log

  [3] http://www.w3.org/2009/03/19-wam-irc

Attendees

   Present
  Art, Frederick, Dan, Andy, Andrew, David, Mike, Thomas,
  Bryan, Marcos, Arve, Benoit, Robin

   Regrets
   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Review and tweak agenda
 2. [6]Announcements
 3. [7]DigSig: no longer require the first signature to be
processed
 4. [8]DigSig: Remove DSAwithSHA1 requirement? Status of
requirement R47 (Section 2)?
 5. [9]DigSig: Suggest removing the restatement of algorithm
requirements in section 7.1, specifically remove #5a and
#5b.
 6. [10]DigSig: reference widgets packaging zip relative path
 7. [11]DigSig: Are we ready to approve the publication of a
new WD?
 8. [12]P&C spec: should the config file be mandatory?
 9. [13]P&C: s on s
10. [14]P&C spec: status of P&C LC comment handling; next steps
 * [15]Summary of Action Items
 _



ScribeNick: ArtB

Scribe: Art

[IPcaller] jjjis

argh

zaki, [IPcaller] is me

bha

bah

   Date: 19 March 2009

Review and tweak agenda

   AB: draft agenda published on March 18:
   [16]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/08
   15.html
   ... Since then, Frederick proposed some agenda changes via
   [17]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/08
   31.html ; we will accept those that intersect the original agenda;
   add e.; skip the editorial points (f., g., h.)
   ... There is also a proposal by Marcos to add a new  element
   ([18]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0
   816.html) that will be added to the agenda.
   ... Are there any other change requests?

 [16] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0815.html
 [17] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0831.html
 [18] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0816.html)


   [None]

   Benoit: what about RSS?

   AB: not today

   David: what about the PAG?

   AB: I have no new info about the PAG

   MS: it is being set up; I am responsible for setting it up; I have a
   draft charter
   ... will go to W3M soon if hasn't been done already
   ... hope to get the annoucement out RSN
   ... some logistics still be worked out

   David: PP says AC reps need to get involved; would appreciate an
   update

   MS: I don't have much more to add; nothing surprising; can look at
   the REX PAG for an example

   David: we weren't members then

   TLR: we will give plenty of advance notice

Announcements

   AB: any short announcements? I don't have any.

   David: BONDI review period ends March 23

DigSig: no longer require the first signature to be processed

[19]http://bondi.omtp.org is the link for BONDI

 [19] http://bondi.omtp.org/

welcome back to a former co-chair of one of the previous
   incarnations of this wG

   AB: Frederick mentioned his change on March 18
   [20]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/08
   30.html
   ... and added to the latest ED
   [21]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures
   ... any concerns or objections with FH's proposal or can we approve
   it as is?

 [20] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0830.html
 [21] http://dev.w3.org/2006/waf/widgets-digsig/#locating- 
signatures


   
   [22]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

 [22] http://dev.w3.org/2006/waf/widgets-digsig/#locating- 
signatures


   MC: I approve

   AB: FH's proposal approved

DigSig: Remove DSAwithSHA1 requirement? Status of requirement R47
(Section 2)?

   AB: these issues are still open. Briefly, what is the plan to
   address them?

   FH: want to add an Note that XML Sec WG has not reached consensus on
   the algorithms for XML Sig 1.1
   ... I don't want to do anything rash here
   ... We need to get more feedback

   AB: support your proposal for the note

suggest to add editorial note along these lines:

   David: we are discussing this in OMTP
   ... different companies have differ

Re: [widget-digsig] Editors note to be added to widget signature


revised to be as follows, now that I look at it more closely:

Note:

The Web Applications WG is seeking feedback on required  algorithms  
for widget signatures, in particular which algorithms should be  
required in addition to RSAwithSHA256. The WG has not yet agreed on  
final set of required algorithms.


This Widget Signature specification relies on XML SIgnature 1.1 which  
introduces new and stronger algorithms to XML Signature. The XML  
Security WG has not yet achieved consensus on required  algorithms in  
XML SIgnature 1.1, in particular whether to mandate

ECDSAwithSHA256. The XML Security WG is also requesting feedback on the
FPWD of XML SIgnature 1.1.

regards, Frederick

Frederick Hirsch
Nokia



On Mar 19, 2009, at 9:48 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:


Based on the discussion on today's call, I will add the following
editors note to Widget Signature in section 6, Algorithms [1]:

Note:

This Widget Signature  specification relies on XML Signature 1.1 and
the Web Applications WG is also seeking feedback on required
algorithms for widget signatures, in particular which algorithms
should be required in addition to RSAwithSHA256.

The XML Security WG has not yet achieved consensus on required
algorithms in XML SIgnature 1.1, in particular whether to mandate
ECDSAwithSHA256. The XML Security WG is requesting feedback on the
FPWD of XML SIgnature 1.1.

regards, Frederick

Frederick Hirsch
Nokia


[1] http://dev.w3.org/2006/waf/widgets-digsig/#algorithms

RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms

Hi Frederick,
 
I agree with all of your changes with two comments. The sentence:
 
"The Signature  MUST be produced using a key of the recommended key
length
 "
 
is still problematic given that we allow (although discourage) key
lengths less than the recommended key length, and probably don't want to
rule out the use of longer keys. Suggest changing to:
 
"The Signature SHOULD be produced using a key of the recommended key
length
 .
The Signature MUST comply with Signature method algorithm requirements
in the Algorithms section of this document"
 
I also think we need to link recommended key length to algorithms now we
allow other algorithms to be used, ie if ECDSA is used it would be OK to
use shorter keys.
 
Thanks,
 
Mark




From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] 
Sent: 18 March 2009 20:34
To: WebApps WG
Cc: Frederick Hirsch; Priestley, Mark, VF-Group; Marcos Caceres
Subject: [widget-digsig] proposed change to 7.1, common
constraints, for algorithms




Mark 

One issue you raised was that we have MUSTS on algorithms in the
processing rules in section 7.1, but allow other algorithms in the
algorithm section with MAY. 

After our previous email exchange, I suggest the following
changes to section 7.1 in Widget Signature [1] to address this concern:

(1) Change item 3b from

The Algorithm attribute of the ds:digestMethod MUST be set to a
digest algorithm specified in the Algorithms section of this document.


to


The Algorithm attribute of the ds:digestMethod MUST comply with
the digest algorithm requirements specified in the Algorithms section of
this document.

(2) Change 5a from 


The Algorithm attribute of the ds:CanonicalizationMethod element
MUST be set to a Canonicalization method specified in the Algorithms
section of this document.


to


The Algorithm attribute of the ds:CanonicalizationMethod element
MUST comply with the Canonicalization method algorithm requirements
specified in the Algorithms section of this document.




(3) Change 5b from 


The ds:SignatureValue element MUST contain a signature generated
using a Signature method specified in the Algorithms section of this
document and MUST use a key that is of the length of arecommended key
length
 .


to


The Signature method algorithm used in the ds:SignatureValue
element MUST  comply with Signature method algorithm requirements in the
Algorithms section of this document. The Signature  MUST be produced
using a key of the recommended key length
 




Does this change make sense? Do you have any suggestion or
comment?


Thanks for the careful review of the draft.


regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/ 


[mp] While this is better I think it misses the fact
that we are
strongly recommending the use of certain algorithms. I
still like the
idea of including authoring (signing)
guidelines/recommendations, ie you
can sign your widget using any signature algorithm but
if you want it to
work across all W3C widget user agents use algorithm X.
Same sort of
thing for digest algorithm and key length. What do you
think?

[widget-digsig] Editors note to be added to widget signature

Based on the discussion on today's call, I will add the following  
editors note to Widget Signature in section 6, Algorithms [1]:


Note:

This Widget Signature  specification relies on XML Signature 1.1 and  
the Web Applications WG is also seeking feedback on required  
algorithms for widget signatures, in particular which algorithms  
should be required in addition to RSAwithSHA256.


The XML Security WG has not yet achieved consensus on required  
algorithms in XML SIgnature 1.1, in particular whether to mandate  
ECDSAwithSHA256. The XML Security WG is requesting feedback on the  
FPWD of XML SIgnature 1.1.


regards, Frederick

Frederick Hirsch
Nokia


[1] http://dev.w3.org/2006/waf/widgets-digsig/#algorithms

RE: [widgets-digsig] Updated 5.1 with revised Reference constraint text

Looks good to me - thanks Frederick and Marcos!

From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch
Sent: 18 March 2009 21:03
To: WebApps WG
Cc: Frederick Hirsch
Subject: [widgets-digsig] Updated 5.1 with revised Reference
constraint text

I have updated the Widgets Signature editors draft, section 5.1
(use of xml signature) with revised text for Reference constraints. This
is revised from what I proposed on list earlier as I tried to make the
two cases clear (and disallow other random external references): 

I replaced:

Every ds:Reference used within a widget signature
  MUST have
a URI   attribute. Every
ds:Reference to an item within the widget signature
  MUST use
an IDREF value for the ds:Reference URI
  attribute, referring
to a unique ID within the widget signature

[XML-Schema-Datatypes]
 .
Every ds:Reference to a widget file
  MUST use a
relative URI expressing the path from the root of the widget resource

to the referenced widget file
  [URI]
 .

with
Every ds:Reference used within a widget signature
  MUST have
a URI   attribute.

Every ds:Reference MUST be one of the following two kinds of
reference:

Reference to content within the same ds:Signature
element 
Every ds:Reference to an item within the widget
signature 
MUST use an IDREF value for theds:Reference URI
  attribute, referring
to a unique ID within the widget signature

[XML-Schema-Datatypes]
 .

Reference to a widget file
  in the same
widget resource

The URI attribute of every ds:Reference to a widget file
  MUST be a
URL-encoded [URI]   zip
relative path that identifies a file inside the widget package. A zip
relative path MUST conform to the [ABNF]
  for zip-rel-path as
specified in [Widgets Packaging]
 .

Please let me know any additional comment or corrections. Thanks
Marcos for suggestions to this wording.

(Also removed Inc from Nokia in title page)

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/

RE: [widget-digsig] changed widget signature files processing rule in section 4

Hi Frederick,
 
Small comment. I would change the sentence:
 
"Process the digital signatures in the signatures list in descending
order, with distributor signature
 s
first."
 
to
 
"Process the digital signatures in the signatures list in list order
starting with the first file-entry." or something similar
 
(They should already be in descending order, with distributor signatures
first, as list has been sorted in previous steps.)
 
Thanks,
 
Mark 
 
 




From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch
Sent: 18 March 2009 21:07
To: WebApps WG
Cc: Frederick Hirsch
Subject: [widget-digsig] changed widget signature files
processing rule in section 4


I have updated the latest Widget Signature editors draft section
4 (locating and processing digital signatures) to no longer require the
first signature to be processed.  

http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

The language is now (numbering ok in draft):



1.  Process the digital signatures in the signatures list in
descending order, with distributor signature
 s
first.

The decision of which (if any) distributor signature
 s are
to be validated and whether the author signature
  is
validated is out of scope of this specification. This may be determined
by the Security Policy used by the user agent.

The ordering by widget file name
  can be
used to allow consistent processing and possible optimization.

2.  Every signature that is validated MUST be validated
according to Signature Validation

defined in this specification.

Please indicate any comment or correction.

The latest draft also changes all usage of "widget user agent"
to "user agent".

regards, Frederick

Frederick Hirsch
Nokia


On Mar 16, 2009, at 4:46 PM, ext Priestley, Mark, VF-Group
wrote:


[mp] My view is that whether zero, one or more
signatures is processed
is up to the widget user agents security policy
therefore we don't need
to say anything about which signatures (if any) must be
processed. The
purpose of sorting the distributor signatures into
ascending order is to
allow some optimisation of signature processing under
certain
conditions. Maybe good to further clarify - I can try
and come up with
something if you'd like (and of course if you agree)?

RE: [widgets] Agenda for 19 March 2009 Voice Conference

2009-03-19 Thread Sullivan, Bryan

Regrets for today's call; conflict with UWA. I will join late if possible.

Best regards,
Bryan Sullivan | AT&T
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, March 18, 2009 6:41 AM
To: public-webapps
Subject: [widgets] Agenda for 19 March 2009 Voice Conference

Below is the draft agenda for the March 19 Widgets Voice Conference  
(VC).

Inputs and discussion before the meeting on all of the agenda topics  
via public-webapps is encouraged (as it can result in a shortened  
meeting).

Logistics: *** STILL 1-HOUR EARLIER FOR non-US PARTICIPANTS ***

Time: 22:00 Tokyo; 15:00 Helsinki; 14:00 Paris; 13:00 London;  
09:00 Boston; 06:00 Seattle
Duration = 60 minutes
Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
IRC channel = #wam; irc.w3.org:6665
Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

3. DigSig spec:

  Widgets DigSig: 
  XML Sig Props: 

a. Open issues Frederick identified in:

b. Remove "Only the first distributor signature MUST be processed."?

c. Remove DSAwithSHA1 requirement? Status of requirement R47 (Section  
2)?

d. Suggest removing the restatement of algorithm requirements in  
section 7.1, specifically remove #5a and #5b.

e. Proposal to publish new Working Draft

4. P&C spec: status of P&C LC comment handling; next steps

5. P&C spec: should the config file be mandatory? Complete discussion  
started on March 12; see Marcos' proposal:

6. Window Modes spec: status and next steps

7. A&E spec: status and next steps

Re: [widgets] Minutes from 25 February 2009 Widgets F2F Meeting

Please take a look at the FPWD of XML Signature 1.1 which describes
the use of Elliptic Curve algorithms in the context of XML Signature:

http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/

Ideally widgets signature should just reference XML Signature 1.1
algorithms.

I also note that the XML Security WG continues to refine XML Signature
1.1 and is looking for feedback.

Thanks

regards, Frederick

Frederick Hirsch
Nokia

On Mar 19, 2009, at 6:17 AM, ext Hillebrand, Rainer wrote:

Dear Art,

May I give feedback on an old action item regarding the preference
for ECDSA vs. DSA. I hope that T-Mobile's position statement is not
too late.

T-Mobile favors ECDSA. DSA has no advantage regarding speed and
memory consumption against the classic RSA. ECDSA improves the
security level.

Please note that ECDSA supports prime field cases and binary field
cases. Especially the binary field cases are covered by patents.

Due to the fact that different parameters for the elliptic curves
can be used or are standardized, these parameters are relevant too.
The NIST recommends fifteen elliptic curves (five prime curves and
ten binary curves, see also http://en.wikipedia.org/wiki/Elliptic_curve_cryptography)
. The so-called Brainpool curves are preferred in Germany (see also http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-03.txt)
.

Best Regards,

Rainer

*
T-Mobile International
Terminal Technology
Rainer Hillebrand
Head of Terminal Security
Landgrabenweg 151, D-53227 Bonn
Germany

+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)
E-Mail: rainer.hillebr...@t-mobile.net

http://www.t-mobile.net

This e-mail and any attachment are confidential and may be
privileged. If you are not the intended recipient, notify the sender
immediately, destroy all copies from your system and do not disclose
or use the information for any purpose.

Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte
bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte
Adressat sind, informieren Sie bitte den Absender unverzüglich,
löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie
oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.

T-Mobile International AG
Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/
Chairman)
Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/
Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender

Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276
Steuer-Nr./Tax No.: 205 / 5777/ 0518
USt.-ID./VAT Reg.No.: DE189669124
Sitz der Gesellschaft/ Corporate Headquarters: Bonn

[widgets] Further argument for making config.xml mandatory

Hi Marcos, All,
 
I would like to raise a comment in support of making the configuration
document at the root of the widget mandatory.
 
The localisation model currently described by [1] allows for multiple
configuration documents; zero or one at the root of the widget and zero
or one at the root of each locales folder.
 
While we support the approach of allowing localisation of the
configuration document (with the addition of the fallback mechanism that
has been previously discussed), one concern we had with such an approach
was that it doesn't make sense to localise some of the information in
the configuration document, for example: the feature element, (the
replacement for) the access element, the license element, the id and
version attributes (and maybe others?). In fact in some cases, allowing
different values could present security risks. 
 
Previously we (Vodafone) had considered an approach of requiring user
agents to, for example, create a list of all feature elements present in
any valid configuration document. We had not yet thought how to handle
the case in which the different configuration documents contain
different id attribute values.
 
However, now that there is a proposal to make the configuration document
at the root of the widget mandatory, I would like to propose that a
better (although not pretty) solution would be specify which attributes
and elements are localisable. The non-localisable attributes / elements
would only be valid if included in the configuration document at the
root of the widget.
 
Thoughts?
 
Thanks,
 
Mark
 
[1] http://dev.w3.org/2006/waf/widgets/
 
Mark Priestley 

Mobile: +44 (0)7717512838
E-mail: mark.priest...@vodafone.com 

 
Vodafone Group Services Limited 
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN Registered in England No 3802001

Re: [widgets] s on s