IRC log of wam on 2008-10-21

Timestamps are in UTC.

07:15:53 [RRSAgent]
RRSAgent has joined #wam
07:15:53 [RRSAgent]
logging to http://www.w3.org/2008/10/21-wam-irc
07:16:02 [ArtB]
rrsagent, make log public
07:16:12 [ArtB]
Meeting: Widgets f2f Meeting
07:16:18 [ArtB]
Date: 21 October 2008
07:16:20 [ArtB]
Chair: Art
07:16:23 [ArtB]
Scribe: Art
07:16:24 [marcos]
marcos has joined #wam
07:16:28 [ArtB]
ScribeNick: ArtB
07:16:39 [ArtB]
Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
07:17:07 [ArtB]
Present: Paddy, Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike
07:17:41 [ArtB]
Present+ Lucy_Lynch
07:17:57 [ArtB]
Topic: Agenda Review
07:19:47 [MikeSmith]
MikeSmith has joined #wam
07:21:59 [ArtB]
[ Art reviews agenda; two new additions for AOB section ]
07:22:08 [ArtB]
AB: any change requests or additions?
07:22:14 [ArtB]
[ None ]
07:22:23 [ArtB]
Topic: Widgets 1.0 Digital Signature spec
07:22:51 [ArtB]
AB: latest ED is http://dev.w3.org/2006/waf/widgets-digsig/
07:26:50 [marcos]
http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html
07:27:48 [drogersuk]
drogersuk has joined #wam
07:27:50 [ArtB]
MC: Mark and I have been focusing on simplifying the spec
07:28:08 [ArtB]
... One goal was to make the spec more efficent regarding processing
07:28:22 [ArtB]
... Also want generic XML Sig tools to be useable as is
07:28:29 [paddy]
paddy has joined #wam
07:28:37 [ArtB]
... Also tried to reflect what is being done in the industry
07:28:38 [mpriestl]
mpriestl has joined #wam
07:29:28 [ArtB]
... New model is 1) ZIP; 2) Sign; 3) ZIP again
07:29:47 [ArtB]
ABe: I object to this change
07:29:50 [ArtB]
MC: why?
07:30:04 [ArtB]
ABe: because there are already tools that follow our previous model
07:30:32 [ArtB]
MC: no; just need to sign the ZIP file rather than 100's of files
07:30:51 [ArtB]
ABe: this adds runtime complexity
07:30:59 [tlr]
tlr has joined #wam
07:31:15 [ArtB]
... In Opera we can read directly into the ZIP
07:31:24 [ArtB]
... thus it adds complexity for us
07:31:36 [ArtB]
... What is the cost of the old model?
07:31:51 [ArtB]
PB: what is the cost you are trying to avoid?
07:32:05 [ArtB]
MP: we have a signing server
07:32:10 [ArtB]
... it signs Widgets
07:32:38 [ArtB]
... The old model requires signing each file individually
07:33:08 [ArtB]
... All we really want is one signature for the entire package.
07:33:25 [ArtB]
... This is particuarly important when we have to sign a bunch of Widgets
07:33:57 [ArtB]
PB: then you loose the flexibility of signing specific files
07:34:13 [stefanoCrosta]
stefanoCrosta has joined #wam
07:34:43 [ArtB]
MP: the more signing that has to be done, the greater the probability something can fail
07:35:04 [ArtB]
... e.g. twenty signatures (1 per file) versus just 1 signature for the package
07:35:40 [ArtB]
PB: the JAR spec allows individual signing
07:36:06 [ArtB]
... and then a hash over the entire JAR
07:36:43 [ArtB]
AB: we already agreed everything needs to be signed
07:37:21 [ArtB]
MP: want to understand the complexity concern Arve has
07:37:32 [ArtB]
ABe: this puts an extra toll on the client
07:37:43 [ArtB]
... must keep the package in memory twice
07:37:58 [ArtB]
MC: no, that doesn't seem right
07:38:03 [ArtB]
PB: no, Arve's right
07:38:16 [ArtB]
ABe: on low memory devices, that isn't acceptable
07:39:29 [ArtB]
PB: have to extract the inner ZIP onto disc
07:39:37 [ArtB]
... and this previously wasn't necessary
07:40:11 [ArtB]
ABe: verification of the ZIP isn't the hard part
07:40:52 [ArtB]
ABe: need to deflate the inner ZIP and keep it in memory
07:41:02 [ArtB]
... must keep the outer file in memory too
07:41:13 [ArtB]
MP: why does the outer file need to be in memory
07:41:52 [ArtB]
PB: the outer ZIP must be in memory to run the widget
07:42:10 [ArtB]
ABe: I agree this shortens the spec
07:42:35 [ArtB]
MC: the proposal makes it easier on the signing server
07:43:09 [ArtB]
... this doesn't change tools
07:43:43 [ArtB]
AB: so we have a new proposal with a sustained objection
07:44:27 [ArtB]
MP: given Arve's concerns, I can live with the original model
07:44:41 [ArtB]
... the change doesn't change the existing proc model
07:44:49 [noah]
noah has joined #wam
07:44:58 [ArtB]
MC: I'm not convinced about Arve's concerns and would need to do some research.
07:45:09 [ArtB]
... OTOH, I can live with the existing model
07:46:56 [arve_]
arve_ has joined #wam
07:46:57 [ArtB]
MC: OK, we will stay with the model where every file is signed
07:47:23 [ArtB]
RESOLUTION: we will maintain the model where every file is signed
07:48:04 [ArtB]
MC: another thing I removed is the WidgetSignatureInfo element
07:48:12 [ArtB]
... because it requires a custom tool
07:48:34 [ArtB]
... that element only contains a TimeStamp element
07:48:43 [ArtB]
... I couldn't think of a good use case
07:48:50 [ArtB]
... This was introduced by Thomas
07:49:12 [ArtB]
AB: any objections to the removal of the WidgetSignatureInfor element?
07:50:18 [ArtB]
ACTION: thomas do you object to the removal of the WidgetSignatureInfo element?
07:50:18 [trackbot]
Created ACTION-273 - Do you object to the removal of the WidgetSignatureInfo element? [on Thomas Roessler - due 2008-10-28].
07:50:31 [ArtB]
MP: I agree with this change
07:51:04 [ArtB]
[ No objections ]
07:51:11 [ArtB]
Present+ Nick
07:51:28 [ArtB]
Topic: transform element
07:52:17 [ArtB]
MC: some files need to be transformed via deflate
07:52:27 [ArtB]
... we can write this in prose
07:54:19 [ArtB]
... We removed it in Dublin meeting
07:54:27 [ArtB]
... I think we need it
07:54:43 [ArtB]
AB: let's put this on the agenda for the XMLSec joint meeting
07:54:46 [ArtB]
MC: good idea
07:55:10 [ArtB]
Present+ Bashar_Jano
07:56:26 [ArtB]
Topic: Certificate Chains
07:56:36 [ArtB]
MC: does XML Sig support cert chains
07:56:56 [ArtB]
[ Marcos displays xmldsig-core ]
07:57:08 [ArtB]
MC: yes, it looks like it
07:57:55 [ArtB]
AB: should we add this to the XMLSec agenda?
07:58:04 [ArtB]
MC: yes. Want to understand ordering for example
08:00:20 [ArtB]
MC: return values could be: Fail, Verified (Y or N), Revoked (Y or No or Unavail)
08:00:32 [ArtB]
... If revoedk stop and only one sig then stop
08:00:45 [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.
08:00:46 [ArtB]
... Also need table of return values based on conditions
08:02:32 [ArtB]
MC: Mark and I will meet next week
08:02:43 [ArtB]
... Hope to have a new WD ready for pub by end of next week
08:04:59 [ArtB]
Topic: Widgets Requirements LC #2
08:06:04 [ArtB]
AB: Widgets reqs LC #2 http://www.w3.org/TR/widgets-reqs/
08:06:23 [ArtB]
MC: the doc is written using RFC2119
08:06:43 [ArtB]
... LC #2 comment period ended Oct 13
08:07:08 [ArtB]
... We want to know the next step -> WG Note or Recommendation
08:07:27 [ArtB]
PLH: a Rec doesn't make sense to me
08:07:35 [ArtB]
AB: why
08:07:42 [ArtB]
PLH: what would you actually require?
08:08:02 [ArtB]
... the reqs are meant to be inclusive
08:08:22 [ArtB]
s/PLH: what/MC: what/
08:08:32 [ArtB]
PLH: what will be the exit criteria of CR?
08:08:49 [ArtB]
MC: I was thinking OWL has a precedence for this
08:09:12 [ArtB]
PLH: infoset had some exit criteria
08:09:33 [ArtB]
MC: we can explicitly list those reqs which are address by various specs
08:10:19 [ArtB]
PLH: what are the status of the specs?
08:10:33 [ArtB]
MC: they are all in WDs
08:11:15 [ArtB]
PLH: I can be convinced that a Recommendation is OK
08:11:35 [ArtB]
MC: personally, I want to move this to Recommendation
08:11:52 [ArtB]
... We have talked to a lot of industry groups e.g. OMTP
08:12:46 [ArtB]
MP: we would like to be able to reference this doc from OMTP
08:12:54 [ArtB]
PLH: does it need to a Rec?
08:13:04 [ArtB]
PB: it needs to be a stable doc
08:13:28 [ArtB]
CV: it would be good to be Rec
08:14:51 [ArtB]
AB: I think the options are:
08:14:55 [ArtB]
... 1. leave as is
08:15:03 [ArtB]
... 2. publish another LC
08:15:07 [ArtB]
... 3. publish a CR
08:15:36 [ArtB]
... In the CR, state the exit criteria is that each requirement in scope for WebApps must be addressed by one of our specs
08:17:19 [ArtB]
AB: 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
08:17:43 [ArtB]
MC: I propose we leave the Reqs doc as is
08:19:15 [ArtB]
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
08:20:13 [ArtB]
Topic: Widgets 1.0 Updates spec
08:20:33 [ArtB]
AB: latest ED is: http://dev.w3.org/2006/waf/widgets-updates/
08:21:32 [ArtB]
MC: we haven't received much feedback yet
08:21:43 [ArtB]
... other than some typos
08:22:30 [ArtB]
CV: what happens if device has numerous widgets that need to be updated
08:23:02 [ArtB]
MC: could wrap <widgetupate> in some outer element
08:23:11 [ArtB]
... we haven't spec'ed that yet
08:24:42 [ArtB]
CV: shoud the spec say something about this?
08:24:55 [ArtB]
MC: it would certainly complicate the current model
08:26:07 [ArtB]
PB: what is the trust model if the widgetupdate came via some mechanism other than https?
08:27:07 [ArtB]
MP: need to understand the integrity of the source
08:28:01 [ArtB]
CV: thinking about 50 widgets trying to do an update at the same time
08:29:01 [ArtB]
MC: can imagine some wrapper process that does the updates over a single connection
08:29:50 [ArtB]
MS: I wonder about that use case i.e. 50 widgets on a device
08:30:04 [ArtB]
... typically expect updates 1 at a time
08:30:38 [ArtB]
ABe: I would expect more like 15-20
08:31:16 [ArtB]
MS: I can see there could be many but would the user really want to update them all at the same time
08:31:47 [ArtB]
PB: a question is one of scalability
08:32:38 [ArtB]
MC: I think the current model is sufficient for v1
08:33:51 [ArtB]
AB: Claudio, can you live with the existing model for v1 and add your use case and reqs to the v2 reqs doc
08:33:52 [ArtB]
CV: yes, that's OK
08:34:46 [ArtB]
PB: I think the current model is OK for v1
08:35:29 [ArtB]
ACTION: Claudio Add handling 50 widget update use case and requirements to the v2 feature and requirements list
08:35:29 [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].
08:36:13 [ArtB]
RRSAgent, make minutes
08:36:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
08:36:49 [ArtB]
rssagent, make log public
08:38:00 [ArtB]
Present+ Philipe_LeHegaret
08:38:10 [ArtB]
RRSAgent, make minutes
08:38:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
08:59:37 [ArtB]
ArtB has joined #wam
09:01:39 [ArtB]
ArtB has joined #wam
09:08:24 [drogersuk]
drogersuk has joined #wam
09:10:15 [Zakim]
Zakim has joined #wam
09:12:39 [paddy]
paddy has joined #wam
09:13:52 [ArtB]
Topic: Digital Signature Joint meeting with XML Sec WG
09:14:30 [ArtB]
AB: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesday.2C_October_21
09:14:34 [arve]
arve has joined #wam
09:15:25 [drogersuk]
AB: We would like to discuss the questions that we sent over
09:15:49 [drogersuk]
We also have some additional questions and Marcos would like to show you the draft document
09:16:16 [ArtB]
ScribeNick: Drogersuk
09:16:57 [drogersuk]
MP outlined the questions
09:17:16 [ArtB]
Scribe+ David
09:17:25 [drogersuk]
MP: Within Vodafone and the OMTP BONDI initiative, we have looked at the digital signatures
09:17:31 [fjh]
fjh has joined #wam
09:17:42 [tlr]
tlr has joined #wam
09:17:43 [drogersuk]
MP: The NIST recommendation is that SHA-1 should be phased out
09:17:58 [drogersuk]
MP: This is being recommended in BONDI at the moment
09:18:20 [drogersuk]
MP: Do you foresee that SHA-256 will be supported?
09:18:31 [drogersuk]
XML Dig-Sig: Yes, that is correct
09:18:44 [drogersuk]
XML Dig-Sig: Many companies have already banned SHA-1 usage
09:19:12 [drogersuk]
..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
09:19:21 [tlr]
s/XML Dig-Sig/BrianLaMacchia/
09:19:28 [ArtB]
Present+ Frederick_Hirsch
09:19:34 [ArtB]
Present+ Thomas
09:19:41 [drogersuk]
..you need to stop people generating new signatures and reference hashes with SHA-1
09:20:11 [drogersuk]
MP: This is completely in-line with our plans. We recognise the need to support SHA-1 for past / still-valid certificates
09:20:21 [drogersuk]
MP: We would like to strongly recommend the usage of SHA-256
09:20:31 [tlr]
Present+ RobMiller
09:20:35 [tlr]
Present+ PratikDatta
09:20:44 [tlr]
Present+ Gerald Edgar
09:20:50 [tlr]
Present+ KelvinYiu
09:20:54 [tlr]
Present+ BrianLaMacchia
09:20:59 [tlr]
Present+ ChrisSolc
09:21:03 [tlr]
Present+ BruceRich
09:21:22 [drogersuk]
MP: How in XML DigSig do you deal with supporting new hash algorithms?
09:23:17 [drogersuk]
MP: We would like to mandate support for DSA
09:23:31 [drogersuk]
BLM: You don't want to do DSA
09:23:47 [drogersuk]
...1024 bits is too short
09:24:01 [drogersuk]
...for DSA....RSA at 1024 is too short
09:24:35 [drogersuk]
...use EC and RSA
09:25:09 [drogersuk]
...obvious choice is EC-DSA
09:25:52 [drogersuk]
MP: for key length, we are mandating that the consuming platform must support 2048
09:25:59 [drogersuk]
BLM: That is good
09:26:01 [shepazu]
shepazu has joined #wam
09:26:18 [drogersuk]
MP: You may use 1024 in the short term - we're not disallowing this
09:26:28 [drogersuk]
BLM: What is the lifetime of that?
09:26:42 [drogersuk]
PB: It depends on the policy of the author of the widget
09:26:51 [newnick]
newnick has joined #wam
09:27:00 [tlr]
q+
09:27:02 [drogersuk]
BLM: It depends on your security level and how long you want to protect the information for
09:27:06 [mpriestl]
mpriestl has joined #WAM
09:27:14 [mpriestl]
mpriestl has joined #wam
09:27:47 [drogersuk]
BLM: RSA 1024 is what you're going to have the least interoperability issues with
09:28:14 [drogersuk]
...is it performance that is driving the requirement?
09:28:34 [drogersuk]
MP: Yes, it is the verify time that some companies have this opinion on
09:28:53 [drogersuk]
MP: Some countries want weaker cryptography for signatures
09:29:07 [drogersuk]
TLR: This sounds like an alarming requirement
09:29:25 [drogersuk]
MP: I'm only expressing the feedback that we've received
09:29:50 [drogersuk]
MP: There are some requests to be able to choose 1024
09:30:53 [drogersuk]
TLR: What I'm hearing is that you are arguing for 1024
09:31:19 [drogersuk]
MP: We strongly recommend 2048, but there is still a requirement for 1024 from some other companies
09:31:44 [drogersuk]
PD: The argument is probably using it in the interim period
09:32:18 [drogersuk]
MP: We're broadly aligned with you - but should we support 1024?
09:32:26 [drogersuk]
BLM: It is the lifetime question
09:32:37 [drogersuk]
...it should expire within a year
09:32:49 [ArtB]
RRSAgent, make minutes
09:32:49 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
09:32:52 [drogersuk]
...because of the associated risk
09:33:03 [drogersuk]
...you should highlight this in your documents
09:33:14 [drogersuk]
MP: Yes that is ok we can do that
09:33:41 [drogersuk]
MP: OK, so we will come up with a proposal for lifetime on 1024
09:34:36 [fjh]
q+
09:34:41 [drogersuk]
BLM: Certificates. We don't see references to timestamping or expiry and the certificate chain falling apart
09:34:50 [drogersuk]
...what behaviour do you expect?
09:34:51 [tlr]
q-
09:35:03 [drogersuk]
...widgets would need to be re-signed
09:35:30 [drogersuk]
BLM: If I publish a widget and a year later it expires..
09:35:44 [drogersuk]
MP: We only do the check at installation time
09:36:03 [drogersuk]
...at the moment, we only 'revoke' at installation time, we don't remove them from existing devices
09:36:18 [drogersuk]
..that isn't a full revocation model in the classic sense
09:36:46 [drogersuk]
...it depends on your signing model, but in W3C and BONDI we're silent on how you try and establish trust..
09:37:06 [drogersuk]
..but from Vodafone's point of view we will revoke the certificate - this is one implementation model
09:37:39 [drogersuk]
FJH: We're talking about traditional lifecycle / PKI things - it sounds like you need a model for this
09:37:51 [drogersuk]
..we could talk a long time about how to figure this out..
09:38:29 [fjh]
q?
09:38:32 [ArtB]
ACTION: Mark what is our lifecycle, revocation model?
09:38:32 [trackbot]
Created ACTION-275 - What is our lifecycle, revocation model? [on Mark Priestley - due 2008-10-28].
09:38:36 [fjh]
q-
09:39:01 [drogersuk]
BLM: We went through this 10 years ago with authenticode
09:39:23 [drogersuk]
MP: A related question - is there any thoughts of adding timestamps to the digital signatures specification?
09:39:45 [drogersuk]
BLM: There were IPR issues and issues in IETF
09:40:17 [fjh]
XAdES , http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=21353
09:40:33 [drogersuk]
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
09:41:09 [drogersuk]
BLM: There could be issues with recovering a bad widget if it gets out there and you need to think about that
09:45:12 [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.
09:45:39 [klanz2]
klanz2 has joined #wam
09:45:44 [drogersuk]
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?
09:45:47 [tlr]
Algorithm identifiers for SHA 256 and RSA-SHA256 are in Encryption and RFC 4051, respectively.
09:46:16 [ori]
ori has joined #wam
09:46:57 [drogersuk]
MP: We want to have separate files with signatures in
09:47:35 [drogersuk]
BLM: You would end up with more characters because you can't share references with the different blocks
09:47:54 [tlr]
q?
09:47:56 [drogersuk]
BLM: I can understand why you would want to do that with different parties signing
09:48:49 [drogersuk]
MC explained the requirements document
09:49:11 [drogersuk]
MC: We need to talk to you about the certificate chains part
09:49:55 [drogersuk]
...we probably need some guidance on the inclusion of revocation
09:50:43 [drogersuk]
MC showed an example
09:51:46 [drogersuk]
Point 8 in the document was discussed
09:52:30 [drogersuk]
BLM: Let us discuss this offline
09:53:26 [drogersuk]
MC: We would not like to have to decompress the whole package to verify the signature
09:53:57 [drogersuk]
..do we need to contain a transform element in there to indicate that you need to deflate this in order to verify?
09:54:12 [drogersuk]
BLM: Signatures are in the zip?
09:55:22 [drogersuk]
BLM: The URIs in the references point to what?
09:55:32 [drogersuk]
MC: They point to file entries
09:56:17 [drogersuk]
BLM: This could be ok. For efficiency purposes, that is implementation. The URI you reference will be to the raw uncompressed data
09:56:52 [drogersuk]
..you wouldn't have a transform because as far as it is concerned it is uncompressed data
09:56:56 [klanz2]
Doe URIs allow to reference inse a zip file ... ? Java has soemthing in the format jar:<url>!/[<entry>]
09:57:12 [drogersuk]
MC: OK, so we won't use the transform
09:57:18 [klanz2]
s/Doe/Do/
09:58:32 [drogersuk]
There was a brief discussion on URI schemes
09:59:27 [klanz2]
http://tools.ietf.org/html/rfc3986#section-5.1.2 ...
09:59:42 [drogersuk]
TLR: You need to identify in the signature properties element the profile and the timestamp.
10:00:08 [drogersuk]
MC showed an example
10:00:33 [drogersuk]
MP: On top of specifying XML DigSig, why do need to specify the profile here
10:00:46 [drogersuk]
TLR: You have a processing model in mind...
10:00:58 [drogersuk]
...it may or may not go beyond the model from XML DigSig
10:01:25 [drogersuk]
TLR: It is a way to prevent signatures not designed for this purpose being used
10:01:27 [klanz2]
wondering if it is good to invent new processing models over and over again when there is a "web architecture"
10:02:16 [drogersuk]
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
10:02:36 [drogersuk]
..you could have problems with your CAs
10:03:06 [drogersuk]
MC: We are quite reluctant to put this in because COTS tools would have problems
10:04:04 [drogersuk]
BLM: You can use the object element in XML DigSig
10:04:13 [drogersuk]
MC: Do we need that in our own namespace?
10:04:37 [klanz2]
Look into XAdES for SignatureTimstamp
10:04:54 [klanz2]
s/SignatureTimstamp/SignatureTimestamp/
10:04:54 [drogersuk]
MC: Do we need the timestamp as mandatory
10:05:11 [drogersuk]
BLM: It depends on what you want the behaviour to be
10:05:35 [klanz2]
http://en.wikipedia.org/wiki/XAdES
10:07:04 [drogersuk]
TLR: signature properties element can be used to put this into
10:07:22 [fjh]
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-SignatureProperties
10:07:37 [drogersuk]
MP: We will discuss the model offline if we need to define processing for a timestamp
10:07:53 [drogersuk]
MC: Can we derive it some other way?
10:07:58 [drogersuk]
MP: No, this is the way you would do it
10:09:04 [drogersuk]
MC: Certificate chains. For signatures we just include multiple X509 data blocks?
10:09:24 [drogersuk]
BLM: Yes, you want one X509 data and multiple X509 certificates
10:09:57 [fjh]
wss timestamp uility namespace, see appendix C in http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
10:10:13 [drogersuk]
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?
10:10:24 [drogersuk]
BLM: Yes we are.
10:10:25 [fjh]
also XAdES
10:10:42 [drogersuk]
BLM: You may even prefer this in your model
10:11:06 [drogersuk]
MP: Yes mobile operators are more likely to prefer this
10:11:12 [drogersuk]
..it is still to be defined exactly how we will
10:11:50 [drogersuk]
MP: We are seeing the need to scale up our OCSP servers and CRL servers
10:12:12 [drogersuk]
..this will grow. We would like to do some more intelligent packaging of that information.
10:13:36 [drogersuk]
MC: OK, so the final part for multiple signatures, we're planning to enumerate the signature xmls
10:13:57 [drogersuk]
MC: First come, first served etc.
10:14:26 [fjh]
q+
10:14:29 [drogersuk]
MP: We'd like to see them processed in order
10:14:48 [drogersuk]
MP: We're not having counter-signatures
10:15:52 [drogersuk]
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
10:17:03 [drogersuk]
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
10:17:19 [drogersuk]
MP: You could do it by filename, but that could be manipulated
10:17:45 [ArtB]
RRSAgent, make minutes
10:17:45 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
10:18:04 [drogersuk]
...we want to be as silent as we can on the actual model, we don't want to mandate the model that is used
10:18:31 [drogersuk]
PD: You want to optimise your common deployment scenario
10:18:49 [drogersuk]
PD: It makes sense to offer a best practice note on efficiency
10:19:22 [drogersuk]
MP: We could strip out the other signatures, or make sure that the Vodafone signature was processed first
10:20:01 [drogersuk]
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
10:20:41 [drogersuk]
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
10:21:00 [drogersuk]
..but in general if we can find a way of avoiding processing multiple digital signatures that would be a good thing
10:21:40 [drogersuk]
MP: It comes down to not knowing the policy of the consuming device
10:23:20 [drogersuk]
Policy and trust domains were discussed
10:23:56 [drogersuk]
There were concerns raised about performance impact of processing lots of signatures
10:24:35 [drogersuk]
MC: The last issue is procedure for verifying and providing feedback to the widget engine
10:25:13 [drogersuk]
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
10:25:37 [drogersuk]
..however you can do some things here, if you get something back
10:25:49 [drogersuk]
BLM: You can get information saying it failed
10:26:09 [drogersuk]
BLM: More interesting is if you get a reason code saying that it was revoked
10:26:24 [drogersuk]
BLM: You could revoke for many reasons
10:27:03 [drogersuk]
...the problem is - is there any cross-link when you have multiple digital signatures?
10:27:21 [drogersuk]
MP: We have been through this and we have a matrix of values
10:28:10 [fh]
fh has joined #wam
10:28:45 [drogersuk]
MP: So i the 'No' part there are reason codes too?
10:28:50 [drogersuk]
BLM: Yes there can be
10:29:25 [drogersuk]
BLM: You may get more or less information back depending on the implementation
10:29:52 [drogersuk]
MP: Perhaps we should insert the table and get your feedback on it
10:30:03 [drogersuk]
BLM: I'm not sure you can do much with this
10:30:25 [drogersuk]
BLM: You haven't even assumed that you have a chain validation policy
10:30:33 [drogersuk]
...because you are leaving this to the implementation
10:31:01 [drogersuk]
PB: It is possible for a widget to be completely unsigned
10:31:28 [drogersuk]
...in the failure cases, there are cases where you may want to treat the widget as unsigned
10:31:40 [drogersuk]
..so you have fallbacks or rejections
10:31:51 [fh]
zakim, who is here?
10:31:51 [Zakim]
sorry, fh, I don't know what conference this is
10:31:52 [Zakim]
On IRC I see fh, ori, klanz2, mpriestl, BruceRich, shepazu, tlr, arve, paddy, Zakim, drogersuk, ArtB, stefanoCrosta, MikeSmith, RRSAgent, claudio, anne, hsivonen, hendry, timeless,
10:31:54 [Zakim]
... trackbot
10:32:47 [drogersuk]
PB: For example, in Java, if a midlet package is signed, but no root is available, you have to reject
10:33:15 [drogersuk]
...it is a problem in practice, because it means that authors feel that it is better to be unsigned
10:33:25 [drogersuk]
BLM: A disincentive for signing...
10:33:35 [drogersuk]
PB: Exactly, this is what we want to avoid with this
10:33:56 [drogersuk]
BLM: What are you doing with the signed v unsigned information?
10:34:12 [drogersuk]
MP: A signed widget will be allocated to a different trust domain
10:34:46 [drogersuk]
MP: 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
10:35:04 [drogersuk]
TLR: Unsigned widgets get access to a limited set of functionality
10:35:33 [drogersuk]
AB: Ok, let us wrap up then. Thankyou very much Frederick.
10:36:46 [ArtB]
RRSAgent, make minutes
10:36:46 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
10:43:38 [DanC_lap]
DanC_lap has joined #wam
11:35:13 [MikeSmith]
MikeSmith has joined #wam
11:41:49 [ArtB]
ArtB has joined #wam
11:42:14 [paddy]
paddy has joined #wam
11:42:23 [anne]
anne has joined #wam
11:45:14 [anne]
anne has joined #wam
11:47:31 [drogersuk]
drogersuk has joined #wam
11:52:59 [brich]
brich has joined #wam
12:02:03 [shepazu]
shepazu has joined #wam
12:10:28 [DanC_lap]
DanC_lap has joined #wam
12:15:34 [stefanoCrosta]
stefanoCrosta has joined #wam
12:16:46 [ArtB]
Topic: Widget Permissions, Access, etc.
12:17:08 [mpriestl]
mpriestl has joined #wam
12:17:16 [arve]
arve has joined #wam
12:17:44 [ArtB]
MC: with BONDI we've been thinking about the features element
12:17:53 [ArtB]
... and whether it fullfills all of our reqs
12:18:05 [ArtB]
... Not clear it is flexibile enough
12:18:28 [ArtB]
... Some issues could be overcome with a separate permissions element
12:18:52 [marcos]
marcos has joined #wam
12:18:56 [ArtB]
AB: where are the requirements that aren't being met?
12:19:12 [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}.{delete(),readContents(),moveTo()} widget.vodafone.messaging.{sms,mms,email}.{watchIncoming(),watchOutgoing()} 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
12:19:37 [ArtB]
s/MC: with BONDI/MP: with BONDI/
12:20:34 [ArtB]
MP: how to state some features but not all of the features
12:20:42 [ArtB]
... A question here about granularity
12:20:47 [dom]
dom has joined #wam
12:20:59 [ArtB]
... e.g. a Widget needs to only API or perhaps several APIs
12:21:11 [marcos]
http://example.org/feature/feature/freature OR http:/example.org/api?allow=this,this,this&deny=that,that,that
12:21:47 [ArtB]
MP: also need to consider composite widgets
12:22:06 [ArtB]
... eg. a Widget that needs to access Camera and other device services
12:22:16 [claudio]
claudio has joined #wam
12:22:31 [marcos]
http://camera.api.org/gps/changename/contacts/add/delete/album/
12:22:33 [ArtB]
... A Camera widget may need for example to create a folder
12:22:58 [marcos]
<feature id="http//camera.example.org"/>
12:23:05 [ArtB]
... It may need to access Location info
12:23:12 [ArtB]
... It may need to access file system
12:23:26 [marcos]
<feature id="http//camera.example.org"> <permission name="gps" value="allow"/> </feature>
12:23:53 [ArtB]
ABe: not sure I agree with this use case
12:24:33 [ArtB]
... shouldn't combine a bunch of different functions into a single API
12:24:38 [ArtB]
MP: but why not?
12:24:47 [ArtB]
ABe: I think it is a bad design
12:25:30 [ArtB]
MP: what about a camera API that allows geo-locating the image
12:26:20 [ArtB]
MC: this seems to be about how to specify APIs beyond what is being spec'ed by BONDI
12:26:52 [ArtB]
NA: I think an objective behind Mark's proposal is to provide a robust sec model that works for poorly designed APIs
12:27:51 [ArtB]
PB: we realize BONDI is not the only place where these types of APIs will be defined
12:28:48 [DanC_lap]
DanC_lap has left #wam
12:28:49 [ArtB]
... It is certainly possible to have a 1:1 relationship between a single API and an explicity permission
12:29:48 [ArtB]
[ Marcos enters an example in a temporary text buffer ... ]
12:31:22 [marcos]
current option
12:31:23 [marcos]
<feature id="http//camera.example.org?gps=allow"/>
12:31:23 [marcos]
<feature id="http//camera.example.org">
12:31:23 [marcos]
<permission name="gps" value="allow"/>
12:31:23 [marcos]
<permission name="sound" value="disallow"/>
12:31:23 [marcos]
</feature>
12:31:38 [marcos]
and kinda proposed option
12:32:09 [tlr]
tlr has joined #wam
12:34:17 [ArtB]
ABe: the main problem I have with this proposal is that for each feature, must write a domain-specific language for that feature
12:35:17 [arve]
<feature id="[URL FOR GEOLOCATION]"><param name="precision" "0.1m" /></feature
12:35:18 [arve]
>
12:36:24 [ArtB]
BS: what is your interpretation for the permission element?
12:36:33 [ArtB]
MP: used by author and the widget engine
12:36:48 [ArtB]
... could also be used to infer info to display to the user
12:37:52 [ArtB]
... One question is whether this mapping is done explicitly via the config file or an internal detail
12:38:19 [ArtB]
ABe: we assume the device will apply policies depending on the origin of the widget
12:38:31 [ArtB]
... and hence gives a trust model
12:39:12 [klanz2]
klanz2 has left #wam
12:40:44 [ArtB]
... With the exception of network (which is well defined), I don't think we should add domain-specific paramaters
12:41:32 [ArtB]
... If we go this route, the language needs to be rich enough to describe every conceivable API
12:42:26 [Zakim]
Zakim has left #wam
12:42:51 [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.
12:43:05 [ArtB]
BS: I'm wondering what we need to do for v1.0
12:43:19 [ArtB]
MP: we think the current model isn't granular enough
12:44:35 [ArtB]
CV: I think the above syntax is agnostic regarding semantics
12:44:49 [ArtB]
... The author and policy can decide the level of detail
12:46:32 [ArtB]
... I think just allow and not-allow isn't good enough; need some additional richness
12:47:19 [ArtB]
ABe: but this requires a generic syntax for codifying arbitrary constraints
12:50:03 [ArtB]
CV: we need a generic way to define additional constraints for the API
12:50:15 [ArtB]
AB: I agree with some of the concerns Arve is raising
12:50:43 [ArtB]
... not clear for example how rich the language of the value would need to be e.g. regular expressions, booleans, etc.
12:51:00 [arve]
FWIW, I think we are basically discussing python's 'import' statement here
12:51:11 [arve]
from antigravity import *
12:51:42 [ArtB]
MC: could also use a level of indirection here e.g. put the permissions in a separate document
12:52:51 [ArtB]
PB: a requirement is the need to parameterize the features
12:53:08 [ArtB]
... Arve's correct, each API will have different parameters
12:55:17 [ArtB]
MC: this really about providing a standardized way to encode proprietary parameters
12:56:31 [ArtB]
... I also think this goes against the spirit of the OAA's API style guide
12:58:27 [ArtB]
CV: could define an ontology for the various features and their parameters
12:58:54 [ArtB]
MC: to me this implies writing a "proprietary widget"
12:59:39 [kapyaho]
kapyaho has joined #wam
13:00:32 [ArtB]
MC: I don't think the proposal is supported by W3C's Geolocation API
13:02:29 [ArtB]
AB: It's clear we don't have consensus on this issue.
13:02:54 [Zakim]
Zakim has joined #wam
13:02:58 [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
13:03:01 [ArtB]
... Is that OK?
13:03:03 [ArtB]
MP: yes
13:03:47 [ArtB]
ACTION: Mark submit a short set of requirements re extended permissions and parameters and a proposal to address those requirements (to public-webapps)
13:03:48 [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].
13:03:56 [ArtB]
RRSAgent, make minutes
13:03:56 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB
13:13:51 [stefanoCrosta]
stefanoCrosta has joined #wam
13:18:31 [stefanoCrosta]
stefanoCrosta has joined #wam
13:28:11 [tlr]
I suggest bringing this up at the security workshop in December.
13:28:18 [tlr]
http://www.w3.org/2008/security-ws/
13:38:01 [ArtB]
Topic: Widget Testing
13:38:46 [ArtB]
Present+ Kai_Hendry
13:39:07 [ArtB]
Present+ Carmelo
13:39:45 [ArtB]
Present+ Dom
13:40:18 [arve]
arve has joined #wam
13:40:41 [ArtB]
Present+ Denise
13:41:14 [ArtB]
AB: agenda http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesday.2C_October_21
13:45:29 [ArtB]
Scribe+ Paddy
13:45:45 [dom]
ScribeNick: paddy
13:46:18 [paddy]
MC: Dom had a chance to do a first overview of the spec and test issues
13:46:24 [paddy]
... initial thought is ok
13:46:35 [paddy]
... some first thoughts send out
13:47:05 [dom]
-> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0664.html Dom's initial comments on Widgets packaging and configuration
13:47:09 [paddy]
MC showing Packaging and OCnfiguration spec
13:47:17 [paddy]
MC: we're looking for advice on how to do this
13:47:22 [paddy]
.. eg what is a test harness?
13:47:42 [paddy]
.. for example can we identify each testable assertion in the spec and build test cases?
13:48:10 [paddy]
... given the cases in an XML file can we make each test individually addressable and automatable?
13:48:24 [paddy]
... Another spec we looked at wrt testing was from Hixie
13:48:31 [paddy]
... outlined how it was done for CDD
13:48:37 [paddy]
s/CDD/CSS
13:49:04 [paddy]
... defined different levels of testing: atomic, assertion-level, evil, edge cases etc
13:49:20 [paddy]
... that's all we know about testing
13:49:31 [paddy]
... if you have experience/advice that would be great
13:49:44 [paddy]
... our spec isn't that big and we've split the doc into two:
13:49:52 [paddy]
... first half mainly definitions
13:49:59 [paddy]
... second half is the testable part
13:50:34 [paddy]
... html5 followed a systematic approach
13:50:43 [paddy]
... so we tried to structure the doc to facilitate this
13:51:27 [paddy]
MC: eg steps for processing widget resource might be individually testable
13:51:48 [paddy]
Dom: I think a good way to start is to identify each conformance statemennt
13:52:00 [paddy]
... try to construct a simple test case for some of them
13:52:06 [paddy]
... this will not be a very interesting set
13:52:14 [paddy]
... except it will be a starting point
13:52:28 [paddy]
... will give some pointers as to where interoperability fails
13:52:53 [paddy]
... a good strategy is to find the points where interoperability is hardest
13:53:19 [paddy]
MC: unfortunately there are no implementations today
13:53:26 [paddy]
... so there is massive fragmentation
13:53:43 [paddy]
Dom: I guess them I would start during last call with a simple set of test cases
13:54:08 [paddy]
... leave most difficult tests to CR when it is more stable and there are more implementations
13:54:13 [paddy]
... leave evil tests to later
13:54:28 [paddy]
MC: If we will be doing it that way, we might just start creating test cases by hand
13:54:46 [paddy]
... rather than automate the process
13:55:06 [paddy]
Dom: one thing that helps is formluating the conformance requirements
13:55:21 [paddy]
... eg what things would be the subject of conformance?
13:55:27 [paddy]
MC: There are 3 things:
13:55:34 [paddy]
... wodget package
13:55:41 [paddy]
... widget configuration document
13:55:45 [paddy]
... widget runtime
13:55:52 [paddy]
... conformance checker
13:55:54 [paddy]
(4 things)
13:56:06 [paddy]
Dom: would initial focus be on the engine?
13:56:21 [paddy]
... so focus on these conformance statement?
13:56:36 [paddy]
MC: eg testing validity of zip archive
13:56:45 [paddy]
... we could construct an invalid archive
13:56:54 [paddy]
... and test that an engine rejected it
13:57:07 [paddy]
Carmelo: 2 observations:
13:57:17 [paddy]
... mentioned about creating tests by hand:
13:57:25 [paddy]
... usually very time consuming
13:57:34 [paddy]
... xml driven approach is a good idea
13:57:45 [paddy]
MC: I don't think we have expertise in XSLT in this group
13:57:55 [paddy]
Dom: we could help with that
13:57:59 [paddy]
Carmelo:
13:58:11 [nallott]
nallott has joined #wam
13:58:24 [paddy]
... would it be possible to markup tests directly in the spec?
13:58:39 [paddy]
MC: we already have some markup (eg css class)
13:58:51 [paddy]
Dom: you could do some XSLT to extract them
13:59:27 [paddy]
JK: At Nokia been creating an internal document toolchain
13:59:39 [paddy]
... where testable requirements can be identified by markup
13:59:48 [paddy]
... could maybe make this available
13:59:58 [paddy]
MC: we can easily add the markup
14:00:10 [paddy]
Carmelo: have a paper on this I will send
14:00:23 [ArtB]
ACTION: Barstow ask Carmelo for the URI of his testing paper
14:00:23 [trackbot]
Created ACTION-277 - Ask Carmelo for the URI of his testing paper [on Arthur Barstow - due 2008-10-28].
14:00:32 [paddy]
Dom: once you have the testable assertions you still have to create the content corresponding to the test case
14:00:44 [paddy]
... I expect this needs to be done by hand
14:00:46 [paddy]
MC: Yes
14:01:40 [paddy]
Dom: one way to proceed would be to automate the creation of basic test case template only
14:01:54 [paddy]
... but start manually creating the content of each test case
14:02:07 [paddy]
... explicitly referenced to each testable assertion
14:02:18 [paddy]
MC: I imagine I will be the one writing the test cases
14:02:24 [paddy]
KH: I can help
14:02:52 [paddy]
Carmelo: we have a tool which can take test definitions in XML format and generate test cases
14:03:01 [ArtB]
ACTION: Barstow figure out a way (procedurally) for Kai Hendry to contribute to the Widgets testing (with Mike Smith)
14:03:01 [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].
14:03:33 [paddy]
Dom: based on formal RelaxNG description of configuration document perhaps this can be used to drive automate creation of some test cases
14:03:56 [paddy]
... also this can be used to validate the examples in the spec
14:04:11 [paddy]
... this also validates the schema
14:04:27 [paddy]
MC: once we are in last call this will be included in validator.nu
14:04:54 [paddy]
MC: if that existed it will be very easy to create non-conforming content
14:05:21 [paddy]
Dom: also might want to export examples from spec to test cases and vice versa