W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

[widgets] Minutes from 7 August 2008 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 7 Aug 2008 08:25:11 -0400
Message-Id: <B089BF9D-62B3-4AA2-8031-CFBFF09BE1A4@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the August 7 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 August 14 (next voice  
conference); otherwise these minutes will be considered approved.

-Regards, Art Barstow


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

                                - DRAFT -

                        Widgets Voice Conference

07 Aug 2008


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

    See also: [3]IRC log

       [3] http://www.w3.org/2008/08/07-wam-irc


           Art, Nick, David, Luca, Claudio, Mark, Marcos, Thomas, Arve,




      * [4]Topics
          1. [5]Agenda Review
          2. [6]Annoucements
          3. [7]R11 Digital Signatures
          4. [8]R38 Addtional Digital Certs
          5. [9]Proposed Requirements
          6. [10]Signing Procedure Agnostic
          7. [11]AOB
      * [12]Summary of Action Items

    Date: 7 August 2008

    <scribe> Scribe: Art

    <tlr> whooops

    <scribe> ScribeNick: ArtB

    <tlr> zaim, I am thomas

    <marcos> I would never!

    <marcos> :)

    <marcos> oh crap. I'll dial in again.

    <marcos> tlr, was it me?

    <marcos> hmmm...., there is nothing next to me or any other device.
    Will dial in again

