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

[widgets] Minutes of 27 August 2008 Widgets f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Sat, 30 Aug 2008 09:15:12 -0400
Message-Id: <35F8B417-C254-4412-951D-213BA96E4D42@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the August 27 Widgets f2f meeting are available at  
the following and copied below:

  <http://www.w3.org/2008/08/27-wam-minutes.html>

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

-Regards, Art Barstow

    [1]W3C

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

                                - DRAFT -

              Web Applications Working Group Teleconference
                               27 Aug 2008

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

    Present
           Art_Barstow, Marcos_Caceres, Mark_Priestly, David_Rogers,
           Fabio_Ricciato, Luca_Bruera, Benoit_Suzzane, Marco_Bartolini,
           Maruo_Sacco, Paddy_Byers, Thomas_Landspurg, Claudio_Venezia,
           Josh_Soref, Arve_Bersvendsen, Nick_Allot, Thomas_Roessler,
           Mike_Smith, Walter_Goix

    Regrets
    Chair
           Art

    Scribe
           Art, timeless

Contents

      * [4]Topics
          1. [5]Agenda Review
          2. [6]R11 Digital Signature
          3. [7]Handling the remaining comments from OMTP re Signature
             requirements
          4. [8]Dig Sig Issues
          5. [9]Issue #15 - Allow or deny installing additional digital
             certificates on widget engines?
          6. [10]Issue #19 - Widgets digital Signatures spec does not
             meet required use cases and requirements
          7. [11]Issue #22 - Is sha1 as a DigestMethod strong enough for
             Widgets digital signatures?
          8. [12]Security Model
          9. [13]Marcos' Strawman for API Binding
         10. [14]API and Events Spec
         11. [15]Next Steps for the API and Events spec
         12. [16]Auto Updates
      * [17]Summary of Action Items
      _________________________________________________________



    <tlr> trackbot, start meeting

    <trackbot> Date: 27 August 2008

    <tlr> ugh

    <tlr> art, how many people do we expect to dial in?

    <ArtB> ScribeNick: ArtB

    <scribe> Scribe: Art

    <timeless>
    [18]http://mxr-test.konigsberg.mozilla.org/dev-w3/source/2006/waf/wi
    dgets/

      [18] http://mxr-test.konigsberg.mozilla.org/dev-w3/source/2006/ 
waf/widgets/

    <MikeSmith> tlr: I think we will just need to do the ad-hoc
    conference thing

    <tlr> sounds like it

Agenda Review

    <timeless> /m mikesmith can you tell zakim about +??P0?

    AB: agenda [19]http://www.w3.org/2006/appformats/group/TurinF2F

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

    <tlr> artb: OMTP will send PDF to mailing list which identifies
    contribution from OMTP members that have not agreed to patent policy

    <tlr> ... will go through document, with exception of areas that
    David has identified ...

    DR: Art, are you OK with Aplix's participation in this meeting?

    <tlr> artb: understand that applix will agree to patent policy. With
    that understanding and promise, ok with them participating in
    meeting.

    AB: OMTP's attorney and W3C's attorney have agreed Aplix can
    participate if they will agree to the W3C Patent Policy.
    ... Paddy Byers indicated Aplix will agree to the W3C Patent Policy.
    ... Given this understand that Aplix will make this agreement, I am
    OK with them participating in this meeting as if they were a WG
    member.

    <tlr> tlr: I heard a promise to finalize paperwork, which typically
    means somebody hasn't yet signed off on things.

    <tlr> ... somebody care to explain?

    PB: just to clarify, our dialog with Rigo says we must nominate
    someone from Aplix to make the formal agreement to the W3C Patent
    Policy

    <MikeSmith> yep, can hear now

    <tlr> pb: understanding of the process to follow is, (a) nominate an
    authorized representative who can make these commitments, (b) make
    submission. Have completed that step. According to Rigo's step,
    signifies agreement to patent policy. Understanding is that we have
    ageed to that.

    PB: my understanding is we have agree to the Patent Policy

    <tlr> ... next step would be to make specific disclosures regarding
    to possible claims ...

    <tlr> ... we have no such disclosures to make ...

    <tlr> ... there are no patents we hold that we believe are relevant
    to current scope of WG ...

    <tlr> ... given instructions from Rigo, I believe that's all we need
    to do ...

    <tlr> ... confirmation from Rigo pending ...

    AB: any concerns Thomas or Mike?

    <tlr> I'll try to get Rigo to answer that e-mail ASAP ;-)

    MS: as long as Rigo has agreed to Paddy's participation, it's OK
    with me
    ... I will try to get Rigo's confirmation right now

    AB: we will begin with OMTP's document whose Subject was "... 1 of
    2"
    ...
    [20]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    08.html

      [20] http://lists.w3.org/Archives/Public/public-webapps/ 
2008JulSep/0308.html

R11 Digital Signature

    MP: suggested some re-wording of the existing text to correct some
    minor points and to clarify
    ... We then added some new sub-requirements
    ... [ Mark reads the new text proposal ]
    ... A question was raised about the CRLs
    ... I submitted a response on 13 August
    ...
    [21]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    98.html

      [21] http://lists.w3.org/Archives/Public/public-webapps/ 
