<trackbot-ng> Date: 07 May 2008

<Mez> http://www.w3.org/2006/WSC/Group/cheatsheet#Scribing

<johnath> ScribeNick: bill-d

<Mez> http://www.w3.org/2008/04/30-wsc-minutes.html

Mez: approve last meeting minutes

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0001.html

Mez: open action items
... no issues pending

<scribe> ... closed items due to inactivity

tlr: is this item going to resurface?
... does phil need to take a second look

mez: agenda bashing, isue 133 what about that plug in stuff, 181 http - http3, 183 automatic self signed, 190 relaxing relaxed path

<Mez> http://lists.w3.org/Archives/Member/member-wsc-wg/2008May/0000.html

mez: other issues are listed in f2f, if we have other issues should be brought up now

<Mez> issue-133?

<trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the Robustiness section interact? -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/133

mez: pick up on issue 133 plug in issues
... email from Joesteele on issue 133

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0218.html

joesteele: definition of web page in regards to plug ins was to tight, should be more general, second item answers question about robustness and plugins interact
... existing security plugins, do they need to conform

mez: 133 may need more discussion and taken to f2f. original approach was lowbar. at least should say plugins could undermine security model of browsers
... and joe has raised questions and text questioning this practice.
... question is if the text is clear, crisp enough to change the set of recomendations in terms of robustness and compliance

ifette: it is often not possible for browser to know what the plug-in is doing. plugins can invalidate the IA model of browser and that is what it is

<yngve> Opera includes all plugin requests through Netscape

<yngve> API (via browser) when evaluating security level for the document.

joesteele: in regards to what yngve said, user agent may not know what plugin is doing, but not sure if this should be the way plugins should work.

<yngve> (That does not mean we are able to tell or include everything the plugin does in the state)

joesteele: IE has a way to be notified and should the issue be raised. looking at cardspace, cardspace greys out the background and security details that may be present

<Mez> Mez' reply to Joe

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0018.html

<Mez> Joe's mail:

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0015.html

ifette: wsc may not be the place to suggest changes to the plugin api

<Zakim> Mez, you wanted to say I liked the idea of allowing plug ins to be compliant

phb2: part of the plugin architecture should have the capability to not IA details

mez: concept that joe brought forward that seemed agreeable was to note how well behaved plugins met WSC guidance

joesteele: regard cardspace as an external system but triggered by browser, are external systems part of WSC guidance, because they are launched by the browser.

ifette: out of system text is in WSC text because of acrobat reader.all of the processing is taken on by acroreader. same as windows media player. browser is not informed of security status

<johnath> Mez: fwiw, I'm silent here because I'm thinking about it - I will be in Oslo though, so I hope to have a considered opinion by then :)

mez: if anyone has strong opinion on subject please take it on, request from joesteele to make additional email comments and clarify via email thread.

<Mez> issue-181?

<trackbot-ng> ISSUE-181 -- Should there be an authoring practice suggesting http/https URI space consistency -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/181

mez: on to issue 181
... http - https sharing same uri space, and consistent uri schem

<Zakim> ifette, you wanted to axe this text

mez: how users should get security context be obtained - available from https / http

<yngve> https://www.spv.no/

<Zakim> johnath, you wanted to probably agree with ifette, depending on what he says

ifette: original though was http site, https site should be consistent -

<ifette> +1

johnath: don't think we need standard language around how the uri should be managed

<joesteele> +1

tlr: proposed handling for man in the middle attacks, looking for tyler to further define how the issue should be defined

mez: move the issue to after june
... issue 181

<Mez> issue-183?

<trackbot-ng> ISSUE-183 -- Automatic Selfsigned Certificate acceptance/probation MUST NOT be implemented unless there is a history capability -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/183

mez: on to issue 183 self signed certificate
... question on self signed certificates and pinning them

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

tlr: 5.5.1 may support pinning through some interaction
... two choices user agent may use a notification that allows accept cert with pinning
... may use notification or should - not must

mez: given how is stands a user agent could achieve conformance and automatically accept self signed cert, - does this change to must?

tlr: change should to must to conform with yngve proposal

<joesteele> +q

mez: proposal to change 5.5.1 from should to must, does anyone object

