Meeting record: 2008-03-26

Minutes from our meeting on 2008-03-26 were approved and are
available online here:

   http://www.w3.org/2008/03/26-wsc-minutes.html

A text version is included below the .signature.

-- 
Thomas Roessler, W3C  <tlr@w3.org>




   [1]W3C

               Web Security Context Working Group Teleconference
                                  26 Mar 2008

   See also: [2]IRC log

Attendees

   Present
          Mary Ellen Zurko, Thomas Roessler, Anil Saldhana, Bill Doyle,
          Daniel Schutzer, Ian Fette, Maritza Johnson, Mike McCormick, Jan
          Vidar Krey, Johnathan Nightingale, Phillip Hallam-Baker, Stephen
          Farrell, Tyler Close, Yngve Pettersen,William Eburn

   Regrets
          Tim Hahn

   Chair
          Mary Ellen Zurko

   Scribe
          Anil Saldhana

Contents

     * [3]Topics
     * [4]Summary of Action Items
     __________________________________________________________________



   <trackbot-ng> Date: 26 March 2008

   <Mez> we don't have a scribe

   <tlr_> and my attempts to recruit one failed so far...

   <Mez> fyi, I've called in

   <tlr_> tyler, we're on a different bridge!

   <tyler> Oh, this one seems to be working

   <johnath> what a convenient time for my email client to die!

   <johnath> and I suppose I can't ask zakim for the code, can I?

   <Mez> :-)

   <Mez> right

   <Mez> hold on, I'll let you know

   <johnath> oop - back now

   <johnath> oh, it does my heart good to see "tieline" :)

   <Mez> ha

   <tlr_> oh well, they left again

   <Mez> on the IBM line, it's *6 to mute (or unmute) yourself

   <Mez> but I haven't a clue on how I can mute someone else

   <ifette> no

   <tlr> back...

   <tlr> ScribeNick: asaldhan

   <Mez> [5]http://www.w3.org/2008/03/19-wsc-minutes.html

   Mez: Approving meeting from prev meeting. Link from mez
   ... minutes approved

   <scribe> ... completed action items

   <Mez>
   [6]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0133.html

   Mez: open action items
   ... any issues?
   ... open action items closed due to inactivity
   ... 6) Agenda Bashing
   ... opera booking/hotel issue

   <johnath> sorry zakim

   <ifette> Mez: Agenda bashing

   <ifette> ... will do Yngve re face to face first

   Mez: 7) Version of 6.1 for LC June

   johnath: logotypes issue (7.6) got resolved by email?

   Mez: I think it got resolved too

   johnath: stephen started a discussion about acknowledgements
   ... discussion made minor progress

   Mez: lets nail in oslo.

   <johnath> o_O

   Mez: anything else on agenda bashing
   ... first topic: opera hotel/booking

   yngve: the original rate is wrong (details in email)
   ... the rate is not available via online system but need to send emails
   ... the email address is sent in the member list

   <Mez>
   [7]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Mar/0010.html

   yngve: sorry for not getting the info on online system problem earlier
   ... it works around 160 dollars

   ifette: u can get the conversion from google.

   <ifette> ifette: simply type "870NOK to USD" in Google

   <ifette>
   [8]http://www.google.com/search?source=ig&hl=en&rlz=&q=870NOK+to+USD&bt
   nG=Google+Search

   yngve: any questions regarding oslo

   <ifette> fjords on monday...

   yngve: will send links for sight seeing

   <tlr> s/efening/evening/

   Mez: thanks to yngve for working on the logistics

   <Mez>
   [9]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal

   Mez: get a version of 6.1 ready for lc-june
   ...
   [10]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
   [11]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0051.html
   ... lets do agenda sub bashing
   ... lets talk about the 5 issues and seek feedback

   <PHB2> oh #(&#@$^(&*

   <PHB2> back in a mo

   Mez: 1) screen space

   Issue 1) Requiring a "no identity" state, particularly in primary
   chrome. The text:

   scribe: Issue 2) proposal to remove or downgrade requirement to show
   domain name label
   ... Issue 3) remove otherwise authenticated - resolved Issue 4) remove
   must on displaying CA or keep only for installed trust roots
   ... ISSUE-181

   <Mez> 7.1) The recommendation currently takes up screen real estate
   indicating lack of an identity (which will be a common state): User
   interactions to access this identity signal MUST be consistent across
   all Web interactions facilitated by the user agent, including
   interactions during which the Web user agent has no trustworthy
   information about the [[identity]]of the Web site that a user interacts
   with. In this case, user agents MUST indicate that no information is
   avai

   <PHB2> me yet again

   <Zakim> ifette, you wanted to ask some questions on this

   ifette: 2 qs

   <johnath> (ifette - you're sort of quiet - away from the phone?)

   ifette: 1 question. if we on no-ssl site, is lack of indicator (broken
   padlock etc) conform?
   ... 2 question. If I can provide multiple ways to get to the info such
   as a menu for the display of identity signal, does that fall in line

   <Mez>
   [12]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal

   <Mez> tlr, the link into xit doesn't quite seem right; fyi

   johnath: to answer question 1, ex. firefox the fact that the button is
   always there will get u the identity signal info
   ... 2nd question. not good enough that there is a way of getting to the
   info. Insufficient.

   ifette: johnath answered q2 to some extent. In Firefox2, u can get to
   page info. Given that info is always accessible, is that conforming to
   the text. There is an extra method with the lock icon.

   johnath: interesting q. guess based on the language already present, it
   will be conformant. security indicators that users pay attention is
   predominantly padlock and padlock is not conformant.

   tlr: u can argue ff2 user interaction may be conformant. Intent of the
   text is that the interaction is not sufficient.

   <Zakim> ifette, you wanted to say that I am happy with the current
   version

   ifette: happy that ff2 method is conformant. not happy that show
   identity signal only when meaningful info available
   ... happy with the current text.

   <Zakim> johnath, you wanted to separate this question from the
   SHOULD/MUST debate I hear about identity signal in primary chrome

   johnath: sounds like branching. the issue was whether the text should
   be changed from MUST to SHOULD or remove it altogether. I say leave it
   there

   <ifette> +1 to leave as is

   tyler: results from usability studies: users did not notice absence of
   indicators. Not showing an indicator is not helpful. It is better to
   show indicators

   <johnath> ifette: remember that this text is about interaction - not
   indicator

   <johnath> urr - /s/ifette/tyler/ :)

   tyler: studies show that indicators need to be shown in chrome even
   when info is not available

   <Mez> Poll -

   <Mez> a) leave as is

   <Mez> b) substitute SHOULDs for both MUSTs

   <Mez> c) remove

   <Zakim> ifette, you wanted to talk about absence of indicators

   <ifette> ifette votes A

   Mez: straw poll

   <tyler> A

   <tlr> a

   <PHB> a

   <bill-d> bill d: A

   <MikeM> A

   <Mez> dan: a

   <yngve> A

   <Mez> bill e : a

   <maritzaj> A

   <jvkrey> A

   A

   Mez: result is A: leave text as it is
   ... create a new issue if you think otherwise
   ... next item on agenda 7.2

   <Mez> During interactions with a TLS-secured Web page for which the
   top-level resource has been retrieved through a strongly TLS-protected
   interaction that involves an validated certificate (including an
   augmented assurance certificate), the following applies:

   <Mez> The identity signal MUST include an applicable DNS name retrieved
   from the subject's Common Name attribute or from a subjectAltName
   extension.

   Mez: do not remember who raised this issue
   ... straw poll

   <Zakim> ifette, you wanted to vote for removing this text

   ifette: wildcard search. goes to a bank site with foo as the resource.
   do we show foo or bank?

   tlr: u hit a bug in the text

   <ifette> ifette: if I have a wildcard cert for *.foo.com and a user
   goes to bankofamerica.login.foo.com, do we display *.foo.com or
   bankofamerica.login.foo.com ?

   Mez: tlr bug in the text?

   tlr: possible bug in text: cert can include a wild card or include
   domain name which we are going to show. we show domain name in certain
   situations

   <Zakim> johnath, you wanted to respond to ifette :)

   <PHB> also problems with redirect cert for www.bank.com, user goes to
   bank.com and gets a redirect

   johnath: against removing text. only text what to do with identity
   signal with certs

   tlr: johnath is confused about the section we are in

   <ifette> johnath: "Am I confused?" :)

   <tlr>
   [13]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content

   <Mez>
   [14]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content

   johnath: please provide me a link

   Mez: the text has changed a lot.

   tlr: text: The identity signal MUST include human-readable information
   about the certificate subject, derived as specified in 5.1.3 Augmented
   Assurance Certificates, to inform the user about the owner of the Web
   page.
   ... we use domain name when available

   yngve: not valid according to https
   ... opera accepts in current build. not in 9.50. It does not match the
   name
   ... opera does host name check (Opera 9.50 follows the HTTPS RFC by
   matching *.example.com only for foo.example.com, not
   bar.foo.example.com; this was not done in previous version, as that
   implementation predated the RFC)

   PHB: mention the issue with problem with redirects
   ... often cert that does not a wildcard, u want to show www.bank.com
   (not the one u got redirected to)

   <johnath> sounds like a separate issue to me!

   <Zakim> johnath, you wanted to say I stand by my original point, but I
   didn't get it all the way out

   <johnath> :)

   <tlr> I don't think PHB's issue exists

   johnath: agree with tlr mostly.

   <tlr> +1 to johnath

   johnath: if I have a ev certificate, the 3 bullet points represent the
   identity signal .

   Mez: one addition to straw poll is the variant johnath tlr propose
   ... petname

   <johnath> straw poll option e) TLR's rework of current text, keep MUST

   <tlr> Unless the identity signal includes human-readable information
   about the certificate subject derived from an augmented assurance
   certificate, or a petname, the identity signal MUST include ...

   Mez: what other variants for straw poll

   <tlr> (sth like this)

   <ifette> we shouldn't mention petnames if petnames aren't in the
   spec...

   Mez: no need for a straw poll. Text needs slight rewrite

   <Mez> if there is not an item from AA (and would include petname if it
   makes it), then MUST DNS. (if weren't already showing something else
   from the spec)

   <Mez> were my notes

   tlr: will get some petnamish text in

   <tlr> ACTION: thomas to revise "MUST include applicable DNS name" based
   on discussion [recorded in
   [15]http://www.w3.org/2008/03/26-wsc-minutes.html#action01]

   <trackbot-ng> Created ACTION-409 - Revise \"MUST include applicable DNS
   name\" based on discussion [on Thomas Roessler - due 2008-04-02].

   <Mez> For Web user agents that use a visual user interface capable of
   displaying bitmap graphics the identity signal [[MAY | SHOULD]] include
   display of a suitable logotype, selected according to the rules in
   5.1.5 Logotype Certificates.

   <Mez> For AA certs, currently say:

   <ifette> i vote for rm -rf

   <Mez> Poll -

   <Mez> a) SHOULD

   <Mez> b) MAY

   <Mez> c) remove

   <johnath> ifette: my reason for MAY is that it calls out the technology
   for implementors that may not know about it, and that we've considered
   it

   <Mez> bille: may

   <Mez> dan: may

   <MikeM> B

   <johnath> johnath: may

   <Mez> bille: B

   <maritzaj> may

   <PHB> may

   <ifette> A rm -rf

   <Mez> dan: B

   <ifette> or was that C?

   <ifette> whatever

   <johnath> ifette: (itym c)

   <ifette> I want to get rid of it

   <jvkrey> b

   may

   <tlr> may

   <tyler> B

   <yngve> b, MAY, because some devices may not have the screenspace

   <PHB> may

   Mez: let me sum up the votes

   <Mez> b - BillE, Dan, MikeM, Johnath, Maritza, PHB, jvkrey, anil, tlr,
   tyler, yngve

   <Mez> c - ian

   <tlr> (no action needed, committing the change)

   <Mez> [16]http://www.w3.org/2006/WSC/track/issues/137

   <ifette> ISSUE-137?

   <trackbot-ng> ISSUE-137 -- Require Identity Signal whenever URLs are
   displayed -- OPEN

   <trackbot-ng> [17]http://www.w3.org/2006/WSC/track/issues/137

   <Mez> "The identity signal MUST be part of primary user interface when
   any identity sources that are from unauthenticated or untrusted sources
   are (also) part of the primary user interface. These sources include
   URLs."

   <ifette> ifette votes against 137

   Mez: poll: accept or reject

   <johnath> (ifette louder?)

   ifette: Q I have is basically text existed that identity signal was not
   needed to be in primary chrome. But this text says that it should be
   part of primary chrome

   Mez: it is just a IF clause
   ... motivation: idea is that url is taken as an identity signal. But it
   is also used for attacks
   ... a better identity signal should be displayed if possible than url

   <MikeM> is it primary chrome if it only appears when I mouse hover over
   address bar?

   yngve: you are saying that the identity signal should be in the same
   chrome as address bar

   Mez: yes

   <Zakim> ifette, you wanted to try to understand identity signal
   desirableness

   ifette: understanding the desire. It seems that there are studies
   people do not notice absence of locks. we are trying to get an
   indicator always
   ... correct me if my premise is wrong

   <johnath> Mez: I'm personally conflicted - I'd much rather have
   browsers doing it, but I think it might also hurt adoption of the spec
   I don't know how to vote. :/

   Mez: that was not the reason of proposal. the reason is if people take
   a signal as a bad thing, then we are trying to get a better signal

   ifette: do we consider a signal saying "no identity signal avail" is
   better

   tyler: I consider that as better. if there is no identity signal, they
   are better off looking at the url and have a better chance

   ifette: question to tyler
   ... I understand that when users see url as trustworthy. they see
   absence of locks. now they are confused. wonder if they are doing the
   wrong thing. In the default state, no lock but a signal "no identity
   signal available". bank.com/xyz will lead to a diff user interaction

   tyler: have read recos from the WG
   ... rather than "no signal is available", better provide something to
   user that they can proceed. they may have only the url and they need to
   make a decision to go ahead

   ifette: any browser will never want to show scary in the default case
   ... because if when the user is doing their normal browsing, such as
   being on Google or Microsoft etc, and they're seeing a scary indicator,
   that's not good. So I think the default state would have to be
   non-scary

   <Zakim> MikeM, you wanted to ask if it is primary chrome if it only
   appears when I mouse hover over address bar?

   MikeM: my Q was that. I understand real estate is precious

   <ifette> I also want to answer mike's question.

   <ifette> ifette: no cert is not the same as cert not matching

   yngve: it sounds to me we are back to the old issue of display identity
   signal with http
   ... or unsecure page

   <ifette> I would agree with that assessment of where we're at ;)

   Mez: think that is part of the discussion

   yngve: Q is what to do on insecure page

   Mez: cannot imagine alternative proposals on this topic

   <Mez> actually, I can

   <Mez> tlr

   <Zakim> tlr, you wanted to speak to this specific point

   <Mez> "If a positive form of identity is availble, the identity signal
   MUST be part of primary user interface when any identity sources that
   are from unauthenticated or untrusted sources are (also) part of the
   primary user interface. These sources include URLs."

   tlr: we are mixing 2 discussion - 1) does there a need to be "MUST
   show" identity signal in case of http

   <Mez> there's a crack at an alternative

   tlr: I would like to understand about mez's proposal if it applies to
   bookmark where I have a dialog with tons of urls.

   Mez: bookmarks show urls?

   tlr: bookmark dialogs show urls

   Mez: proposal as worded, in that case

   tlr: i have doubts about this case.

   <MikeM> IE bookmarks display URL as a hover help

   tlr: undecided

   <Mez> bill-d

   Mez: we have had no discussion

   bill-d: is the primary chrome considered secure

   Mez: do not remember making statements about that

   bill-d: conversation about secure chrome. was that related to primary
   chrome

   tlr: section 7 is about making chrome secure

   Mez: long ago, there were proposals pointing about secure chromes

   <tlr> mike, bookmark dialogues show URLs in Safari, Opera, and Firefox
   on the Mac

   <MikeM> yeah but in IE it's disolayed right in the Favorites list (no
   dialog required)

   PHB: want to go back to the Q about negative indicators
   ... want to make sure that we do not make recommendations that browsers
   create clutter.

   <ifette> +1 to phb

   PHB: presenting useless information confuses uses

   <stephenF> yep, +1 to that too

   <ifette> -1 to clutter

   <tlr> w+

   PHB: telling people that "u have no signal" is a bad thing

   johnath: support browsers doing it
   ...

   <tlr> MikeM, hadn't gotten that point. FF3 actually shows URIs in
   status bar if you hover over bookmarks.

   <johnath> johnath: I would much rather use browsers that do adhere to
   this, but I'm not sure we can recommend it without hurting adoption.
   Mez's alternate text is much less contentious, since the padlock would
   be compliant.

   tlr: my Q / observation: Identity signal: when no https is present, we
   are hearing 2 diff hypothesis about user behavior
   ... hypothesis: having negative signal is confusing
   ... other hypothesis is: negative signal in case of HTTP actually helps

   <Zakim> ifette, you wanted to respond to tlr

   <MikeM> Thomas, thanks

   <Mez> I don't think we'd do that with you around ian

   ifette: we are not going to get data on these two cases unless major
   browsers implement it
   ... very skeptical on getting useful data.

   <ifette> ifette votes for dropping mez's text on the floor

   <Mez> A) original text

   <Mez> B) the amended text

   <Mez> C) calling it a day

   <ifette> C rm-rf

   <Mez> 04 01"If a positive form of identity is availble, the identity
   signal MUST be part of primary user interface when any identity sources
   that are from unauthenticated or untrusted sources are (also) part of
   the primary user interface. These sources include URLs."

   <johnath> B (on the interpretation that the padlock is implicitly
   conformant with mez's text)

   <tyler> A

   <maritzaj> c

   <jvkrey> c

   <PHB> +1 stephenf

   <Mez> [18]http://www.w3.org/2006/WSC/track/issues/137

   [19]http://www.w3.org/2006/WSC/track/issues/137

   <PHB> b

   tlr: MUST in 6.1 is totally independent of this straw poll?

   Mez: yes, it is different

   <bill-d> bill d: B

   <tlr> b

   <MikeM> B

   <Mez> B

   B

   <stephenF> b

   <yngve> C, we need more exploration of the possible issues

   bill-d: B would be a better answer

   bill-e: I do not have a vote

   <PHB2> my power is back

   <PHB2> Don't buy a Tripp-lite UPS

   <PHB2> rubbish

   <ifette> Buy APC

   <ifette> :)

   tlr: any other business: appreciate feedback on proposals for error
   handling
   ... would people indicate whether u disagree with what I have said
   there

   <ifette> thr

   <ifette> will the non-schengen lounge rennovations be done by f2f?

   <ifette> or for my ams layover should I head to schengen still

