- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Sat, 30 Aug 2008 09:15:12 -0400
- 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 UTC