Widgets f2f Meeting -- 21 Oct 2008

<ArtB> Date: 21 October 2008

<ArtB> Scribe: Art

<ArtB> ScribeNick: ArtB

Agenda Review

[ Art reviews agenda; two new additions for AOB section ]

AB: any change requests or additions?

[ None ]

Widgets 1.0 Digital Signature spec

AB: latest ED is http://dev.w3.org/2006/waf/widgets-digsig/

<marcos> http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html

MC: Mark and I have been focusing on simplifying the spec
... One goal was to make the spec more efficent regarding processing
... Also want generic XML Sig tools to be useable as is
... Also tried to reflect what is being done in the industry

<scribe> ... New model is 1) ZIP; 2) Sign; 3) ZIP again

ABe: I object to this change

MC: why?

ABe: because there are already tools that follow our previous model

MC: no; just need to sign the ZIP file rather than 100's of files

ABe: this adds runtime complexity
... In Opera we can read directly into the ZIP
... thus it adds complexity for us
... What is the cost of the old model?

PB: what is the cost you are trying to avoid?

MP: we have a signing server
... it signs Widgets
... The old model requires signing each file individually
... All we really want is one signature for the entire package.
... This is particuarly important when we have to sign a bunch of Widgets

PB: then you loose the flexibility of signing specific files

MP: the more signing that has to be done, the greater the probability something can fail
... e.g. twenty signatures (1 per file) versus just 1 signature for the package

PB: the JAR spec allows individual signing
... and then a hash over the entire JAR

AB: we already agreed everything needs to be signed

MP: want to understand the complexity concern Arve has

ABe: this puts an extra toll on the client
... must keep the package in memory twice

MC: no, that doesn't seem right

PB: no, Arve's right

ABe: on low memory devices, that isn't acceptable

PB: have to extract the inner ZIP onto disc
... and this previously wasn't necessary

ABe: verification of the ZIP isn't the hard part
... need to deflate the inner ZIP and keep it in memory
... must keep the outer file in memory too

MP: why does the outer file need to be in memory

PB: the outer ZIP must be in memory to run the widget

ABe: I agree this shortens the spec

MC: the proposal makes it easier on the signing server
... this doesn't change tools

AB: so we have a new proposal with a sustained objection

MP: given Arve's concerns, I can live with the original model
... the change doesn't change the existing proc model

MC: I'm not convinced about Arve's concerns and would need to do some research.
... OTOH, I can live with the existing model
... OK, we will stay with the model where every file is signed

RESOLUTION: we will maintain the model where every file is signed

MC: another thing I removed is the WidgetSignatureInfo element
... because it requires a custom tool
... that element only contains a TimeStamp element
... I couldn't think of a good use case
... This was introduced by Thomas

AB: any objections to the removal of the WidgetSignatureInfor element?

<scribe> ACTION: thomas do you object to the removal of the WidgetSignatureInfo element? [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action01]

<trackbot> Created ACTION-273 - Do you object to the removal of the WidgetSignatureInfo element? [on Thomas Roessler - due 2008-10-28].

MP: I agree with this change

[ No objections ]

transform element

MC: some files need to be transformed via deflate
... we can write this in prose
... We removed it in Dublin meeting
... I think we need it

AB: let's put this on the agenda for the XMLSec joint meeting

MC: good idea

Certificate Chains

MC: does XML Sig support cert chains

[ Marcos displays xmldsig-core ]

MC: yes, it looks like it

AB: should we add this to the XMLSec agenda?

MC: yes. Want to understand ordering for example
... return values could be: Fail, Verified (Y or N), Revoked (Y or No or Unavail)
... If revoedk stop and only one sig then stop

<mpriestl> We need to also understand what a XML digital signature processing engine will return when processing a signature, e.g. document is malformed, certificate chain can't be verified, certificate has been revoked (yes, no, revocation information unavailable) etc.

MC: Also need table of return values based on conditions
... Mark and I will meet next week
... Hope to have a new WD ready for pub by end of next week

Widgets Requirements LC #2

AB: Widgets reqs LC #2 http://www.w3.org/TR/widgets-reqs/

MC: the doc is written using RFC2119
... LC #2 comment period ended Oct 13
... We want to know the next step -> WG Note or Recommendation

PLH: a Rec doesn't make sense to me

AB: why

MC: what would you actually require?
... the reqs are meant to be inclusive

PLH: what will be the exit criteria of CR?