joesteele: likes wording but had question may provide mechanisim to pinning, can an automatic mechanism be in place that includes something like a whitelist

johnath: cut them from your own ca and it will be trusted

tlr: language in 5.5.1 applies to self signed cert that does not lead to a trusted root certificate.
... a technically self signed cert is validated, a degenerate case. the locallly configured trust root is used by the server in the tls transaction. noted as a poor practice

<tlr> ACTION: thomas to propose language for SSC section that covers "locally configured trust anchor is actually shown by server" edge case - due 2008-06-07 [recorded in http://www.w3.org/2008/05/07-wsc-minutes.html#action01]

<trackbot-ng> Created ACTION-427 - propose language for SSC section that covers \"locally configured trust anchor is actually shown by server\" edge case [on Thomas Roessler - due 2008-06-07].

yngve: a mechanism that the certificate has been used, accepted before by the user

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

mez: after clarification from yngve 5.5.1 tls error - change item 4 from should to must.

tlr: generic issue if error signaling for non interactive user agents would be non compliant

<tlr> When this specification speaks of a "Web user agent" to describe the application through which a user interacts with the Web, then this term is used on a conceptual level: No assumption is made about implementation details; the "Web user agent" may denote a combination of several applications, extensions to such applications, operating system features, and assistive technologies.

<tlr> That, to me, means that non-interactive user agents are simply out of scope.

<tlr> (thinking about it for a moment more)

tlr: confused about non interactive user agent, wsc defines user agent as interactive. and this may need additional clarification
... if we have another mechanism to determine if cert is trusted

joesteele: question on f the note is compete to define this issue

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates

<Mez> so, joesteele, can you look at the reference and let us know if you've got a case you think that doesn't cover?

yngve: going back to tlr comments on user interaction. where user has set up prefetching

<Zakim> ifette, you wanted to talk to yngve's point abouit prefetching

yngve: user notes pages to be looked and and browser fills up cache

<tlr> yeah, just don't prefetch, but fetch in realtime

ifette: if client is prefetching, browser should not prefetch broken http

<tlr> +1, but I think we don't have to talk about it

mez: on the table txt 183 change should to must

<ifette> 3

<Mez> A) first line http://www.w3.org/2006/WSC/track/issues/183

<tlr> If a client is able to automatically accept a Selfsigned Certificate, or recover from similar problem without user interaction, it MUST NOT do so unless the client also have a history mechanism about security information.

<Mez> B) change http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors item 4. to MUST

<Mez> C) do nothing

<ifette> I vote C

<tlr> c

<joesteele> c

<Mez> Otherwise, user agents MUST use error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages).

<Mez> zakim's who's here?

<yngve> B is acceptable

c

<tlr> errrrr

<tlr> wait a sec

<johnath> B

<tlr> B

b

<jvkrey> b

<ifette> C

<PHB2> b

<joesteele> C

<asaldhan> B

<johnath> cheese doesn't have the same throughput that mice do

<johnath> (indeed, cheese is famous for slowing urr... throughput)

<jvkrey> beer is typically 50NOK for 0.4 liter

<Mez> B: Yngve, Johnathan, TLR, Bill, Jan Vidar, PHB, Anil

<Mez> C: Ian, Joe

mez: option b, issue 183 item 4 change should to must
... on non interactive agents please further define
... request goes out to wsc wg

<Zakim> asaldhan, you wanted to ask that I need NOK

joesteele: concern is not so much about non interactive but locally configured. the locally configured trust anchors and interaction with unsigned certificates

tlr: assumption self signed certificate could be trust anchor and part of the trust chain
... not always but sometimes can be trust anchor

mez: tlr will rewrite text, tlr and joesteele appear to be in agreement

