mintues approval

yngve: questions about the flash case

stephenF: I took it out

<tlr> <yngve> [pointed out a flash-only site with mixed content]

Mez: No other issues?

<tlr> RESOLVED: minutes apporved

Newly completed action items

Mez: Newly completely action items
... thanks to Maritza, Yngve, and Hal

<asaldha1> I will be back

<tlr> ACTION-331?

<trackbot-ng> ACTION-331 -- Maritza Johnson to work toward worked example of usability testing for conformance -- due 2007-11-23 -- CLOSED

<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/331

Open action items

Mez: no more discussion on action items?
... we'll go through and identify next steps along with approving and reading through

ifette: I'm lazy and want a link I can double click, because although I read my email I archive it and don't want to switch away from IRC to search for that email, please help me

Agenda bashing

Mez: issue with reconfiguring primary chrome, trouble parsing potential proposal
... anything else?

<Mez> http://www.w3.org/2006/WSC/track/issues/111

Issue-111: Login form interactions

Mez: ISSUE: 111, login form interactions

Mez: PII editor bar, browser components for login interactions

ifette: change the issue for less material
... I'll create a new issue

tlr: typical login interaction is more constrained than general form interaction
... maybe a more constraining behavior?

PHB2: make the web a safe place for credit cards vs. never entering them and authenticate other ways
... we should look at the second approach
... not practical for a system with a safe mode

<Mez> there's some quote about german banks in our kickoff workshop (were you there?) on iTAN

<tlr> iTan is an authorization nonce for a particular transaction that you get out of band

tlr: close to some aspects of the bar

<tlr> I'm only talking UI level for repeated interactions, not protocol level.

PHB2: cardspace solves this but isn't adopted

<serge> except that cardspace doesn't work...

<tlr> e.g., I don't want to have a text entry field activated when I hit HTTP auth

PHB2: leading a way to have more secure components as they become available

<Zakim> stephenF, you wanted to ask what auth protocol tlr means

stephenF: tlr please elaborate

tlr: we have heuristics for the form-based password case
... if we have an easily-recognized UI (maybe tied to certs), it's more difficult to login to a phishing site

stephenF: if we can give guidance, maybe w/ heuristics, we can help users with entering stuff on phishing sites

ifette: if not legitimate/unknown interaction, it's very difficult to determine legitimacy
... but others say users will become accustomed!

still is #1

<stephenF> what I meant to say was more "this would be worthwhile iff it helped users not enter credentials to phishing sites"

tlr: reliance on habituation is a generic argument

serge: bigger problem is users don't understand domain names

Mez: can you, tlr, do a proposal?

tlr: <waffling>uhhhhhh....responsibility! no!!!</waffling

err, "I'll try"

<ifette> :-)

<rachna> aren't we supposed to have a discussion of PII (a walk through of the usability analysis) soon?

aww

<rachna> I thought Tyler volunteered last time

Mez: issue? action item? won't somebody please think of the children?!

<tlr> yes

Mez: I feel good about 111 next steps?
... moving on...issue 114

Issue-114: self-signed certificate changeover

<Mez> http://www.w3.org/2006/WSC/track/issues/114

Mez: self signed certificate changeover

tlr: if they use a self-signed cert for a while, we trust it, but what if it changes?
... maybe a better indicator for a ca-signed?

<stephenF> section 5.3.3 maybe

tlr: I would like to listen to Ian, but not really

<tlr> http://www.w3.org/2006/WSC/drafts/rec/#selfsignedcerts

<tlr> http://www.w3.org/2006/WSC/drafts/rec/#errors-basic

ifette: I was aware of displaying an error, but why a ban on a click-through?

<Zakim> stephenF, you wanted to say this is just hard

stephenF: it's a hard problem, how do we distinguish?

<serge> what do we mean by a "hard error"?

Mez: I need a sequence of prototypes for these recommendations
... just a heads up, since we'll need it to close the recommendations

PHB2: this is why we need no-interaction certificates

stephenf: I disagree, many are just looking for encryption

PHB2: I agree it's not an answer to the issue, but what about embedded devices?

so that's a place for a self-signed cert....

<stephenF> what's domain-validation?

PHB2: the question becomes what you get by not paying for a certificate

<stephenF> answer MUST NOT be paying is required for user interaction IMO

PHB2: everyone should give money to Verisign

stephenF: some folks of modest means need other options when there little need to pay a CA