MC: I was thinking OWL has a precedence for this

PLH: infoset had some exit criteria

MC: we can explicitly list those reqs which are address by various specs

PLH: what are the status of the specs?

MC: they are all in WDs

PLH: I can be convinced that a Recommendation is OK

MC: personally, I want to move this to Recommendation
... We have talked to a lot of industry groups e.g. OMTP

MP: we would like to be able to reference this doc from OMTP

PLH: does it need to a Rec?

PB: it needs to be a stable doc

CV: it would be good to be Rec

AB: I think the options are:
... 1. leave as is
... 2. publish another LC
... 3. publish a CR
... In the CR, state the exit criteria is that each requirement in scope for WebApps must be addressed by one of our specs
... My concern about CR now is that none of our specs are yet in LC and the probability of needing to change a req is relatively high

MC: I propose we leave the Reqs doc as is

RESOLUTION: we will leave the Widgets Requirements as is and not publish another document until the specs (P&C, DigSig, etc) have reached Last Call

Widgets 1.0 Updates spec

AB: latest ED is: http://dev.w3.org/2006/waf/widgets-updates/

MC: we haven't received much feedback yet
... other than some typos

CV: what happens if device has numerous widgets that need to be updated

MC: could wrap <widgetupate> in some outer element
... we haven't spec'ed that yet

CV: shoud the spec say something about this?

MC: it would certainly complicate the current model

PB: what is the trust model if the widgetupdate came via some mechanism other than https?

MP: need to understand the integrity of the source

CV: thinking about 50 widgets trying to do an update at the same time

MC: can imagine some wrapper process that does the updates over a single connection

MS: I wonder about that use case i.e. 50 widgets on a device
... typically expect updates 1 at a time

ABe: I would expect more like 15-20

MS: I can see there could be many but would the user really want to update them all at the same time

PB: a question is one of scalability

MC: I think the current model is sufficient for v1

AB: Claudio, can you live with the existing model for v1 and add your use case and reqs to the v2 reqs doc

CV: yes, that's OK

PB: I think the current model is OK for v1

<scribe> ACTION: Claudio Add handling 50 widget update use case and requirements to the v2 feature and requirements list [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action02]

<trackbot> Created ACTION-274 - Add handling 50 widget update use case and requirements to the v2 feature and requirements list [on Claudio Venezia - due 2008-10-28].

rssagent, make log public

Digital Signature Joint meeting with XML Sec WG

AB: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesday.2C_October_21

<drogersuk> AB: We would like to discuss the questions that we sent over

<drogersuk> We also have some additional questions and Marcos would like to show you the draft document

<scribe> ScribeNick: Drogersuk

MP outlined the questions

<ArtB> Scribe+ David

MP: Within Vodafone and the OMTP BONDI initiative, we have looked at the digital signatures
... The NIST recommendation is that SHA-1 should be phased out
... This is being recommended in BONDI at the moment
... Do you foresee that SHA-256 will be supported?

XML Dig-Sig: Yes, that is correct

BrianLaMacchia: Many companies have already banned SHA-1 usage
... moving to SHA-256 is the right thing to do. You should be prepared to roll that to a new hash function if SHA-256 breaks
... you need to stop people generating new signatures and reference hashes with SHA-1

MP: This is completely in-line with our plans. We recognise the need to support SHA-1 for past / still-valid certificates
... We would like to strongly recommend the usage of SHA-256
... How in XML DigSig do you deal with supporting new hash algorithms?
... We would like to mandate support for DSA

BLM: You don't want to do DSA
... 1024 bits is too short
... for DSA....RSA at 1024 is too short
... use EC and RSA
... obvious choice is EC-DSA

MP: for key length, we are mandating that the consuming platform must support 2048

BLM: That is good

MP: You may use 1024 in the short term - we're not disallowing this

BLM: What is the lifetime of that?

PB: It depends on the policy of the author of the widget

BLM: It depends on your security level and how long you want to protect the information for
... RSA 1024 is what you're going to have the least interoperability issues with
... is it performance that is driving the requirement?

MP: Yes, it is the verify time that some companies have this opinion on
... Some countries want weaker cryptography for signatures

TLR: This sounds like an alarming requirement

MP: I'm only expressing the feedback that we've received
... There are some requests to be able to choose 1024

TLR: What I'm hearing is that you are arguing for 1024

MP: We strongly recommend 2048, but there is still a requirement for 1024 from some other companies

