W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

[widgets] Minutes from 21 October f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 21 Oct 2008 16:41:14 -0400
Message-Id: <50251D2E-67C6-4717-893F-DAE6B75F9111@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the October 21 Widgets f2f meeting are available at  
the following and copied below:


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

-Regards, Art Barstow


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

                                - DRAFT -

                           Widgets f2f Meeting

21 Oct 2008


       [2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda

    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/21-wam-irc


           Paddy, Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike,
           Lucy_Lynch, Nick, Bashar_Jano, Philipe_LeHegaret,
           Frederick_Hirsch, Thomas, RobMiller, PratikDatta, Gerald,
           Edgar, KelvinYiu, BrianLaMacchia, ChrisSolc, BruceRich,
           Kai_Hendry, Carmelo, Dom, Denise




      * [4]Topics
          1. [5]Agenda Review
          2. [6]Widgets 1.0 Digital Signature spec
          3. [7]transform element
          4. [8]Certificate Chains
          5. [9]Widgets Requirements LC #2
          6. [10]Widgets 1.0 Updates spec
          7. [11]Digital Signature Joint meeting with XML Sec WG
          8. [12]Widget Permissions, Access, etc.
          9. [13]Widget Testing
         10. [14]API and event
         11. [15]V2 list
         12. [16]Benoit slides
         13. [17]F2F meeting
      * [18]Summary of Action Items

    <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 [19]http://dev.w3.org/2006/waf/widgets-digsig/

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


      [20] 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

    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

    <scribe> ACTION: thomas do you object to the removal of the
    WidgetSignatureInfo element? [recorded in

    <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 [22]http://www.w3.org/TR/widgets-reqs/

      [22] 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

    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: [23]http://dev.w3.org/2006/waf/widgets-updates/

      [23] 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

    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

    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

    <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


      [25] http://www.w3.org/2008/webapps/wiki/ 

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

    <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
    ... 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
    ... 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

    <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 ,

      [27] http://webapp.etsi.org/workprogram/Report_WorkItem.asp? 

    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> [28]http://tools.ietf.org/html/rfc3986#section-5.1.2 ...

      [28] 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> [29]http://en.wikipedia.org/wiki/XAdES

      [29] http://en.wikipedia.org/wiki/XAdES

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


      [30] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec- 

    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

      [31] http://www.oasis-open.org/committees/download.php/16790/ 

    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
    ... 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
    ... 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

    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

    <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()
    oing()} 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> [32]http://example.org/feature/feature/freature OR

      [32] http://example.org/feature/feature/freature

    <ArtB> MP: also need to consider composite widgets

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


      [33] http://camera.api.org/gps/changename/contacts/add/delete/ 

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

    <marcos> <feature id="http//camera.example.org"/>

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

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

    <marcos> <feature id="http//camera.example.org"> <permission
    name="gps" value="allow"/> </feature>

    <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

    <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> <feature id="http//camera.example.org?gps=allow"/>

    <marcos> <feature id="http//camera.example.org">

    <marcos> <permission name="gps" value="allow"/>

    <marcos> <permission name="sound" value="disallow"/>

    <marcos> </feature>

    <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

    <arve> >

    <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

    <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

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

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

      [35] http://www.w3.org/2008/security-ws/

Widget Testing

    <ArtB> AB: agenda

      [36] http://www.w3.org/2008/webapps/wiki/ 

    <ArtB> Scribe+ Paddy

    <dom> ScribeNick: paddy

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

    <dom> [37]Dom's initial comments on Widgets packaging and

      [37] http://lists.w3.org/Archives/Public/public-webapps/ 

    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

    Dom: I think a good way to start is to identify each conformance
    ... 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

    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
    ... 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

    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

    <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

    <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
    ... 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

    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
    ... 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

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

    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

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

    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

    <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
    ... 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> [43]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

      [43] 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

    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

    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

    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
    ... 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
    ... 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> [44]http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R

      [44] http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R

    <arve> relevant link on Opera widget modes:

      [45] http://dev.opera.com/articles/view/widget-modes-docked- 

    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
    ... 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

      [46] 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

    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

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

    AB: maybe remove Nokia if there's an implied commitment to meet the
    ... 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

    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

    AB: we're done

Summary of Action Items

    [NEW] ACTION: Arve talk to Wilhelm about contributing to the Widgets
    testing effort [recorded in
    [NEW] ACTION: Barstow ask Carmelo for the URI of his testing paper
    [recorded in
    [NEW] ACTION: Barstow figure out a way (procedurally) for Kai Hendry
    to contribute to the Widgets testing (with Mike Smith) [recorded in
    [NEW] ACTION: Barstow propose a new time for the weekly Widgets
    Voice Conf - 1-3 hours later than now [recorded in
    [NEW] ACTION: Claudio Add handling 50 widget update use case and
    requirements to the v2 feature and requirements list [recorded in
    [NEW] 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
    [NEW] ACTION: Mark what is our lifecycle, revocation model?
    [recorded in
    [NEW] ACTION: Nick check with BONDI team to see if they can
    contribute to the Widgets testing effort [recorded in
    [NEW] ACTION: thomas do you object to the removal of the
    WidgetSignatureInfo element? [recorded in

    [End of minutes]
Received on Tuesday, 21 October 2008 20:42:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC