W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[widgets] Minutes from 12-Feb-2009 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 12 Feb 2009 14:51:40 -0500
Message-Id: <44AF2672-107C-4023-BC71-7CFEBE977E08@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the February 12 Widgets voice conference 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 19 February 2009 (the  
next Widgets voice conference); otherwise these minutes will be  
considered Approved.

-Regards, Art Barstow


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

                                - DRAFT -

                        Widgets Voice Conference

12 Feb 2009


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

    See also: [3]IRC log

       [3] http://www.w3.org/2009/02/12-wam-irc


           Art, Arve, Benoit, Mark, Frederick, Josh

           Marcos, Claudio, Mike, Thomas, Jere




      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]Announcements
          3. [7]Context of Widgets DigSig discussion
          4. [8]Use Cases
          5. [9]Requirements
          6. [10]Is supporting multiple signatures per package a MUST
             for v1?
          7. [11]AOB
      * [12]Summary of Action Items

    Date: 12 Feb 2009

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

Review and tweak agenda

    AB: Widgets DigSig spec is the only item on the agenda and it's
    relatively packed
    ... If we can't get to a topic and its not "closed" by the f2f
    meeting, we can add the topic to the f2f agenda
    ... Any change requests?

    Arve: Marcos is critical for these discussions

    AB: agree. If we make any decisions, we can make them tentative
    pending input from Marcos
    ... would that be acceptable Arve?

    Arve: yes


    AB: Feb 24-26 f2f meeting agenda has been updated:
    ... [13]http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
    ... any other announcements?

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


