twg.org/2009-March/018935.html
> [7] https://informationcard.net/wiki/index.php/Browser_Integration_WG
>
>
> Channy
> -
> http://www.linkedin.com/in/channy
> http://www.creation.net
>
> Daum Developers Network & Affiliates
> http://dna.daum.net
>
--
Marcos Caceres
http://datadriven.com.au
TF's KEYPROV
> will fail as hard as XKMS did if we ignore the browser connection all the
> time.
I see. thanks for the history. However, what, if anything, should our
working group do? I don't see anything that is in scope or anything
directed at any one of our specifications. If we are screwing
something up somewhere, then please be clear as to where and we will
do our best to fix it.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
gets published. Please send any feedback you
might have by the end of the week.
Kind regards,
Marcos
[1] http://dev.w3.org/2006/waf/widgets-digsig/
--
Marcos Caceres
http://datadriven.com.au
ry. The change was to put it inline with P&C. Do you see
any issues arising from the new NS? should I change it back? I'm of
the position that NSs should not be dated because changing NS and,
hence semantics, for elements in the future is probably a bad idea.
> The other changes looked good, thanks for improving the draft.
My pleasure! Thanks for doing all the hard work and actual thinking! :)
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Hi Thomas,
On Fri, Mar 20, 2009 at 1:31 PM, Thomas Roessler wrote:
> On 20 Mar 2009, at 10:46, Marcos Caceres wrote:
>
>> To compliment the new i18n model, I've added the following
>> restrictions on XML base:
>> [[
>> xml:base attribute
>> The xml:base
body else. Therefore, I would recommend to
> delete this bullet point.
>
Agreed. Can we say "were signed with the same certificate" instead?
> 10. Section 5.2: change "A widget package MAY contain zero or one author
> signatures." to "A widget package MAY contain zero or one author signature."
>
fixed.
> More change proposals may come tomorrow (if identified tomorrow).
Thanks for taking the time to do the review!!!
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
ically
can to achieving that goal. However, if that current solution is
inadequate, then please send us suggestions.
--
Marcos Caceres
http://datadriven.com.au
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
>
>
--
Marcos Caceres
http://datadriven.com.au
lect the time when
>> signature generation completed.
>>
>
>
> [3]
>
> These signatures MUST be sorted numerically
> based on the numeric
> portion of the name.
>
> to
>
> Within a widget package these signature files MUST be ordered based
>> on the numeric portion of the signature file name."
>
> [4]
>
> "The RECOMMENDED version of the certificate format is X.509 version 3
> [X509v3]. Implementations MUST be prepared to accept X.509 v3 certificates
> [X509v3], [RFC5280]. "
> could become
> "The RECOMMENDED version of the certificate format is X.509 version 3
> as specified in [RFC5280]. Implementations MUST be prepared to accept
> X.509 v3 certificates [RFC5280]."
>
> removed X509 v3 reference.
>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
ave read only Storage values,
naturally we would need some kind of access violation exception to be
thrown when someone tries to change a read only value...
Anyway, we would like to hear your thoughts.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
gt; comments in red in the following exchange:
>
>
> Benoit Suzanne
> Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM
> benoit.suza...@orange-ftgroup.com
>
>
>
>
>
> ____
> From: Marcos CACERES
> Date: Wed,
ill continue working on the Widgets 1.0:
Updates specification and hope to publish a new draft soon.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
s,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Hi i18n core,
On Sun, Feb 22, 2009 at 11:28 PM, Marcos Caceres
wrote:
> On Thu, Jan 29, 2009 at 10:56 PM, Phillips, Addison
> wrote:
>> 2. Section 7.4 (Widget) The various language bearing elements such as
>> , , etc. are of the zero-or-one type. However, it is
>> t
ution before I add anything else to
the spec.
Kind regards,
Marcos
[1] http://dev.w3.org/2006/waf/widgets/
[2] (unfinished draft!) http://dev.w3.org/2006/waf/widgets/i18n.html
--
Marcos Caceres
http://datadriven.com.au
I had a discussion with Anne on IRC about using the Storage interface
and XHR [1]. He recommended that we recommend support for Storage only
on user agents that support HTML5. With regards to XHR, the same
applies: it would be a property of the underlying document technology.
So, proposal are:
may make this method
impractical or just unusable. I.e., when would this method be called?
When the widget restarts, but after document.onload or before
document.onload? etc.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
seems to be implying that we should not replicate
functionality available in other context. For example, would a
(hypothetical) Flash-only Widget UA be expected to implement Storage?
Or would we mandate that such user agents implement their own solution
or use whatever means are currently available on the platform
(whatever that might be for Flash)?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
I guess that unless we come up with a realistic scenario, this is a
non-issue. Josh?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
e with what is currently specified in
the P&C spec.
I have added your suggestion for V2.0 to the wiki:
http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R
--
Marcos Caceres
http://datadriven.com.au
Hi,
Two blog posts have recently appeared which provide good critical
feedback on the Widgets 1.0: Digital Signatures specs:
http://sfsecurity.wordpress.com/2009/04/08/code-signing-can-be-trusted-but-not-blindly/#comment-12
http://www.links.org/?p=600
Kind regards,
Marcos
--
Marcos Caceres
ou think is needed in the Widgets DigSig spec?
>>
>>Defining an API in this spec doesn't seem like a good approach.
>>
>>-Regards, Art Barstow
>>
>>[1] <http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
>>0017.html>
>>
>>
>>
>
>
--
Marcos Caceres
http://datadriven.com.au
On 4/9/09 3:56 PM, Arthur Barstow wrote:
On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:
On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
wrote:
Hi Art, All,
If there is no use case for accessing this information (I was after why
you would want to access this information
Hi Art,
On 4/13/09 1:03 PM, Arthur Barstow wrote:
On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote:
On 4/9/09 3:56 PM, Arthur Barstow wrote:
On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:
On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
wrote:
Hi Art, All,
If there
above, once we see
> which paths are trodden and what people complain about (and we can rely on
> complaints to reach us) we can extend the element to provide it with much
> more granular matching (simply by giving it children or other attributes
> that override href). The point he
established detached signature format for
> signing a file of bytes?
Although I agree that it was probably a short-sightedness mistake on
our part to not have looked at JAR signing at the start of this
process, I think it is too late for you to ask us to dump over a year
worth of work on this spec - especially as we are about to go to Last
Call and have significant industry support (BONDI) for using XML
Signatures. Although I also agree that there are issues with
canonicalization, I find it hard to believe that JAR signatures are
not without their own problems. I think it would be more productive to
help us address the issues that you mentioned, instead of asking us to
dump everything and start again.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On 4/14/09 2:51 PM, timeless wrote:
Marcos Caceres wrote:
Although I agree that it was probably a short-sightedness mistake on
our part to not have looked at JAR signing at the start of this
process, I think it is too late for you to ask us to dump over a year
worth of work on this spec
On Tue, Apr 14, 2009 at 2:56 PM, Marcos Caceres wrote:
>
>
> On 4/14/09 2:51 PM, timeless wrote:
>>
>> Marcos Caceres wrote:
>>>
>>> Although I agree that it was probably a short-sightedness mistake on
>>> our part to not have looked at JAR signing
Hi Henri,
On Tue, Apr 14, 2009 at 4:19 PM, Henri Sivonen wrote:
> On Apr 14, 2009, at 14:38, Marcos Caceres wrote:
>
>> I think it would be more productive to help us address the issues that you
>> mentioned, instead of asking us to dump everything and start again.
>
>
&g
After discussions with Josh and Arve, I would like to propose that we
drop the screenshot element. The rationales for the decision are:
* screenshots bloat the package,
* and screenshots are never used when the widget is instantiated.
* Also, there is no way to identify on which platform the
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Hi Henri,
On 4/17/09 1:19 PM, Henri Sivonen wrote:
On Apr 17, 2009, at 13:24, Robin Berjon wrote:
Trying to separate the discussion from the change request: would you
be satisfied if requirements to perform C14N were removed and reliance
on XSD data types for definition purposes were replaced
Hi Yves,
On 4/17/09 5:37 AM, Yves Savourel wrote:
Hi Marcos,
A few notes:
=== From a localizer viewpoint (so maybe not from a user-agent efficiency
view), using the locale folders method is likely better than the localized
elements method:
Having a document with the same content in multiple
Hi Mark,
On 4/16/09 7:20 PM, Mark Davis wrote:
I just glanced at this, but the first line is wrong:
Internationalization, or i18n, is the automated process employed by a
user agent to select localized content from a widget package that
matches the language preferences of an end-user.
If you wan
ks,
>
> Mark
>
>>-Original Message-
>>From: public-webapps-requ...@w3.org
>>[mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow
>>Sent: 18 April 2009 15:21
>>To: ext Marcos Caceres
>>Cc: public-webapps
>>Subject: Re: [widgets] drop
Hi Francois,
Sorry for taking s long to get back to you. I started addressing
your feedback but then your comments kinda spun out of control and
became a new document:
http://dev.w3.org/2006/waf/widgets/i18n.html
I'm hopeful you will find the time to give your two cents about the
proposed sol
sion? Add other version attributes? Add some tokens as in
> version="1.0 +dsig +wm"?
>
> I understand the draw to flagging versions, it somehow "feels neater", and
> that's why people tend to want to throw them in (I just made the very same
>
On Sun, Mar 29, 2009 at 9:23 AM, timeless wrote:
> Marcos Caceres wrote:
>> 4. a zip relative path cannot contain any of the following characters:
>> <,>,:,",/,\,|,?,*,^,`,{,}. I introduced that restriction, not Zip. The
>> reason why these characters are banned
ter Chapter 7.7 in an IE 6.0.
>
I can only suggest using a modern browser that supports Web
standards... have you tried Opera?;)
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On Mon, Apr 6, 2009 at 7:13 PM, Arthur Barstow wrote:
> On Apr 6, 2009, at 10:36 AM, ext Marcos Caceres wrote:
>
>> I would like to propose we get remove the following methods from the A&E
>> spec:
>>
>> 7.17 The onbeforeupdate Callback
>> 7.18 The onafter
invoked if the user
acknowledges the notification message, for instance by clicking on
it."
The above needs to be cleaned up a bit, but will do for now.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
tion."
Added under "Digital Signatures" section. If Mark is happy, then we
should close this issue.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
tatic
> xml:base would be enough, I guess. I don’t know where we currently stand on
> the subtag issue, but it seems like an important use case.
Agreed. I think we should support sub-tag searching. It's valuable here.
> Hope I’ve added at least some value to the discussion. It might be good to
> ask other WG members to provide their explicit preferences about the
> different proposals, or at least input such as I have. I hope and think you
> can extract some of my preferences from above.
Thank you for taking the time to send comments! they were very helpful!
--
Marcos Caceres
http://datadriven.com.au
ignature Properties [XMLDSIG-Properties] and
>> this specification."
>>
>
> this is not inconsistent. Section 9 says if used, section 5.1 says it is
> used in the profile...
>
>> Suggest deletion of ", if this property is used," from the first
>> sentence
>
> I do not think I understand the rationale for this change.
>
>>
>>
>> -
>> 9.1.2
>>
>> "Profiles MUST specify details of the identifier property value creation
>> and interpretation." What does "Profiles" mean in this sentence
>
> the widgets signature specification is a profile...
>
>>
>>
>> -
>> "If multiple instances of this property are found on a single signature,
>> then applications MUST NOT deem any of these properties valid." - which
>> would in turn mean that the signature was invalid, right? We may want to
>> state this?
>
> the properties are not valid though the signature still might be valid.
> Interpretation of properties is profile dependent.
>
>>
>>
>> -
>> 9.2
>>
>> Note that the same comments may apply to 9.2.1 and 9.2.2 dependent on
>> the discussions on the mandatory/optional status of this property.
>
> same answers as for 9.1.2
>
>>
>>
>>
>>> -Original Message-
>>> From: public-webapps-requ...@w3.org
>>> [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow
>>> Sent: 02 April 2009 17:21
>>> To: public-webapps
>>> Subject: [widgets] New WD of Widgets 1.0: Digital Signatures
>>> spec published on March 31
>>>
>>> On March 31 a new WD of the Widgets 1.0 Digital Signature spec
>>> was published and announced on the W3C's home page:
>>>
>>> [[
>>> 2009-03-31: The Web Applications Working Group has published a
>>> Working Draft of Widgets 1.0: Digital Signatures. This
>>> document defines a profile of the XML Signature Syntax and
>>> Processing 1.1 specification to allow a widget package to be
>>> digitally signed.
>>> Widget authors and distributors can digitally sign widgets as
>>> a trust and quality assurance mechanism. Prior to
>>> instantiation, a user agent can use the digital signature to
>>> verify the integrity of the widget package and perform source
>>> authentication. This document specifies conformance
>>> requirements on both widget packages and user agents.
>>> ]]
>>>
>>> Please review this new WD as soon as possible, preferably
>>> within the next two weeks:
>>>
>>> <http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/>
>>>
>>> -Regards, Art Barstow
>>>
>>>
>>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
On Tue, Apr 21, 2009 at 11:17 PM, Frederick Hirsch
wrote:
> if there is no need for the Created property in the Widgets Signature spec I
> suggest we remove it, though keep what we have in the Signature Properties
> specification.
The less dependencies the better, from my POV.
-
might have missed?
I'm not sure if we addressed the issue that was raised on a two blogs
about the assertion that "Widget authors and distributors can
digitally sign widgets as a trust and quality assurance mechanism."
It was suggested that we should drop that sentence, I think.
--
Marcos Caceres
http://datadriven.com.au
> Thanks for noting this one.
No probs. It might be worth while reading the comments that are on the
two blogs to see if there is anything useful there:
http://sfsecurity.wordpress.com/
http://www.links.org/?p=600
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On 3/12/09 12:25 PM, ivan.demar...@orange-ftgroup.com wrote:
Mmmm.
And how we define more than one viewmode?
I mean, apart from the "default one" for the content, was not decided to give
to the developer the possibility of declaring what modes the widget supports and how (in
terms of size)?
Also works for me.
Marcos
On Thursday, April 23, 2009, Arthur Barstow wrote:
> A shorter counter-proposal below ...
>
> On Apr 21, 2009, at 9:56 AM, ext Marcos Caceres wrote:
>
>
> On Tue, Apr 21, 2009 at 3:31 PM, Frederick Hirsch
> wrote:
>
> ISSUE-83 states:
> Ins
On Thu, Apr 23, 2009 at 12:04 AM, Arthur Barstow wrote:
> A shorter counter-proposal below ...
>
> On Apr 21, 2009, at 9:56 AM, ext Marcos Caceres wrote:
>
>> On Tue, Apr 21, 2009 at 3:31 PM, Frederick Hirsch
>> wrote:
>>>
>>> ISSUE-83 states:
>>
n a new draft.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
() Method] Make the last statement explicitly
> non-normative (as a note for instance)
>
Changed the offending text to a note.
> 17. [The ShowNotification() Method] "reference to a function" is confusing
> (also in onmodechange). I would change to just function
>
Changed to just function.
> 18. [Informative References] The references are in a section (the intro) that
> is not marked as informative in the conformance section.
>
Agreed. But that section will be completed when we go to LC.
--
Marcos Caceres
http://datadriven.com.au
ference
>
> http://dev.w3.org/2006/waf/widgets-digsig/
>
> Note that we will need to update the Signature Properties reference, when
> that specification is published with this specification.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
s is true.
> 2. As far as security policies are concerned, this suggests that we are
> acquiring an additional set of complexity earlier than I had thought.
It would be really helpful if you could enumerate these complexities, please?
--
Marcos Caceres
http://datadriven.com.au
On Thu, Apr 23, 2009 at 2:26 PM, Robin Berjon wrote:
> On Apr 23, 2009, at 12:36 , Marcos Caceres wrote:
>>>
>>> 3. [User Agents] "A user agent is an implementation" a bit vague. Perhaps
>>> some of the text in the following note should be move here, to re
On Fri, Apr 24, 2009 at 11:51 AM, Thomas Roessler wrote:
> On 24 Apr 2009, at 10:54, Marcos Caceres wrote:
>
>> It would be really helpful if you could enumerate these complexities,
>> please?
>
> What I'm proposing currently (and I think other proposals are having th
. Right?
> It should be noted, however, that this is problematic on device for a number
> of reasons, given that floating or mini widgets would typically exist on some
> "desktop" or in an application grid, so these mode changes are problematic
> from a UX-view (and may as well have a security implication or two)
>
Agreed.
--
Marcos Caceres
http://datadriven.com.au
On Fri, Apr 24, 2009 at 1:25 PM, Arve Bersvendsen wrote:
> On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote:
>
>>> In that case, it is not a request, so widget.changeMode()
>>> would be more appropriate, where a user agent MAY choose to not honor
>>> the
Sounds like a plan! Let's do it. I'll do another review of the spec
tomorrow and send feedback to Frederick. I'll also give the ol'
Requirements doc a quick tune-up.
Kind regards,
Marcos
On Apr 27, 2009, at 9:06 PM, Arthur Barstow
wrote:
Since the Widgets DigSig is now feature complete
his is to adopt Art's simplified proposal
>
> By the way I really think P&C should use uppercase MUSTs etc.
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
"Signatures generated using key lengths of less than 2048 bits SHOULD
NOT be used unless the life time of the signature is less than one
year."
Again, it is not clear to me who "SHOULD NOT be used" is directed at?
should not be used by the UA?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
gt; rapid changes?
LOL! hell no, that's when most changes happen because it's the only
time people pay enough attention to do an actual review. That's why
Last Call should really be called "First Call" :)
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On 4/29/09 2:32 PM, Frederick Hirsch wrote:
+1
I don't see the need for that paragraph.
Ok, no probs. Leave it out.
Kind regards,
Marcos
made clear.
>>
>
> how about
>
> The signer uses the dsp:Identifier signature property to
> uniquely identify the signature to enable signature management.
>
> (you don't like passive voice? :)
>
>
>
>> "value is unique for the widgets that they sign."
>>>
>> "value is unique for the widget packages that they sign."
>>
>>
>
>
> ok
>
>> 6.1
>> "Signatures generated using key lengths of less than 2048 bits SHOULD
>> NOT be used unless the life time of the signature is less than one
>> year."
>>
>> Again, it is not clear to me who "SHOULD NOT be used" is directed at?
>> should not be used by the UA?
>>
>
> The signer SHOULD NOT generate signatures using key lengths of less than
> 2048 bits unless the life time of the signature is less than one year.
>
> By the way, shouldn't this be a MUST NOT?
>
>
>> Kind regards,
>> Marcos
>
> thanks
>
>>
>> --
>> Marcos Caceres
>> http://datadriven.com.au
>>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
In prep for republication of the Requirements document, I made the
following changes:
Fixed some typos
Removed Screenshot requirement
Renamed "Scripting Interfaces" to "Application Programming Interfaces"
Removed the following requirements:
Asynchronous HTTP requests
Icon API
Cross-widg
regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On Thu, Apr 23, 2009 at 2:04 PM, Max Froumentin wrote:
> Hi Marcos,
>
> All changes approved, except the 2 below:
>
> Marcos Caceres writes:
>
>>> 5. [Dependencies on Other Specifications] The last 2 statements logically
>>> yield "A user agent MUST
modechange attribute MAY hold a
> function that is [...]".
>
Fixed.
> 7. Section "The onmodechange Callback": This section contains the term
> "currentMode" two times. However, this attribute is not defined. It can't be
> "viewMode" because viewMode is either the default value from P&C Step 3 or
> the value from P&C Step 7.
>
Right, I marked this an issue for now as the whole section needs a
rewrite! The value is actually computed based on the view mode as
determined by the UA.
--
Marcos Caceres
http://datadriven.com.au
On Tue, Apr 28, 2009 at 12:13 AM, Marcos Caceres wrote:
> I will make the changes below and change the style sheet to uppercase
> rfc2119 terms.
Ok, done.
> On Monday, April 27, 2009, Frederick Hirsch
> wrote:
>> I suggest the following
>>
>> remove from widge
ur comments to
help us move forward on these issues!
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
t something that apps request (nor should it be as
> irrespective of what they ask the decision should rest with me, the
> all-powerful user). What's more if we add that we can add a lot of other
> things such as roaming, time of day (which can influence the price of a byte
> in some places), etc.
>
Agreed.
--
Marcos Caceres
http://datadriven.com.au
going to propose that we go with (c) — this is just like multiple tabs
> open to the same page. If a UA wants to offer a way to make a given instance
> separate (i.e. provide it with a different origin) that is of course fine,
> but IMHO it is the same problem as allowing a user to have different cookies
> in different tabs in a browser: useful, but not defined per spec.
>
Agreed.
--
Marcos Caceres
http://datadriven.com.au
the widget)
2. take fresh values from from the config doc... might need something
in the preference element to force a reset of a value on each
instantiation.
Marcos
--
Marcos Caceres
http://datadriven.com.au
ame page in a new browser window, then the server supplies the
> persisted instance ids on re-rendering the page, so instances retain the
> same preferences keyed on their original context.
Right. The above is what I would expect as the appropriate behavior
for widget instances.
--
Marcos Caceres
http://datadriven.com.au
an be
determined as early as possible in
the discovery/download/use process, e.g. at the app store.
Best regards,
Bryan Sullivan | AT&T
-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of
Marcos Caceres
Sent: Friday, May 01, 2009 8:36 AM
Kai Hendry wrote:
>>
>>> http://dev.w3.org/2006/waf/widgets-digsig/#identifier-signature-
>>> property
>>>
>>> I'm not sure what "signature management" is exactly, though can
>>> someone please inform me what a UA is supposed to
houghts?
I support b. Added some of your text above to the spec.
>
> [0]http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets/i18n.html?rev=1.29&content-type=text/html;%20charset=utf-8
>
> --
> Robin Berjon - http://berjon.com/
> Feel like hiring me? Go to http://robineko.com/
>
>
>
>
>
>
>
--
Marcos Caceres
http://datadriven.com.au
Kai - please let us know if Frederick's proposal is acceptable.
>
--
Marcos Caceres
http://datadriven.com.au
On Mon, May 4, 2009 at 7:00 PM, Thomas Roessler wrote:
> On 4 May 2009, at 18:42, Marcos Caceres wrote:
>
>> On Mon, May 4, 2009 at 4:13 PM, Frederick Hirsch
>> wrote:
>>>
>>> The Identifier property is useful for audit and management in the
>>> back
On Mon, May 4, 2009 at 7:08 PM, Frederick Hirsch
wrote:
> The spec is more than a UA spec, it also describes signature format which
> affects parties other than the UA (e.g. audit etc)
>
Oh ok. Yes, this is true.
--
Marcos Caceres
http://datadriven.com.au
On 5/5/09 1:38 PM, Frederick Hirsch wrote:
I was aware of what you quoted Marcos, but it was implicit. If it is ok,
then I'm not sure why we've been having this email thread...
I guess so we are clear as to why we have something that does not do
anything in the UA. We now have a clear ratio
Hi,
Here is list of things that need to be done (mostly by me) before the
P&C is LC ready (some items are quite low priority, e.g., references):
1. Internationalization/localization section (50% done)
2. general relaxation and decoupling of conformance checking from actual
runtime behavior (1
Hi,
Just want to thank everyone who has sent feedback on the i18n document.
I have collated all the feedback and am using it as I fold the i18n
document I prepared into the spec. I probably won't respond individually
to comments sent, but I will ask those who sent feedback to re-review
the upd
On 3/12/09 12:25 PM, ivan.demar...@orange-ftgroup.com wrote:
Mmmm.
And how we define more than one viewmode?
I mean, apart from the "default one" for the content, was not decided to give
to the developer the possibility of declaring what modes the widget supports and how (in
terms of size)?
On 5/11/09 1:43 PM, ivan.demar...@orange-ftgroup.com wrote:
Forgive my ignorance, but... "spoofing attack"? O_o
I guess Arve means click jacking.
I'll explain the scenario I have in mind:
- Widget calls the API "requestModeChange();"
- WUA checks if that mode is valid (the string is valid)
On 5/18/09 7:05 PM, Arthur Barstow wrote:
Marcos,
On May 14, 2009, at 10:05 AM, Barstow Art (Nokia-CIC/Boston) wrote:
P&C spec: Status of completing L10N model
AB: MC, when can you have the edits completed?
MC: by May 15 can have first set of edits in
... but Robin and I need to work toget
ck in and find the resource given
>> just a relative URI like 'flag.png'.
>
> +1.
>
>
>> - If the content negotiation finds no localized content (i.e. there is no
>> requested representation for the resource), a resource with the specified
>> name in the root of the widget is used. If not present, it is probably an
>> error.
>
> +1 without the final "probably". If not present, it is an error.
>
>
>> I'm trying to help Marcos hammer out these things in the P&C spec, so I
>> really appreciate your feedback.
>
> Good luck! :)
>
> Francois.
>
>
--
Marcos Caceres
http://datadriven.com.au
om Widgets 1.0 and
deferred to Widgets 2.0 once it is properly sorted out.
--
Marcos Caceres
http://datadriven.com.au
(again with my "editor" hat on)
On 5/19/09 12:07 PM, Thomas Roessler wrote:
I'm not particularly happy with this proposal, mostly since it doesn't
seem to make the case of "I don't need anything scary" easy.
I don't know what "I don't need anything scary" is.
My take on where we were in the
On 5/19/09 12:44 PM, Arthur Barstow wrote:
Marcos,
On May 19, 2009, at 4:15 AM, ext Marcos Caceres wrote:
On 5/18/09 7:05 PM, Arthur Barstow wrote:
What is the status of the P&C's L10N model?
It appears you've made some progress since the May 14 call:
<http://dev.w3.org
On Tue, May 19, 2009 at 12:46 PM, Arve Bersvendsen wrote:
> On Tue, 19 May 2009 11:18:36 +0200, Marcos Caceres wrote:
>
>> With my "editor" hat on, I would like to propose the following
>> security model for widgets:
>>
>> 1. If no element is used, th
On 5/19/09 12:36 PM, Robin Berjon wrote:
On May 19, 2009, at 12:07 , Thomas Roessler wrote:
My take on where we were in the end of the call yesterday is as follows:
1. A widget runs in its own domain of trust.
2. Communication of that domain of trust with the network is
prohibited by default
In today's Widgets security teleconf, we decided to rip out of
P&C and into a new spec: Widgets 1.0: Access Requests... or the "WAR"
spec - thanks Robin!;)).
The new Editors' drat of the WAR spec is at:
http://dev.w3.org/2006/waf/widgets-access/
Kind regards,
Marcos
eds to
happen before we can get a FPWD to happen.
--
Marcos Caceres
http://datadriven.com.au
for certain view
modes this value is ignored. Which view modes should honor the value
of this attribute is defined in the the [Widgets-WM] specification.
This means that P&C no longer has default values for width and height,
they will be defined by the Window Modes spec.
--
Marcos Caceres
On Wed, May 20, 2009 at 12:53 PM, Robin Berjon wrote:
> On May 20, 2009, at 11:34 , Marcos Caceres wrote:
>>
>> On Wed, May 20, 2009 at 10:28 AM, Robin Berjon wrote:
>>>
>>> Then I would like the plan to be that we call for discussion here on the
>>
On Tue, May 19, 2009 at 1:26 PM, Marcos Caceres wrote:
>
>
> On 5/19/09 12:44 PM, Arthur Barstow wrote:
>>
>> Marcos,
>>
>> On May 19, 2009, at 4:15 AM, ext Marcos Caceres wrote:
>>>
>>> On 5/18/09 7:05 PM, Arthur Barstow wrote:
>>>>
allowing the
widget user agent to, for example, confirm with the user before
installing the widget, or adjust its policies before instantiating it.
Example of security sensitive services that could require
access-control include accessing end-user's storage device, or
performing a cross-domain request.
--
Marcos Caceres
http://datadriven.com.au
Just a heads up that the widget URI scheme is back (with a vengence)
in its own spec:
http://dev.w3.org/2006/waf/widgets-uri/Overview.html
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
801 - 900 of 1416 matches
Mail list logo
