See also: IRC log
<trackbot-ng> Date: 30 January 2008
<scribe> ScribeNick: ifette
tlr: f2f next week, see mez's
agenda email
... some draft text low hanging fruit, take a look
... look at editor's draft, and follow-up via email re:
discussion on what can be fast-tracked
... today is poor attendance day
... mez, tjh, hal, phb, et al not here
... current AGENDA
... quick look at wsc-usecases, then ISSUE-131, then ISSUE-130,
then ISSUE-114
... and ISSUE-129
<tlr> http://www.w3.org/2008/01/23-wsc-minutes.html
RESOLUTION: minutes approved
tlr: no closed action items
... tyler, can you give us an update?
tyler: in tracker, only one
action open against note to incorporate tjh's review
... that action is marked pending review, expecting tjh to go
through doc and make sure it's good
... also got an email from Al Gillman, problem when reading
note using screen reader. The table doesn't come out well
... he has people who will contact tyler re: how to reformat
that
... want to turn table into list, tyler not so keen on because
it's not so good pointing out what isn't covered
tlr: what table?
tyler: at the top of the list of scenarios is a table
tlr: takeaway is there is some editorial stuff left, tlr happy to provide help if he can
<tyler> http://www.w3.org/2006/WSC/drafts/note/Overview.html#scenarios
tlr: does tjh know that he's on the hook to review?
tyler: pinged mez, she put it into pending, expecting mez to ping tjh. tlr will email tjh
<tlr> ACTION-376
tyler: it's ACTION-367
<tyler> http://www.w3.org/2006/WSC/track/actions/367
tlr: all for this agendum
ISSUE-131?
<trackbot-ng> ISSUE-131 -- Executing code outside of browser in 8.3.2.3 is vague / scary -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/131
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#techniques-robustness
tlr: some level of agreement in december, on some text
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0116.html
tlr: see this email
... lengthy discussion thread re: plugins and how all of this
applies to plugins
... should we go forward taking effectively a mix of the text
that Mez had proposed in Dec. with the change that Mike had
proposed, or...?
ifette: i have no problem with the text in the email that the link tlr posted contains
tlr: reads text
yngve: would like to see the new
version in written form
... should post somewhere
ifette: already there
tlr: action item to send mail to list
<scribe> ACTION: tlr to send email to list regarding ISSUE-131 containing full text of new proposal, and will close out the issue [recorded in http://www.w3.org/2008/01/30-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-380 - Send email to list regarding ISSUE-131 containing full text of new proposal, and will close out the issue [on Thomas Roessler - due 2008-02-06].
tlr: assuming nobody objects to the email sent out, assume email ready to put to bed
ISSUE-130?
<trackbot-ng> ISSUE-130 -- Trust Anchor Consistency Across Devices? -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/130
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0015.html
tlr: latest proposal from luis posted
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-across-devices
tlr: affected text is here (link
above)
... content doesn't really control the UX
... we should not ask for the same UX
... suggests web content should offer trust and TLS consistency
across UAs
... why doesn't luis introduce last changes
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0015.html
luis: only minor changes to
proposed text, just clarifications
... first one is about user experience
... according to original text, says content should be designed
to offer same UX, that's difficult, propose to change this,
only thing web designers control is trust and TLS consistency,
UX is on client side
tlr: so let me understand
... by the same argument, tls consistency is a UA question as
well
... after all, the UA selects the key of trust roots
... direction is to say that having the same security
experience is a goal which designers should aim for
... disinclined to say TLS and trust anchor consistency
... suggests for first part, instead of "designed to offer"
-> "designed to enable"
... "designed to enable a consistent UX"
luis: maybe something more
releaxed
... enabled more relaxed, better
<tlr> "designed to enable a consistent user experience across..."
tlr: happy to do that
luis: second comment
... about website owners operating tls protected sites should
anticpate mobile use
... may have constrained capabilities OR restricted trust
anchors
... sounds like two options
... but really one is a consequence of the other
yngve: point about certificates,
it is possible for a CA that is not embedded in clients to be
cross-signed by another CA
... similar to EV
tlr: let's keep that out of our
document
... have any concrete proposals?
... my inclination would be to take the text for first comment
as agreed above, and taking luis's second change as is
currently phrased
RESOLUTION: issue closed, move on
tlr: suggests yngve takes issue
to phrase your problem more generally
... and tlr should close out 130
<tlr> ACTION: tlr to change 9.5 in line with ISSUE-130 discussion ago; close issue. [recorded in http://www.w3.org/2008/01/30-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-381 - Change 9.5 in line with ISSUE-130 discussion ago; close issue. [on Thomas Roessler - due 2008-02-06].
<tlr> ACTION: yngve to bring up generic techniques for trust root changeover [recorded in http://www.w3.org/2008/01/30-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-382 - Bring up generic techniques for trust root changeover [on Yngve Pettersen - due 2008-02-06].
ISSUE-114?
<trackbot-ng> ISSUE-114 -- Self-signed certificate changeover -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/114
tlr: what is currently proposed
is a UX that makes cert changeover for SSCs basically
impossible
... how do we deal with it
... any way to have changeover to a different SSC is a way to
have a MITM attack
... no compelling solutions
... ideas?
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-tls-state
yngve: think X509/PKIX had a
mechanism for telling what's the next key/whatever
... problem is that SSCs are going to be made by people not
aware of it
tlr: doesn't fit use case
yngve: might work for some minor
use cases
... not general use case
tlr: can always say that there
should be an interaction that provides ample warning and a
reasonably complex user interaction that makes it hard to
casually accept cert, but we end up having a coin toss between
an attack going through and a new legit cert
... we might in fact be best served by saying MAY do
override
... tempted to throw out that as a proposal for resolution
tyler: will interested parties be at f2f?
tlr: some, some will be on phone
<bill-d> good drop off
tyler: sort of thing that mez was talking about, fast-track?
tlr: no resolution
RESOLUTION: none
<tlr> ISSUE-129?
<trackbot-ng> ISSUE-129 -- Should we say anything about scoring techniques? -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/129
ISSUE-129?
<trackbot-ng> ISSUE-129 -- Should we say anything about scoring techniques? -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/129
scribe: quite a bit of recent discussion
tlr: tjh had proposed a
rewrite
... not sure he sees a rewrite in there
... wonder if current status is to merge in
<Zakim> ifette, you wanted to jump on this issue
ifette: no
... very against merging language into the document
... feel very strongly against SHOULD
... because a non-binary score is useless to users
... changes in score might be useful as a signal that we should
warn something
... but a user seeing some number of bars, a percent, a score,
a meter, is totally useless
tlr: will defer this issue
... thanks for having shown up here
... one of the shorter calls in a while, see some of you next
week in Palo Alto