Agenda Review

    AB: Agenda:

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

    <marcos> any better?

    <marcos> bah!

    <arve> doesn't zakim have some function to see who's making noise?

    <tlr> gah

    <tlr> zkaim, ??P8 is marcos

    AB: any change requests for the agenda

    <marcos> hmmm... sorry about this.

    AB: [none]


    AB: registration for the Turin f2f is open; please register ASAP

      [14] http://www.w3.org/2006/appformats/group/TurinF2F/Participants

    Claudio: must bring a Passport or valid ID
    ... company badge is probably not going to work

    <tlr> I hope there is no NDA coming along with the ID requirement.

    <scribe> ACTION: Barstow passport is required for Turin f2f meeting
    [recorded in

    <trackbot> Created ACTION-21 - Passport is required for Turin f2f
    meeting [on Arthur Barstow - due 2008-08-14].

R11 Digital Signatures

    AB: OMTP input
    ... request mods to several signature reqs and propose some new reqs
    ... who is going to lead the OMTP discussion?

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

    David: Mark will lead the tech discussion

    AB: the proposal expands on the existing text in R11

    Mark: we think the req needs some clarifications
    ... we also propose additional behavior e.g. when there are
    signature chains
    ... need to say what the client will do in various scenarios
    ... need consistent behavior
    ... need to say what happens if the chain can't be verified
    ... e.g. if missing root cert
    ... e.g. if cert is expired
    ... we suggest the Widget should be considered unsigned

    Arve: I'm concerened about treating the resource as valid
    ... it could encourage unsafe behavior by the user
    ... Some users aren't qualified to "make the right decision"

    <marcos> MC: I share Arve's concerns.

    Arve: e.g. is it safe to treat the package as safe

    <marcos> MC: and by unsigned, what do you mean?

    Mark: if the widget is not signed, it should never be presented as
    if it is signed

    Arve: need to clarify unsigned versus invalid
    ... an invalid widget should not be launchable

    Mark: if the root cert is missing we want the widget to still be
    launchable but just not as a "signed" widget

    <marcos> MC: hmmmm.... this results in "security profiles"

    Mark: we don't want additional security privs for an unsigned widget

    TR: want to consider the proposed addition in one piece
    ... If none of the parts can be verifed, treat as unsigned
    ... have a couple of concerns
    ... should install continue if there some part cannot be verified or
    fails verification
    ... Need to address revoked/unrevoked versus expired
    ... We need a consistent model here
    ... and a simple model
    ... but very clear on these issues
    ... Don't want to have an unexpected consequences

    Mark: we are certainly open to reformulating this text
    ... Perhaps we need to flesh out the details of this req
    ... We have some error cases that must be addressed
    ... I will investigate CRL lists
    ... Think we should continue discussions over e-mail

    TR: I understand your concerns Marks
    ... but we need some additional text re the CRL handling
    ... There are also some deployment concerns re revocation
    ... we need to think about those issues too
    ... is there a different UC re revocation then the "normal" ones?

    AB: Mark, what are the next steps for this req?

    Mark: encourage people to discuss on the public mail list
    ... I will take the lead on reformatting the text

    AB: Mark, Thomas - is there some Use Case work that needs to be

    <tlr> That background explanation would be useful, indeed.

    Mark: I can elaborate on the justification

    TR: yes, I think some background info would be useful

    <marcos> MC: yes, they seem mostly ok

    Mark: are people OK with the proposed rationale in our input?

R38 Addtional Digital Certs

    AB: R38:

      [17] http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/#r38.-

    Mark: there is some interaction here with the security policy and
    root certs
    ... need a mechanism to define the relationship

    Marcos: I think the proposal is good

    Arve: if the engine has a mechanism for installing or uninstalling a
    root cert, then I think a MAY is sufficient

    Mark: need to be more explicit about the relationship between the
    root cert and security policy
    ... in BONDI expect a hook between a root cert and a security policy
    ... root certs will have different trust levels

    <arve> Do we need to define a method to define/export trust
    level/security configuration for certificates? What would this need
    to look like?

    Mark: we haven't made a final decision on the various approaches we
    have talked about
    ... would like to get some feedback on this issue
    ... This is a broader issue then just widget signatures

    TR: we are moving into much larger secuity models
    ... I don't think those type of broad policy models should be in
    scope for the signature spec
    ... Say "can install root certs; there may or not be restrictions on
    how they are used" but perhaps not a lot more

    Arve: I tend to agree
    ... the issue is more about trust delegation

    TR: it's also about how you shape the market
    ... suggest a relatively dry model
    ... and not try to address broad policy issues

    Mark: I also tend to agree with Thomas
    ... The topic does need to be addressed i.e. security policy and we
    will continue to work on it in BONDI

    AB: so where do we stand on this req?

    Mark: think we need to refine the wording
    ... And also address Thomas' concerns

    <tlr> Trust in a root certificate is established through a security
    critical mechanism that is out of scope for this specification.

    Mark: this discussion is also relevant to R43

    TR: a problem with policies here is that the industry is doing
    different things here
    ... we need to be careful not to go in YA direction

    Mark: we need to define some behavior

    Marcos: yes, the engines are doing different things
    ... Arve already posted their model

Proposed Requirements

    AB: how do we want to address these?

    Marcos: I think they are mostly good
    ... and I can add them as is

    Mark: Thomas submitted some reqs
    ... Signing Procedure Agnostic is one TR responded to and I'd like
    to take it first

    Bryan: the MWBP WG also propsed some new reqs
    ... have they been received?

    Marcos: yes, I saw them

    <tlr> marcos, URI?

    Marcos: I haven't had time yet to read them in detail
    ... I will respond soon-ish

Signing Procedure Agnostic

    <marcos> tlr... getting it.

    <marcos> tlr :

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

    <marcos> and

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

    Mark: I think this req needs some clarification
    ... we expect scenarios with different Actors involved

    <marcos> MC: Here is link to Arve's security input:

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

    AB: Thoma's comments on this:

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

    Mark: we need to decide what is mandatory to support
    ... Re PKCS#11 interface, it is being used today
    ... thus we see a need for some interop

    TR: so the req is "don't mess up the ability for smart card to be
    ... on the face, it make sense
    ... But what does this req actually apply to?
    ... e.g. does it apply to every crypto mech that could be plugged in
    ... Need some examples; what are the challenges.

    Mark: those are good points

    <tlr> Put differently, this may be a slam-dunk or a major problem. I
    suspect slam-dunk, but I'd like to be sure of that.

    <scribe> ACTION: Mark create some motiviation and examples for the
    proposed Signing Procedure Agnostic requirement [recorded in

    <trackbot> Created ACTION-22 - Create some motiviation and examples
    for the proposed Signing Procedure Agnostic requirement [on Mark
    Priestley - due 2008-08-14].

    Marcos: not clear what the WG will do with this input

    Mark: I think we may need to break it down a bit
    ... we need to make sure we don't break existing mechanisms

    Marcos: should we establish a more formal liaison with XML Security?

    AB: I think that make sense
    ... after we have fine-tuned the signature reqs

    TR: I can help liaise with the XML Security WG
    ... when we understand the PKCS#11 req better, we should discuss it
    with XML Sec

    <claudio> +q

    Mark: perhaps some of our proposed reqs are more appropriate for the
    XML Sec WG to address

    Claudio: in general we'd like OMTP to provide some clearer Use Cases
    ... we think it would facilitate the discussion

    <tlr> +1 to Claudio, actually

    Claudio: would also help us understand whether or not the reqs are
    out of scope or in scope

    Mark: we have provided rational for some of the reqs
    ... It would be better if people were mor explicit about which reqs
    need more information

    Claudio: the rationale is good but security models and policy are
    quite broad and knowing specific Use Cases would be very helpful
    ... again to help with "scope" related issues
    ... having the Use Cases more explicit now should actually make the
    spec work go quicker


    TR: when is the next conf call?

    AB: next week; same time
    ... End of Meeting

    <claudio> quit

    <Luca> quit

Summary of Action Items

    [NEW] ACTION: Barstow passport is required for Turin f2f meeting
    [recorded in
    [NEW] ACTION: Mark create some motiviation and examples for the
    proposed Signing Procedure Agnostic requirement [recorded in

    [End of minutes]
Received on Thursday, 7 August 2008 12:26:39 UTC

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