- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 21 Oct 2008 16:41:14 -0400
- To: public-webapps <public-webapps@w3.org>
The minutes from the October 21 Widgets f2f meeting are available at
the following and copied below:
<http://www.w3.org/2008/10/21-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before October 23 (next Widgets
voice conference); otherwise these minutes will be considered approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets f2f Meeting
21 Oct 2008
[2]Agenda
[2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
See also: [3]IRC log
[3] http://www.w3.org/2008/10/21-wam-irc
Attendees
Present
Paddy, Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike,
Lucy_Lynch, Nick, Bashar_Jano, Philipe_LeHegaret,
Frederick_Hirsch, Thomas, RobMiller, PratikDatta, Gerald,
Edgar, KelvinYiu, BrianLaMacchia, ChrisSolc, BruceRich,
Kai_Hendry, Carmelo, Dom, Denise
Regrets
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Agenda Review
2. [6]Widgets 1.0 Digital Signature spec
3. [7]transform element
4. [8]Certificate Chains
5. [9]Widgets Requirements LC #2
6. [10]Widgets 1.0 Updates spec
7. [11]Digital Signature Joint meeting with XML Sec WG
8. [12]Widget Permissions, Access, etc.
9. [13]Widget Testing
10. [14]API and event
11. [15]V2 list
12. [16]Benoit slides
13. [17]F2F meeting
* [18]Summary of Action Items
_________________________________________________________
<ArtB> Date: 21 October 2008
<ArtB> Scribe: Art
<ArtB> ScribeNick: ArtB
Agenda Review
[ Art reviews agenda; two new additions for AOB section ]
AB: any change requests or additions?
[ None ]
Widgets 1.0 Digital Signature spec
AB: latest ED is [19]http://dev.w3.org/2006/waf/widgets-digsig/
[19] http://dev.w3.org/2006/waf/widgets-digsig/
<marcos>
[20]http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html
[20] http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html
MC: Mark and I have been focusing on simplifying the spec
... One goal was to make the spec more efficent regarding processing
... Also want generic XML Sig tools to be useable as is
... Also tried to reflect what is being done in the industry
<scribe> ... New model is 1) ZIP; 2) Sign; 3) ZIP again
ABe: I object to this change
MC: why?
ABe: because there are already tools that follow our previous model
MC: no; just need to sign the ZIP file rather than 100's of files
ABe: this adds runtime complexity
... In Opera we can read directly into the ZIP
... thus it adds complexity for us
... What is the cost of the old model?
PB: what is the cost you are trying to avoid?
MP: we have a signing server
... it signs Widgets
... The old model requires signing each file individually
... All we really want is one signature for the entire package.
... This is particuarly important when we have to sign a bunch of
Widgets
PB: then you loose the flexibility of signing specific files
MP: the more signing that has to be done, the greater the
probability something can fail
... e.g. twenty signatures (1 per file) versus just 1 signature for
the package
PB: the JAR spec allows individual signing
... and then a hash over the entire JAR
AB: we already agreed everything needs to be signed
MP: want to understand the complexity concern Arve has
ABe: this puts an extra toll on the client
... must keep the package in memory twice
MC: no, that doesn't seem right
PB: no, Arve's right
ABe: on low memory devices, that isn't acceptable
PB: have to extract the inner ZIP onto disc
... and this previously wasn't necessary
ABe: verification of the ZIP isn't the hard part
... need to deflate the inner ZIP and keep it in memory
... must keep the outer file in memory too
MP: why does the outer file need to be in memory
PB: the outer ZIP must be in memory to run the widget
ABe: I agree this shortens the spec
MC: the proposal makes it easier on the signing server
... this doesn't change tools
AB: so we have a new proposal with a sustained objection
MP: given Arve's concerns, I can live with the original model
... the change doesn't change the existing proc model
MC: I'm not convinced about Arve's concerns and would need to do
some research.
... OTOH, I can live with the existing model
... OK, we will stay with the model where every file is signed
RESOLUTION: we will maintain the model where every file is signed
MC: another thing I removed is the WidgetSignatureInfo element
... because it requires a custom tool
... that element only contains a TimeStamp element
... I couldn't think of a good use case
... This was introduced by Thomas
AB: any objections to the removal of the WidgetSignatureInfor
element?
<scribe> ACTION: thomas do you object to the removal of the
WidgetSignatureInfo element? [recorded in
[21]http://www.w3.org/2008/10/21-wam-minutes.html#action01]
<trackbot> Created ACTION-273 - Do you object to the removal of the
WidgetSignatureInfo element? [on Thomas Roessler - due 2008-10-28].
MP: I agree with this change
[ No objections ]
transform element
MC: some files need to be transformed via deflate
... we can write this in prose
... We removed it in Dublin meeting
... I think we need it
AB: let's put this on the agenda for the XMLSec joint meeting
MC: good idea
Certificate Chains
MC: does XML Sig support cert chains
[ Marcos displays xmldsig-core ]
MC: yes, it looks like it
AB: should we add this to the XMLSec agenda?
MC: yes. Want to understand ordering for example
... return values could be: Fail, Verified (Y or N), Revoked (Y or
No or Unavail)
... If revoedk stop and only one sig then stop
<mpriestl> We need to also understand what a XML digital signature
processing engine will return when processing a signature, e.g.
document is malformed, certificate chain can't be verified,
certificate has been revoked (yes, no, revocation information
unavailable) etc.
MC: Also need table of return values based on conditions
... Mark and I will meet next week
... Hope to have a new WD ready for pub by end of next week
Widgets Requirements LC #2
AB: Widgets reqs LC #2 [22]http://www.w3.org/TR/widgets-reqs/
[22] http://www.w3.org/TR/widgets-reqs/
MC: the doc is written using RFC2119
... LC #2 comment period ended Oct 13
... We want to know the next step -> WG Note or Recommendation
PLH: a Rec doesn't make sense to me
AB: why
MC: what would you actually require?
... the reqs are meant to be inclusive
PLH: what will be the exit criteria of CR?
MC: I was thinking OWL has a precedence for this
PLH: infoset had some exit criteria
MC: we can explicitly list those reqs which are address by various
specs
PLH: what are the status of the specs?
MC: they are all in WDs
PLH: I can be convinced that a Recommendation is OK
MC: personally, I want to move this to Recommendation
... We have talked to a lot of industry groups e.g. OMTP
MP: we would like to be able to reference this doc from OMTP
PLH: does it need to a Rec?
PB: it needs to be a stable doc
CV: it would be good to be Rec
AB: I think the options are:
... 1. leave as is
... 2. publish another LC
... 3. publish a CR
... In the CR, state the exit criteria is that each requirement in
scope for WebApps must be addressed by one of our specs
... My concern about CR now is that none of our specs are yet in LC
and the probability of needing to change a req is relatively high
MC: I propose we leave the Reqs doc as is
RESOLUTION: we will leave the Widgets Requirements as is and not
publish another document until the specs (P&C, DigSig, etc) have
reached Last Call
Widgets 1.0 Updates spec
AB: latest ED is: [23]http://dev.w3.org/2006/waf/widgets-updates/
[23] http://dev.w3.org/2006/waf/widgets-updates/
MC: we haven't received much feedback yet
... other than some typos
CV: what happens if device has numerous widgets that need to be
updated
MC: could wrap <widgetupate> in some outer element
... we haven't spec'ed that yet
CV: shoud the spec say something about this?
MC: it would certainly complicate the current model
PB: what is the trust model if the widgetupdate came via some
mechanism other than https?
MP: need to understand the integrity of the source
CV: thinking about 50 widgets trying to do an update at the same
time
MC: can imagine some wrapper process that does the updates over a
single connection
MS: I wonder about that use case i.e. 50 widgets on a device
... typically expect updates 1 at a time
ABe: I would expect more like 15-20
MS: I can see there could be many but would the user really want to
update them all at the same time
PB: a question is one of scalability
MC: I think the current model is sufficient for v1
AB: Claudio, can you live with the existing model for v1 and add
your use case and reqs to the v2 reqs doc
CV: yes, that's OK
PB: I think the current model is OK for v1
<scribe> ACTION: Claudio Add handling 50 widget update use case and
requirements to the v2 feature and requirements list [recorded in
[24]http://www.w3.org/2008/10/21-wam-minutes.html#action02]
<trackbot> Created ACTION-274 - Add handling 50 widget update use
case and requirements to the v2 feature and requirements list [on
Claudio Venezia - due 2008-10-28].
rssagent, make log public
Digital Signature Joint meeting with XML Sec WG
AB:
[25]http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesd
ay.2C_October_21
[25] http://www.w3.org/2008/webapps/wiki/
WidgetsMandelieuAgenda#Tuesday.2C_October_21
<drogersuk> AB: We would like to discuss the questions that we sent
over
<drogersuk> We also have some additional questions and Marcos would
like to show you the draft document
<scribe> ScribeNick: Drogersuk
MP outlined the questions
<ArtB> Scribe+ David
MP: Within Vodafone and the OMTP BONDI initiative, we have looked at
the digital signatures
... The NIST recommendation is that SHA-1 should be phased out
... This is being recommended in BONDI at the moment
... Do you foresee that SHA-256 will be supported?
XML Dig-Sig: Yes, that is correct
BrianLaMacchia: Many companies have already banned SHA-1 usage
... moving to SHA-256 is the right thing to do. You should be
prepared to roll that to a new hash function if SHA-256 breaks
... you need to stop people generating new signatures and reference
hashes with SHA-1
MP: This is completely in-line with our plans. We recognise the need
to support SHA-1 for past / still-valid certificates
... We would like to strongly recommend the usage of SHA-256
... How in XML DigSig do you deal with supporting new hash
algorithms?
... We would like to mandate support for DSA
BLM: You don't want to do DSA
... 1024 bits is too short
... for DSA....RSA at 1024 is too short
... use EC and RSA
... obvious choice is EC-DSA
MP: for key length, we are mandating that the consuming platform
must support 2048
BLM: That is good
MP: You may use 1024 in the short term - we're not disallowing this
BLM: What is the lifetime of that?
PB: It depends on the policy of the author of the widget
BLM: It depends on your security level and how long you want to
protect the information for
... RSA 1024 is what you're going to have the least interoperability
issues with
... is it performance that is driving the requirement?
MP: Yes, it is the verify time that some companies have this opinion
on
... Some countries want weaker cryptography for signatures
TLR: This sounds like an alarming requirement
MP: I'm only expressing the feedback that we've received
... There are some requests to be able to choose 1024
TLR: What I'm hearing is that you are arguing for 1024
MP: We strongly recommend 2048, but there is still a requirement for
1024 from some other companies
PD: The argument is probably using it in the interim period
MP: We're broadly aligned with you - but should we support 1024?
BLM: It is the lifetime question
... it should expire within a year
... because of the associated risk
... you should highlight this in your documents
MP: Yes that is ok we can do that
... OK, so we will come up with a proposal for lifetime on 1024
BLM: Certificates. We don't see references to timestamping or expiry
and the certificate chain falling apart
... what behaviour do you expect?
... widgets would need to be re-signed
... If I publish a widget and a year later it expires..
MP: We only do the check at installation time
... at the moment, we only 'revoke' at installation time, we don't
remove them from existing devices
... that isn't a full revocation model in the classic sense
... it depends on your signing model, but in W3C and BONDI we're
silent on how you try and establish trust..
... but from Vodafone's point of view we will revoke the certificate
- this is one implementation model
FJH: We're talking about traditional lifecycle / PKI things - it
sounds like you need a model for this
... we could talk a long time about how to figure this out..
<ArtB> ACTION: Mark what is our lifecycle, revocation model?
[recorded in
[26]http://www.w3.org/2008/10/21-wam-minutes.html#action03]
<trackbot> Created ACTION-275 - What is our lifecycle, revocation
model? [on Mark Priestley - due 2008-10-28].
BLM: We went through this 10 years ago with authenticode
MP: A related question - is there any thoughts of adding timestamps
to the digital signatures specification?
BLM: There were IPR issues and issues in IETF
<fjh> XAdES ,
[27]http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=21
353
[27] http://webapp.etsi.org/workprogram/Report_WorkItem.asp?
WKI_ID=21353
MP: OK, so we'll follow-up offline on this. There are differing
opinions, which is why we're being silent on the exact model
BLM: There could be issues with recovering a bad widget if it gets
out there and you need to think about that
<tlr> We expect to do the algorithm changes, minor clean-ups,
low-hanging simplifications in XML Signature 1.1. No change of
namespace. No clear time plan quite yet.
MP: Multiple signatures. We want to add multiple parallel signatures
signed by different end-entities in a widget package. I wondered
whether there was any prior art for this that we should look at?
<tlr> Algorithm identifiers for SHA 256 and RSA-SHA256 are in
Encryption and RFC 4051, respectively.
MP: We want to have separate files with signatures in
BLM: You would end up with more characters because you can't share
references with the different blocks
... I can understand why you would want to do that with different
parties signing
MC explained the requirements document
MC: We need to talk to you about the certificate chains part
... we probably need some guidance on the inclusion of revocation
MC showed an example
Point 8 in the document was discussed
BLM: Let us discuss this offline
MC: We would not like to have to decompress the whole package to
verify the signature
... do we need to contain a transform element in there to indicate
that you need to deflate this in order to verify?
BLM: Signatures are in the zip?
... The URIs in the references point to what?
MC: They point to file entries
BLM: This could be ok. For efficiency purposes, that is
implementation. The URI you reference will be to the raw
uncompressed data
... you wouldn't have a transform because as far as it is concerned
it is uncompressed data
<klanz2> Do URIs allow to reference inse a zip file ... ? Java has
soemthing in the format jar:<url>!/[<entry>]
MC: OK, so we won't use the transform
There was a brief discussion on URI schemes
<klanz2> [28]http://tools.ietf.org/html/rfc3986#section-5.1.2 ...
[28] http://tools.ietf.org/html/rfc3986#section-5.1.2
TLR: You need to identify in the signature properties element the
profile and the timestamp.
MC showed an example
MP: On top of specifying XML DigSig, why do need to specify the
profile here
TLR: You have a processing model in mind...
... it may or may not go beyond the model from XML DigSig
... It is a way to prevent signatures not designed for this purpose
being used
<klanz2> wondering if it is good to invent new processing models
over and over again when there is a "web architecture"
BLM: You could put a separate EKU in the cert. Using a code-signing
purpose cert, there are platforms out there that use code signing
certs already and would do something useful with it
... you could have problems with your CAs
MC: We are quite reluctant to put this in because COTS tools would
have problems
BLM: You can use the object element in XML DigSig
MC: Do we need that in our own namespace?
<klanz2> Look into XAdES for SignatureTimestamp
MC: Do we need the timestamp as mandatory
BLM: It depends on what you want the behaviour to be
<klanz2> [29]http://en.wikipedia.org/wiki/XAdES
[29] http://en.wikipedia.org/wiki/XAdES
TLR: signature properties element can be used to put this into
<fjh>
[30]http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-Signatu
reProperties
[30] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-
SignatureProperties
MP: We will discuss the model offline if we need to define
processing for a timestamp
MC: Can we derive it some other way?
MP: No, this is the way you would do it
MC: Certificate chains. For signatures we just include multiple X509
data blocks?
BLM: Yes, you want one X509 data and multiple X509 certificates
<fjh> wss timestamp uility namespace, see appendix C in
[31]http://www.oasis-open.org/committees/download.php/16790/wss-v1.1
-spec-os-SOAPMessageSecurity.pdf
[31] http://www.oasis-open.org/committees/download.php/16790/
wss-v1.1-spec-os-SOAPMessageSecurity.pdf
MP: What are your plans for the new version of digital signature -
at the moment you provide the ability to include CRLs, are you
planning to include OCSP?
BLM: Yes we are.
<fjh> also XAdES
BLM: You may even prefer this in your model
MP: Yes mobile operators are more likely to prefer this
... it is still to be defined exactly how we will
... We are seeing the need to scale up our OCSP servers and CRL
servers
... this will grow. We would like to do some more intelligent
packaging of that information.
MC: OK, so the final part for multiple signatures, we're planning to
enumerate the signature xmls
... First come, first served etc.
MP: We'd like to see them processed in order
... We're not having counter-signatures
MP explained that in an ideal mobile world, different operators
would sign widgets. If a developer decided to, for example sign for
all operators in the UK
MP: When the widget arrives at the consuming device - you could go
through and look for a certificate that matches the root authority
on your device
... You could do it by filename, but that could be manipulated
... we want to be as silent as we can on the actual model, we don't
want to mandate the model that is used
PD: You want to optimise your common deployment scenario
... It makes sense to offer a best practice note on efficiency
MP: We could strip out the other signatures, or make sure that the
Vodafone signature was processed first
BS: If I forwarded it on to my friend by Bluetooth who wasn't on
Vodafone, it wouldn't work if the signatures had been stripped
PB: There is no way of checking ahead of time which of those
certificates gives you the greater number of rights under the
security policy
... but in general if we can find a way of avoiding processing
multiple digital signatures that would be a good thing
MP: It comes down to not knowing the policy of the consuming device
Policy and trust domains were discussed
There were concerns raised about performance impact of processing
lots of signatures
MC: The last issue is procedure for verifying and providing feedback
to the widget engine
MP: If you process multiple signatures and one has been revoked and
another hasn't, in a lot of cases you have to leave it to the policy
on the device
... however you can do some things here, if you get something back
BLM: You can get information saying it failed
... More interesting is if you get a reason code saying that it was
revoked
... You could revoke for many reasons
... the problem is - is there any cross-link when you have multiple
digital signatures?
MP: We have been through this and we have a matrix of values
... So i the 'No' part there are reason codes too?
BLM: Yes there can be
... You may get more or less information back depending on the
implementation
MP: Perhaps we should insert the table and get your feedback on it
BLM: I'm not sure you can do much with this
... You haven't even assumed that you have a chain validation policy
... because you are leaving this to the implementation
PB: It is possible for a widget to be completely unsigned
... in the failure cases, there are cases where you may want to
treat the widget as unsigned
... so you have fallbacks or rejections
... For example, in Java, if a midlet package is signed, but no root
is available, you have to reject
... it is a problem in practice, because it means that authors feel
that it is better to be unsigned
BLM: A disincentive for signing...
PB: Exactly, this is what we want to avoid with this
BLM: What are you doing with the signed v unsigned information?
MP: A signed widget will be allocated to a different trust domain
... They will be used to get access to different APIs, there is a
big security issue with giving unsigned widgets unfettered access to
these sensitive APIs
TLR: Unsigned widgets get access to a limited set of functionality
AB: Ok, let us wrap up then. Thankyou very much Frederick.
Widget Permissions, Access, etc.
<ArtB> MP: with BONDI we've been thinking about the features element
<ArtB> ... and whether it fullfills all of our reqs
<ArtB> ... Not clear it is flexibile enough
<ArtB> ... Some issues could be overcome with a separate permissions
element
<ArtB> AB: where are the requirements that aren't being met?
<mpriestl> Issue 1 - Principle of least privilege Example messaging
API widget.vodafone.messaging.{sms,mms,email}.send()
widget.vodafone.messaging.{sms,mms,email}.{inbox,outbox,drafts}.{del
ete(),readContents(),moveTo()}
widget.vodafone.messaging.{sms,mms,email}.{watchIncoming(),watchOutg
oing()} Requirement 1 It should be possible for the author to limit
the widget to use the exact functionality that it requires. At the
same time this should be done in a way that if
<ArtB> MP: how to state some features but not all of the features
<ArtB> ... A question here about granularity
<ArtB> ... e.g. a Widget needs to only API or perhaps several APIs
<marcos> [32]http://example.org/feature/feature/freature OR
http:/example.org/api?allow=this,this,this&deny=that,that,that
[32] http://example.org/feature/feature/freature
<ArtB> MP: also need to consider composite widgets
<ArtB> ... eg. a Widget that needs to access Camera and other device
services
<marcos>
[33]http://camera.api.org/gps/changename/contacts/add/delete/album/
[33] http://camera.api.org/gps/changename/contacts/add/delete/
album/
<ArtB> ... A Camera widget may need for example to create a folder
<marcos> <feature id="http//camera.example.org"/>
<ArtB> ... It may need to access Location info
<ArtB> ... It may need to access file system
<marcos> <feature id="http//camera.example.org"> <permission
name="gps" value="allow"/> </feature>
<ArtB> ABe: not sure I agree with this use case
<ArtB> ... shouldn't combine a bunch of different functions into a
single API
<ArtB> MP: but why not?
<ArtB> ABe: I think it is a bad design
<ArtB> MP: what about a camera API that allows geo-locating the
image
<ArtB> MC: this seems to be about how to specify APIs beyond what is
being spec'ed by BONDI
<ArtB> NA: I think an objective behind Mark's proposal is to provide
a robust sec model that works for poorly designed APIs
<ArtB> PB: we realize BONDI is not the only place where these types
of APIs will be defined
<ArtB> ... It is certainly possible to have a 1:1 relationship
between a single API and an explicity permission
<ArtB> [ Marcos enters an example in a temporary text buffer ... ]
<marcos> current option
<marcos> <feature id="http//camera.example.org?gps=allow"/>
<marcos> <feature id="http//camera.example.org">
<marcos> <permission name="gps" value="allow"/>
<marcos> <permission name="sound" value="disallow"/>
<marcos> </feature>
<marcos> and kinda proposed option
<ArtB> ABe: the main problem I have with this proposal is that for
each feature, must write a domain-specific language for that feature
<arve> <feature id="[URL FOR GEOLOCATION]"><param name="precision"
"0.1m" /></feature
<arve> >
<ArtB> BS: what is your interpretation for the permission element?
<ArtB> MP: used by author and the widget engine
<ArtB> ... could also be used to infer info to display to the user
<ArtB> ... One question is whether this mapping is done explicitly
via the config file or an internal detail
<ArtB> ABe: we assume the device will apply policies depending on
the origin of the widget
<ArtB> ... and hence gives a trust model
<ArtB> ... With the exception of network (which is well defined), I
don't think we should add domain-specific paramaters
<ArtB> ... If we go this route, the language needs to be rich enough
to describe every conceivable API
<ArtB> ... This is going to lead to fragmentation issues. For
example with the location API above, what happens if there are 0.2m,
0.3m, granularity, etc.
<ArtB> BS: I'm wondering what we need to do for v1.0
<ArtB> MP: we think the current model isn't granular enough
<ArtB> CV: I think the above syntax is agnostic regarding semantics
<ArtB> ... The author and policy can decide the level of detail
<ArtB> ... I think just allow and not-allow isn't good enough; need
some additional richness
<ArtB> ABe: but this requires a generic syntax for codifying
arbitrary constraints
<ArtB> CV: we need a generic way to define additional constraints
for the API
<ArtB> AB: I agree with some of the concerns Arve is raising
<ArtB> ... not clear for example how rich the language of the value
would need to be e.g. regular expressions, booleans, etc.
<arve> FWIW, I think we are basically discussing python's 'import'
statement here
<arve> from antigravity import *
<ArtB> MC: could also use a level of indirection here e.g. put the
permissions in a separate document
<ArtB> PB: a requirement is the need to parameterize the features
<ArtB> ... Arve's correct, each API will have different parameters
<ArtB> MC: this really about providing a standardized way to encode
proprietary parameters
<ArtB> ... I also think this goes against the spirit of the OAA's
API style guide
<ArtB> CV: could define an ontology for the various features and
their parameters
<ArtB> MC: to me this implies writing a "proprietary widget"
<ArtB> MC: I don't think the proposal is supported by W3C's
Geolocation API
<ArtB> AB: It's clear we don't have consensus on this issue.
<ArtB> AB: Mark, I propose you create a short set of requirements
and a proposal to address those requirements and send it to the
public-webapps mail list
<ArtB> ... Is that OK?
<ArtB> MP: yes
<ArtB> ACTION: Mark submit a short set of requirements re extended
permissions and parameters and a proposal to address those
requirements (to public-webapps) [recorded in
[34]http://www.w3.org/2008/10/21-wam-minutes.html#action04]
<trackbot> Created ACTION-276 - Submit a short set of requirements
re extended permissions and parameters and a proposal to address
those requirements (to public-webapps) [on Mark Priestley - due
2008-10-28].
<tlr> I suggest bringing this up at the security workshop in
December.
<tlr> [35]http://www.w3.org/2008/security-ws/
[35] http://www.w3.org/2008/security-ws/
Widget Testing
<ArtB> AB: agenda
[36]http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesd
ay.2C_October_21
[36] http://www.w3.org/2008/webapps/wiki/
WidgetsMandelieuAgenda#Tuesday.2C_October_21
<ArtB> Scribe+ Paddy
<dom> ScribeNick: paddy
MC: Dom had a chance to do a first overview of the spec and test
issues
... initial thought is ok
... some first thoughts send out
<dom> [37]Dom's initial comments on Widgets packaging and
configuration
[37] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0664.html
MC showing Packaging and OCnfiguration spec
MC: we're looking for advice on how to do this
... eg what is a test harness?
... for example can we identify each testable assertion in the spec
and build test cases?
... given the cases in an XML file can we make each test
individually addressable and automatable?
... Another spec we looked at wrt testing was from Hixie
... outlined how it was done for CSS
... defined different levels of testing: atomic, assertion-level,
evil, edge cases etc
... that's all we know about testing
... if you have experience/advice that would be great
... our spec isn't that big and we've split the doc into two:
... first half mainly definitions
... second half is the testable part
... html5 followed a systematic approach
... so we tried to structure the doc to facilitate this
... eg steps for processing widget resource might be individually
testable
Dom: I think a good way to start is to identify each conformance
statemennt
... try to construct a simple test case for some of them
... this will not be a very interesting set
... except it will be a starting point
... will give some pointers as to where interoperability fails
... a good strategy is to find the points where interoperability is
hardest
MC: unfortunately there are no implementations today
... so there is massive fragmentation
Dom: I guess them I would start during last call with a simple set
of test cases
... leave most difficult tests to CR when it is more stable and
there are more implementations
... leave evil tests to later
MC: If we will be doing it that way, we might just start creating
test cases by hand
... rather than automate the process
Dom: one thing that helps is formluating the conformance
requirements
... eg what things would be the subject of conformance?
MC: There are 3 things:
... wodget package
... widget configuration document
... widget runtime
... conformance checker
(4 things)
Dom: would initial focus be on the engine?
... so focus on these conformance statement?
MC: eg testing validity of zip archive
... we could construct an invalid archive
... and test that an engine rejected it
Carmelo: 2 observations:
... mentioned about creating tests by hand:
... usually very time consuming
... xml driven approach is a good idea
MC: I don't think we have expertise in XSLT in this group
Dom: we could help with that
Carmelo: ... would it be possible to markup tests directly in the
spec?
MC: we already have some markup (eg css class)
Dom: you could do some XSLT to extract them
JK: At Nokia been creating an internal document toolchain
... where testable requirements can be identified by markup
... could maybe make this available
MC: we can easily add the markup
Carmelo: have a paper on this I will send
<ArtB> ACTION: Barstow ask Carmelo for the URI of his testing paper
[recorded in
[38]http://www.w3.org/2008/10/21-wam-minutes.html#action05]
<trackbot> Created ACTION-277 - Ask Carmelo for the URI of his
testing paper [on Arthur Barstow - due 2008-10-28].
Dom: once you have the testable assertions you still have to create
the content corresponding to the test case
... I expect this needs to be done by hand
MC: Yes
Dom: one way to proceed would be to automate the creation of basic
test case template only
... but start manually creating the content of each test case
... explicitly referenced to each testable assertion
MC: I imagine I will be the one writing the test cases
KH: I can help
Carmelo: we have a tool which can take test definitions in XML
format and generate test cases
<ArtB> ACTION: Barstow figure out a way (procedurally) for Kai
Hendry to contribute to the Widgets testing (with Mike Smith)
[recorded in
[39]http://www.w3.org/2008/10/21-wam-minutes.html#action06]
<trackbot> Created ACTION-278 - Figure out a way (procedurally) for
Kai Hendry to contribute to the Widgets testing (with Mike Smith)
[on Arthur Barstow - due 2008-10-28].
Dom: based on formal RelaxNG description of configuration document
perhaps this can be used to drive automate creation of some test
cases
... also this can be used to validate the examples in the spec
... this also validates the schema
MC: once we are in last call this will be included in validator.nu
... if that existed it will be very easy to create non-conforming
content
Dom: also might want to export examples from spec to test cases and
vice versa
MC: now it's just a matter of gathering the tools
Dom: initially start highlighting test cases more explicitly as
blocks
... then I can start work on extracting them
MC: that would be great
Carmelo: sounds like we would be working together for a while
AB: to Dom, can you give us an update on the work you're doing?
Dom: there are a few people working on it
KH: can be get Wilhelm working on it?
<ArtB> ACTION: Arve talk to Wilhelm about contributing to the
Widgets testing effort [recorded in
[40]http://www.w3.org/2008/10/21-wam-minutes.html#action07]
<trackbot> Created ACTION-279 - Talk to Wilhelm about contributing
to the Widgets testing effort [on Arve Bersvendsen - due
2008-10-28].
NA: Will take action to determine whether or not there could be any
shared activity with BONDI
<ArtB> ACTION: Nick check with BONDI team to see if they can
contribute to the Widgets testing effort [recorded in
[41]http://www.w3.org/2008/10/21-wam-minutes.html#action08]
<trackbot> Created ACTION-280 - Check with BONDI team to see if they
can contribute to the Widgets testing effort [on Nick Allott - due
2008-10-28].
Dom: are you working closely with implementors?
... how far advanced are you with implementation?
MC: no public announcements of implementations at this time
AB: if there are active implementations, please say so
Benoit: the way people are talking about it, it sounds like they are
implementing it
ABe: Access are claiming conformance
Dom: I heard Qualcomm claim they are implementing it
<ArtB> ACTION: Barstow propose a new time for the weekly Widgets
Voice Conf - 1-3 hours later than now [recorded in
[42]http://www.w3.org/2008/10/21-wam-minutes.html#action09]
<trackbot> Created ACTION-281 - Propose a new time for the weekly
Widgets Voice Conf - 1-3 hours later than now [on Arthur Barstow -
due 2008-10-28].
MC: one problem is that I will be away in November
... I will be away for 20 days so work will cease
... I will try to do as much as I can in the next week
... most docs fairly close to last call
... would like basic test suite
Dom: not a good idea to put test suite into critical path
... you'll want to get first last call done asap
... and there will be other last calls where corrections can be made
arising from test creationb
... someone else can create test cases
MC: I can try doing the markup
... and perhaps Kai can start working on some test cases
... specifically looking at the document from a testability point of
view
... that would be great
... once the document is in good enoug shape we can start automating
the creation of test case skeletons
KH: we'll talk about it
MC: so while I'm away can you do that? you have a month
Carmelo: I'll send some testable assertion documents
AB: I think we have covered the main questions
... anyone else got anything they want to add?
... or volunteer to do?
... thanks to all and appreciate it
... if people aren't too tired lets look at the API draft
API and event
ABe: just checked in latest version:
<arve> [43]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html
[43] http://dev.w3.org/2006/waf/widgets-api/Overview.src.html
ABe: (version is not built)
AB: we now have an absract
ABe: Marcos, onBlur/onFocus are out so this issue should be deleted
... based on implementation experience we're not sure that this part
of the spec (onModeChange) is mature enough
... to be confident we're specifying something sensible
... on the desktop there are 3 modes
...1: chromeless
... 2: chromeless and full screen
... (content has no control over its size)
Benoit: doesn't the content still need to know the size?
Abe: that's not the issue
... our concern is being able to know what modes make sense
... have to understand issues relating to how css size/position
directives are processed and understood in each mode
... before we can realistically say what the modes are
MP: are there are any requirements specified already for supported
modes?
MC: no specific modes specified yet
... only the mode attribute
ABe: there are also conflicting market requirements for the modes
required, and what each means
Claudio: are we talking about docked/undocked mode?
ABe: even here there are multiple options
... you could think of docked mode as iconified
... where there is a facility to update/animate the icon
... the second one is similar except that the contents of the icon
are based on an html document
... the third way is that the docked view is a window opened
explicitly by the widget
... as in Vista
Claudio: I was looking at it from the user perspective
... it makes sense to understand when a widget is undocked and
visible to the user
... and when it is docked it is visible just like a widget
... ie iconified
... in iconified state the widget is still instantiated
ABe: is the docked state exclusive to other display states?
... what should we define as being docked mode?
Benoit: we should define all of these modes explicitly because they
are part of the existing environment
... eg active icon in Yahoo!
... sidebar is in Vista
... floating is supported in all of the desktop models
... fullscreen would also be relevant in mobile.
MC: I propose 3 for version 1:
ABe: or 4 if you count hidden
MC: modes in the doc presently:
... docked
... full-screen
... invisible
ABe: docked isn't really a mode in the same way as the others
... when docked it is non-interactive
... and it has to be opened to become interactive again
Benoit: what about supporting the dashboard widget icon bar?
... these are icons, non-interactive
... but can have animation
ABe: or could be an image
... or an animated html document
Benoit: it would be good to define at least some terminology in this
meeting
MP: I think it is useful to do this
... but want to find out if Vodafone as requirements in this area
Claudio: could we at least define the modes/states based on use
cases?
Benoit: would be interested in capability to temporarily expand an
instantiated widget from the docked state
... interact with it
... and then re-dock it, keeping the widget running
MC: I think we will run into problems with this
Benoit: use case on mobile would be an SMS widget
MC: can we do it with multiple content elements, each associated
with a different mode?
... corresponding document only exists for the time the widget is in
a given mode
... only persistent state carries forward from one mode to the next
... would the html5 persistence model be good enough for this?
ABe: storage is defined in terms of a local storage attribute
... only additional thing needed for this specification is already
in the document
... not a change, but the requirement that different widget
instances are defined as having separate origins
PB: would multiple instances have the same origin?
ABe: no
... otherwise you could not have different instances with different
settings
... eg multiple clock instances, one for each timezone
AB: I have a hard stop in 15 minutes
... how do we wrap this up?
ABe: I propose going forward by moving this document from editors
draft and publish it with this as a known issue
MC: I think we at least need to specify two modes
... eg floating and fullscreen
... to provide a starting point to publish the spec
AB: I think that would be good enough to publish
ABe: This is related to the icon interface issue
... I propose that we rewrite this so that APIs for getting/setting
view states and icons are omitted
Benoit: there should be a comment about what we have in mind
AB: Arve has made a proposal for what we do right now
Claudio: how is it done in Opera?
ABe: we support css media queries
... so you can do an opera-proprietary media query with a widget
mode
... we need to know what a viewState is
AB: where do we stand: Do we have a proposal?
MC: If Vodafone has a proposal it would ne interesting to see
... if BONDI has a proposal it would be interesting
... we should also look again what what is in the landscape document
... we need to limit the supported viewStates to the minimum
... packaging should be independent of this
... so we have to separate things so that this issue doesn't hold up
the packaging spec
AB: we could continue to spend more time on this
... but I think we should move on
V2 list
<claudio> [44]http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R
[44] http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R
<arve> relevant link on Opera widget modes:
[45]http://dev.opera.com/articles/view/widget-modes-docked-widget-an
d-more/
[45] http://dev.opera.com/articles/view/widget-modes-docked-
widget-and-more/
Claudio: there is a list of features that might be interesting in v2
... different items at different levels of granularity
... we can't go now into detail
... invitation to all is to refer to the wiki page and check it and
make sure that if there is something you want then it is added to
the list
... then we will see what makes sense to address in v2
AB: I don't have anything much to add
... (to all) if you add anything to the list please make sure there
is sufficient detail to make it comprehensible
... also please clarify whether the scenarios already listed are
just examples or real proposals
Claudio: the important thing is to get people to identify shortfalls
and work constructively towards resolving them in v2
... rather than just using them to criticise v1
AB: this is a great start
... anyone in the WG can have write access to this
... but pls check with Claudio first
Benoit slides
Benoit: introduction
... these are just internal slides I prepared
... but I wanted to share them with the group
... if the group feels they can usefully be reused we can
rebrand/reformat them
... 2 elements I wanted to present
... 1 is standardisation process
... 2 is about WG activity specifically
... as we don't have time now we won't go into the details
... tried to capture who is active in this WG
... outline widget definition, and WG deliverables and relationship
... outline current status and roadmap
AB: do we want to go ahead and put some of this information on the
wiki?
... I would characterise it has having 4 pieces of information:
... a) w3c process
... b) widget intro .. put in widgets page in wiki
<ArtB> AB: status is
[46]http://www.w3.org/2008/webapps/wiki/PubStatus
[46] http://www.w3.org/2008/webapps/wiki/PubStatus
AB: c) status
... d) roadmap .. not opposed to publishing it but don't want to be
held to it
MP: Vodafone would appreciate having this document for internal Q&A
AB: a bit concerned about publishing the roadmap information
Benoit: in order to provide a complete overview I need a complete
set of slides
AB: so upload the entire document to the wiki?
Benoit: yes
... I think a slideset is a useful format
AB: so how do we maintain it?
Benoit: don't know, that's the question
... for example can we just update the status by hand at the end of
each weekly meeting?
AB: what do others think?
PB: I think it is useful if non-branded but cautious about roadmap
information
MC: what if just the roadmap is maintained on the wiki, but
everything else is in the powerpoint?
... then the roadmap information can be copied in when needed or
updated
Benoit: is anyone opposed to having their logos in the presentation?
AB: maybe remove Nokia if there's an implied commitment to meet the
roadmap
... need to wrap up
... we don't have consensus yet
... continue discussion on mail list
F2F meeting
AB: Benoit agreed to host us in Paris
Benoit: regluar meeting logistics are easy
... but coffee breaks might not be catered
AB: would you be able to accommodate the APIs parallel track as
well?
Benoit: it should be OK
... based on the numbers we usually get
... a single large room for plenary meeting would be harder
AB: would a 4-day meeting be possible?
Benoit: yes
... (except for coffee)
AB: need to check with Chaals, Mike, Doug
... what about timing?
... security workshop is in December
... and we need 8 week notice
Benoit: earliest date for last call on packaging spec is beginning
of December
... so review period goes to end December
... so late January night be a good time for the meeting
DR: there is an OMTP meeting in Jan 26-30th (London)
... MWC is 16-19th February (Barcelona)
Claudio: W3C w'shop (future of social networking) 15-16th January
(Barcelona)
AB: we're done
Summary of Action Items
[NEW] ACTION: Arve talk to Wilhelm about contributing to the Widgets
testing effort [recorded in
[47]http://www.w3.org/2008/10/21-wam-minutes.html#action07]
[NEW] ACTION: Barstow ask Carmelo for the URI of his testing paper
[recorded in
[48]http://www.w3.org/2008/10/21-wam-minutes.html#action05]
[NEW] ACTION: Barstow figure out a way (procedurally) for Kai Hendry
to contribute to the Widgets testing (with Mike Smith) [recorded in
[49]http://www.w3.org/2008/10/21-wam-minutes.html#action06]
[NEW] ACTION: Barstow propose a new time for the weekly Widgets
Voice Conf - 1-3 hours later than now [recorded in
[50]http://www.w3.org/2008/10/21-wam-minutes.html#action09]
[NEW] ACTION: Claudio Add handling 50 widget update use case and
requirements to the v2 feature and requirements list [recorded in
[51]http://www.w3.org/2008/10/21-wam-minutes.html#action02]
[NEW] ACTION: Mark submit a short set of requirements re extended
permissions and parameters and a proposal to address those
requirements (to public-webapps) [recorded in
[52]http://www.w3.org/2008/10/21-wam-minutes.html#action04]
[NEW] ACTION: Mark what is our lifecycle, revocation model?
[recorded in
[53]http://www.w3.org/2008/10/21-wam-minutes.html#action03]
[NEW] ACTION: Nick check with BONDI team to see if they can
contribute to the Widgets testing effort [recorded in
[54]http://www.w3.org/2008/10/21-wam-minutes.html#action08]
[NEW] ACTION: thomas do you object to the removal of the
WidgetSignatureInfo element? [recorded in
[55]http://www.w3.org/2008/10/21-wam-minutes.html#action01]
[End of minutes]
Received on Tuesday, 21 October 2008 20:42:38 UTC