Web Applications Working Group Teleconference -- 27 Aug 2008

<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> 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 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"
... 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
... 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 (http://www.cabforum.org) is a voluntary organization of leading Certificate Authorities and vendors of Internet browser software. 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.

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 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 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 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 http://www.w3.org/2000/09/dbwg/overlap)

Dig Sig Issues

AB: in the agenda we identified issues #15, #19 and #22
... 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 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 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: 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: 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: 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 http://www.w3.org/2008/08/27-wam-minutes.html#action05]

Security Model

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

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 http://lists.w3.org/Archives/Public/public-appformats/2008Apr/att-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, ...

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 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: 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 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 http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0309.html

<arve> My strawman proposal

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?

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> <feature id = "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> widget.("http://google.com/api/goeloc") returns true|false;

<marcos> widget.hasFeature

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

<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 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 http://dev.w3.org/2006/waf/widgets-api/
... latest and greatest should be: 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 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> 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 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> http://www.w3.org/TR/auto-update/Overview.src.html

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

MC: I proposed three models on the mail list
... 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> 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> 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

- DRAFT -

Web Applications Working Group Teleconference
27 Aug 2008

Attendees

Contents

Agenda Review

R11 Digital Signature

Handling the remaining comments from OMTP re Signature requirements

Dig Sig Issues

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

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

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

Security Model

Marcos' Strawman for API Binding

API and Events Spec

Next Steps for the API and Events spec

Auto Updates

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Applications Working Group Teleconference 27 Aug 2008

Attendees

Contents

Agenda Review

R11 Digital Signature

Handling the remaining comments from OMTP re Signature requirements

Dig Sig Issues

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

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

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

Security Model

Marcos' Strawman for API Binding

API and Events Spec

Next Steps for the API and Events spec

Auto Updates

Summary of Action Items

Scribe.perl diagnostic output

Web Applications Working Group Teleconference
27 Aug 2008