PD: The argument is probably using it in the interim period

MP: We're broadly aligned with you - but should we support 1024?

BLM: It is the lifetime question
... it should expire within a year
... because of the associated risk
... you should highlight this in your documents

MP: Yes that is ok we can do that
... OK, so we will come up with a proposal for lifetime on 1024

BLM: Certificates. We don't see references to timestamping or expiry and the certificate chain falling apart
... what behaviour do you expect?
... widgets would need to be re-signed
... If I publish a widget and a year later it expires..

MP: We only do the check at installation time
... at the moment, we only 'revoke' at installation time, we don't remove them from existing devices
... that isn't a full revocation model in the classic sense
... it depends on your signing model, but in W3C and BONDI we're silent on how you try and establish trust..
... but from Vodafone's point of view we will revoke the certificate - this is one implementation model

FJH: We're talking about traditional lifecycle / PKI things - it sounds like you need a model for this
... we could talk a long time about how to figure this out..

<ArtB> ACTION: Mark what is our lifecycle, revocation model? [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action03]

<trackbot> Created ACTION-275 - What is our lifecycle, revocation model? [on Mark Priestley - due 2008-10-28].

BLM: We went through this 10 years ago with authenticode

MP: A related question - is there any thoughts of adding timestamps to the digital signatures specification?

BLM: There were IPR issues and issues in IETF

<fjh> XAdES , http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=21353

MP: OK, so we'll follow-up offline on this. There are differing opinions, which is why we're being silent on the exact model

BLM: There could be issues with recovering a bad widget if it gets out there and you need to think about that

<tlr> We expect to do the algorithm changes, minor clean-ups, low-hanging simplifications in XML Signature 1.1. No change of namespace. No clear time plan quite yet.

MP: Multiple signatures. We want to add multiple parallel signatures signed by different end-entities in a widget package. I wondered whether there was any prior art for this that we should look at?

<tlr> Algorithm identifiers for SHA 256 and RSA-SHA256 are in Encryption and RFC 4051, respectively.

MP: We want to have separate files with signatures in

BLM: You would end up with more characters because you can't share references with the different blocks
... I can understand why you would want to do that with different parties signing

MC explained the requirements document

MC: We need to talk to you about the certificate chains part
... we probably need some guidance on the inclusion of revocation

MC showed an example

Point 8 in the document was discussed

BLM: Let us discuss this offline

MC: We would not like to have to decompress the whole package to verify the signature
... do we need to contain a transform element in there to indicate that you need to deflate this in order to verify?

BLM: Signatures are in the zip?
... The URIs in the references point to what?

MC: They point to file entries

BLM: This could be ok. For efficiency purposes, that is implementation. The URI you reference will be to the raw uncompressed data
... you wouldn't have a transform because as far as it is concerned it is uncompressed data

<klanz2> Do URIs allow to reference inse a zip file ... ? Java has soemthing in the format jar:<url>!/[<entry>]

MC: OK, so we won't use the transform

There was a brief discussion on URI schemes

<klanz2> http://tools.ietf.org/html/rfc3986#section-5.1.2 ...

TLR: You need to identify in the signature properties element the profile and the timestamp.

MC showed an example

MP: On top of specifying XML DigSig, why do need to specify the profile here

TLR: You have a processing model in mind...
... it may or may not go beyond the model from XML DigSig
... It is a way to prevent signatures not designed for this purpose being used

<klanz2> wondering if it is good to invent new processing models over and over again when there is a "web architecture"

BLM: You could put a separate EKU in the cert. Using a code-signing purpose cert, there are platforms out there that use code signing certs already and would do something useful with it
... you could have problems with your CAs

MC: We are quite reluctant to put this in because COTS tools would have problems

BLM: You can use the object element in XML DigSig

MC: Do we need that in our own namespace?

<klanz2> Look into XAdES for SignatureTimestamp

MC: Do we need the timestamp as mandatory

BLM: It depends on what you want the behaviour to be

<klanz2> http://en.wikipedia.org/wiki/XAdES

TLR: signature properties element can be used to put this into

<fjh> http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-SignatureProperties

MP: We will discuss the model offline if we need to define processing for a timestamp

MC: Can we derive it some other way?

MP: No, this is the way you would do it

MC: Certificate chains. For signatures we just include multiple X509 data blocks?

BLM: Yes, you want one X509 data and multiple X509 certificates

<fjh> wss timestamp uility namespace, see appendix C in http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

MP: What are your plans for the new version of digital signature - at the moment you provide the ability to include CRLs, are you planning to include OCSP?

BLM: Yes we are.

<fjh> also XAdES

BLM: You may even prefer this in your model

MP: Yes mobile operators are more likely to prefer this
... it is still to be defined exactly how we will
... We are seeing the need to scale up our OCSP servers and CRL servers
... this will grow. We would like to do some more intelligent packaging of that information.

MC: OK, so the final part for multiple signatures, we're planning to enumerate the signature xmls
... First come, first served etc.

MP: We'd like to see them processed in order
... We're not having counter-signatures

MP explained that in an ideal mobile world, different operators would sign widgets. If a developer decided to, for example sign for all operators in the UK

MP: When the widget arrives at the consuming device - you could go through and look for a certificate that matches the root authority on your device
... You could do it by filename, but that could be manipulated
... we want to be as silent as we can on the actual model, we don't want to mandate the model that is used

PD: You want to optimise your common deployment scenario
... It makes sense to offer a best practice note on efficiency

MP: We could strip out the other signatures, or make sure that the Vodafone signature was processed first

BS: If I forwarded it on to my friend by Bluetooth who wasn't on Vodafone, it wouldn't work if the signatures had been stripped

PB: There is no way of checking ahead of time which of those certificates gives you the greater number of rights under the security policy
... but in general if we can find a way of avoiding processing multiple digital signatures that would be a good thing

MP: It comes down to not knowing the policy of the consuming device

Policy and trust domains were discussed

There were concerns raised about performance impact of processing lots of signatures

MC: The last issue is procedure for verifying and providing feedback to the widget engine

MP: If you process multiple signatures and one has been revoked and another hasn't, in a lot of cases you have to leave it to the policy on the device
... however you can do some things here, if you get something back

BLM: You can get information saying it failed
... More interesting is if you get a reason code saying that it was revoked
... You could revoke for many reasons
... the problem is - is there any cross-link when you have multiple digital signatures?

MP: We have been through this and we have a matrix of values
... So i the 'No' part there are reason codes too?

BLM: Yes there can be
... You may get more or less information back depending on the implementation

MP: Perhaps we should insert the table and get your feedback on it

BLM: I'm not sure you can do much with this
... You haven't even assumed that you have a chain validation policy
... because you are leaving this to the implementation

PB: It is possible for a widget to be completely unsigned
... in the failure cases, there are cases where you may want to treat the widget as unsigned
... so you have fallbacks or rejections
... For example, in Java, if a midlet package is signed, but no root is available, you have to reject
... it is a problem in practice, because it means that authors feel that it is better to be unsigned

BLM: A disincentive for signing...

PB: Exactly, this is what we want to avoid with this

BLM: What are you doing with the signed v unsigned information?

MP: A signed widget will be allocated to a different trust domain
... They will be used to get access to different APIs, there is a big security issue with giving unsigned widgets unfettered access to these sensitive APIs

TLR: Unsigned widgets get access to a limited set of functionality

AB: Ok, let us wrap up then. Thankyou very much Frederick.

Widget Permissions, Access, etc.

<ArtB> MP: with BONDI we've been thinking about the features element

<ArtB> ... and whether it fullfills all of our reqs

<ArtB> ... Not clear it is flexibile enough

<ArtB> ... Some issues could be overcome with a separate permissions element

<ArtB> AB: where are the requirements that aren't being met?

<mpriestl> Issue 1 - Principle of least privilege Example messaging API widget.vodafone.messaging.{sms,mms,email}.send() widget.vodafone.messaging.{sms,mms,email}.{inbox,outbox,drafts}.{delete(),readContents(),moveTo()} widget.vodafone.messaging.{sms,mms,email}.{watchIncoming(),watchOutgoing()} Requirement 1 It should be possible for the author to limit the widget to use the exact functionality that it requires. At the same time this should be done in a way that if

<ArtB> MP: how to state some features but not all of the features

<ArtB> ... A question here about granularity

<ArtB> ... e.g. a Widget needs to only API or perhaps several APIs

<marcos> http://example.org/feature/feature/freature OR http:/example.org/api?allow=this,this,this&deny=that,that,that

<ArtB> MP: also need to consider composite widgets

<ArtB> ... eg. a Widget that needs to access Camera and other device services

