$Id: 06-waf-minutes.html,v 1.8 2007/11/15 14:51:21 mike Exp $
See also: IRC log
AB: which version will we use today?
MC: the latest version is CVS; I will drop the URI into IRC
<scribe> Meeting: http://www.w3.org/2007/11/05-waf-minutes.html
<Marcos> http://dev.w3.org/2006/waf/widgets/Overview.src.html
<Marcos> latest editor's draft
MC: let's first look at the list
of supported technologies at the beginning
... should HTML be included?
ABe: yes
CM: yes, tend to agree; another issue is SVG only viewers
<danbri> (yep, what charles says)
CM: but if say HTML then need to say something about XHTML
AB: not sure what it means to make this list a must requirements
<danbri> (there are non-html/.js widgets around, eg. http://dev.widsets.com/wiki/Getting_started#INTRODUCTION_TO_WIDGET_FOR_WIDSETS builds on a custom scripting language)
RM: agree it's not completely
clear what is the purpose of this list
... especially since the list is likely to change over time
<Marcos> and Yahoo! widgets too
AB: is there any user agent that can clearly claim 100% support for HTML 4.01?
CM: yes one app but it has very few users
AB: then I think that kinda' substantiates my claim (this list should only be non-Normative)
<danbri> yep, if the config format has a notion of "Must Understand" extensions, non-hackparsers are needed
MC: I will mark this section as
non-normative
... should we include Flash?
CM: not sure it is "typical"
MC: I will create a proposal for this
<scribe> ACTION: Marcos submit a proposal to address the Resource names and Hierarchy section [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action01]
<trackbot-ng> Created ACTION-133 - Submit a proposal to address the Resource names and Hierarchy section [on Marcos Caceres - due 2007-11-13].
RM: we could create a new scheme
CM: no, please don't go
there
... creates other problems
<charlton> With respect to supported technologies, happy if we have ECMAScript
CM: just need some type of relative URI scheme
<charlton> (FYI, Flex is an open technology)
<danbri> I'd suggest simply saying, Widget content formats are expected to be the common languages of the Web, with HTML, .js and CSS expected therefore to be typical common core.
<danbri> If people want to use Flash, E4X, etc... W3C doesn't need to rule on yes/no ...
MC: just mention that a relative naming scheme is needed and don't create a separate section
CM: that's OK with me
MC: Arve?
ABe: OK with me too
MC: I will delete it then
CM: I suggest chaning to should
RM: a UA doesn't have to support zip64 extensions [but it could]
CM: make it so it is clear zip64 extension support is not required
MC: OK, bullet reworded [and red box deleted]
ABe: I suggest removing that UTF-8 bullet
MC: Charlton, how does Adobe deal with UTF-8 names?
<charlton> AIR presently handles US-ASCII (beta 2), release will have UTF-8
CB: we do plan to support it in Adobe Air
<danbri> fwiw we're built on top of Mozilla, UI-wise. so we have whatever they have unless we go to special effort.
MC: I will add a AT RISK qualifier to this issue
ABe: two cases really: an extension that is required for the widget to work but also if the extension isn't supported the widget still [mostly] works
CM: the "interoperable manner" part is a bit too Mom & Apple Pie'y
AB: what exactly do we want to say?
CM: want to say - if you use ZIP extensions it better not break those UAs that do not support the extension
RM: think this might be a bit of over specification
MC: yeah, I tend to agree it may not be needed
<danbri> In TimBL's note ... important for downlevel / stupid clients to understand when they've met "something from the future", ... ie. when they shouldn't proceed and ignore extensions.
CM: if you find something you don't recognize what do you do -> stop, go on, ...
<danbri> (actually i wasn't mumbling *this* time ... but am skyping in)
<danbri> (my point is more re manifests than zip formats, ... but we might say that the .zip format extensions should be indicated in the manifest at least?)
<chaals> [I agree with danbri that we should ensure this is clear for the manifests]
MC: I have removed the 1st sentence in the Extensibility section
CM: and I think the 2nd sentence should also be removed
MC: OK, will do
MC: the OCF has defined something we can leverage
<scribe> ACTION: Marcos will read the OCF spec for ASCII name input [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action02]
<trackbot-ng> Created ACTION-134 - Will read the OCF spec for ASCII name input [on Marcos Caceres - due 2007-11-13].
<scribe> ACTION: Barstow check the copyright issues regarding OCF [with Mike Smith] [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action03]
<trackbot-ng> Created ACTION-135 - Check the copyright issues regarding OCF [with Mike Smith] [on Arthur Barstow - due 2007-11-13].
<Marcos> OCF: http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm
RM: is the OCF definition of a container the same as the package/archive definition for the Widgets spec?
MC: no, not really. For starters they add some things like mandating the first few bytes of the container must be something specific
CM: could we say the filenames must be URI-escaped?
MC: interesting, I'll need to
investigate that
... will look into RFC3492 - IRI encoding
CM: think adding a max filename size of 255 chars.
<arve> doesn't other platforms have shorter names than that?
<charlton> in use?
<charlton> amiga?
RM: what are the max filenames on mobiles?
<arve> charlton: what's os x's limit? I thought it was shorter than 255
<scribe> ACTION: barstow what are the max filename lengths on mobile devices? [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action04]
<trackbot-ng> Created ACTION-136 - What are the max filename lengths on mobile devices? [on Arthur Barstow - due 2007-11-13].
<charlton> symbian os has a 255-char limit
RC: having max filename lengths well defined would be good
<arve> informative: filename restrictions http://en.wikipedia.org/wiki/Filename#Comparison_of_file_name_limitations
ABe: what about illegal characters?
MC: we will enumerate those characters that are not legal
CM: we should use the URI encoding mechanism
<charlton> arve: os x is 255
<charlton> arve: but 255 UTF-16 characters
<charlton> take a look at http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
ABe: I was talking about reserved words in the filename
CM: can you save URI-encoded names to a file system?
<charlton> the limit on path name length is nasty in windoze
MC: what about case sensitivity?
CM: I think they should be case sensitive
<charlton> arve: OS X is covered in http://en.wikipedia.org/wiki/HFS_Plus
<arun> +1 we should stipulate case sensitivity. the onus will be on developers to honor this within platform constraints.
<arve> I think opting for straight (absolute) case sensitivity is the only sane choice
<arun> +1 arve
CM: URI refs need to be case sensitive
<danbri> so widget signing in 30 mins?
<danbri> how long likely for?
<arve> off until 11.20
<RogerCutler> Fac3t1m3
<danbri> yeah
<danbri> I don't hear much
<arve> artb: calling in now
<danbri> do i understand right: widget spec adds a layer of indirection by putting digest info in its own manifest?
<danbri> we're also looking at signtool which comes with Mozilla
MC: Joost is using JAR
signer
... Opera was pushing PKCS7
<danbri> re signtool see http://www.mozilla.org/projects/security/components/signed-scripts.html#signing
MC: XML Sig is a good solution
for us
... but I think the spec is a bit complicated
... what question is - can we use just a subset of the
spec?
... e.g. not require XML Canonical or XPath
... something like XML Signature "Lite"
... perhaps only requiring a small set of the algorithms
<danbri> I've seen no great need for canonicalising xml with widget signing
<danbri> Re Joost, ... jar sign is one option, mozilla signtool is another ... amongst our highest priority is tool support and simplicity for developers
MC: any objections from Adobe?
CB: we are discussing it
AB: are there any objections to the spec using XML Signature?
<chaals> [I may come back and scream later...]
RESOLUTION: we will use XML Signature
<danbri> data point re complexity, https://addons.mozilla.org/en-US/firefox/addon/4522 is 855K and doesn't work on Macs
CM: I may come back to this later
<arve> can Frederic move closer to the mic?
<danbri> jarsign for us is more for developers *creating* signed widgets, ... we also need to check them in a (currently java-free) moz-based environment
FH: there is likely to be a new
WG to update XML Signature spec
... think the profiling you want would be in scope for this new
WG
... You could do your own profiling.
... There are a few corner cases to be careful about.
<danbri> (are there any examples out there of specs that profile xml sig?)
<danbri> i hear... wss, wsi-sec (?)
FH: WSS and WS-I BSP do some
profiling of XML Signature
... SignedInfo element is a must
<danbri> "You can use almost all of the XML signature features in WSS-Core except enveloped signature and enveloping signature. However, WSS-Core has some recommendations such as exclusive canonicalization for the c14n algorithm and some additional features such as SecurityTokenReference and KeyIdentifier." in http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.
<danbri> doc/info/exp/ae/cwbs_digsignv6.html
FH: the certs issue is a bit
tangential
... KeyInfo is somewhat open
<arve> brb
FH: you could sign the zip itself
but wouldn't recommend it.
... makes more sense to have the signature in the zip
MC: so if we create a profile, what are the key things?
<danbri> at the moment our format spec says this: http://www.iana.org/assignments/media-types/application/vnd.joost.joda-archive (but since then we've made moves to be more w3c-compatible ...)
FH: identifying the algorithms e.g. SHAH-256
<danbri> (sun jar spec: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Signed%20JAR%20File (sorry to interrupt flow for minutes)
AB: does the XML Sign spec say about profiles?
FH: the spec provides must
requirements
... what is your timing?
MC: November 2008 we want to in LC
FH: that should work reasonably well with the follow WG that has been proposed
<scribe> ACTION: barstow lobby for new XML Sig work with Team Contact [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action05]
<trackbot-ng> Created ACTION-137 - Lobby for new XML Sig work with Team Contact [on Arthur Barstow - due 2007-11-13].
<Marcos> Widget spec has been checked in, get it while it's hot:
<Marcos> http://dev.w3.org/2006/waf/widgets-reqs/Overview.src.html
<Marcos> Arve, Danbri...
FH: there are required algorithms and canonicalization issues
<scribe> ACTION: Marcos update requirements doc to reflect major signature requirements [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action06]
<trackbot-ng> Created ACTION-138 - Update requirements doc to reflect major signature requirements [on Marcos Caceres - due 2007-11-13].
AB: I'm concerned about building a dependency on a WG that is still a TBD
FH: but you can start discussing this with the existing XML Security Maintenance group
AB: we could potentially split the signature stuff into its own spec that may be taken over by the new WG
MC: main use case is quality assurance
AB: http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0041.html
MC: are there any issues with not signing everything?
FH: that's related to the threat
model, not about signatures per se
... does the manifest enumerate every file in the archive?
MC: no it doesn't
FH: if it did, then no one could add a file
AB: what's the precedence?
FH: in soap, only important things are signed
MC: I'm also concerned about the man-in-the-middle attack e.g. adds another file to the package
FH: but an extra file would be ignored by the UA, right?
ABe: yes, I agree
MC: but I'm thinking about an input field that then references the inserted file
<danbri> i'm not sure if our .js APIs currently allow widget to enumerate contents of a directory
<danbri> but if so, ... we can imagine innocent code doing "foreach image in images/ " ...
<danbri> (this isn't vendor specific particularly ... just about being clear what the sig checking tells us)
DB: images can also potentially cause a problem
<danbri> dealing with the "foreach" thing, ... is purely a matter of the sigs documentation making it clear that additions are possible
<danbri> and for sure - we should never assume that the w3c-blessed APIs are the only ones available to widget code
TR: may want to include data in
the manifest that says what is not signed
... what is the UC for stuff that is un-signed
<danbri> UC for stuff being unsigned: widget-authoring workflow
TR: what precisely is the Threat Model?
<danbri> ... coder does the programming, passes it down to graphic design
<danbri> ... or business make "skinning" deals
FH: agree the threat model needs to be clear
CM: simplest use case is adding
an image
... 2nd level is some script
FH: but that's not a signature issue
TR: what decisions do we expect
UA to make depending on the widget being signed or not?
... do we expect for example the name of the signer to effect
the UA?
... partial signing makes me nervous.
... Simplicity is a huge virtue.
<danbri> slightly more complex than "add an image" --- adding translations. Translation of UI text have potential for malice. Can people sign and drop in a french UI translation without breaking top level manifest?
CM: Operas may sign a Widget; we could also only post widgets that have been signed by some specific person/entity.
TR: what would you tell the user regarding a partially signed widget?
<arun> Arun proposes an all or nothing sign model.
AR: I think the model should be ALL or Nothing
CB: I agree with Charlton
<danbri> re "all or nothing", ... depends on the i18n/l18n model
<danbri> (sorry my audio isn't up to participate fully)
AB: what's the scenario that requires partial?
<charlton> signing s/b on the widget level
<charlton> signing of individual components s/b delegated (e.g. policy model)
<danbri> (for us ... all/nothing is ok for a 1.0 I would guess, and that is a *guess*)
MC: Charles was thinking about a widget getting something added by a friendly 3rd party
<arun> Arun: secondary updates to the widget (aka the "fish" model) can also potentially be signed.
<FrederickHirsch> question: why use a ds:Manifest rather than having each ds:Reference in SignedInfo itself
ABe: but what about different parts of the signature being signed by different parties
<FrederickHirsch> difference is processing rule - digests must be verified for References in SignedInfo, but this verification is optional for ds:References in ds:Manifest
<FrederickHirsch> however, application could always choose to verify those in manifest as well
<danbri> the people whose signatures are trusted for signing .js behaviour may not be the people who make the .fr .it etc language translation packs ....
<FrederickHirsch> by the way, canonicalization is not required for ds:Reference processing of an xml content to create the digest
AR: need to be explicit about the error handling when not everything is signed
<FrederickHirsch> "If no Transforms element is present, the resource's content is digested directly"
<FrederickHirsch> http://www.w3.org/TR/xmldsig-core/#sec-o-Reference
<FrederickHirsch> manifest distinction - "The difference from the list in SignedInfo is that it is application defined which, if any, of the digests are actually checked against the objects referenced and what to do if the object is inaccessible or the digest compare fails."
<scribe> ACTION: Charles determine Opera's position regarding signing All versus Partial signing [with Arve] [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action07]
<trackbot-ng> Created ACTION-139 - Determine Opera's position regarding signing All versus Partial signing [with Arve] [on Charles McCathieNevile - due 2007-11-13].
<FrederickHirsch> http://www.w3.org/TR/xmldsig-core/#sec-Manifest
<FrederickHirsch> xml security specifications maintenance wg - http://www.w3.org/2007/xmlsec/
<FrederickHirsch> workshop on next steps - http://www.w3.org/2007/xmlsec/ws/report.html
DB: my main concern is that the
signature aspect and localization model must be
consistent
... must not need to resign JS if a new localization file is
added
MC: I feel fairly strongly that
everything should be signed
... if a localization file needs to be added then resign
everything
... But I'm not sure how the biz models work for signing.
<FrederickHirsch> WSI Basic Security Profile -1.0 example, http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html#XMLSignature
DB: I think a widget will float among various stakeholders and they all need to be able to add different stuff to the zip
<arun> Arun: The question was about obtaining a code signing certificate. You may obtain a code signing certificate from a CA and use it to sign code ("objects" or blobs such as JAR) to your heart's desire. One certificate is typically bound to an organization, which can typically be an individual developer.
CM: the last person that touches the widget signs it
MC: another issue is what - if anything - the UA should do to inform the user that a widget is signed
<scribe> ACTION: Barstow start a liaison with WSC WG regarding signing and the user [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action08]
<trackbot-ng> Created ACTION-140 - Start a liaison with WSC WG regarding signing and the user [on Arthur Barstow - due 2007-11-13].
FH: WS-I has done quite a bit of work regarding threat models
<FrederickHirsch> http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf
<danbri> OK I'm gonna have to run now. thanks all!
<FrederickHirsch> see section #4, threats.
<arve> everyone back again?
ABe: want to talk about widget
extensions
... for example an extension may have security related
issues
... e.g. providing security for accessing to GPS hardware
... I presume extensions are added in different
namespaces
... support for an extension is of course optional
... we serve widgets based on the UA
... determined via the UserAgent header
... So on widgets.opera.com we check the UA and only present
those widgets that will work on the requesting device
... need some way to declare extensions
AB: so you want an <extension> element?
ABe: something like that; could be an attribute
AB: any specific models we can leverage?
ABe: the mustUnderstand attribute is relevant
<Marcos> ...<extensions><api>opera.locationService</api>...</extensions>
ABe: nothing is needed in the APIs - only in the config file
AB: would this require some type of registration mechanism?
ABe: no; the UA could either ignore it or do-the-right-thing
AB: something like this does seem
reasonable to me
... but Marcos doesn't seem convinced
MC: I need to think about it some more ...
<Marcos> ...<requires><api required="true">opera.gps</api></requires>
<Marcos> ...<extensions><api required="true">opera.gps</api></extensions>
<arve> <widget mustUnderstand="http://example.com/gps http://example.com/tv" > ... </widget>
<arve> <widget mustUnderstand="http://example.com/gps http://example.com/haskellscript" > ... </widget>
<arve> version 1: http://example.com/ns/gps/1.0
<arve> version 2: http://example.com/ns/gps/2.0
ABe: this model assumes a mapping between the namespaces (e.g. .../gps) and some API [installed on the UA's system]
<Marcos> http://example.com/gps = "com.sun.location"; != object notation
<Marcos> for haskel
<Marcos> http://example.com/udp
MC: I understand the idea and mostly like it but I'm not convinced
ABe: I can submit a proposal to the mail list that articulates the Use Case
MC: not clear we want to add this type of data to the config file
AB: the site specializing in widget downloading and aggregation could use this metadata to help organize the set of widgets made available e.g. based on some user-supplied criteria
<benoit> BS: well it is useful for a widget to run in a checked environment, and it is better to have a configuration check then a dev check
<scribe> ACTION: Arve submit a proposal regarding the manifest's extension mechanism [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action09]
<trackbot-ng> Created ACTION-141 - Submit a proposal regarding the manifest's extension mechanism [on Arve Bersvendsen - due 2007-11-13].
<arve> I couldn't hear the latest speaker
<benoit> tx, but I will not be able to stay on the call, but I can watch the conversation on IRC
CV: agree this is an important issue but I'm not sure what is the right data to encode
<benoit> good point
<Marcos> http://example.com/ns/gps/2.0
MC: Gorm and Anne were quite keen on this
ABe: need to define how widgets
expose themselves to each other
... requirement: widget must be able to announce and
un-announce themselves
... #2 requirement: widgets should be able to control the set
of widgets they expose themselves to
AB: the widget would need to define itself, right?
RM: yes its API
ABe: that is defined in
HTML5
... this uses the postMessage method
<Marcos> http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages
AB: does this raise any new security concerns?
ABe: events use their domain and
data attributes
... may trust any widget from e.g. opera.com but not
evil.com
RM: would need user interaction as well
AB: in Opera's implementation how are the requirements being met?
ABe: set up an event
listener
... and then remove it
RM: open ajax hub says publish on the hub and then listen/subscribe for events
ABe: we did something
similar
... and had some problems
... can we get this OAA doc on the mail list?
MC: yes
<scribe> ACTION: Marcos send the URI of the OAA's pub/sub model to the mail list [recorded in http://www.w3.org/2007/11/06-waf-minutes.html#action10]
<trackbot-ng> Created ACTION-142 - Send the URI of the OAA's pub/sub model to the mail list [on Marcos Caceres - due 2007-11-13].
<MikeSmith> http://openajax.org/OpenAjax%20Hub.html
AB: I think this is a useful but I don't see it as a high priority, especially for v1.0
MC: I've marked it as AT Risk/Low Priority
MC: propose changing <title> to <name>
AB: why?
MC: everyone else is doing it
ABe: that OK with me
RESOLUTION: <title> changed to <name>
MC: no one is using license element
ABe: the content model for license is under-specified
MC: not clear on the real purpose
ABe: similar to Atom RFC's rights
RM: user will never understand the data if it is is "GUN, GPL, etc.".
ABe: propose making it an AT RISK
MC: OK with me; done
Title: Copyright
MC: do we need to add
copyright?
... or perhaps date of publication
<arve> ABe: My thinking here is that licenses need to be machine-readable to have actual value
<arve> then a consumer/user can automatically detect it
<arve> and decide
<arve> it's clearly overkill
MC: I'm a bit concerned we're moving towards 'tools will save us'
<Marcos> http://widgets.opera.com/widget/3903/
MC: Charlton, what is Adobe doing with licensing in Air?
CB: licenses can be affixed to an
Air deployment script (as well as other metadata)
... can also configure the Air app's skin, images, etc.
ABe: so this data goes into Air's manifest file
CB: yes, that's true
<charlton> http://www.adobe.com/devnet/air/
<charlton> site - covers info on licensing, packaging AIR, etc.
<Marcos> DDEEEEEEE-NNNNNOOOOOOOO!!!!!
<Marcos> I heard a rumor about dino!
MC: 1st rumor - Dean is coming back to be the Team Contact :-)
<Marcos> YAY!!!!
<benoit> lol
AR: widgets work and binding are
both important and I support them
... the Read Access stuff seems appropriate too
... therefore I endorse the change
CM: we're both doing stuff that
is just "off the edge of HTML"
... makes sense to me to continue both the WAF work and Web API
work
... both groups are relatively small and there is some
overlap
... merging the groups will help reduce travel!
<arun> Arun: just to minute the nuances of what I'm saying: a widget API (e.g. gadget.*.* or widget.*.*) and XBL, which binds behavior to elements declaratively with a "code behind" model, make a lot of sense given WebAPI's future directions. Thus, I think that this work DOES make sense within WebAPI, and I support the fusion of WAF with WebAPI.
CM: Another benefit is that we get two Team Contacts
<arun> AR: furthermore, MC points out that the "read only" stuff makes sense to the AJAX community, and this is another piece of work that should belong under the WebAPI umbrella.
AB: I think it's a good idea and support it
<arun> AR: Summary of my points -- WebAPI + WAF fusion is something I support, as AOL's representative :)
MC: given the overlap I think it
makes sense
... will also hopefully get more input from the Web API WG
AR: any chance Yahoo will join this work?
TT: not sure
CV: I hope to contribute more in the future but no promises
AB: Roland, I'd like IBM to join this WG and you or Jon would be great candidates
RM: we'll have to look into it
MC: yes, establishing a relationship with OAA would be good
TT: looks like a good idea to combine the WGs
<charlton> CB: Adobe is keen to contribute enabling technologies and looking toward how to better empower web widgets
<charlton> CB: I agree that combining the WGs will be valuable
AB: I could host a f2f meeting in Burlington, MA (~30 km from Cambridge), Cambridge MA or Helsinki
MC: I could host again in Brisbane
CM: I could host in Tokyo or Oslo
AB: the 2008 TPAC meeting will be in fall in France [tentative]
<chaals> [rumour: Dino's new start-up will host us at a meeting in Australia, all travel sponsored, ...]
AB: Good Luck to Arun in his new endeavors - we will miss him!
<dino> [rumor: Dino to be elected next PM of australia]
AB: Meeting adjourned!