IRC log of wam on 2008-08-07

Timestamps are in UTC.

11:01:57 [RRSAgent]
RRSAgent has joined #wam
11:01:57 [RRSAgent]
logging to
11:02:06 [claudio]
claudio has joined #wam
11:02:10 [ArtB]
Meeting: Widgets Voice Conference
11:02:15 [ArtB]
Date: 7 August 2008
11:02:19 [ArtB]
Chair: Art
11:02:23 [tlr]
tlr has joined #wam
11:02:24 [ArtB]
Scribe: Art
11:02:26 [tlr]
11:02:29 [ArtB]
ScribeNick: ArtB
11:02:31 [Zakim]
11:02:41 [ArtB]
11:03:00 [tlr]
zakim, mute me
11:03:00 [Zakim]
sorry, tlr, I do not know which phone connection belongs to you
11:03:04 [tlr]
zaim, I am thomas
11:03:06 [tlr]
zakim, I am thomas
11:03:06 [Zakim]
ok, tlr, I now associate you with Thomas
11:03:07 [tlr]
zakim, mute me
11:03:07 [Zakim]
Thomas should now be muted
11:03:11 [mpriestl]
mpriestl has joined #wam
11:03:42 [tlr]
zakim, who is on the phone?
11:03:42 [Zakim]
On the phone I see +44.207.070.aaaa, Art_Barstow, Claudio, Mark, marcos, Thomas (muted)
11:03:47 [tlr]
zakim, who is making noise?
11:03:55 [arve]
arve has joined #wam
11:03:57 [ArtB]
zakim, aaaa is Nick and David
11:03:57 [Zakim]
I don't understand 'aaaa is Nick and David', ArtB
11:03:59 [Zakim]
tlr, listening for 10 seconds I heard sound from the following: Claudio (18%)
11:04:05 [marcos]
zakim, mute me
11:04:05 [Zakim]
marcos should now be muted
11:04:12 [marcos]
I would never!
11:04:15 [marcos]
11:04:20 [tlr]
zakim, aaaa is Nick
11:04:20 [Zakim]
+Nick; got it
11:04:22 [tlr]
zakim, Nick has David
11:04:22 [Zakim]
+David; got it
11:04:36 [marcos]
oh crap. I'll dial in again.
11:04:42 [tlr]
ack t
11:04:46 [Zakim]
+ +47.23.69.aaee
11:04:48 [marcos]
tlr, was it me?
11:04:55 [arve]
Zakim, aaee is me
11:04:55 [Zakim]
+arve; got it
11:05:25 [marcos]
hmmm...., there is nothing next to me or any other device. Will dial in again
11:05:29 [Zakim]
11:05:33 [ArtB]
Present: Art, Nick, David, Luca, Claudio, Mark, Marcos, Thomas, Arve
11:05:58 [ArtB]
Topic: Agenda Review
11:05:59 [Zakim]
11:06:05 [ArtB]
AB: Agenda:
11:06:05 [marcos]
any better?
11:06:06 [marcos]
11:06:33 [arve]
doesn't zakim have some function to see who's making noise?
11:06:45 [marcos]
zakim, who is making noise?
11:06:50 [tlr]
zakim, temporarily mute marcos
11:06:50 [Zakim]
sorry, tlr, I do not know which phone connection belongs to marcos
11:06:54 [tlr]
zakim, temporarily mute P8
11:06:54 [Zakim]
sorry, tlr, I do not know which phone connection belongs to P8
11:06:56 [Zakim]
marcos, listening for 10 seconds I heard sound from the following: Claudio (14%)
11:06:56 [tlr]
11:07:00 [tlr]
zkaim, ??P8 is marcos
11:07:05 [tlr]
zakim, temporarily mute ??P8
11:07:05 [Zakim]
??P8 should now be muted
11:07:21 [Zakim]
??P8 should now be unmuted again
11:07:38 [ArtB]
AB: any change requests for the agenda
11:07:41 [marcos]
hmmm... sorry about this.
11:07:48 [ArtB]
AB: [none]
11:07:57 [ArtB]
Topic: Annoucements
11:08:00 [Luca]
Luca has joined #wam
11:08:00 [marcos]
zakim, ??P8 is me
11:08:00 [Zakim]
+marcos; got it
11:08:14 [ArtB]
AB: registration for the Turin f2f is open; please register ASAP
11:08:23 [ArtB]
11:08:54 [ArtB]
Claudio: must bring a Passport or valid ID
11:09:03 [ArtB]
... company badge is probably not going to work
11:09:21 [tlr]
I hope there is no NDA coming along with the ID requirement.
11:09:25 [ArtB]
ACTION: Barstow passport is required for Turin f2f meeting
11:09:25 [trackbot]
Created ACTION-21 - Passport is required for Turin f2f meeting [on Arthur Barstow - due 2008-08-14].
11:10:14 [ArtB]
Topic: R11 Digital Signatures
11:10:26 [ArtB]
AB: OMTP input
11:10:45 [ArtB]
... request mods to several signature reqs and propose some new reqs
11:11:13 [ArtB]
... who is going to lead the OMTP discussion?
11:11:28 [ArtB]
David: Mark will lead the tech discussion
11:12:55 [ArtB]
AB: the proposal expands on the existing text in R11
11:13:17 [ArtB]
Mark: we think the req needs some clarifications
11:13:40 [ArtB]
... we also propose additional behavior e.g. when there are signature chains
11:13:55 [ArtB]
... need to say what the client will do in various scenarios
11:14:01 [ArtB]
... need consistent behavior
11:14:23 [ArtB]
... need to say what happens if the chain can't be verified
11:14:31 [ArtB]
... e.g. if missing root cert
11:14:42 [ArtB]
... e.g. if cert is expired
11:15:02 [ArtB]
... we suggest the Widget should be considered unsigned
11:15:34 [tlr]
11:15:58 [ArtB]
Arve: I'm concerened about treating the resource as valid
11:16:07 [ArtB]
... it could encourage unsafe behavior by the user
11:16:23 [ArtB]
... Some users aren't qualified to "make the right decision"
11:16:26 [marcos]
MC: I share Arve's concerns.
11:16:43 [ArtB]
.... e.g. is it safe to treat the package as safe
11:16:55 [marcos]
MC: and by assinged, what do you mean?
11:17:14 [ArtB]
Mark: if the widget is not signed, it should never be presented as if it is signed
11:17:26 [marcos]
11:17:30 [ArtB]
Arve: need to clarify unsigned versus unvalid
11:17:42 [marcos]
11:17:53 [ArtB]
Arve: an invalid widget should not be launchable
11:18:50 [ArtB]
Mark: if the root cert is missing we want the widget to still be launchable but just not as a "signed" widget
11:19:33 [marcos]
MC: hmmmm.... this results in "security profiles"
11:19:45 [ArtB]
... we don't want additional security privs for an unsigned widget
11:19:57 [tlr]
11:20:12 [Bryan]
Bryan has joined #wam
11:20:27 [tlr]
ack t
11:20:36 [ArtB]
TR: want to consider the proposed addition in one piece
11:21:02 [ArtB]
... If none of the parts can be verifed, treat as unsigned
11:21:21 [ArtB]
TR: have a couple of concerns
11:21:45 [drogersuk]
drogersuk has joined #wam
11:21:51 [ArtB]
... should install continue if there some part cannot be verified or fails verification
11:21:56 [Zakim]
11:22:18 [ArtB]
... Need to address revoked/unrevoked versus expired
11:22:30 [ArtB]
Present+ Bryan
11:23:05 [ArtB]
... We need a consistent model here
11:23:20 [ArtB]
... and a simple model
11:23:33 [ArtB]
... but very clear on these issues
11:23:50 [ArtB]
... Don't want to have an unexpected consequences
11:24:32 [ArtB]
Mark: we are certainly open to reformulating this text
11:25:06 [ArtB]
... Perhaps we need to flesh out the details of this req
11:25:54 [Bryan_Sullivan]
Bryan_Sullivan has joined #wam
11:25:55 [ArtB]
... We have some error cases that must be addressed
11:26:04 [ArtB]
... I will investigate CRL lists
11:26:27 [ArtB]
... Think we should continue discussions over e-mail
11:26:52 [drogers]
drogers has joined #wam
11:26:59 [ArtB]
TR: I understand your concerns Marks
11:27:27 [ArtB]
... but we need some additional text re the CRL handling
11:28:05 [ArtB]
... There are also some deployment concerns re revocation
11:28:17 [ArtB]
... we need to think about those issues too
11:30:03 [ArtB]
TR: is there a different UC re revocation then the "normal" ones?
11:30:35 [ArtB]
AB: Mark, what are the next steps for this req?
11:30:49 [ArtB]
Mark: encourage people to discuss on the public mail list
11:31:16 [ArtB]
... I will take the lead on reformatting the text
11:31:30 [ArtB]
AB: Mark, Thomas - is there some Use Case work that needs to be done?
11:31:38 [tlr]
That background explanation would be useful, indeed.
11:31:39 [ArtB]
Mark: I can elaborate on the justification
11:31:56 [ArtB]
TR: yes, I think some background info would be useful
11:32:44 [marcos]
MC: yes, they seem mostly ok
11:32:46 [ArtB]
Mark: are people OK with the proposed rationale in our input?
11:32:57 [marcos]
zakim, unmute me
11:32:57 [Zakim]
marcos was not muted, marcos
11:33:35 [ArtB]
Topic: R38 Addtional Digital Certs
11:33:55 [ArtB]
AB: R38:
11:34:33 [arve]
11:34:43 [ArtB]
Mark: there is some interaction here with the security policy and root certs
11:34:44 [arve]
11:34:59 [ArtB]
... need a mechanism to define the relationship
11:35:26 [ArtB]
Marcos: I think the proposal is good
11:36:36 [ArtB]
Arve: if the engine has a mechanism for installing or uninstalling a root cert, then I think a MAY is sufficient
11:37:13 [ArtB]
Mark: need to be more explicit about the relationship between the root cert and security policy
11:38:47 [ArtB]
Mark: in BONDI expect a hook between a root cert and a security policy
11:39:15 [ArtB]
... root certs will have different trust levels
11:39:20 [arve]
Do we need to define a method to define/export trust level/security configuration for certificates? What would this need to look like?
11:40:08 [ArtB]
Mark: we haven't made a final decision on the various approaches we have talked about
11:40:23 [ArtB]
... would like to get some feedback on this issue
11:41:06 [ArtB]
... This is a broader issue then just widget signatures
11:41:28 [ArtB]
TR: we are moving into much larger secuity models
11:42:05 [ArtB]
... I don't think those type of broad policy models should be in scope for the signature spec
11:42:59 [ArtB]
... Say "can install root certs; there may or not be restrictions on how they are used" but perhaps not a lot more
11:43:12 [ArtB]
Arve: I tend to agree
11:43:21 [ArtB]
... the issue is more about trust delegation
11:43:34 [ArtB]
TR: it's also about how you shape the market
11:43:35 [drogersuk]
drogersuk has joined #wam
11:43:48 [ArtB]
... suggest a relatively dry model
11:44:08 [ArtB]
... and not try to address broad policy issues
11:44:17 [ArtB]
Mark: I also tend to agree with Thomas
11:44:55 [ArtB]
... The topic does need to be addressed i.e. security policy and we will continue to work on it in BONDI
11:45:28 [ArtB]
AB: so where do we stand on this req?
11:45:38 [ArtB]
Mark: think we need to refine the wording
11:45:56 [ArtB]
... And also address Thomas' concerns
11:47:11 [tlr]
Trust in a root certificate is established through a security critical mechanism that is out of scope for this specification.
11:47:31 [ArtB]
Mark: this discussion is also relevant to R43
11:48:26 [ArtB]
TR: a problem with policies here is that the industry is doing different things here
11:48:43 [ArtB]
... we need to be careful not to go in YA direction
11:49:17 [ArtB]
Mark: we need to define some behavior
11:49:29 [ArtB]
Marcos: yes, the engines are doing different things
11:49:45 [ArtB]
... Arve already posted their model
11:51:54 [ArtB]
Topic: Proposed Requirements
11:52:04 [ArtB]
AB: how do we want to address these?
11:52:10 [Bryan_Sullivan]
11:52:13 [ArtB]
Marcos: I think they are mostly good
11:52:19 [ArtB]
... and I can add them as is
11:52:24 [arve]
11:52:26 [drogers]
drogers has joined #wam
11:52:37 [ArtB]
Mark: Thomas submitted some reqs
11:52:56 [ArtB]
... Signing Procedure Agnostic is one TR responded to and I'd like to take it first
11:53:28 [ArtB]
Bryan: the MWBP WG also propsed some new reqs
11:54:42 [ArtB]
... have they been received?
11:54:48 [ArtB]
Marcos: yes, I saw them
11:54:52 [tlr]
marcos, URI?
11:54:59 [ArtB]
... I haven't had time yet to read them in detail
11:55:14 [ArtB]
... I will respond soon-ish
11:55:49 [ArtB]
Topic: Signing Procedure Agnostic
11:55:51 [marcos]
tlr... getting it.
11:56:12 [marcos]
tlr :
11:56:29 [marcos]
11:56:41 [ArtB]
Mark: I think this req needs some clarification
11:57:14 [ArtB]
... we expect scenarios with different Actors involved
11:57:33 [marcos]
MC: Here is link to Arve's security input:
11:58:29 [ArtB]
AB: Thoma's comments on this:
11:58:53 [tlr]
11:59:28 [ArtB]
Mark: we need to decide what is mandatory to support
12:00:06 [ArtB]
... Re PKCS#11 interface, it is being used today
12:00:20 [ArtB]
... thus we see a need for some interop
12:01:13 [ArtB]
TR: so the req is "don't mess up the ability for smart card to be used"
12:01:22 [ArtB]
... on the face, it make sense
12:01:34 [ArtB]
... But what does this req actually apply to?
12:02:02 [ArtB]
... e.g. does it apply to every crypto mech that could be plugged in
12:02:29 [ArtB]
... Need some examples; what are the challenges.
12:03:09 [ArtB]
Mark: those are good points
12:03:24 [Bryan_Sullivan]
12:03:31 [marcos]
12:03:42 [tlr]
Put differently, this may be a slam-dunk or a major problem. I suspect slam-dunk, but I'd like to be sure of that.
12:03:52 [ArtB]
ACTION: Mark create some motiviation and examples for the proposed Signing Procedure Agnostic requirement
12:03:52 [trackbot]
Created ACTION-22 - Create some motiviation and examples for the proposed Signing Procedure Agnostic requirement [on Mark Priestley - due 2008-08-14].
12:04:16 [tlr]
12:04:17 [tlr]
12:04:55 [ArtB]
Marcos: not clear what the WG will do with this input
12:05:04 [arve]
12:05:14 [ArtB]
Mark: I think we may need to break it down a bit
12:05:47 [ArtB]
... we need to make sure we don't break existing mechanisms
12:06:23 [arve]
12:06:29 [marcos]
12:07:25 [tlr]
12:07:42 [ArtB]
Marcos: should we establish a more formal liaison with XML Security?
12:07:49 [ArtB]
AB: I think that make sense
12:07:58 [ArtB]
... after we have fine-tuned the signature reqs
12:08:16 [ArtB]
TR: I can help liaise with the XML Security WG
12:08:39 [ArtB]
... when we understand the PKCS#11 req better, we should discuss it with XML Sec
12:09:15 [mpriestl]
12:09:23 [tlr]
12:09:25 [claudio]
12:09:37 [drogersuk]
drogersuk has joined #wam
12:10:09 [ArtB]
Mark: perhaps some of our proposed reqs are more appropriate for the XML Sec WG to address
12:11:12 [ArtB]
Claudio: in general we'd like OMTP to provide some clearer Use Cases
12:11:22 [ArtB]
... we think it would facilitate the discussion
12:11:35 [tlr]
+1 to Claudio, actually
12:11:42 [ArtB]
... would also help us understand whether or not the reqs are out of scope or in scope
12:11:46 [mpriestl]
12:12:24 [ArtB]
Mark: we have provided rational for some of the reqs
12:12:53 [ArtB]
... It would be better if people were mor explicit about which reqs need more information
12:13:42 [ArtB]
Claudio: the rationale is good but security models and policy are quite broad and knowing specific Use Cases would be very helpful
12:13:54 [ArtB]
... again to help with "scope" related issues
12:13:56 [drogers]
drogers has joined #wam
12:14:26 [ArtB]
... having the Use Cases more explicit now should actually make the spec work go quicker
12:14:52 [ArtB]
Topic: AOB
12:15:12 [ArtB]
TR: when is the next conf call?
12:15:20 [ArtB]
AB: next week; same time
12:15:27 [ArtB]
AB: End of Meeting
12:15:29 [Zakim]
12:15:30 [Zakim]
12:15:33 [Zakim]
12:15:34 [Zakim]
12:15:34 [Zakim]
12:15:37 [claudio]
12:15:43 [Luca]
12:15:44 [Zakim]
12:15:52 [ArtB]
RRSAgent, make logs Public
12:15:57 [Luca]
Luca has left #wam
12:16:15 [ArtB]
RRSAgent, make minutes
12:16:15 [RRSAgent]
I have made the request to generate ArtB
12:17:27 [Zakim]
12:18:13 [Zakim]
12:18:15 [Zakim]
IA_WebApps(Widgets)7:00AM has ended
12:18:16 [Zakim]
Attendees were +44.207.070.aaaa, +44.771.751.aabb, Art_Barstow, +39.011.228.aacc, Claudio, +44.771.751.aadd, marcos, Mark, Thomas, David, +47.23.69.aaee, arve, Bryan_Sullivan
12:21:39 [ArtB]
RRSAgent, bye
12:21:39 [RRSAgent]
I see 2 open action items saved in :
12:21:39 [RRSAgent]
ACTION: Barstow passport is required for Turin f2f meeting [1]
12:21:39 [RRSAgent]
recorded in
12:21:39 [RRSAgent]
ACTION: Mark create some motiviation and examples for the proposed Signing Procedure Agnostic requirement [2]
12:21:39 [RRSAgent]
recorded in