<marcos> http://camera.api.org/gps/changename/contacts/add/delete/album/

<ArtB> ... A Camera widget may need for example to create a folder

<ArtB> ... It may need to access Location info

<ArtB> ... It may need to access file system

<ArtB> ABe: not sure I agree with this use case

<ArtB> ... shouldn't combine a bunch of different functions into a single API

<ArtB> MP: but why not?

<ArtB> ABe: I think it is a bad design

<ArtB> MP: what about a camera API that allows geo-locating the image

<ArtB> MC: this seems to be about how to specify APIs beyond what is being spec'ed by BONDI

<ArtB> NA: I think an objective behind Mark's proposal is to provide a robust sec model that works for poorly designed APIs

<ArtB> PB: we realize BONDI is not the only place where these types of APIs will be defined

<ArtB> ... It is certainly possible to have a 1:1 relationship between a single API and an explicity permission

<ArtB> [ Marcos enters an example in a temporary text buffer ... ]

<marcos> current option

<marcos> and kinda proposed option

<ArtB> ABe: the main problem I have with this proposal is that for each feature, must write a domain-specific language for that feature

<arve> <feature id="[URL FOR GEOLOCATION]"><param name="precision" "0.1m" /></feature

<ArtB> BS: what is your interpretation for the permission element?

<ArtB> MP: used by author and the widget engine

<ArtB> ... could also be used to infer info to display to the user

<ArtB> ... One question is whether this mapping is done explicitly via the config file or an internal detail

<ArtB> ABe: we assume the device will apply policies depending on the origin of the widget

<ArtB> ... and hence gives a trust model

<ArtB> ... With the exception of network (which is well defined), I don't think we should add domain-specific paramaters

<ArtB> ... If we go this route, the language needs to be rich enough to describe every conceivable API

<ArtB> ... This is going to lead to fragmentation issues. For example with the location API above, what happens if there are 0.2m, 0.3m, granularity, etc.

<ArtB> BS: I'm wondering what we need to do for v1.0

<ArtB> MP: we think the current model isn't granular enough

<ArtB> CV: I think the above syntax is agnostic regarding semantics

<ArtB> ... The author and policy can decide the level of detail

<ArtB> ... I think just allow and not-allow isn't good enough; need some additional richness

<ArtB> ABe: but this requires a generic syntax for codifying arbitrary constraints

<ArtB> CV: we need a generic way to define additional constraints for the API

<ArtB> AB: I agree with some of the concerns Arve is raising

<ArtB> ... not clear for example how rich the language of the value would need to be e.g. regular expressions, booleans, etc.

<arve> FWIW, I think we are basically discussing python's 'import' statement here

<arve> from antigravity import *

<ArtB> MC: could also use a level of indirection here e.g. put the permissions in a separate document

<ArtB> PB: a requirement is the need to parameterize the features

<ArtB> ... Arve's correct, each API will have different parameters

<ArtB> MC: this really about providing a standardized way to encode proprietary parameters

<ArtB> ... I also think this goes against the spirit of the OAA's API style guide

<ArtB> CV: could define an ontology for the various features and their parameters

<ArtB> MC: to me this implies writing a "proprietary widget"

<ArtB> MC: I don't think the proposal is supported by W3C's Geolocation API

<ArtB> AB: It's clear we don't have consensus on this issue.

<ArtB> AB: Mark, I propose you create a short set of requirements and a proposal to address those requirements and send it to the public-webapps mail list

<ArtB> ... Is that OK?

<ArtB> MP: yes

<ArtB> ACTION: Mark submit a short set of requirements re extended permissions and parameters and a proposal to address those requirements (to public-webapps) [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action04]

<trackbot> Created ACTION-276 - Submit a short set of requirements re extended permissions and parameters and a proposal to address those requirements (to public-webapps) [on Mark Priestley - due 2008-10-28].

<tlr> I suggest bringing this up at the security workshop in December.

<tlr> http://www.w3.org/2008/security-ws/

Widget Testing

<ArtB> AB: agenda http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesday.2C_October_21

<ArtB> Scribe+ Paddy

<dom> ScribeNick: paddy

MC: Dom had a chance to do a first overview of the spec and test issues
... initial thought is ok
... some first thoughts send out

<dom> Dom's initial comments on Widgets packaging and configuration

MC showing Packaging and OCnfiguration spec