Context of Widgets DigSig discussion

    AB: Let me start with a little context setting ...
    ... Some recent discussions indicate we may not all be on the same
    page re Use Cases and Requirements
    ... I want to step back a bit and make sure we're in agreement here
    ... As you know Frederick is now a co-Editor of the DigSig spec and
    he is an Editor of the XML Sig spec
    ... but he wasn't part of the WG when we started this spec and hence
    may be missing some context
    ... We can use this call to help clarify some high level UCs, Reqs,
    ... Note that we will dedicate all of Wedn afternoon on Feb 25 for
    DigSig and can get into the spec details tehn
    ... A factor we need to consider as we discuss UCs, Reqs and the
    Spec itself is what is mandatory for v1.0 versus the NextGen (NG)
    ... We must also be very careful to separate what we need to specify
    in the spec itself versus deployment issues that are out of band and
    implementation issues which of course are also out of band
    ... Regarding the roadmap/timeline for this spec, I would like to
    see a new WD in early March with a LCWD in April/May and a Candidate
    starting beginning in June/July
    ... This may seem a bit aggressive and we can spend some time
    talking about schedule today and/or at the f2f meeting
    ... So with that introduction are there any quick follow-ups or
    comments before we move to the agenda?

    FH: want to think about XML Sig 1.1 schedule

    <scribe> ACTION: Barstow need to track Widgets DigSig and XML Sig
    1.1 for possible conflicts [recorded in

    MP: we fully support an agressive timeline for this spec
    ... agree we need to get agreement on the high level objectives
    ... don't think the spec issues are that great

Use Cases

    AB: what are the main use cases regarding creation, installation and
    ... we don't really have a Use Cases document per se
    ... However, for each requirement we do have some descriptive
    information and "Motivation"
    ... Frederick, All - what do you want to discuss regarding Use
    Cases? What needs clarification and what's missing?
    ... Before I open the floor, let's be careful to not conflate what
    needs to actually be specified in our DigSig spec versus deployment
    issues and implementation issues

    FH: a few questions
    ... not sure I understand update model and sec features related
    ... Also need to understand the UCs wrt the properties

    MP: in one of my emails to the list I expanded on the UCs

    <fjh> I understand the use case of widget package integrity, via
    signature at any time, not clear on other use cases, including
    update or need for properties

    MP: some of them don't necessarily need to be part of v1 of the spec
    ... But v1 must not rule out those UCs postponed to v.NG
    ... Main one: use signature to verify identity

    <fjh> use case includes signature verification and cert validation,
    trust establishment

    <mpriestl> ...and to verify that some entity has signed the widget
    package and is making some statement about it

    MP: wrt updates, we realized there is a need to support more than
    one sig
    ... in a package
    ... e.g. an "update signature"
    ... need to reliably establish an update is a reliable replacement
    ... different levels of strength to do that
    ... an update sig would be separate
    ... the original pack could have an update sig
    ... and if the update sig in the original pack has the same key as
    the separate update sig
    ... have confidence the upate is reliable
    ... Think the usage property can be usefule here
    ... Some rule changes would need to change to reflect this usage

    FH: have one comment about main UC but I can defer it
    ... Still confused on the update scenario
    ... Does the update replace the entire widget?

    MP: yes
    ... how do you know the update you want to install is the "right"
    one to use for the update

    FH: a hash of the orig widget can be used
    ... don't think you need keys

    MP: there is a widget id
    ... don't want anyone to trick the install mechanism
    ... a hash of the widget could be fudged too

    FH: not sure all of the info needed can be put in the property

    MP: perhaps I should expand on the mail list

    FH: this is the critical UC that is driving the property use
    ... I don't understand the update mechanism well enough

    MP: I'm suggesting the update sig could be one of the mech used to
    decide if an update widget is the authorized update

    FH: concerned about using the same prvt key
    ... what if it is revoked
    ... Could use org name
    ... still not sure I understand the UC
    ... not clear about auth decision
    ... but the idea is the Usage property cand help

    MP: the update sig is not the same as the widget signauture
    ... using other parts of the cert is problematic

    <fjh> ok

    FH: perhaps we can simplify more
    ... there are a few roles in the model now
    ... do you really need an update prop

    MP: there is an author signature and the distributor signature

    <fjh> author signature to be coverd by distributor signaure

    MP: can expect distributor sig to cover the author sig

    FH: don't think a Usage property is needed
    ... I can generate a proposal for this

    <scribe> ACTION: Hirsch create a proposal for properties and send it
    to the mail list [recorded in

    FH: re UC #1 above.
    ... concerned about integrity if sigs can be added or removed
    ... think we need one sig that covers all of the other sigs

    MP: agree we have to think about this

    FH: two possible attacks: one is something is missing; another is
    man in the middle
    ... Need to note the risks

    MP: I'm fine with that

    <fjh> first risk can be addressed legally, author does not include

    <fjh> second man in middle, could be addressed by transfer channel
    security e.g. tls

    <timeless> zakim who is on?

    FH: beside the two UCs we have discussed, are there others?

    MP: we've mainly discussed these two
    ... there are some others we have talked about
    ... but they aren't critical for v1
    ... Howver, we don't want v1 to preclude addressing the other UCs

    <fjh> ability to sign portions of content is inherent in xml
    signature capabilities

    MP: want to make sure we have an extension mechanism
    ... may be able to use roles
    ... I can provide feedback once I see FH's role inpunpout

    FH: want to make sure we understand OCSP

    MP: I responded today
    ... think it can be removed from the spec


    AB: the basic question here is if the related requirements are
    "right" or do they still need some work e.g. additions,
    ... the agenda contains the list of related reqs and there are 8 of
    ... I don't think we should necessarily go thru each of them but we
    can spend time on those that are particularly problematic.
    ... the requirements doc is

      [16] http://dev.w3.org/2006/waf/widgets-reqs/%3E

    FH: two questions
    ... one I already responded on the list
    ... the other is about elliptic curve
    ... we can also take that on the list
    ... we still need to explicitly define the algorithms

    <fjh> issue ECDSAwithSHA256 as required algorithm in place of
    DSAwithSHA256? related to XML Signature 1.1 outcome as well

Is supporting multiple signatures per package a MUST for v1?

    AB: there has already been some discussion on this

    <fjh> issue: ECDSAwithSHA256 as required algorithm in place of
    DSAwithSHA256? related to XML Signature 1.1 outcome as well

    AB: Mark says this is a MUST:
    ... Other comments?

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

    <fjh> ISSUE: ECDSAwithSHA256 as required algorithm in place of
    DSAwithSHA256? related to XML Signature 1.1 outcome as well

    MP: Marcos sent something to the list about this
    ... I think his proposal is a good one
    ... I don't think it is a big issue to specify

    FH: if have different roles that could get complicated

    <mpriestl> good point - still shouldn't be that complicated though -


    AB: register for f2f meeting; deadline is Feb 16 to register
    ... meeting adjourned

Summary of Action Items

    [NEW] ACTION: Barstow need to track Widgets DigSig and XML Sig 1.1
    for possible conflicts [recorded in
    [NEW] ACTION: Hirsch create a proposal for properties and send it to
    the mail list [recorded in

    [End of minutes]
Received on Thursday, 12 February 2009 19:52:44 UTC

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