W3C home > Mailing lists > Public > public-wsc-wg@w3.org > December 2007

Meeting record: 2007-11-28

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 19 Dec 2007 19:55:38 +0100
To: public-wsc-wg@w3.org
Message-ID: <20071219185538.GA25929@iCoaster.does-not-exist.org>

Minutes from our meeting on 2007-11-28 were approved and are
available online here:


A text version is included below the .signature.

Thomas Roessler, W3C  <tlr@w3.org>


                                   - DRAFT -

               Web Security Context Working Group Teleconference
                                  28 Nov 2007


   See also: [3]IRC log


          luis,rachna,schutzer,serge,stephenf,tjh,tlr,tyler,yngve, jvkrey

          Johnathan_N, Tim_H




     * [4]Agenda
         1. [5]mintues approval
         2. [6]Newly completed action items
         3. [7]Open action items
         4. [8]Agenda bashing
         5. [9]Issue-111: login form interactions
         6. [10]Issue-114: self-signed certificate changeover
     * [11]Summary of Action Items

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

   <trackbot-ng> [12]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
   ... anything else?

   <Mez> [13]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
   ... 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

   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

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


   <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> [14]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> [15]http://www.w3.org/2006/WSC/drafts/rec/#selfsignedcerts

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

   ifette: I was aware of displaying an error, but why a ban on a

   <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

   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

   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

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

   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

   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

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

   <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

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

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

   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

   <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

Summary of Action Items

   [NEW] ACTION: tlr to request ISSUE-1144 on f2f agenda - due 2008-01-15
   [recorded in


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0122.html
   3. http://www.w3.org/2007/11/28-wsc-irc
   4. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0122.html
   5. http://www.w3.org/2007/11/28-wsc-minutes.html#item01
   6. http://www.w3.org/2007/11/28-wsc-minutes.html#item02
   7. http://www.w3.org/2007/11/28-wsc-minutes.html#item03
   8. http://www.w3.org/2007/11/28-wsc-minutes.html#item04
   9. http://www.w3.org/2007/11/28-wsc-minutes.html#item05
  10. http://www.w3.org/2007/11/28-wsc-minutes.html#item06
  11. http://www.w3.org/2007/11/28-wsc-minutes.html#ActionSummary
  12. http://www.w3.org/2006/WSC/track/actions/331
  13. http://www.w3.org/2006/WSC/track/issues/111
  14. http://www.w3.org/2006/WSC/track/issues/114
  15. http://www.w3.org/2006/WSC/drafts/rec/#selfsignedcerts
  16. http://www.w3.org/2006/WSC/drafts/rec/#errors-basic
  17. http://www.w3.org/2007/11/28-wsc-minutes.html#action01
  18. http://www.w3.org/2007/11/28-wsc-minutes.html#action01

Thomas Roessler, W3C  <tlr@w3.org>
Received on Wednesday, 19 December 2007 18:55:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:51 UTC