<asaldhan> ACTION: asaldhan to incorporate above def to spec [recorded in http://www.w3.org/2008/05/07-wsc-minutes.html#action02]

<trackbot-ng> Created ACTION-428 - Incorporate above def to spec [on Anil Saldhana - due 2008-05-14].

<Mez> issue-190?

<trackbot-ng> ISSUE-190 -- Relaxed Path Validation - optional, recommended? -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/190

mez: issue 190

ifette: had time to think about it, relaxed path validation, browsers fine to handle certs in two different ways. but it could be confusing if browsers can validate using differnet ways

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-pathval

<tlr> When, for a TLS-protected HTTP connection, the certificate presented is found to have been expired, error signalling of class danger (6.4.4 Danger Messages) MUST be used. Note that user agents that apply Relaxed Path Validation to non-AA certificates will never detect this error condition for such certificates.

<Mez> as well as all of 5.4

tlr: text is in 5.5.1

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates

tlr: 5.1.3 may use relaxed validation
... as well as 5.1.2

<tlr> User agents MUST NOT use Relaxed Path Validation to validate paths that lead to an AA-qualified trust root. Instead, Basic Path Validation MUST be used.

<tlr> User agents MAY use Relaxed Path Validation for certificate paths that chain up to a locally configured trust anchor which is not AA-qualified.

tlr: question to ian - if we were to drop relaxed path validation what is the message to user?

ifette: user should get a modal warning

tlr: warning - not danger, danger does not let the user through

mez: clarify error and warning messages
... as to what generates warnings / errors

<tlr> sorry

<tlr> danger is explicit for domain mismatch

<tlr> When the URL corresponding to the transaction at hand does not match the certificate presented, and a validated certificate is used, then error signalling of level danger(6.4.4 Danger Messages) MUST be used.

PHB: starting to agree to punt the relaxed text

<ifette> ISSUE: Domain name mismatch should be a WARNING and not a DANGER interaction

PHB: agree with ifette

tlr: would like to have a followup discussion, let it mature and take it up at f2f

<yngve> Mez: http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0039.html

tlr: continue on mailing list

<johnath> ifette: don't think trackbot-ng noticed that, for some reason

<yngve> Oslo Social at http://www.sult.no/englishinformation.cfm

<johnath> oh, you've noticed that :)

tlr: next meeting is the f2f
... representitive from microsoft will be observing on second day

<ifette> I is only sometimes a vowel?

<ifette> :-)

<Mez> :-)

<Mez> wow, good question ian

<Zakim> asaldhan, you wanted to tlr

<asaldhan> Mez: ignore

<Mez> sorry

<Mez> maybe you can ping him on IRC

<asaldhan> Mez: that is what I am doing now. :)

<johnath> Mez: I forget, when do you get in again?

<asaldhan> johnath: I get in Sunday around 1pm

<Mez> Monday mid day; I'm not going to put in that extra day to frisk about after all

<johnath> asaldhan: probably about the same for me - have to recheck that itinerary

<ifette> I get in sunday around 5

<Mez> http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

<asaldhan> I had to book saturday as it was a difference of 700 dollars

<ifette> arrives OSL 4:35pKL

<ifette> KL1147 arrives 4:35p that is

<Mez> if you put it inthe wiki you only have to type it once :-)

<ifette> i didnt see a page on wiki for that

<jvkrey> monday is a public holiday in norway, so shops are closed, btw

<Mez> http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

<Mez> iane

<Mez> Ian

<Mez> that's the wiki

<Mez> page

<Mez> which I sent out in email

<Mez> http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

<asaldhan> I cannot edit it

<asaldhan> how do I edit it?

<Mez> have you ever edited the wiki?

<asaldhan> yes

<Mez> did you ever get your name on the ACL t

<Mez> ?

<Mez> then it's just like that

<asaldhan> I do not think it is on the acl

<Mez> see Edit(Text) at the bottom?

<Mez> if not, check with tlr about the acl

<asaldhan> ok

<asaldhan> pinging tlr

what has to happen to scribe notes?

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: bill-d
Inferring Scribes: bill-d

WARNING: No "Topic:" lines found.

Default Present: MaryEllen_Zurko, Bill_Doyle, johnath, jvkrey, ifette, Thomas, yngve, joesteele, PHB, +1.708.524.aaaa, asaldhan
Present: MaryEllen_Zurko Bill_Doyle johnath jvkrey ifette Thomas yngve joesteele PHB +1.708.524.aaaa asaldhan
Regrets: Tim H

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 May 2008
Guessing minutes URL: http://www.w3.org/2008/05/07-wsc-minutes.html
People with action items: asaldhan thomas

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report