Re: Action-430 Updated the Web Apps document

Thank you, Robin, for your comments!

I will take care of the editorial suggestions.

By "client-side URI" I mean URIs generated on the client to capture the 
state of an application.
For example, if you use Google maps, you customize it by  specifying a 
particular location.  Google maps
generates a URI for the corresponding map which you can store and reload 
or mail to a friend.

Now to your more substantive comments:

1. The term "widget" covers a variety of capabilities with several 
security models.
I will bring this up for discussion at the upcoming TAG f2f.  We may 
need to mint some names.
suggestions welcome!

2.Signatures don't produce trust
Yes. In the narrowest sense, signatures merely guarantee that the 
document has not been tampered with.
Certificates are a means of identification.  But trust must have been 
established beforehand, perhaps we need
a separate trust establishment protocol and a white-list mechanism as 
recommended by CORS.
All the best, Ashok


Robin Berjon wrote:
> Hi Ashok,
>
> a few quick and half-random notes.
>
> On May 28, 2010, at 14:01 , ashok malhotra wrote:
>   
>> I have updated the Web Apps document.  See http://www.w3.org/2001/tag/2010/05/WebApps.html
>> I added a fourth architecture followed by some discussion and a couple of paragraphs about client-side
>> storage.  The diagram needs more work and, if I get to speak with John next week, I will add more words.
>>     
>
> Please make sure that the document can be completely understood without diagrams. Personally, I never understand them.
>
> It's Marcos Cáceres, not "Cacares" :)
>
> It would be very useful if the TAG were to come up with concise terminology to capture the different security models of "in browser" and "stuff with pre-agreed trust of some sort". Some people use "widgets" for the latter, but there's demand for running widgets inside the browser, using the same security model as for any other browser-oriented content so that won't work. Equally, there's interest in using widget or widget-like technology to create browser extensions, which run in the browser but have any number of different security models. What we're looking for is a clear distinction for "default/traditional arbitrary web resource trust model" versus "enhanced trust models". I think you'll find that folks in DAP and WebApps will be happy to give a hand there.
>
> I agree with Marcos that signatures don't produce trust. People will tend to trust applications that come from a well-known source, be it an app store, a website they know, or a friend's USB key. It is perhaps possible that other models could produce trust, such as a policy-based model (where you trust a third-party to define a security policy which then gets applied to what you accept that apps are allowed to do — this is essentially the browser model except that it introduces variability in policy) or a web-of-trust model whereby you trust apps (irrespective of the functionality they make use of) based on what your "friends" trust. There have been suggestions of such a model being noodled on for Jetpack but I don't know much more.
>
> As a side note, a totally distributed model (the whole Web's an app store) is more likely to be possible if there are common, easy means to make money off it (such as universal micropayments).
>
> I'm not sure what you mean by "client-side URIs". If you're thinking of Widget URIs, these essentially exist so as to enable the usage of URIs (because most of the technology being used requires them) in situations where no URI is readily available. These can be stored and transmitted, but they won't be retrievable (or, in fact, meaningful much) outside the context of a (locally stored) widget.
>
>

Received on Monday, 31 May 2010 15:51:04 UTC