<stephenF> doesn't address re-install from scratch

PHB2: we should have a hierarchy
... one self-signed root per site, most folks will keep it for many years

bill-d: many intranets use self-signed certs

<stephenF> your welcome

<serge> install the roots

ifette: install the roots

<stephenF> radio waves tunnel through tlrs head

tlr: sitting next to a wireless router, accessing by HTTPS
... after accessing it at an IP for a while, it should trust it

<stephenF> +1 to accomodating as well as we can

<serge> if it only trust a self-signed cert after a while, it's going to confuse a lot of users.

<stephenF> don't think sub-op[timal is the right phrase here

<tlr> in that case, MAY have click-through

schutzer: another aspect is what happens when certs are updated?

serge: two issues: self-signed certs, and certificate consistency

PHB2: I suggested a suboptimal user experience in certain cases, e.g. rollover, but we can eliminate that for cases where we don't want interaction
... we can do things similar to checking programs which haven't been run before, community review, etc.

<stephenF> +1 to different display

<tlr> +1 to that as well

<tlr> (it's in the current spec text, actually)

<stephenF> -1 to "how much authentication" which isn't decidable on the client

tlr: we have self-signed certificates that create a user experience the first time they're displayed

<MikeMc> Mike waves back :)

tlr: error detection when certificate, but we need some assurance that ??? (couldn't hear)

<ifette> 312 is chicagoland?

<ifette> 415 is not yet taken care of...

Mez: any proposed next steps?

<serge> I think we should argue some more

<stephenF> mean or poor or just installed a server that generates an SSC

serge: this shouldn't be about who paid more

<stephenF> +1 to SSCs aren't good here

ifette:SSCs aren't good at some things, they have problems in certain areas. People using them are already accepting these problems, I don't think we need to kill ourselves to try to fix the SSCs to be good at something they are inherently not good at.

<tlr> we don't want to end up in a situation where people are willing to pay $100 for the self-signed certificate experience....

<tlr> sidetrack

tlr: I agree, willingness to pay money doesn't translate

<serge> I'm not sure it has to

stephenF: the argument to just spend money doesn't apply here
... there are people who need SSCs
... we can do something if a new SSC turns up

<Zakim> ifette, you wanted to say if we have to dictate the override experience, or leave that to implementations

ifette:you have already agreed to problems as a trade-off of what you get vs what you can/are willing to pay for, these problems exist, and there's really not anything that we can do for some of them. We should do what we can for things like key-continuitity, but when it breaks, there are known problems and that's one of the trade-offs of using a SSC.

<Mez> +1 to what can you do if you have neither a trust root nor key cont?

<tyler> The difference between a self-signed cert and a self-managed CA is just a small matter of programming.

<tyler> We could tell people to use a self-managed CA

PHB2: it's hard to provide seemless experience and prevent attacks at same time

<Zakim> serge, you wanted to bring up point again about writing down issues of contention

schutzer: follow up step: we liked EV and safe mode because there are too many kinds of certificates
... we need something that browser developers find practical to fully integrate

<stephenF> ...or its just a v. hard problem

<serge> well, I plan on conducting a study, but it's going to be in 6+ months

tyler: this is in the safe web form proposal

<serge> I don't think we should make any recommendations without empirical evidence

tyler: let's not make recs until we test this

<maritzaj> i have to get to another meeting, bye.

ifette: no progress on the issue

<stephenF> mex it remains an "issue" though maybe not an "ISSUE"

Mez: let's close and wait for a better idea

<ifette> I would really like to keep the issue open

tjh: we should handle this with comments

<tlr> +1 tio ifette

<stephenF> +1 to ian

<ifette> It's an issue that we know about

<ifette> we don't have a solution yet, but we know it's an issue :(

<serge> we need data before recommending anything

... this is utterly silly to argue over without it

<ifette> 2008-05-31

<rachna> is anything going to happen between now and 3 months to change the discussion?

<ifette> I just don't want to lose track of it

<tlr> ACTION: tlr to request ISSUE-1144 on f2f agenda - due 2008-01-15 [recorded in http://www.w3.org/2007/11/28-wsc-minutes.html#action01]

<trackbot-ng> Created ACTION-352 - request ISSUE-1144 on f2f agenda [on Thomas Roessler - due 2008-01-15].

<ifette> we didn't get to 115 either, did we?

Mez: we didn't get to 115 or the others, so for next meeting

<ifette> k