MC: we're looking for advice on how to do this
... eg what is a test harness?
... for example can we identify each testable assertion in the spec and build test cases?
... given the cases in an XML file can we make each test individually addressable and automatable?
... Another spec we looked at wrt testing was from Hixie
... outlined how it was done for CSS
... defined different levels of testing: atomic, assertion-level, evil, edge cases etc
... that's all we know about testing
... if you have experience/advice that would be great
... our spec isn't that big and we've split the doc into two:
... first half mainly definitions
... second half is the testable part
... html5 followed a systematic approach
... so we tried to structure the doc to facilitate this
... eg steps for processing widget resource might be individually testable

Dom: I think a good way to start is to identify each conformance statemennt
... try to construct a simple test case for some of them
... this will not be a very interesting set
... except it will be a starting point
... will give some pointers as to where interoperability fails
... a good strategy is to find the points where interoperability is hardest

MC: unfortunately there are no implementations today
... so there is massive fragmentation

Dom: I guess them I would start during last call with a simple set of test cases
... leave most difficult tests to CR when it is more stable and there are more implementations
... leave evil tests to later

MC: If we will be doing it that way, we might just start creating test cases by hand
... rather than automate the process

Dom: one thing that helps is formluating the conformance requirements
... eg what things would be the subject of conformance?

MC: There are 3 things:
... wodget package
... widget configuration document
... widget runtime
... conformance checker

(4 things)

Dom: would initial focus be on the engine?
... so focus on these conformance statement?

MC: eg testing validity of zip archive
... we could construct an invalid archive
... and test that an engine rejected it

Carmelo: 2 observations:
... mentioned about creating tests by hand:
... usually very time consuming
... xml driven approach is a good idea

MC: I don't think we have expertise in XSLT in this group

Dom: we could help with that

Carmelo: ... would it be possible to markup tests directly in the spec?

MC: we already have some markup (eg css class)

Dom: you could do some XSLT to extract them

JK: At Nokia been creating an internal document toolchain
... where testable requirements can be identified by markup
... could maybe make this available

MC: we can easily add the markup

Carmelo: have a paper on this I will send

<ArtB> ACTION: Barstow ask Carmelo for the URI of his testing paper [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action05]

<trackbot> Created ACTION-277 - Ask Carmelo for the URI of his testing paper [on Arthur Barstow - due 2008-10-28].

Dom: once you have the testable assertions you still have to create the content corresponding to the test case
... I expect this needs to be done by hand

MC: Yes

Dom: one way to proceed would be to automate the creation of basic test case template only
... but start manually creating the content of each test case
... explicitly referenced to each testable assertion

MC: I imagine I will be the one writing the test cases

KH: I can help

Carmelo: we have a tool which can take test definitions in XML format and generate test cases

<ArtB> ACTION: Barstow figure out a way (procedurally) for Kai Hendry to contribute to the Widgets testing (with Mike Smith) [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action06]

<trackbot> Created ACTION-278 - Figure out a way (procedurally) for Kai Hendry to contribute to the Widgets testing (with Mike Smith) [on Arthur Barstow - due 2008-10-28].

Dom: based on formal RelaxNG description of configuration document perhaps this can be used to drive automate creation of some test cases
... also this can be used to validate the examples in the spec
... this also validates the schema

MC: once we are in last call this will be included in validator.nu
... if that existed it will be very easy to create non-conforming content

Dom: also might want to export examples from spec to test cases and vice versa

MC: now it's just a matter of gathering the tools

Dom: initially start highlighting test cases more explicitly as blocks
... then I can start work on extracting them

MC: that would be great

Carmelo: sounds like we would be working together for a while

AB: to Dom, can you give us an update on the work you're doing?

Dom: there are a few people working on it

KH: can be get Wilhelm working on it?

<ArtB> ACTION: Arve talk to Wilhelm about contributing to the Widgets testing effort [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action07]

<trackbot> Created ACTION-279 - Talk to Wilhelm about contributing to the Widgets testing effort [on Arve Bersvendsen - due 2008-10-28].

NA: Will take action to determine whether or not there could be any shared activity with BONDI

<ArtB> ACTION: Nick check with BONDI team to see if they can contribute to the Widgets testing effort [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action08]

<trackbot> Created ACTION-280 - Check with BONDI team to see if they can contribute to the Widgets testing effort [on Nick Allott - due 2008-10-28].

Dom: are you working closely with implementors?
... how far advanced are you with implementation?

MC: no public announcements of implementations at this time

