07:15:53 RRSAgent has joined #wam 07:15:53 logging to http://www.w3.org/2008/10/21-wam-irc 07:16:02 rrsagent, make log public 07:16:12 Meeting: Widgets f2f Meeting 07:16:18 Date: 21 October 2008 07:16:20 Chair: Art 07:16:23 Scribe: Art 07:16:24 marcos has joined #wam 07:16:28 ScribeNick: ArtB 07:16:39 Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda 07:17:07 Present: Paddy, Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike 07:17:41 Present+ Lucy_Lynch 07:17:57 Topic: Agenda Review 07:19:47 MikeSmith has joined #wam 07:21:59 [ Art reviews agenda; two new additions for AOB section ] 07:22:08 AB: any change requests or additions? 07:22:14 [ None ] 07:22:23 Topic: Widgets 1.0 Digital Signature spec 07:22:51 AB: latest ED is http://dev.w3.org/2006/waf/widgets-digsig/ 07:26:50 http://dev.w3.org/2006/waf/widgets-digsig/Overview.src.html 07:27:48 drogersuk has joined #wam 07:27:50 MC: Mark and I have been focusing on simplifying the spec 07:28:08 ... One goal was to make the spec more efficent regarding processing 07:28:22 ... Also want generic XML Sig tools to be useable as is 07:28:29 paddy has joined #wam 07:28:37 ... Also tried to reflect what is being done in the industry 07:28:38 mpriestl has joined #wam 07:29:28 ... New model is 1) ZIP; 2) Sign; 3) ZIP again 07:29:47 ABe: I object to this change 07:29:50 MC: why? 07:30:04 ABe: because there are already tools that follow our previous model 07:30:32 MC: no; just need to sign the ZIP file rather than 100's of files 07:30:51 ABe: this adds runtime complexity 07:30:59 tlr has joined #wam 07:31:15 ... In Opera we can read directly into the ZIP 07:31:24 ... thus it adds complexity for us 07:31:36 ... What is the cost of the old model? 07:31:51 PB: what is the cost you are trying to avoid? 07:32:05 MP: we have a signing server 07:32:10 ... it signs Widgets 07:32:38 ... The old model requires signing each file individually 07:33:08 ... All we really want is one signature for the entire package. 07:33:25 ... This is particuarly important when we have to sign a bunch of Widgets 07:33:57 PB: then you loose the flexibility of signing specific files 07:34:13 stefanoCrosta has joined #wam 07:34:43 MP: the more signing that has to be done, the greater the probability something can fail 07:35:04 ... e.g. twenty signatures (1 per file) versus just 1 signature for the package 07:35:40 PB: the JAR spec allows individual signing 07:36:06 ... and then a hash over the entire JAR 07:36:43 AB: we already agreed everything needs to be signed 07:37:21 MP: want to understand the complexity concern Arve has 07:37:32 ABe: this puts an extra toll on the client 07:37:43 ... must keep the package in memory twice 07:37:58 MC: no, that doesn't seem right 07:38:03 PB: no, Arve's right 07:38:16 ABe: on low memory devices, that isn't acceptable 07:39:29 PB: have to extract the inner ZIP onto disc 07:39:37 ... and this previously wasn't necessary 07:40:11 ABe: verification of the ZIP isn't the hard part 07:40:52 ABe: need to deflate the inner ZIP and keep it in memory 07:41:02 ... must keep the outer file in memory too 07:41:13 MP: why does the outer file need to be in memory 07:41:52 PB: the outer ZIP must be in memory to run the widget 07:42:10 ABe: I agree this shortens the spec 07:42:35 MC: the proposal makes it easier on the signing server 07:43:09 ... this doesn't change tools 07:43:43 AB: so we have a new proposal with a sustained objection 07:44:27 MP: given Arve's concerns, I can live with the original model 07:44:41 ... the change doesn't change the existing proc model 07:44:49 noah has joined #wam 07:44:58 MC: I'm not convinced about Arve's concerns and would need to do some research. 07:45:09 ... OTOH, I can live with the existing model 07:46:56 arve_ has joined #wam 07:46:57 MC: OK, we will stay with the model where every file is signed 07:47:23 RESOLUTION: we will maintain the model where every file is signed 07:48:04 MC: another thing I removed is the WidgetSignatureInfo element 07:48:12 ... because it requires a custom tool 07:48:34 ... that element only contains a TimeStamp element 07:48:43 ... I couldn't think of a good use case 07:48:50 ... This was introduced by Thomas 07:49:12 AB: any objections to the removal of the WidgetSignatureInfor element? 07:50:18 ACTION: thomas do you object to the removal of the WidgetSignatureInfo element? 07:50:18 Created ACTION-273 - Do you object to the removal of the WidgetSignatureInfo element? [on Thomas Roessler - due 2008-10-28]. 07:50:31 MP: I agree with this change 07:51:04 [ No objections ] 07:51:11 Present+ Nick 07:51:28 Topic: transform element 07:52:17 MC: some files need to be transformed via deflate 07:52:27 ... we can write this in prose 07:54:19 ... We removed it in Dublin meeting 07:54:27 ... I think we need it 07:54:43 AB: let's put this on the agenda for the XMLSec joint meeting 07:54:46 MC: good idea 07:55:10 Present+ Bashar_Jano 07:56:26 Topic: Certificate Chains 07:56:36 MC: does XML Sig support cert chains 07:56:56 [ Marcos displays xmldsig-core ] 07:57:08 MC: yes, it looks like it 07:57:55 AB: should we add this to the XMLSec agenda? 07:58:04 MC: yes. Want to understand ordering for example 08:00:20 MC: return values could be: Fail, Verified (Y or N), Revoked (Y or No or Unavail) 08:00:32 ... If revoedk stop and only one sig then stop 08:00:45 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 ... Also need table of return values based on conditions 08:02:32 MC: Mark and I will meet next week 08:02:43 ... Hope to have a new WD ready for pub by end of next week 08:04:59 Topic: Widgets Requirements LC #2 08:06:04 AB: Widgets reqs LC #2 http://www.w3.org/TR/widgets-reqs/ 08:06:23 MC: the doc is written using RFC2119 08:06:43 ... LC #2 comment period ended Oct 13 08:07:08 ... We want to know the next step -> WG Note or Recommendation 08:07:27 PLH: a Rec doesn't make sense to me 08:07:35 AB: why 08:07:42 PLH: what would you actually require? 08:08:02 ... the reqs are meant to be inclusive 08:08:22 s/PLH: what/MC: what/ 08:08:32 PLH: what will be the exit criteria of CR? 08:08:49 MC: I was thinking OWL has a precedence for this 08:09:12 PLH: infoset had some exit criteria 08:09:33 MC: we can explicitly list those reqs which are address by various specs 08:10:19 PLH: what are the status of the specs? 08:10:33 MC: they are all in WDs 08:11:15 PLH: I can be convinced that a Recommendation is OK 08:11:35 MC: personally, I want to move this to Recommendation 08:11:52 ... We have talked to a lot of industry groups e.g. OMTP 08:12:46 MP: we would like to be able to reference this doc from OMTP 08:12:54 PLH: does it need to a Rec? 08:13:04 PB: it needs to be a stable doc 08:13:28 CV: it would be good to be Rec 08:14:51 AB: I think the options are: 08:14:55 ... 1. leave as is 08:15:03 ... 2. publish another LC 08:15:07 ... 3. publish a CR 08:15:36 ... 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 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 MC: I propose we leave the Reqs doc as is 08:19:15 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 Topic: Widgets 1.0 Updates spec 08:20:33 AB: latest ED is: http://dev.w3.org/2006/waf/widgets-updates/ 08:21:32 MC: we haven't received much feedback yet 08:21:43 ... other than some typos 08:22:30 CV: what happens if device has numerous widgets that need to be updated 08:23:02 MC: could wrap in some outer element 08:23:11 ... we haven't spec'ed that yet 08:24:42 CV: shoud the spec say something about this? 08:24:55 MC: it would certainly complicate the current model 08:26:07 PB: what is the trust model if the widgetupdate came via some mechanism other than https? 08:27:07 MP: need to understand the integrity of the source 08:28:01 CV: thinking about 50 widgets trying to do an update at the same time 08:29:01 MC: can imagine some wrapper process that does the updates over a single connection 08:29:50 MS: I wonder about that use case i.e. 50 widgets on a device 08:30:04 ... typically expect updates 1 at a time 08:30:38 ABe: I would expect more like 15-20 08:31:16 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 PB: a question is one of scalability 08:32:38 MC: I think the current model is sufficient for v1 08:33:51 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 CV: yes, that's OK 08:34:46 PB: I think the current model is OK for v1 08:35:29 ACTION: Claudio Add handling 50 widget update use case and requirements to the v2 feature and requirements list 08:35:29 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 RRSAgent, make minutes 08:36:13 I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB 08:36:49 rssagent, make log public 08:38:00 Present+ Philipe_LeHegaret 08:38:10 RRSAgent, make minutes 08:38:10 I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB 08:59:37 ArtB has joined #wam 09:01:39 ArtB has joined #wam 09:08:24 drogersuk has joined #wam 09:10:15 Zakim has joined #wam 09:12:39 paddy has joined #wam 09:13:52 Topic: Digital Signature Joint meeting with XML Sec WG 09:14:30 AB: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda#Tuesday.2C_October_21 09:14:34 arve has joined #wam 09:15:25 AB: We would like to discuss the questions that we sent over 09:15:49 We also have some additional questions and Marcos would like to show you the draft document 09:16:16 ScribeNick: Drogersuk 09:16:57 MP outlined the questions 09:17:16 Scribe+ David 09:17:25 MP: Within Vodafone and the OMTP BONDI initiative, we have looked at the digital signatures 09:17:31 fjh has joined #wam 09:17:42 tlr has joined #wam 09:17:43 MP: The NIST recommendation is that SHA-1 should be phased out 09:17:58 MP: This is being recommended in BONDI at the moment 09:18:20 MP: Do you foresee that SHA-256 will be supported? 09:18:31 XML Dig-Sig: Yes, that is correct 09:18:44 XML Dig-Sig: Many companies have already banned SHA-1 usage 09:19:12 ..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 s/XML Dig-Sig/BrianLaMacchia/ 09:19:28 Present+ Frederick_Hirsch 09:19:34 Present+ Thomas 09:19:41 ..you need to stop people generating new signatures and reference hashes with SHA-1 09:20:11 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 MP: We would like to strongly recommend the usage of SHA-256 09:20:31 Present+ RobMiller 09:20:35 Present+ PratikDatta 09:20:44 Present+ Gerald Edgar 09:20:50 Present+ KelvinYiu 09:20:54 Present+ BrianLaMacchia 09:20:59 Present+ ChrisSolc 09:21:03 Present+ BruceRich 09:21:22 MP: How in XML DigSig do you deal with supporting new hash algorithms? 09:23:17 MP: We would like to mandate support for DSA 09:23:31 BLM: You don't want to do DSA 09:23:47 ...1024 bits is too short 09:24:01 ...for DSA....RSA at 1024 is too short 09:24:35 ...use EC and RSA 09:25:09 ...obvious choice is EC-DSA 09:25:52 MP: for key length, we are mandating that the consuming platform must support 2048 09:25:59 BLM: That is good 09:26:01 shepazu has joined #wam 09:26:18 MP: You may use 1024 in the short term - we're not disallowing this 09:26:28 BLM: What is the lifetime of that? 09:26:42 PB: It depends on the policy of the author of the widget 09:26:51 newnick has joined #wam 09:27:00 q+ 09:27:02 BLM: It depends on your security level and how long you want to protect the information for 09:27:06 mpriestl has joined #WAM 09:27:14 mpriestl has joined #wam 09:27:47 BLM: RSA 1024 is what you're going to have the least interoperability issues with 09:28:14 ...is it performance that is driving the requirement? 09:28:34 MP: Yes, it is the verify time that some companies have this opinion on 09:28:53 MP: Some countries want weaker cryptography for signatures 09:29:07 TLR: This sounds like an alarming requirement 09:29:25 MP: I'm only expressing the feedback that we've received 09:29:50 MP: There are some requests to be able to choose 1024 09:30:53 TLR: What I'm hearing is that you are arguing for 1024 09:31:19 MP: We strongly recommend 2048, but there is still a requirement for 1024 from some other companies 09:31:44 PD: The argument is probably using it in the interim period 09:32:18 MP: We're broadly aligned with you - but should we support 1024? 09:32:26 BLM: It is the lifetime question 09:32:37 ...it should expire within a year 09:32:49 RRSAgent, make minutes 09:32:49 I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB 09:32:52 ...because of the associated risk 09:33:03 ...you should highlight this in your documents 09:33:14 MP: Yes that is ok we can do that 09:33:41 MP: OK, so we will come up with a proposal for lifetime on 1024 09:34:36 q+ 09:34:41 BLM: Certificates. We don't see references to timestamping or expiry and the certificate chain falling apart 09:34:50 ...what behaviour do you expect? 09:34:51 q- 09:35:03 ...widgets would need to be re-signed 09:35:30 BLM: If I publish a widget and a year later it expires.. 09:35:44 MP: We only do the check at installation time 09:36:03 ...at the moment, we only 'revoke' at installation time, we don't remove them from existing devices 09:36:18 ..that isn't a full revocation model in the classic sense 09:36:46 ...it depends on your signing model, but in W3C and BONDI we're silent on how you try and establish trust.. 09:37:06 ..but from Vodafone's point of view we will revoke the certificate - this is one implementation model 09:37:39 FJH: We're talking about traditional lifecycle / PKI things - it sounds like you need a model for this 09:37:51 ..we could talk a long time about how to figure this out.. 09:38:29 q? 09:38:32 ACTION: Mark what is our lifecycle, revocation model? 09:38:32 Created ACTION-275 - What is our lifecycle, revocation model? [on Mark Priestley - due 2008-10-28]. 09:38:36 q- 09:39:01 BLM: We went through this 10 years ago with authenticode 09:39:23 MP: A related question - is there any thoughts of adding timestamps to the digital signatures specification? 09:39:45 BLM: There were IPR issues and issues in IETF 09:40:17 XAdES , http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=21353 09:40:33 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 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 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 has joined #wam 09:45:44 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 Algorithm identifiers for SHA 256 and RSA-SHA256 are in Encryption and RFC 4051, respectively. 09:46:16 ori has joined #wam 09:46:57 MP: We want to have separate files with signatures in 09:47:35 BLM: You would end up with more characters because you can't share references with the different blocks 09:47:54 q? 09:47:56 BLM: I can understand why you would want to do that with different parties signing 09:48:49 MC explained the requirements document 09:49:11 MC: We need to talk to you about the certificate chains part 09:49:55 ...we probably need some guidance on the inclusion of revocation 09:50:43 MC showed an example 09:51:46 Point 8 in the document was discussed 09:52:30 BLM: Let us discuss this offline 09:53:26 MC: We would not like to have to decompress the whole package to verify the signature 09:53:57 ..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 BLM: Signatures are in the zip? 09:55:22 BLM: The URIs in the references point to what? 09:55:32 MC: They point to file entries 09:56:17 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 ..you wouldn't have a transform because as far as it is concerned it is uncompressed data 09:56:56 Doe URIs allow to reference inse a zip file ... ? Java has soemthing in the format jar:!/[] 09:57:12 MC: OK, so we won't use the transform 09:57:18 s/Doe/Do/ 09:58:32 There was a brief discussion on URI schemes 09:59:27 http://tools.ietf.org/html/rfc3986#section-5.1.2 ... 09:59:42 TLR: You need to identify in the signature properties element the profile and the timestamp. 10:00:08 MC showed an example 10:00:33 MP: On top of specifying XML DigSig, why do need to specify the profile here 10:00:46 TLR: You have a processing model in mind... 10:00:58 ...it may or may not go beyond the model from XML DigSig 10:01:25 TLR: It is a way to prevent signatures not designed for this purpose being used 10:01:27 wondering if it is good to invent new processing models over and over again when there is a "web architecture" 10:02:16 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 ..you could have problems with your CAs 10:03:06 MC: We are quite reluctant to put this in because COTS tools would have problems 10:04:04 BLM: You can use the object element in XML DigSig 10:04:13 MC: Do we need that in our own namespace? 10:04:37 Look into XAdES for SignatureTimstamp 10:04:54 s/SignatureTimstamp/SignatureTimestamp/ 10:04:54 MC: Do we need the timestamp as mandatory 10:05:11 BLM: It depends on what you want the behaviour to be 10:05:35 http://en.wikipedia.org/wiki/XAdES 10:07:04 TLR: signature properties element can be used to put this into 10:07:22 http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-SignatureProperties 10:07:37 MP: We will discuss the model offline if we need to define processing for a timestamp 10:07:53 MC: Can we derive it some other way? 10:07:58 MP: No, this is the way you would do it 10:09:04 MC: Certificate chains. For signatures we just include multiple X509 data blocks? 10:09:24 BLM: Yes, you want one X509 data and multiple X509 certificates 10:09:57 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 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 BLM: Yes we are. 10:10:25 also XAdES 10:10:42 BLM: You may even prefer this in your model 10:11:06 MP: Yes mobile operators are more likely to prefer this 10:11:12 ..it is still to be defined exactly how we will 10:11:50 MP: We are seeing the need to scale up our OCSP servers and CRL servers 10:12:12 ..this will grow. We would like to do some more intelligent packaging of that information. 10:13:36 MC: OK, so the final part for multiple signatures, we're planning to enumerate the signature xmls 10:13:57 MC: First come, first served etc. 10:14:26 q+ 10:14:29 MP: We'd like to see them processed in order 10:14:48 MP: We're not having counter-signatures 10:15:52 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 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 MP: You could do it by filename, but that could be manipulated 10:17:45 RRSAgent, make minutes 10:17:45 I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB 10:18:04 ...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 PD: You want to optimise your common deployment scenario 10:18:49 PD: It makes sense to offer a best practice note on efficiency 10:19:22 MP: We could strip out the other signatures, or make sure that the Vodafone signature was processed first 10:20:01 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 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 ..but in general if we can find a way of avoiding processing multiple digital signatures that would be a good thing 10:21:40 MP: It comes down to not knowing the policy of the consuming device 10:23:20 Policy and trust domains were discussed 10:23:56 There were concerns raised about performance impact of processing lots of signatures 10:24:35 MC: The last issue is procedure for verifying and providing feedback to the widget engine 10:25:13 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 ..however you can do some things here, if you get something back 10:25:49 BLM: You can get information saying it failed 10:26:09 BLM: More interesting is if you get a reason code saying that it was revoked 10:26:24 BLM: You could revoke for many reasons 10:27:03 ...the problem is - is there any cross-link when you have multiple digital signatures? 10:27:21 MP: We have been through this and we have a matrix of values 10:28:10 fh has joined #wam 10:28:45 MP: So i the 'No' part there are reason codes too? 10:28:50 BLM: Yes there can be 10:29:25 BLM: You may get more or less information back depending on the implementation 10:29:52 MP: Perhaps we should insert the table and get your feedback on it 10:30:03 BLM: I'm not sure you can do much with this 10:30:25 BLM: You haven't even assumed that you have a chain validation policy 10:30:33 ...because you are leaving this to the implementation 10:31:01 PB: It is possible for a widget to be completely unsigned 10:31:28 ...in the failure cases, there are cases where you may want to treat the widget as unsigned 10:31:40 ..so you have fallbacks or rejections 10:31:51 zakim, who is here? 10:31:51 sorry, fh, I don't know what conference this is 10:31:52 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 ... trackbot 10:32:47 PB: For example, in Java, if a midlet package is signed, but no root is available, you have to reject 10:33:15 ...it is a problem in practice, because it means that authors feel that it is better to be unsigned 10:33:25 BLM: A disincentive for signing... 10:33:35 PB: Exactly, this is what we want to avoid with this 10:33:56 BLM: What are you doing with the signed v unsigned information? 10:34:12 MP: A signed widget will be allocated to a different trust domain 10:34:46 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 TLR: Unsigned widgets get access to a limited set of functionality 10:35:33 AB: Ok, let us wrap up then. Thankyou very much Frederick. 10:36:46 RRSAgent, make minutes 10:36:46 I have made the request to generate http://www.w3.org/2008/10/21-wam-minutes.html ArtB 10:43:38 DanC_lap has joined #wam 11:35:13 MikeSmith has joined #wam 11:41:49 ArtB has joined #wam 11:42:14 paddy has joined #wam 11:42:23 anne has joined #wam 11:45:14 anne has joined #wam 11:47:31 drogersuk has joined #wam 11:52:59 brich has joined #wam 12:02:03 shepazu has joined #wam 12:10:28 DanC_lap has joined #wam 12:15:34 stefanoCrosta has joined #wam 12:16:46 Topic: Widget Permissions, Access, etc. 12:17:08 mpriestl has joined #wam 12:17:16 arve has joined #wam 12:17:44 MC: with BONDI we've been thinking about the features element 12:17:53 ... and whether it fullfills all of our reqs 12:18:05 ... Not clear it is flexibile enough 12:18:28 ... Some issues could be overcome with a separate permissions element 12:18:52 marcos has joined #wam 12:18:56 AB: where are the requirements that aren't being met? 12:19:12 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