Widgets Voice Conference -- 07 Aug 2008

Date: 7 August 2008

<scribe> Scribe: Art

<tlr> whooops

<scribe> ScribeNick: ArtB

<tlr> zaim, I am thomas

<marcos> I would never!

<marcos> :)

<marcos> oh crap. I'll dial in again.

<marcos> tlr, was it me?

<marcos> hmmm...., there is nothing next to me or any other device. Will dial in again

Agenda Review

AB: Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0318.html

<marcos> any better?

<marcos> bah!

<arve> doesn't zakim have some function to see who's making noise?

<tlr> gah

<tlr> zkaim, ??P8 is marcos

AB: any change requests for the agenda

<marcos> hmmm... sorry about this.

AB: [none]

Annoucements

AB: registration for the Turin f2f is open; please register ASAP
... http://www.w3.org/2006/appformats/group/TurinF2F/Participants

Claudio: must bring a Passport or valid ID
... company badge is probably not going to work

<tlr> I hope there is no NDA coming along with the ID requirement.

<scribe> ACTION: Barstow passport is required for Turin f2f meeting [recorded in http://www.w3.org/2008/08/07-wam-minutes.html#action01]

<trackbot> Created ACTION-21 - Passport is required for Turin f2f meeting [on Arthur Barstow - due 2008-08-14].

R11 Digital Signatures

AB: OMTP input http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0308.html
... request mods to several signature reqs and propose some new reqs
... who is going to lead the OMTP discussion?

David: Mark will lead the tech discussion

AB: the proposal expands on the existing text in R11

Mark: we think the req needs some clarifications
... we also propose additional behavior e.g. when there are signature chains
... need to say what the client will do in various scenarios
... need consistent behavior
... need to say what happens if the chain can't be verified
... e.g. if missing root cert
... e.g. if cert is expired
... we suggest the Widget should be considered unsigned

Arve: I'm concerened about treating the resource as valid
... it could encourage unsafe behavior by the user
... Some users aren't qualified to "make the right decision"

<marcos> MC: I share Arve's concerns.

Arve: e.g. is it safe to treat the package as safe

<marcos> MC: and by unsigned, what do you mean?

Mark: if the widget is not signed, it should never be presented as if it is signed

Arve: need to clarify unsigned versus invalid
... an invalid widget should not be launchable

Mark: if the root cert is missing we want the widget to still be launchable but just not as a "signed" widget

<marcos> MC: hmmmm.... this results in "security profiles"

Mark: we don't want additional security privs for an unsigned widget

TR: want to consider the proposed addition in one piece
... If none of the parts can be verifed, treat as unsigned
... have a couple of concerns
... should install continue if there some part cannot be verified or fails verification
... Need to address revoked/unrevoked versus expired
... We need a consistent model here
... and a simple model
... but very clear on these issues
... Don't want to have an unexpected consequences

Mark: we are certainly open to reformulating this text
... Perhaps we need to flesh out the details of this req
... We have some error cases that must be addressed
... I will investigate CRL lists
... Think we should continue discussions over e-mail

TR: I understand your concerns Marks
... but we need some additional text re the CRL handling
... There are also some deployment concerns re revocation
... we need to think about those issues too
... is there a different UC re revocation then the "normal" ones?

AB: Mark, what are the next steps for this req?

Mark: encourage people to discuss on the public mail list
... I will take the lead on reformatting the text

AB: Mark, Thomas - is there some Use Case work that needs to be done?

<tlr> That background explanation would be useful, indeed.

Mark: I can elaborate on the justification

TR: yes, I think some background info would be useful

<marcos> MC: yes, they seem mostly ok

Mark: are people OK with the proposed rationale in our input?

R38 Addtional Digital Certs

AB: R38: http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/#r38.-

Mark: there is some interaction here with the security policy and root certs
... need a mechanism to define the relationship

Marcos: I think the proposal is good

Arve: if the engine has a mechanism for installing or uninstalling a root cert, then I think a MAY is sufficient

Mark: need to be more explicit about the relationship between the root cert and security policy
... in BONDI expect a hook between a root cert and a security policy
... root certs will have different trust levels

<arve> Do we need to define a method to define/export trust level/security configuration for certificates? What would this need to look like?

Mark: we haven't made a final decision on the various approaches we have talked about
... would like to get some feedback on this issue
... This is a broader issue then just widget signatures

TR: we are moving into much larger secuity models
... I don't think those type of broad policy models should be in scope for the signature spec
... Say "can install root certs; there may or not be restrictions on how they are used" but perhaps not a lot more

Arve: I tend to agree
... the issue is more about trust delegation

TR: it's also about how you shape the market
... suggest a relatively dry model
... and not try to address broad policy issues

Mark: I also tend to agree with Thomas
... The topic does need to be addressed i.e. security policy and we will continue to work on it in BONDI

AB: so where do we stand on this req?

Mark: think we need to refine the wording
... And also address Thomas' concerns

<tlr> Trust in a root certificate is established through a security critical mechanism that is out of scope for this specification.

Mark: this discussion is also relevant to R43

TR: a problem with policies here is that the industry is doing different things here
... we need to be careful not to go in YA direction

Mark: we need to define some behavior

Marcos: yes, the engines are doing different things
... Arve already posted their model

Proposed Requirements

AB: how do we want to address these?

Marcos: I think they are mostly good
... and I can add them as is

Mark: Thomas submitted some reqs
... Signing Procedure Agnostic is one TR responded to and I'd like to take it first

Bryan: the MWBP WG also propsed some new reqs
... have they been received?

Marcos: yes, I saw them

<tlr> marcos, URI?

Marcos: I haven't had time yet to read them in detail
... I will respond soon-ish

Signing Procedure Agnostic

<marcos> tlr... getting it.

<marcos> tlr : http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0298.html

<marcos> and http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/att-0298/MWBP_comments_to_Widget_Requirements_Last_Call_WD.htm

Mark: I think this req needs some clarification
... we expect scenarios with different Actors involved

<marcos> MC: Here is link to Arve's security input: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0332.html

AB: Thoma's comments on this: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0325.html

Mark: we need to decide what is mandatory to support
... Re PKCS#11 interface, it is being used today
... thus we see a need for some interop

TR: so the req is "don't mess up the ability for smart card to be used"
... on the face, it make sense
... But what does this req actually apply to?
... e.g. does it apply to every crypto mech that could be plugged in
... Need some examples; what are the challenges.

Mark: those are good points

<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.

<scribe> ACTION: Mark create some motiviation and examples for the proposed Signing Procedure Agnostic requirement [recorded in http://www.w3.org/2008/08/07-wam-minutes.html#action02]

<trackbot> Created ACTION-22 - Create some motiviation and examples for the proposed Signing Procedure Agnostic requirement [on Mark Priestley - due 2008-08-14].

Marcos: not clear what the WG will do with this input

Mark: I think we may need to break it down a bit
... we need to make sure we don't break existing mechanisms

Marcos: should we establish a more formal liaison with XML Security?

AB: I think that make sense
... after we have fine-tuned the signature reqs

TR: I can help liaise with the XML Security WG
... when we understand the PKCS#11 req better, we should discuss it with XML Sec

<claudio> +q

Mark: perhaps some of our proposed reqs are more appropriate for the XML Sec WG to address

Claudio: in general we'd like OMTP to provide some clearer Use Cases
... we think it would facilitate the discussion

<tlr> +1 to Claudio, actually

Claudio: would also help us understand whether or not the reqs are out of scope or in scope

Mark: we have provided rational for some of the reqs
... It would be better if people were mor explicit about which reqs need more information

Claudio: the rationale is good but security models and policy are quite broad and knowing specific Use Cases would be very helpful
... again to help with "scope" related issues
... having the Use Cases more explicit now should actually make the spec work go quicker

AOB

TR: when is the next conf call?

AB: next week; same time
... End of Meeting

<claudio> quit

<Luca> quit

- DRAFT -

Widgets Voice Conference

07 Aug 2008

Attendees

Contents