AB: if there are active implementations, please say so

Benoit: the way people are talking about it, it sounds like they are implementing it

ABe: Access are claiming conformance

Dom: I heard Qualcomm claim they are implementing it

<ArtB> ACTION: Barstow propose a new time for the weekly Widgets Voice Conf - 1-3 hours later than now [recorded in http://www.w3.org/2008/10/21-wam-minutes.html#action09]

<trackbot> Created ACTION-281 - Propose a new time for the weekly Widgets Voice Conf - 1-3 hours later than now [on Arthur Barstow - due 2008-10-28].

MC: one problem is that I will be away in November
... I will be away for 20 days so work will cease
... I will try to do as much as I can in the next week
... most docs fairly close to last call
... would like basic test suite

Dom: not a good idea to put test suite into critical path
... you'll want to get first last call done asap
... and there will be other last calls where corrections can be made arising from test creationb
... someone else can create test cases

MC: I can try doing the markup
... and perhaps Kai can start working on some test cases
... specifically looking at the document from a testability point of view
... that would be great
... once the document is in good enoug shape we can start automating the creation of test case skeletons

KH: we'll talk about it

MC: so while I'm away can you do that? you have a month

Carmelo: I'll send some testable assertion documents

AB: I think we have covered the main questions
... anyone else got anything they want to add?
... or volunteer to do?
... thanks to all and appreciate it
... if people aren't too tired lets look at the API draft

API and event

ABe: just checked in latest version:

<arve> http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

ABe: (version is not built)

AB: we now have an absract

ABe: Marcos, onBlur/onFocus are out so this issue should be deleted
... based on implementation experience we're not sure that this part of the spec (onModeChange) is mature enough
... to be confident we're specifying something sensible
... on the desktop there are 3 modes
...1: chromeless
... 2: chromeless and full screen
... (content has no control over its size)

Benoit: doesn't the content still need to know the size?

Abe: that's not the issue
... our concern is being able to know what modes make sense
... have to understand issues relating to how css size/position directives are processed and understood in each mode
... before we can realistically say what the modes are

MP: are there are any requirements specified already for supported modes?

MC: no specific modes specified yet
... only the mode attribute

ABe: there are also conflicting market requirements for the modes required, and what each means

Claudio: are we talking about docked/undocked mode?

ABe: even here there are multiple options
... you could think of docked mode as iconified
... where there is a facility to update/animate the icon
... the second one is similar except that the contents of the icon are based on an html document
... the third way is that the docked view is a window opened explicitly by the widget
... as in Vista

Claudio: I was looking at it from the user perspective
... it makes sense to understand when a widget is undocked and visible to the user
... and when it is docked it is visible just like a widget
... ie iconified
... in iconified state the widget is still instantiated

ABe: is the docked state exclusive to other display states?
... what should we define as being docked mode?

Benoit: we should define all of these modes explicitly because they are part of the existing environment
... eg active icon in Yahoo!
... sidebar is in Vista
... floating is supported in all of the desktop models
... fullscreen would also be relevant in mobile.

MC: I propose 3 for version 1:

ABe: or 4 if you count hidden

MC: modes in the doc presently:
... docked
... full-screen
... invisible

ABe: docked isn't really a mode in the same way as the others
... when docked it is non-interactive
... and it has to be opened to become interactive again

Benoit: what about supporting the dashboard widget icon bar?
... these are icons, non-interactive
... but can have animation

ABe: or could be an image
... or an animated html document

Benoit: it would be good to define at least some terminology in this meeting

MP: I think it is useful to do this
... but want to find out if Vodafone as requirements in this area

Claudio: could we at least define the modes/states based on use cases?

Benoit: would be interested in capability to temporarily expand an instantiated widget from the docked state
... interact with it
... and then re-dock it, keeping the widget running

MC: I think we will run into problems with this

Benoit: use case on mobile would be an SMS widget

MC: can we do it with multiple content elements, each associated with a different mode?
... corresponding document only exists for the time the widget is in a given mode
... only persistent state carries forward from one mode to the next
... would the html5 persistence model be good enough for this?

ABe: storage is defined in terms of a local storage attribute
... only additional thing needed for this specification is already in the document
... not a change, but the requirement that different widget instances are defined as having separate origins

PB: would multiple instances have the same origin?

ABe: no
... otherwise you could not have different instances with different settings
... eg multiple clock instances, one for each timezone

AB: I have a hard stop in 15 minutes
... how do we wrap this up?

ABe: I propose going forward by moving this document from editors draft and publish it with this as a known issue

MC: I think we at least need to specify two modes
... eg floating and fullscreen
... to provide a starting point to publish the spec

AB: I think that would be good enough to publish

ABe: This is related to the icon interface issue
... I propose that we rewrite this so that APIs for getting/setting view states and icons are omitted

Benoit: there should be a comment about what we have in mind

AB: Arve has made a proposal for what we do right now

Claudio: how is it done in Opera?

ABe: we support css media queries
... so you can do an opera-proprietary media query with a widget mode
... we need to know what a viewState is

AB: where do we stand: Do we have a proposal?

MC: If Vodafone has a proposal it would ne interesting to see
... if BONDI has a proposal it would be interesting
... we should also look again what what is in the landscape document
... we need to limit the supported viewStates to the minimum
... packaging should be independent of this
... so we have to separate things so that this issue doesn't hold up the packaging spec

AB: we could continue to spend more time on this
... but I think we should move on

V2 list

<claudio> http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R

<arve> relevant link on Opera widget modes: http://dev.opera.com/articles/view/widget-modes-docked-widget-and-more/

Claudio: there is a list of features that might be interesting in v2
... different items at different levels of granularity
... we can't go now into detail
... invitation to all is to refer to the wiki page and check it and make sure that if there is something you want then it is added to the list
... then we will see what makes sense to address in v2

AB: I don't have anything much to add
... (to all) if you add anything to the list please make sure there is sufficient detail to make it comprehensible
... also please clarify whether the scenarios already listed are just examples or real proposals

Claudio: the important thing is to get people to identify shortfalls and work constructively towards resolving them in v2
... rather than just using them to criticise v1

AB: this is a great start
... anyone in the WG can have write access to this
... but pls check with Claudio first

Benoit slides

Benoit: introduction
... these are just internal slides I prepared
... but I wanted to share them with the group
... if the group feels they can usefully be reused we can rebrand/reformat them
... 2 elements I wanted to present
... 1 is standardisation process
... 2 is about WG activity specifically
... as we don't have time now we won't go into the details
... tried to capture who is active in this WG
... outline widget definition, and WG deliverables and relationship
... outline current status and roadmap

AB: do we want to go ahead and put some of this information on the wiki?
... I would characterise it has having 4 pieces of information:
... a) w3c process
... b) widget intro .. put in widgets page in wiki

<ArtB> AB: status is http://www.w3.org/2008/webapps/wiki/PubStatus

AB: c) status
... d) roadmap .. not opposed to publishing it but don't want to be held to it

MP: Vodafone would appreciate having this document for internal Q&A

AB: a bit concerned about publishing the roadmap information

Benoit: in order to provide a complete overview I need a complete set of slides

AB: so upload the entire document to the wiki?

Benoit: yes
... I think a slideset is a useful format

AB: so how do we maintain it?

Benoit: don't know, that's the question
... for example can we just update the status by hand at the end of each weekly meeting?

AB: what do others think?

PB: I think it is useful if non-branded but cautious about roadmap information

MC: what if just the roadmap is maintained on the wiki, but everything else is in the powerpoint?
... then the roadmap information can be copied in when needed or updated

Benoit: is anyone opposed to having their logos in the presentation?

AB: maybe remove Nokia if there's an implied commitment to meet the roadmap
... need to wrap up
... we don't have consensus yet
... continue discussion on mail list

F2F meeting

AB: Benoit agreed to host us in Paris

Benoit: regluar meeting logistics are easy
... but coffee breaks might not be catered

AB: would you be able to accommodate the APIs parallel track as well?

Benoit: it should be OK
... based on the numbers we usually get
... a single large room for plenary meeting would be harder

AB: would a 4-day meeting be possible?

Benoit: yes
... (except for coffee)

AB: need to check with Chaals, Mike, Doug
... what about timing?
... security workshop is in December
... and we need 8 week notice

Benoit: earliest date for last call on packaging spec is beginning of December
... so review period goes to end December
... so late January night be a good time for the meeting

DR: there is an OMTP meeting in Jan 26-30th (London)
... MWC is 16-19th February (Barcelona)

Claudio: W3C w'shop (future of social networking) 15-16th January (Barcelona)

AB: we're done

- DRAFT -

Widgets f2f Meeting

21 Oct 2008

Attendees

Contents