Summary of Action Items

   [NEW] ACTION: thomas to revise "MUST include applicable DNS name" based
   on discussion [recorded in
   [20]http://www.w3.org/2008/03/26-wsc-minutes.html#action01]

   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [21]scribe.perl version 1.133
    ([22]CVS log)
    $Date: 2008/04/03 20:32:58 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/2008/03/26-wsc-irc
   3. http://www.w3.org/2008/03/26-wsc-minutes.html#agenda
   4. http://www.w3.org/2008/03/26-wsc-minutes.html#ActionSummary
   5. http://www.w3.org/2008/03/19-wsc-minutes.html
   6. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0133.html
   7. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Mar/0010.html
   8. http://www.google.com/search?source=ig&hl=en&rlz=&q=870NOK+to+USD&btnG=Google+Search
   9. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
  10. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
  11. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0051.html
  12. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
  13. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
  14. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
  15. http://www.w3.org/2008/03/26-wsc-minutes.html#action01
  16. http://www.w3.org/2006/WSC/track/issues/137
  17. http://www.w3.org/2006/WSC/track/issues/137
  18. http://www.w3.org/2006/WSC/track/issues/137
  19. http://www.w3.org/2006/WSC/track/issues/137
  20. http://www.w3.org/2008/03/26-wsc-minutes.html#action01
  21. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  22. http://dev.w3.org/cvsweb/2002/scribe/

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Thursday, 3 April 2008 20:33:54 UTC