2008JulSep/0398.html

    JS: not sure this can really be done in practice
    ... need to get some buy-in from CAs

    MP: what is your suggestion, Josh?
    ... Should we talk to the CA Forum?

    JS: yes, I think so

    <tlr> tlr: Sorry for cutting in; Paddy can participate as an
    observer for the moment. There's another step to be taken.

    <claudio> A conforming specification shall specify that if none of
    the signatures and certificate chains can be verified, e.g. because
    of missing root certificates or where any certificates in the chain
    have expired or are not yet valid, then the widget resource shall be
    treated as unsigned

    <timeless> i'm trying to look up the cab forum link - and avre was
    away

    AB: any objections to accepting sentence #1 in the paragraph of new
    text in section R11 - begins "A conforming specification SHALL
    specify the expected behaviour when multiple signatures and
    certificate chains are provided."

    ABe: I am uncomfortable with this

    <tlr> I cannot follow the discussion

    ABe: would rather say it will be treated as an invalid widget
    package

    <MikeSmith> arve: you need to get close to mic

    ABe: To me this is more of something that belongs in an informative
    doc and not a spec

    <timeless> ABe: deciding whether to trust / allow a certain feature
    for a widget is not a decision that a user is competent to make.

    MP: why should it be non-conformant?

    <timeless> ABe: marking a widget as unsigned would require the user
    to confirm each individual privilege as the widget tries to use it.

    ABe: because it is invalid
    ... if can't verify then it should be considered invalid

    <timeless> ABe: An expired or unverifiable certificate ...

    <timeless> JS: [from earlier] The CA/Browser forum
    ([22]http://www.cabforum.org) is a voluntary organization of leading
    Certificate Authorities and vendors of Internet browser software.
    [23]http://www.cabforum.org/

      [22] http://www.cabforum.org)/
      [23] http://www.cabforum.org/

    <timeless> ABe: typically a widget containing a signature will be
    requesting access to additional device APIs.

    <timeless> ABe: the browser does not want to present a dialog asking
    the user for permission to use these APIs with a note that not
    allowing these accesses will result in the widget not working.

    <tlr> Scribe: timeless

    <tlr> ScribeNick: timeless

    ABe: Pestering users with these dialogs is what enables rampant
    phishing today.
    ... a widget will not be able to run. e.g. if a widget says I need
    to use the messaging APIs in order to run (but it isn't
    signed-valid) then it won't work.
    ... and a user wanting the feature is forced to allow the widget to
    run.

    <tlr> timeless, please scribe everyone.

    trying

    <tlr> I heard somebody say they strongly object to something, but
    didn't hear what they objected to.

    MC: is afraid of developers being forced to pay money for device
    APIs.

    <tlr> timeless, don't worry about handles

    <marcos> MC: I strongly object that API access should only be
    allowed if you have purchased a cert

    <tlr> just say ??1 or something like that, and hope that Art will
    figure out who speaks

    MC: [earlier] strongly objected ...

    artb isn't nearby

    <tlr> timeless, *anybody* in the meeting can correct notes

    <tlr> it's more important that you scribe *something* than getting
    the attributions right.

    <tlr> I'm sure Art and Marcos will help correct the attributions.

    <tlr> Just *scribe*. ;-)

    ABe: a user isn't competent to make decisions, nor am I, about
    whether a widget should have access to an API.

    MP a user may be able to make decisions based on other things.

    MP you get a system where only signed widgets have access to APIs.

    ABe: [tries to explain the difference between an invalid resource
    and permissions to use features?]
    ... a widget user agent could present a widget that is invalid, but
    it doesn't prevent the widget user agent from allowing an exception.

    MP there's already the (seperatable?) problem relating to CRLs.

    <marcos> MB: my proposal is to remove this sentence (regarding certs
    not falling), and saying this is an implementation detail (ie.,
    leave it to implementers to as to how the implementation treat the
    certs that can't be verified).

    ??1: we need...

    MC: we need to do something

    <tlr> I'm sorry, but sound quality is bad enough that I can't follow
    the meeting in any useful way.

    MP to be clear that's not what we're saying there

    MC: there might be some possibility of things being hacked.

    ??: the suggestion we're making is that they [invalid widgets] be
    treated as unsigned.

    MC: let's say we got a widget signed by you. and then you revoke it.
    ... we'd be able to exploit the trust.

    <tlr> art, I'll be happy to review the draft later on, and to help
    get other working groups to review.

    ??: let's say that you ...

    <tlr> but phone participation just doesn't make sense given the
    quality of the sound.

    ABe: rewording: a conforming specification SHALL specifyu that if
    none of the signatures and certificate chains can be verified, e.g.
    because of missing root certificates or where any certificates in
    the chain have expired or are not yet valid, then the widget
    resource SHOULD be treated as invalid.
    ... A user agent MAY provide a mechanism for forcibly enabling a
    widget to be installed.
    ... An analogy is Firefox 3 when going to a web resource with a
    problematic certificate will allow the user to allow an exception
    for a particular resource.
    ... this leaves the user agent with the ability to handle it.
    ... i have perfectly valid reasons, one of them being marcos's.
    ... i could say treat this widget as if it were signed by some other
    signer.

    JS: [unspoken] this would allow trust from one group but privilege
    assignment by the user/agent based on a different signer.

    ??: being invalid means...

    ??: ... we need to specify one behavior...

    MC: we need to get consensus on the behavior we want.
    ... my position is that the digital signature gives you a way of
    verifying affiliation/authorship.
    ... it gives you verification of data integrity.
    ... it establishes trust as well.
    ... it does not have impact on the security model; doesn't enable
    special APIs.
    ... it should be the group's decision.
    ... as a if it validation fails it SHOULD not be installed.
    ... but a conforming user agent COULD allow it to be installed.

    TL: if you require a widget to be run on a certain device then it
    could be a complete nightmare.

    CV: do we agree w/ MC? do we want to prevent it or what?

    <tlr> From what I see on IRC, we're conflating the "unsigned vs
    invalid" question with the question of waht policies should be based
    on that.

    ??: do we want to use .... digital signatures provide a mechanism to
    establish identity and integrity and in some cases a default level
    of trust.

    JS: tlr: yes. or trying to unconflate it.

    <drogersuk> I'm not sure all the discussion is being captured here,
    the conversation is going quite quicklu

    ??: .... .... what we're saying is that when a widget engine is
    verifying a signature is that it should behave in a consistent way
    across platforms.

    ??: if something can tell that the widget is doing bad things then
    it should not be installed.

    ??: if you can't determine the validity of the signature then you
    should treat it as unsigned.

    ??2: as vodafone, you can say to customers you should only use
    vodafone signed widgets because unsigned widgets could use your
    phone resources in various ways.

    ??: ... phones could be set up with different domains and signatures
    could default assign widgets to the different domains (vodafone,
    other, ...)

    MC: i agree with both sides. if it doesn't have an impact on the
    security model, then you can just treat them as unsigned. as long as
    someone can't come in from the outside and deliberately screw up the
    security chain.

    ??3: for some reason you create a widget, for example you sign the
    widget for vodafone only. but for vodafone spain you want to provide
    the widget but without the signature.

    ??3: does this mean that the widget is treated as invalid because it
    was signed for vodafone germany.

    ??: our position is that it would be treated as unsigned.

    ??: in the other model it would be treated as invalid.

    ??: ... with the ability to force install it

    ABe: roughly that.
    ... with J2ME there are operators who will lock phones and not want
    software installed on their phones.
    ... there are some operators who enable J2ME widgets to run on their
    devices but the same J2ME widget will not run on other operators

    MP: this is what we're trying to avoid

    paddy: it's widely recognized that this is a bad approach and that
    it was a mistake.

    MC: in the Java world it's seen as a security stamp.
    ... if we see it as a stamp of quality assurance and authenticity.
    ... if something can't be verified....

    MP: there's still the problem with CRLs.

    AB: there was a time when you [??5] were putting forth a proposal to
    delete the second sentence.

    <sorry highlighted, i can't transcribe it fast enough it's from the
    BONDI doc?>

    ABe: with the rewording we could allow widgets with invalid
    signatures to run.

    MC: i'm happy with SHOULD (proposed by ABe).

    <tlr> pong, I'm on IRC, but phone quality was bad enough that I
    couldn't follow the meeting

    <tlr> happy to review things later

    <tlr> sorry; I had hoped to participate in the discussion.

    AB: let's see what we can do to wrap up discussion on R11.
    ... what's the editor's understanding of this paragraph.

    MC: i'll let mark and ABe to work it out. when you're done get me
    the paragraph.
    ... please limit your use to the conformance part of the
    specification.

    AB: i want to make sure we have a common understanding of what's
    going to happen to the paragraph that we've been discussing for the
    last hour.
    ... OK, so MC what is your understanding?

    <ArtB> AB: here is the para: A conforming specification SHALL
    specify the expected behaviour when

    JS: could someone dump that into IRC so that I can
    copyedit-transcribe?

    <ArtB> multiple signatures and certificate chains are provided. A
    conforming

    <ArtB> specification SHALL specify that if none of the signatures
    and certificate

    <ArtB> chains can be verified, e.g. because of missing root
    certificates or where any

    <ArtB> certificates in the chain have expired or are not yet valid,
    then the widget

    AB: i'm trying

    <ArtB> resource SHALL be treated as unsigned. A conforming
    specification

    <ArtB> SHALL specify that the widget environment SHALL not install
    or load a

    <ArtB> widget resource when it can determine that any certificate in
    the chain has

    <ArtB> been revoked.

    <tlr> that mixes authentication mechanism and policy.

    hold please!

    <tlr> Can we please move the "shall not install or load" part into a
    separate requirement?

    <tlr> (Just to make it easier to manage contention later on. ;-)

    we're rewriting it now

    now that i have it

    js: i think we are trying to split it into two requirements

    <arve> Zakim: q=

    <marcos> tlr, start with the first sentence

    r11-1

    A conforming specification MUST specify the expected behaviour when
    multiple signatures and certificate chains are provided.

    MP: you have multiple signatures and signature chains. you want to
    address multiple root certificates on specific devices.
    ... then all this sentence says is that we want widget user agents
    to handle those certificate chains in a consistent manner.

    MC: can i be a chicken?

    AB: the question is do we want to support multiple signatures?

    s/AB/MC/ ?

    MC: do we want to include certificate chains?

    Paddy: in the requirements document the sentence as written is
    sufficient it just requires the spec to say something to deal with
    the case where there are multiple certificates.

    ABe: MC you want to know that the requirements given there, what
    would it say in the actual spec.

    <marcos> MC: do we want multiple signatures that are agnostic to
    eachother

    <marcos> ?

    ABe: in reality say that i'm creating the london 2012 olympic widget
    say that I want to allow the widget to run on two distinct platforms
    and they have nothing to do with eachother. i will need to sign them
    twice because they don't have compatible roots.

    <marcos> e.g. signature1.xml, signature2.xml

    MC+all: no no.

    the batching is not my fault, i only batch a single line, everything
    else is this network.

    ABe: if you change the widget package, all signers will have to
    resign it.

    MP: i'm a widget maker in the UK, i want to sign the widget package
    for all the operators.
    ... i want to post my widget package on my portal.

    <tlr> I hope these use cases are captured somewhere...

    MP: to get my widget signed by an operator I may need to make an
    agreement with the operator.

    MC: it's clear that these use cases are what they are / known.

    AB: coming back to that first sentence. do we leave it as is, or
    does it need to be modified?

    MC: i want a coeditor.
    ... if it's too much work to meet that october deadline then i don't
    think i can support multiple signatures without a coeditor by
    version 1.
    ... we need to involve the xml-digsig guys, they need to help us
    with this.

    MP: there are two elements, there's adding text.

    MC: is this stuff defined in X.509?

    MP: it's not processing certificates, it's the next level up. what
    defines the order of processing multiple signatures.

    MP+MC: we need to check

    <marcos> tlr? do you know if there is a spec that defines how to
    process multiple sigs in a chain?

    <ArtB> ACTION: Mark work with Marcos to flesh out the details of the
    processing model for multiple signatures [recorded in
    [24]http://www.w3.org/2008/08/27-wam-minutes.html#action01]

    <trackbot> Created ACTION-224 - Work with Marcos to flesh out the
    details of the processing model for multiple signatures [on Mark
    Priestley - due 2008-09-03].

    <marcos> Does XML dig sig define this?

    <tlr> marcos, do you mean having multiple chains?

    <marcos> or X.509?

    <marcos> yep

    <tlr> mhhh..... you can have multiple signatures of the same
    material.

    <tlr> Not sure about what is defined about multiple chains that lead
    to the same public key

    <tlr> (I.e., same key, different certificates.)

    <tlr> there is some work about countersignatures

    js: read tlr's comments up to parenthetical
    ... +1 line

    <tlr> in other words, I don't have a canned solution for your
    problem right now, sorry. ;-)

    MP: tls is probably right. but we're proposing something different
    here. multiple entity keys for each signature.

    they're reworking the first line.

    A conforming specification MUST specify or recommend a standardized
    behavior when multiple signatures and certificate chains are
    provided.

    <marcos> tlr, thanks.

    <marcos> tlr, it wouldn't be fun if it was all done :D

    ???: who said writing requirements is easy.

    AB: record there are no objections to that rewording.
    ... 90mins for 1 sentence. we might be done by xmas.

    <arve> tlr: it's mostly about requiring to actually write something,
    anything

    <drogersuk> For information - I have re-sent the relevant OMTP BONDI
    input to the mailing list. This highlight the non-W3C member and
    non-RF committed text as discussed earlier.

    we're going to omit this:

    A conforming specification MUST specify that if none of the
    signatures and certificate chains can be verified, e.g. because of
    missing root certificates or where any certificates in the chain
    have expired or are not yet valid, then the widget resource SHOULD
    be treated as unsigned.

    scribe: for the time being until MP+MC+tlr do followup.

    <ArtB> ACTION: Marcos work with Mark and Thomas on sentence #2 in
    the new requirement paragraph of the OMTP input for R11 [recorded in
    [25]http://www.w3.org/2008/08/27-wam-minutes.html#action02]

    <trackbot> Created ACTION-225 - Work with Mark and Thomas on
    sentence #2 in the new requirement paragraph of the OMTP input for
    R11 [on Marcos Caceres - due 2008-09-03].

    MC: ABe do you have an opinion on that line?

    ABe: I reserve the right to complain about that sentence after this
    meeting.

    MC: ABe do you have an opinion on that line?

    ABe: when i get back to oslo i'll have a chat with the relevant
    people. if the right people aren't away I should be able to have an
    answer by next friday.

    AB: that leaves the third sentence.

    JS: suppose AB is a widget vendor and I'm a widget signer. Do i need
    to create my own certificate for each signature i make so that I can
    revoke the certificate i used for the signature?

    ABe: what you're talking about is widget revokation lists.

    MC: claudio had this requirement as well. similar to apple's kill
    switch.

    ABe: what i was trying to say here is that the widget may not be
    part of a widget update system. it may even be a legacy widget.

    ABe is explaining why we can't rely on the update mechanism.

    ABe: widget user agents would have some unspecified way of dealing
    with such widgets.
    ... those mechanisms will have to be in place, so there is no need
    to standardize them.

    JS: what would need to be explained to the widget signers.

    MP: paddy raised a point that the sentence is ambiguous in relation
    to how to handle the case where one certificate is revoked and one
    is not.

    ABe: the reason for revokation could be contractual instead of
    significant to a user.

    MP: i propose not to add the third sentence for the time being. we
    can try to reformulate in the next week.

    for reference, the current wording for the third sentence is:

    A conforming specification MUST specify that the widget environment
    MUST NOT install or load a widget resource when it can determine
    that any certificate in the chain has been revoked.

    <tlr> can we *please* make that a separate requirement, for easier
    reference?

    ABe: a conforming implementation MAY allow the loading of a widget
    resource even if it can determine that any certificate in the chain
    has been revoked.

    AB: tlr: that's really an editorial decision. we're likely to have a
    bunch of sub requirements.

    <tlr> Agree that it's editorial, nevertheless, I think it would be
    useful to make that step.

    MP: i would add to ABe's sentence: provided that at least one of the
    signature chains can be verified.

    ABe: i think that makes sense.

    tlr: i'll do that i guess give me a bit

    <tlr> thx

    r11-1: A conforming specification MUST specify or recommend a
    standardized behavior when multiple signatures and certificate
    chains are provided.

    r11-2: A conforming specification MUST specify that if none of the
    signatures and certificate chains can be verified, e.g. because of
    missing root certificates or where any certificates in the chain
    have expired or are not yet valid, then the widget resource SHOULD
    be treated as unsigned.

    r11-3: a conforming implementation MAY allow the loading of a widget
    resource even if it can determine that any certificate in the chain
    has been revoked provided that at least one of the signature chains
    can be verified.

    as a reminder r11-2 is currently expected to be deleted for the time
    being.

    AB: there's a consensus to add r11-3.

    js: sorry tlr, that's just here, i hope it isn't really
    objectionable to you :)

    ab: we're breaking for lunch

    <tlr> js, I'll look at the stuff and try to get broader review; I
    think that's really more important than just me agreeing

    or at least a bio break (lunch seems awol)

    tlr, sure

    brb

    <ArtB> Scribe: Art

    <ArtB> ScribeNick: ArtB

Handling the remaining comments from OMTP re Signature requirements

    AB: regarding the remaining part of OMTP's input on the Signature
    requirements,
    ... we will follow the same model we've been using for a couple of
    years -
    ... the Editor will submit his comments to the Public mail list
    ... and all of the other WG members should follow-up if they
    disagree with Marcos' comments
    ... and/or if they have additional comments.
    ... As always, silence will be considered agreeing with Marcos'
    comments.
    ... we won't discuss this input document any more
    ... Note Marcos will *not* respond to any parts of the doc that are
    marked as not being under agreement of the W3C Patent Policy.
    ... any concerns or comments?

    CV: some people have asked for some use case work e.g. Thomas
    ... I tend to agree with that

    MC: if we need to document UCs we can do it
    ... We need to focus on the processing model
    ... We will need some other experts e.g. XML Security WG
    ... to help us.

    <scribe> ACTION: Barstow talk to the XML Security WG Chair about how
    to engage that WG in WebApps Signature spec work [recorded in
    [26]http://www.w3.org/2008/08/27-wam-minutes.html#action03]

    <trackbot> Created ACTION-226 - Talk to the XML Security WG Chair
    about how to engage that WG in WebApps Signature spec work [on
    Arthur Barstow - due 2008-09-03].

    PB: can we just defer to XML Signature spec?

    MC: I think we may have some processing rules or reqs that are not
    covered by XML Sig; but I'm not an expert in this area
    ... Thus my interest in engaging with them.

    AB: I'm quite sure we can get XML Sec members to review our work
    ... but getting a commitment to directly contribute is annother
    issue

    <tlr> art, overlap in terms of people is myself

    <tlr> overlap in terms of member companies is Sun, MS, Nokia, Boeing

    <tlr> (based on [27]http://www.w3.org/2000/09/dbwg/overlap)

      [27] http://www.w3.org/2000/09/dbwg/overlap)

Dig Sig Issues

    AB: in the agenda we identified issues #15, #19 and #22
    ... [28]http://www.w3.org/2006/appformats/group/TurinF2F

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

Issue #15 - Allow or deny installing additional digital certificates on
widget engines?

    AB: here is Issue #15
    [29]http://www.w3.org/2008/webapps/track/issues/15

      [29] http://www.w3.org/2008/webapps/track/issues/15

    MP: I thought we discussed this yestereday and Closed it

    MC: we agreed to close this as an impl detail
    ... it is something to compete on

    AB: any objections to closing #15?

    [ None ]

    RESOLUTION: Issue #15 is closed - this feature is considered an
    implementation detail

    <scribe> ACTION: Barstow close Issue #15 with the resolution above
    [recorded in
    [30]http://www.w3.org/2008/08/27-wam-minutes.html#action04]

    <trackbot> Created ACTION-227 - Close Issue #15 with the resolution
    above [on Arthur Barstow - due 2008-09-03].

Issue #19 - Widgets digital Signatures spec does not meet required use
cases and requirements

    AB: the issue is: [31]http://www.w3.org/2008/webapps/track/issues/19

      [31] http://www.w3.org/2008/webapps/track/issues/19

    MC: the rationale section in OMTP's input contains a lot of use case
    information
    ... I think Thomas was asking for more
    ... I think it is closed because there is a place holder in the spec
    for this information

    AB: does anyone object that way of resolving this issue?

    BS: probably better to leave it open

    JS: I'm indifferent, as long as they are available someday,
    somewhere

    AB: so we will leave this open for now

Issue #22 - Is sha1 as a DigestMethod strong enough for Widgets digital
signatures?

    <timeless> JS: what i meant was that if the spec has a note saying
    something needs to be done (which MC says is the case today) then
    i'll complain about the spec and it doesn't matter to me if there's
    an open issue.

    AB: this issue is:
    [32]http://www.w3.org/2008/webapps/track/issues/22

      [32] http://www.w3.org/2008/webapps/track/issues/22

    MC: I propose we support SHA-256 as proposed by BONDI

    <timeless> tlr: ping

    <tlr> pong

    MP: note that SHA-256 is not supported in XML Signature spec

    <tlr> it is not a mandatory to implement algorithm in XML Signature

    DR: please note a non-member has provided input on this requirement

    MP: originally the doc said SHOULD for SHA-256
    ... but other input from OMTP said it should be SHALL SHA-256

    <tlr> however, I'd expect things to change, and I'd expect there to
    be a "blessed" algorithm URI some time soon.

    MP: we don't think SHA-1 will be good enough in the future
    ... want something stronger

    <timeless> JS: my concern is that SHA1 being allowed by the
    specification would result in it being used by widgets and still in
    use at a time when it is exploited. As such, i'd rather it be
    prohibited by the specification.

    MP: will XML Sec WG include SHA-256 in their next version of XML Sig
    spec?

    <timeless> JS: with a statement from the requirements that the hash
    be something "stronger" than SHA1.

    <tlr> I suspect that it will be included either there, or in an
    update to RFC 4051

    <tlr> I recommend sending e-mail to the xml security WG asking "what
    algorithm do you recommend we use, and what identifier should we use
    for it"

    <tlr> ... thereby causing a decision on that WG

    AB: I think Thomas has a good recommendation we should follow
    ... I don't think we should make a decision until we've heard from
    XML Sec WG

    DR: some support for SHA-1 will be dropped soon (~2010)

    BS: in some countries, SHA-256 is too high of a barrier
    ... it may just be for encryption but not for integrity

    AB: I recommend we leave this Issue open until we've heard from XML
    Sec WG
    ... any objections?

    [ None ]

    <drogersuk> Here is some text on the SHA-1 statement from NIST, I'll
    find the source: "the agency last year advised federal users to
    migrate away from use of SHA-1 as quickly as possible and no later
    than by 2010, except for limited functions."

    <drogersuk> that statement was from 2007

    <timeless> JS: other standards bodies, e.g. in Europe tend to defer
    to NIST or equiv, as in the case of FIPS (? federal information
    processing security?) standards.

    <tlr> for the record, I think that moving away from SHA-1 is good
    hygiene for standards at this point.

    <drogersuk> Here is the NIST link:
    [33]http://csrc.nist.gov/groups/ST/hash/statement.html

      [33] http://csrc.nist.gov/groups/ST/hash/statement.html

    <drogersuk> NIST encourages a rapid adoption of the SHA-2 hash
    functions for digital signatures, and, in any event, Federal
    agencies must stop relying on digital signatures that are generated
    using SHA-1 by the end of 2010.

    <scribe> ACTION: Barstow ask the XML Sec WG "what algorithm do you
    recommend we use and what identifier should we use for it?"
    [recorded in
    [34]http://www.w3.org/2008/08/27-wam-minutes.html#action05]

Security Model

    AB: agenda is [35]http://www.w3.org/2006/appformats/group/TurinF2F
    ... what's the status Marcos of the Security Model?

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

    MC: basically, we are in no where land
    ... we understand the broad reqs
    ... but we don't have a WD yet

    ABe: we provided an input for the Security Model [in Dublin]
    ... but I think we first need to discuss the requirements

    MC: can we get a brief summary of Opera's security model, Arve?

    ABe: we looked at some UCs and reqs
    ... and created a security model we have implemented
    ... These reqs were unique from our standpoint.
    ... We have some reqs regarding network access
    ... we created some different classes.
    ... In the mobile world, the network model is different (than the
    desktop world).
    ... Our model is part opt-in and part opt-out
    ... our security model input is
    [36]http://lists.w3.org/Archives/Public/public-appformats/2008Apr/at
    t-0096/w3c-security.html
    ... We have a lot of detail so everyone should read it.
    ... We restrict access to some resources e.g. file, network, ...

      [36] http://lists.w3.org/Archives/Public/public-appformats/ 
2008Apr/att-0096/w3c-security.html

    JS: does it cover IPv6?

    ABe: no it doesn't; perhaps that is something we will need to
    address
    ... haven't handled how to provide access to arbitrary APIs
    ... i.e. proprietary APIs
    ... or something like interacting with a VOIP client
    ... We need to deal with these requirements.
    ... We also believe human authoring is an important requirement
    ... e.g. using a single namespace
    ... and limited vocabulary
    ... regarding extending the model, a question is how to give an API
    an identifier
    ... An important implied req is how to name/identify the APIs
    ... This is a pre-req to nailing down before we discuss a model or
    syntax

    MC: do we use [http] URIs, or urn's or something else

    PB: in BONDI we have taken a similar view
    ... expect to use URIs for API identification
    ... We also have a req for a widget (web app) to express a
    dependency on an API
    ... Need to indicate to the sec fwk the dependency
    ... Need to bind API
    ... When an API dependency is expressed, it could be on just an
    interface (e.g. GeoLocation API)
    ... in this case a URI could be opaque e.g. an urn
    ... Also could use a URL that is traceable to an impl of an API
    ... We don't state if URN or URI etc. are used

    AB: can we get a pointer to the BONDI docs?

    PB: yes; BONDI has a public site; it includes the two docs we sent
    to WebApps re the Reqs doc
    ... but we have other docs too on that site
    ... In those docs you will not be able to distinguish inputs from
    OMTP members that have agreed to the W3C Patent Policy and those
    OMTP Members that have not agreed to the W3C PP
    ... we can go through all of our docs and explicitly mark those
    parts that are contributed under a W3C PP agreement and those parts
    that are not

    ABe: I'm concerned about the liability here if I read such a doc
    ... For example, if I read something that is not covered, do I
    become "tainted"?
    ... From this perspective, I am reluctant to read any such doc.

    AB: I'd like to stop the discussions about the IPR issues now. They
    are important and need to be discussed but I'd prefer to use our f2f
    time to discuss technical issues.
    ... Furthermore, I think we need to bring Rigo Wenning into the
    discussions.

    PB: we can provide a link to the BONDI web site
    ... We are not advocating the WG read that document

    <tlr> +1 to stopping the IPR discussion right now and setting up a
    separate call with Rigo.

    <tlr> I don't think we should inadvertently get into a model of work
    that very closely resembles a disclosure-based policy. There's a
    reason why the current policy tries to isolate WGs from too much of
    an IPR consideration.

    <tlr> (We had a mild version of that already, when the yellow marker
    on the "SHALL" started to taint discussion about hash algorithms.)

    NA: agree we need to get the attorneys involved
    ... However, I do want to get a sense of the timing so we can our
    input to the WG in time to be considered.

    MC: I suggest we look at my input regarding the API identification
    issue and then people can bring in other inputs

    NA: regarding infor sharing, we have about 10 interfaces we are
    working on
    ... We'd like to discuss our underlying model too.

    <scribe> ACTION: Barstow continue discussions with W3C and OMTP
    attorney regarding how to share information [recorded in
    [37]http://www.w3.org/2008/08/27-wam-minutes.html#action06]

    <trackbot> Created ACTION-229 - Continue discussions with W3C and
    OMTP attorney regarding how to share information [on Arthur Barstow
    - due 2008-09-03].

    ABe: I'm not sure the list of ten APIs is really that important in
    understanding the security model

    NA: we have a Security Policy model and then the interfaces

    ABe: the Widgets specs should be agnostic specifics of APIs e.g.
    GeoLoc API

    NA: you are assuming our ten APIs should not be considered to be
    adopted by the WG

    PB: whereas JCP put a large diverse set of APIs in a single spec, we
    want to do more separation

    MC: we should focus on the binding mechanism but not the APIs
    themselves
    ... I don't think we should be doing a bunch of innovating here;
    instead, we should be standardizing stuff that has already been
    widely implemented
    ... after a couple of thousand developers have worked on an API,
    then we should standardize it

    ABe: a model to consider is something like Google Gears where there
    APIs have quite a bit of implemenation and testing and only after
    the functionality is backed/implemented does it go into a WG for
    standardization
    ... e.g. Worker Threads are now being worked on by HTML WG
    ... I don't think we need any more APIs then we have already spec'ed

    MC: yes; and the Landscape doc backs-up the set we're working on
    ... It is at least an initial set.
    ... we can look at my binding proposal or the latest ED of the API
    and Events spec

    <claudio> MC: strawman proposal for API binding:
    [38]http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/03
    09.html

      [38] http://lists.w3.org/Archives/Public/public-webapps/ 
2008AprJun/0309.html

    AB: so what are the next steps re Security Model?

    ABe: I think we need to extract the requirements
    ... We need both implicit and explicit requirements
    ... We could create a separate Widget Security Model Requirements
    document
    ... If that would help with the publishing issue.

    AB: I presume BONDI have already created such a Security Model Reqs
    doc
    ... So we need to work out the details to bring that input into the
    WG

    <scribe> ACTION: Barstow determine how to bring BONDI's Security
    Model Reqs document into the WG for consideration [recorded in
    [39]http://www.w3.org/2008/08/27-wam-minutes.html#action07]

    <trackbot> Created ACTION-230 - Determine how to bring BONDI's
    Security Model Reqs document into the WG for consideration [on
    Arthur Barstow - due 2008-09-03].

Marcos' Strawman for API Binding

    MC: my input is
    [40]http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/03
    09.html

      [40] http://lists.w3.org/Archives/Public/public-webapps/ 
2008AprJun/0309.html

    <arve> My strawman proposal

    <arve> <api src="[41]http://example.org/apis/geolocation/1.0/"
    required="required" />

      [41] http://example.org/apis/geolocation/1.0/

    MC: [ describes his model ... ]

    ABe: not sure we a req to load and unload these dynamically

    JS: but this would give us un-predictable behavior

    ABe: don't like the scheme (URL in the proposal)

    [ Discussion about the syntax i.e. element names and attribute names
    ... ]

    AB: what is the summary of Marco's proposed model?

    MC: I think specific reqs for API binding are needed
    ... Arve said to remove the API loader

    JS: it would complicate the trust model

    ABe: we need to be careful not to spec implementation details
    ... and the loading / unloading is such a detail

    MC: what does hasFeature return, true|false?

    <timeless> <access feature="[42]http://apples"
    feature="[43]http://oranges" network="true" />

      [42] http://apples/
      [43] http://oranges/

    ABe: perhaps we need an "optional" attribute on the feature element

    MC: not clear it is needed

    ABe: I think something like optional could be useful in association
    with the manifest

    AB: have we reached the point of diminishing return on this subject?

    <marcos> <widget>

    <marcos> <access network="true" file="true|false">

    <marcos> <feature id = "[44]http://google.com/api/goeloc"/>

      [44] http://google.com/api/goeloc

    <marcos> <feature id = "[45]http://w3.org/api/geoloc"

      [45] http://w3.org/api/geoloc

    <marcos> required="false"/>

    MC: I think we've about got it; I will post what we've got into IRC

    <marcos> </access>

    <marcos> </widget>

    <marcos> widget.("[46]http://google.com/api/goeloc") returns
    true|false;

      [46] http://google.com/api/goeloc

    <marcos> widget.hasFeature

    <marcos> widget.hasFeature("[47]http://google.com/api/goeloc")
    returns true|false;

      [47] http://google.com/api/goeloc

    <marcos> MC: each API has it's own IDL defined

    ABe: should we take feature fallback into consideration?
    ... e.g. if API #1 isn't available then use API #2

    BS: isn't that going a bit too far?

    MC: I think a Widget can address Arve's question by making a call to
    API#2 if hasFeature("API#1) fails

    <marcos> if(hasFeature("x")){..}else{ if(hasFeature("y")){} }

    <scribe> ACTION: Arve work with Marcos to submit a proposal to
    address the feature fallback problem [recorded in
    [48]http://www.w3.org/2008/08/27-wam-minutes.html#action08]

    <trackbot> Created ACTION-231 - Work with Marcos to submit a
    proposal to address the feature fallback problem [on Arve
    Bersvendsen - due 2008-09-03].

    MC: could just use nested feature elements to imply fallback

    JS: but there could optional features

API and Events Spec

    AB: latest ED is here [49]http://dev.w3.org/2006/waf/widgets-api/
    ... latest and greatest should be:
    [50]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

      [49] http://dev.w3.org/2006/waf/widgets-api/
      [50] http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

    <scribe> ACTION: Arve check the API spec for compliance with the Web
    IDL spec [recorded in
    [51]http://www.w3.org/2008/08/27-wam-minutes.html#action09]

    <trackbot> Created ACTION-232 - Check the API spec for compliance
    with the Web IDL spec [on Arve Bersvendsen - due 2008-09-03].

    MC: Web IDL is based on OMG's IDL but is more JavaScript "friendly"
    ... I think most of the APIs are already compliant with Web IDL

    MP: I have some comments from a colleague

    ABe: I just checked in a new version so everyone should reload
    ... I added a couple of new red blocks aka issues but also removed
    at least one

    MC: we have a requirement for a widget to have a diff icon depending
    on its context

    ABe: we also need to support icons of diff sizes

    JS: how does an app know which resolution it needs to set?

    ABe: the runtime will tell it

    JS: but how?

    ABe: the platform will provide info

    MC: can have more than one icon element

    JS: is order important

    MC: the processing model addresses the order issue

    ABe: want to change the name of this spec and alter the scope
    ... Name = Widgets 1.0 Core APIs and Events
    ... Scope = this spec should only define a minimal set of APIs that
    MUST be implemented
    ... e.g. it should not specify a GeoLoc API

    AB: any concerns about the name or scope?

    BS: rather than change the title, could just add clarifying text

    ABe: it's somewhat of a marketing ploy

    AB: I'm OK with it the renaming

    CV: what is the vision in the evolution of the Widgets spec suite?

    ABe: ideally, this spec will never be republished i.e. 1.0 will be
    the one and only version of this spec

    BS: so a follow-on would be a new spec like "Widget API Extension
    XXX"?

    ABe: yes, that's the idea

    CV: my fear is that we are doing some overselling e.g. we talk about
    Widgets being access some device capabilities and services
    ... If for v1.0 we stick with Core only, that's OK
    ... But does that constrain what we can do in the future?

    AB: I like the idea of a Core because it signals all APIs are
    mandatory and it should be a relatively small set of APIs that can
    be more easily implemented than an API spec that is more un-bounded

    MC: regarding the Widget interface, does anyone have any feedback?

    <arve> [52]http://dev.w3.org/2006/waf/widgets-apis/Overview.src.html

      [52] http://dev.w3.org/2006/waf/widgets-apis/Overview.src.html

    TL: perhaps some parts of the preferences should be in the manifest

    ABe: the reality is there is key value pair of prefs and strings
    ... one model is getPrefForKey and setPrefForKey
    ... basically, it's just string-based storage

    JS: I don't like the use of "preference" in the name
    ... In some cases it just isn't a preference

    ABe: what's your counter-proposal?
    ... "pref" may not be ideal but I think it covers 80% of the cases

    AB: what is your counter-proposal, Josh?

    JS: I can send something to the mail list

    MC: {get,store}Data ?

    AB: we changed this during the last f2f
    ... I recommend we stay with the existing names unless someone
    submits a compelling reason to change it

    MC: what about {get,set}String?

    JS: OK with me

    ABe: I don't like it

    MC: neither do I
    ... I think "prefs" in this context is a precedence we should follow
    ... I don't think it is ideal but it's already being used

    JS: why is the preferences attribute an Array?

    ABe: good question, we need to do some research

    <scribe> ACTION: Arve research the Widget object's preference
    attribute to make sure it uses the correct type [recorded in
    [53]http://www.w3.org/2008/08/27-wam-minutes.html#action10]

    <trackbot> Created ACTION-233 - Research the Widget object's
    preference attribute to make sure it uses the correct type [on Arve
    Bersvendsen - due 2008-09-03].

    JS: also not sure this Array needs to be readonly

    <arve> for (prefname in widget.preferences) { pref =
    widget.preferences[prefname] }

    <arve> pref typeof String === true

    CV: in the Landscape doc there is some text regarding preferences
    and widget states

    <timeless> JS: it might be possible to make the preferences object
    writable and delete the set/get pref methods. relying on
    widget.preferences['foo'] = 'bar'; and if (widget.preferences['foo']
    == 'baz') {... };

    <timeless> JS: as long as preferences promises to .toString the
    assigned value when writing.

    <timeless> JS: i believe my feedback about the name 'preferences'
    existed in the landscape comments. i can't remember what i said
    there.

    CV: if there is a minimum set of APIs is that too restrictive?

    MC: I think there is enough experience with some of the existing
    Widget platforms to know [empirically] which APIs are "core"
    ... There will always be new APIs that we need to consider
    ... And we can add/adopt them as needed

Next Steps for the API and Events spec

    AB: the latest Editor's Draft has several red blocks
    ... what's the plan for addressing the open issues in the spec?

    ABe: I expect to work on some of these issues soon
    ... I would like to be ready for a FPWD in mid-September

    AB: any volunteers to help Arve?

    [ None ]

    ABe: I expect to be able to borrow text from internal work we've
    done

    AB: thanks Arve

    <timeless> i'll definitely read and comment, although i'm likely to
    be sporadically unavailable.

Auto Updates

    AB: what's the short status on the Auto Updates spec, Marcos?

    MC: I haven't touched the ED in a while

    <arve> [54]http://www.w3.org/TR/auto-update/Overview.src.html

      [54] http://www.w3.org/TR/auto-update/Overview.src.html

    <arve> sorry,
    [55]http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html

      [55] http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html

    MC: I proposed three models on the mail list
    ...
    [56]http://lists.w3.org/Archives/Public/public-appformats/2008Jun/00
    28.html

      [56] http://lists.w3.org/Archives/Public/public-appformats/ 
2008Jun/0028.html

    ABe: some issues I've heard about:
    ... Do we do anything regarding remote kill switch re revocation?
    ... Do we have a means to say an update is Mandatory in that it
    cannot be avoided?
    ... That is, do we need to specify such a means?

    <timeless> app.update.url

    <timeless>
    [57]https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%
    /%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DIST
    RIBUTION_VERSION%/update.xml

      [57] https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/% 
BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION 
%/%DISTRIBUTION_VERSION%/update.xml

    <timeless> (from firefox ...)

    CV: is the model push-based?

    MC: no, it is pull-based

    [ Marcos describes the model ... ]

    ABe: the 304 response is a bit counter-intuitive

    MC: OK, I can remove that
    ... the response is an <update> element

    MP: how do you judge if a version is later or not?

    MC: you can't in this model

    ABe: leave upgrade decision to server

    JS: this update URL should be https

    MC: not sure you can make that mandatory

    <timeless>
    [58]https://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSecurity

      [58] https://wiki.mozilla.org/User:Mossop:Fx- 
Docs:AddonUpdateSecurity

    JS: tend to agree it is an impl detail but do change the example to
    https

    <timeless> This is a hash calculated from the xpi file and will
    currently be limited to the sha1, sha256, sha384 and sha512
    algorithms.

    TL: from the user's perspective, they don't care much about versions

    ABe: there are many, many ways to solve the update mechanism
    ... we could even use Debian :-)

    MC: the good news about this model is that it's simple; the bad news
    about this model is that it's simple ...

    [ Discussion regarding the semantics of the update element's src
    attribute ... ]

    AB: what do we need to do before it is ready for FP
    ... Working Draft

    MC: I think it is pretty close
    ... I believe it addresses most of the use cases we have discussed

    ABe: another issue that needs to be captured - how to address
    different widget reqs between versions?
    ... [See Arve's other two issues earlier in this topic ... ]

    <Benoit> the existing proposition does not allow to terminate a
    widget (wile cheking the verion, the widget is notified that it
    should not be open anymore)

    MC: regarding revocation, perhaps we need to do something in v2

    AB: Meeting Closed

Summary of Action Items

    [NEW] ACTION: Arve check the API spec for compliance with the Web
    IDL spec [recorded in
    [59]http://www.w3.org/2008/08/27-wam-minutes.html#action09]
    [NEW] ACTION: Arve research the Widget object's preference attribute
    to make sure it uses the correct type [recorded in
    [60]http://www.w3.org/2008/08/27-wam-minutes.html#action10]
    [NEW] ACTION: Arve work with Marcos to submit a proposal to address
    the feature fallback problem [recorded in
    [61]http://www.w3.org/2008/08/27-wam-minutes.html#action08]
    [NEW] ACTION: Barstow ask the XML Sec WG "what algorithm do you
    recommend we use and what identifier should we use for it?"
    [recorded in
    [62]http://www.w3.org/2008/08/27-wam-minutes.html#action05]
    [NEW] ACTION: Barstow close Issue #15 with the resolution above
    [recorded in
    [63]http://www.w3.org/2008/08/27-wam-minutes.html#action04]
    [NEW] ACTION: Barstow continue discussions with W3C and OMTP
    attorney regarding how to share information [recorded in
    [64]http://www.w3.org/2008/08/27-wam-minutes.html#action06]
    [NEW] ACTION: Barstow determine how to bring BONDI's Security Model
    Reqs document into the WG for consideration [recorded in
    [65]http://www.w3.org/2008/08/27-wam-minutes.html#action07]
    [NEW] ACTION: Barstow talk to the XML Security WG Chair about how to
    engage that WG in WebApps Signature spec work [recorded in
    [66]http://www.w3.org/2008/08/27-wam-minutes.html#action03]
    [NEW] ACTION: Marcos work with Mark and Thomas on sentence #2 in the
    new requirement paragraph of the OMTP input for R11 [recorded in
    [67]http://www.w3.org/2008/08/27-wam-minutes.html#action02]
    [NEW] ACTION: Mark work with Marcos to flesh out the details of the
    processing model for multiple signatures [recorded in
    [68]http://www.w3.org/2008/08/27-wam-minutes.html#action01]

    [End of minutes]
Received on Saturday, 30 August 2008 13:16:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT