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

Meeting record: WSC WG weekly 2007-08-08

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 16 Aug 2007 11:19:22 +0200
To: WSC WG <public-wsc-wg@w3.org>
Message-ID: <20070816091922.GA6202@raktajino.does-not-exist.org>

Minutes from our meeting on 8 August have been approved:


Thomas Roessler, W3C  <tlr@w3.org>


               Web Security Context Working Group Teleconference
                                   8 Aug 2007

   See also: [2]IRC log


          ifette, MaryEllen_Zurko, Thomas, Chuck_Wade, +1.408.748.aaaa,
          Audian, johnath, DanSchutzer, tyler, PHB, rachna

          Maritza_J, Tim_H, Anil_S, Bill_D, Shawn, D


          Audian, tlr


     * [3]Topics
         1. [4]Agenda bashing
         2. [5]Demo infrastructure
         3. [6]IdentitySignal
     * [7]Summary of Action Items

    <trackbot-ng> Date: 08 August 2007

   <tlr> ScribeNick: Audian

   Mez: Minutes from last meeting are approved.


Agenda Bashing

   Mez: agenda - Demo insfrastructure (audian)

Demo Infrastructure

   <tlr> ScribeNick: tlr

   audian: increased license count for GotoMeeting www.gotomeeting.com...

   ... can try for free ...
   ... could try during the call ...
   ... or offline ...
   ... multi platform ...
   ... didn't try with linux, but should work theoretically ...
   ... share screens ...
   ... more than one person dabble over mouse and keyboard control for
   entertainment ...
   ... can host 25 people, more than needed, I hope ...
   ... try?

   mez: sounds good

   audian: I can set up regularly scheduled calls

   mez: cost structure? burden? could drop notes on Fridays

   <ifette> To join the Meeting, please use one of the following supported
   operating systems:

   <ifette> * Windows� 2000, XP Pro, XP Home, 2003 Server, Vista

   <ifette> * Mac OS� X, Panther� 10.3.9, Tiger? 10.4.5 or higher

   audian: it's just there for now

   <ifette> I got an error...

   tlr: see ifette's remark on IRC; does not support linux.
   ... therefore, not useful for Ian or Thomas ...

   <ifette> perhaps in vmware...

   mez: can any of you use one of these systems during meetings?

   tlr: sorry, no

   chuck: it's specific versions of MacOS as well

   johnath: works fine on Mac

   audian: will connect to contact and ask for linux support

   <Chuck> Yes, I can confirm that VNC works on all platforms.

   tlr: vnc would work across platforms

   <ifette> Would offer to host but I'm behind a firewall...

   <Chuck> The most important thing needed for a VNC server is an Internet
   connection with good "uplink" speed.

   chuck, indeed

   audian: will check platform factor; hope that to help for several

   <scribe> ACTION: audian to check on linux platform - due 2007-08-22
   [recorded in [9]http://www.w3.org/2007/08/08-wsc-minutes.html#action01]

   <trackbot-ng> Created ACTION-278 - check on linux platform [on Audian
   Paxson - due 2007-08-22].

   <scribe> ScribeNick: audian



   Mez: conformance language currently 5.5.1 and 5.5.2

   TLR: requirement part...

   <Zakim> ifette, you wanted to ask what it means to make available

   <tlr> ian, shout!

   ian: wants an indicator to be present...
   ... more info on the o field and the verifier...
   ... what about browsers in 'reduced chrome mode'

   johnathan: doesn't know if W3C has background on this (indicator)...
   ... should restrict normative statment to default presentations instead
   of all custom browser settings

   PHB: re: chrome...
   ... attempted explaination of extended chrome to cabforum...

   <Mez> but we're talking user agents, not browsers

   <Mez> so the question is, do all user agents "make available" some sort
   of meta or control information?

   <Mez> If so, the statement might make sense, if not, it might not

   <ifette> +1 mez

   ...should address 'out of the box' configurations...

   <johnath> won't digress by replying with voice, but I think phil's
   point about reversable customization is a tangent - maybe another rec,
   but not part of this one

   <johnath> (though interesting!)

   <tlr> +1 to johnath

   ...example of person using different user's system...ability to change
   to a default state without major steps

   chuck: 9 out 10...how do you get back to a 'normal' browser mode

   <Zakim> ifette, you wanted to say that there is MUST language "MUST use
   the subject field's Org. attribute to inform the user..."

   ifette: 5.1.2 says users agent states MUST not SHOULD...

   <Mez> "make available" is weaker than "in default chrome"

   <tlr> can we take that as the next topic?

   ...should be a pop up for the o field

   <tyler> Just noting that the PII bar proposal doesn't rely on any
   persistent chrome and so isn't affected by chrome reconfiguration

   johnath: I think the language states 5.1.1 uses should or has
   recommended language

   <tlr> johnath, did you just say that a page info dialogue would be
   enough to conform with the identity signal?

   ifette: this isn't how i read this...

   <Mez> good point. but PII only covers input situations, not display

   ifette: 5.1.1 and 5.1.2 might need 'clean up'

   <Zakim> Thomas, you wanted to talk about plugins vs. chrome

   <PHB2> I am on topic

   <Mez> ok phill

   tlr: 1. we are talking about user agents (broadly)...
   ... current def says any piece of software used to retrieve or interact
   with web content

   <Mez> retrieve and interact with web content, obviously allows for one
   with no meta, control, or chrome type information

   tlr: do web browser and plug-ins need to be mutually considered as web
   ... should there be an indicator that is persistent regardless of user
   ... what about full screen mode?...
   ... should user action of disabling chrome be considered

   <Mez> seems like it would be a conformance class (user agents which
   show "chrome") and modes where user has not over ridden that

   johnath: we might be saying the same thing...
   ... if you are using the web browser for something other than normal
   user agent web access..perhaps that should not be included...
   ... might want to leave up to web designers (for use cases and special

   <tyler> Wonders if desktop full screen mode is out of scope, then how
   could we possibly make smartphone displays in scope

   tlr: if we are talking about a single implemen tation...what about plug
   ... we need language in this section to better define the view mode per
   the use case...
   ... and provide some exception examples

   <Chuck> Could we please use the term "identifier" instead of

   <Mez> good pont tyler

   <Mez> I wish Luis was here

   <Mez> though Chuck is :-)

   mez: thinks something should be written up on this

   PHB: 5.1.1 states that identity information should be made
   available...that that information should be stated as legit/secure

   mez: if identity information isn't available, what is stated or
   displayed to the user

   PHB: an assertion should be made regarding the state of the signal

   johnath: should unverifiable or no identitiy information be indicated?

   chuck: what does trust mean (eww!)

   mez: wants to give an action item regarding understand of what the
   information displayed in 5.1.1 means to the user

   <tlr> ACTION: thomas to rewrite first four requirements in 5.1.1 in
   view of call discussion [recorded in

   <trackbot-ng> Created ACTION-279 - Rewrite first four requirements in
   5.1.1 in view of call discussion [on Thomas Roessler - due 2007-08-15].

   tlr: if you look at section 4 of the document...

   ...this is where he is working on definition of trust

   <Zakim> johnath, you wanted to say that the last two bullets in 5.1.1
   can be merged (or last can replace second last)

   johnath: language tlr has in first two bullets is fine

   <Chuck> To Thomas's point, I agree that the framework is in place.
   We'll just have to deal with how trust gets defined within each

   <tlr> chuck, absolutely

   <tlr> guess why I have been re-reading PKIX recently. ;-)

   johnath: no objection to the fourth bullet, but might want tighter
   language instead of using 'industry standard'...
   ... would like the second to last bullet dropped in favor of the last

   <tlr> proposed: to drop "user agents MAY augment ... industry standards
   ..." in favor of last bullet item

   <tlr> RESOLUTION: to drop "user agents MAY augment ... industry
   standards ..." in favor of last bullet item

   <Zakim> ifette, you wanted to discuss what it means to MUST use subject
   field org to inform the user

   ifette: second point - currently have must language under 5.1.2...
   ... what exactly does that mean?

   <tlr> ACTION: thomas to implement resolution to drop "user agents MAY
   augment industry standards" [recorded in

   <trackbot-ng> Created ACTION-280 - Implement resolution to drop \"user
   agents MAY augment industry standards\" [on Thomas Roessler - due

   <johnath> 5.1.2 bullet 1

   ifette: what is the requriement

   <tyler> Since we have significant evidence that passive chrome
   indicators are ineffective, I am wondering how useful it is for us to
   hammer out rec language for passive chrome indicators.

   tlr: should indicate TLS succeeded, path succeeded...
   ... trust cert should tell you about the owner and the certifier

   <johnath> tyler: security context is more than anti-phishing. Context
   information can be a valuable part of the user interface as an aid to
   establishing context, even without ascribed prophylactic effects

   tlr: basically stating that 'these are the two fields you should

   <Mez> tyler, I'm good if you want to propose a topic for the next
   meeting that's not passive chrome.

   tlr: this would not apply for a SSC

   <Mez> you can do it during discussion of that item if we have time, or
   in emai

   <Zakim> ifette, you wanted to ask if this is omnipresent, i.e. that's a
   lot of browser chrome to require people to give up

   <tyler> Johnath, do you have any evidence to support that view? All the
   studies show that the indicators go completely unnoticed.

   ifette: i understand regarding type of certs...
   ...example: should there be a persistent display during an entire

   <johnath> tyler: support what view - that information is nice? I'm not
   claiming preventative effect, I'm just saying it's context.

   <Zakim> Chuck, you wanted to discuss O fields in cert DNs
   ...example: doesn't like that personally (as a web designer or user?)

   chuck: why the O field...

   <tlr> as phrased it is not restricted to EV.

   chuck: why restricted to EV certs?

   <tyler> Johnath, the view that users will make use of these indicators
   in any way. If the indicators are largely ignored, then, they're...

   chuck: example of visiting Fleet site while actually on a BOFA site
   (acquisition example)

   <johnath> tyler: good question! I think most of the studies that have
   been done focus on anti-phishing, I don't know of data either way on
   general day to day browsing

   <tyler> Mez, another topic would be, should we stop spending time on
   passive chrome indicators, since they are at best peripheral to our

   <rachna> +1 Chuck

   <ifette> +1 tyler

   PHB: would distinquish between logos as well...(scribe lost context at
   this point)

   <johnath> woah - we're already on logotypes? I didn't think ian's
   question had been answered yet?

   <johnath> ifette: agree! :) I thought it was a new point though, so I
   was holding my tongue in-queue! :)

   <ifette> :-)

   <Mez> ian, can you restate the question you asked that are hoping for
   an answer, in irc?

   <johnath> Mez - can I q+ to respond to Ian's question, without
   disrupting my queue position for new topics?

   <Mez> sure

   Audian: banks deal with branding transitions and will consider this use
   case if it is a requirment

   <ifette> My question: 1. Are we expecting the O= and Verifier= field to
   be omnipresent in the browser chrome, and if so, how many pixels are we
   realistically expecting people to give up to this? (And if logos must
   also be presented, how many pixels in that case)

   <Chuck> Again, I'd like to endorse Phil's point about indicating which
   "source trust" applies to the site identifiers.

   <tyler> Johnath, my read of the phishing studies was that they found
   that passive indicators were ignored. To me, that means that they are
   not being used at all, let alone providing any anti-phishing benefit.

   Audian: banks deal with branding transitions and will consider this use
   case if it is a requirment

   <johnath> tyler - my read is that most of those studies (perforce,
   given the recency of the phenomenon) involve users with either atypical
   experience (here, read this document about EV and green bars) or no
   experience at all with such indicators?

   johnath: agrees that the language of 1st bullet of 5.1.2 should be

   <Mez> I like the discussion about users' relationship to tdentity, but
   wonder why it never involves, say, the title bar as well.

   johnath: when presenting information, "this is how"

   <Mez> as a wg we did agree that there needs to be trust indicators in
   read only mode

   <Mez> we've discussed and agreed on that twice, though informally (not
   as resolutions)

   <Mez> I fully expect us to do it again

   <ifette> +1 jonath

   johnath: bullet should be re-written to spec display

   <ifette> yes

   <tyler> I think we've agreed that we need to protect reading of
   information, though we haven't agreed that must be done via passive
   chrome indicators

   <Mez> fair enough

   tlr: the way this is phrased, it is not limited to EV cert

   <johnath> tyler: Just to be clear, I agree - active indicators are a
   far better approach to things like anti-phishing

   <Chuck> I did read it as not limited to EV, but the conversation seemed
   to be implying that people were interpreting it as EV-oriented.

   tlr: TLR is +1 regarding Johnathon's proposed changes to bullet 1
   ... wonders if that part should 'go up' into the requirements

   <Zakim> johnath, you wanted to (eventually) contest the logotype point
   and to reply to tlr, though I think this queues me twice, in the wrong

   <tyler> Johnath, I thought so. I think we all do, so I'm wondering why
   we keep them on the front burner

   johnath: do we want to require this in primary chrome versus SHOULD

   <tlr> no, it doesn't mean that. We have "requirements" for secondary

   <ifette> i'm on queue for exactly this issue

   <johnath> ifette: different topic!

   ifette: re: moving rewritten bullet to requirement, would also like to
   fold in (what?)

   <johnath> ifette: I would prefer to just drop the logotype requirement,
   but I think it's a separate topic from the identity information in
   smaller, text format, for instance

   ifette: is logo type display also a requirment?

   <ifette> ok, I'm willing to accept what thomas just said...

   <tlr> mez, I didn't hear you?

   <johnath> tlr: scribe what you just said

   <johnath> mez wanted to see it with some clarity :)

   <tlr> tlr: Let's assume that "User agents SHOULD make an identity
   indicator available in primary user interface, in a consistent visual
   position, for implementations with always-visible chrome." as the
   primary requirement. 5.1.2 describes what goes in there.

   mez: thinks that we are in agreement that 5.1.1 and 5.1.2 should be

   johnath: not sure there is legit vetting technology for logotype
   associations, so wonders if requiring or even recommending a logotype
   display should be MAY

   <ifette> As a note you can queue yourself with 41# on the phone

   johnath: thinks this should be a MAY

   <Zakim> Chuck, you wanted to address requirements for logotypes

   chuck: is any of this stuff really a standard as a genuine
   ... here is a more digestable "friendly" name for users

   PHB: there is problem using identity re: logotypes

   <ifette> afk for a sec

   PHB: trustworthyness of identifier can be subjective...
   ... identities and accreditations should be discussed separatly

   <Zakim> johnath, you wanted to say that I'm not judging the goodness of
   logotype, I'm disputing the wisdom of MUST'ng logotype display

   johnath: concerned that logotypes have MUST language

   danschutzer: wants to talk about identity...
   ...re: companies have multiple organizations

   <johnath> proposed: That the language in the last bullet of 5.1.2
   (concerning logotype) be changed from MUST language to MAY language.

   phb: can't justify MUST but could justify SHOULD...
   ... interested in two distinct issues...
   ... 'bank of americana' <- criminals using trade dress as a mo...
   ... there is always going to be an opportunity to use someone's name

   <tlr> ScribeNick: tlr

   audian: to phil's point...
   ... it's also true that somebody in a suborganization can be a bad
   actor with other tools such as letterhead and printed envelopes ...
   ... they all have access to letterhead ...
   ... if you have that in the mail, people take it as "the real deal"...
   ... and thus treat the content as genuine and important ...
   ... we can't worry about bad actors within organizations ...
   ... rather, use identfiers to discern one group from another one ...
   ... abuse of good will ...
   ... there's mail fraud to deal with this ...
   ... criminals in that sense ...
   ... can also abuse phone system and caller id ...
   ... that's going to be an issue regardless ...
   ... that doesn't mean we have to find a way to identify individuals or
   groups inside large organizations ...

   <scribe> ScribeNick: audian

   mez: wants to consider johnathan's proposal

   <Mez> proposed: That the language in the last bullet of 5.1.2
   (concerning logotype) be changed from MUST language to MAY language.

   <tlr> SHOULD vs. MAY is a HUGE difference

   <ifette> ifette prefers MAY

   <PHB2> +1 TLR

   <johnath> tlr: I agree - I appreciate that it might SOUND trivial

   <ifette> GOOD

   <johnath> GOOD

   <tyler> please type the question we are voting on into IRC

   <PHB2> Bad

   <Chuck> Bad

   <tlr> neutral

   rachna: good

   <tlr> mez: PROPOSED: MUST show logotypes -> MAY show logotypes?

   PHB: thinks we should have this between MUST, SHOULD, MAY

   <tlr> phb: need three-way. Argument is between SHOULD and MAY.

   PHB: should be between SHOULD and MAY

   <Chuck> I vote for Should, but not may

   <Zakim> Chuck, you wanted to try to re-focus on what is relevant to
   this WG

   <PHB2> I vote for SHOULD and against MAY

   chuck: we should be discussing what users will find helpful

   <tlr> ifette, phb, I think we have agreement that the choice is between
   SHOULD and MAY.

   <Mez> we'll have to put it off ian; we can do it in email; I would
   llike that

   <Mez> Phill, can I get you to put the proposal for the Quaker style
   poll in email? Or Ian? Or Johath? then I'll take it from there

   chuck: provide a vehicle to provide a visual indicator that is vetted
   by 'somebody'

   <tyler> +1 to Chuck, but we must also evaluate resistance to
   picture-in-picture spoofing

   <johnath> Mez: let people straw poll with those three words as answers

   <Mez> johnathn, no time in the meeting

   <Chuck> One other point: We cannot achieve the "perfect," we must,
   instead, strive for the "better."

   dan: if a company chose to include a registered logotype in an EV

   <johnath> Chuck: does MAY preclude striving for better?

   dan: that would help in distinction for the user

   <Zakim> Thomas, you wanted to make a meta point

   <Chuck> Yes, to Jonathan

   <johnath> Chuck: that surprises me.

   <Chuck> I feel that may becomes too easy to ignore.

   <tyler> Rachna, I sent an email with a summary of my questions about
   the PII bar review, and have some more time this week to discuss it

   tlr: regarding what goes into the document (and I lost him after that)

   mez: agrees with tlr...
   ... put issues into tracker

   <tlr> long live square brackets

   <rachna> ok tyler- I'll reply to the list and we can set up a time to
   talk if needed.

   <tyler> Rachna, thanks

   <ifette> lol

   mez: wants someone to take the lead in writing the proposal for the

   <tyler> Are we really going to FPWD with passive indicators?

   <tlr> tyler, I wouldn't be surprised.

   <tyler> If so, that would violate the constraints we set out in the

Summary of Action Items

   [NEW] ACTION: audian to check on linux platform - due 2007-08-22
   [recorded in
   [NEW] ACTION: thomas to implement resolution to drop "user agents MAY
   augment industry standards" [recorded in
   [NEW] ACTION: thomas to rewrite first four requirements in 5.1.1 in
   view of call discussion [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [16]scribe.perl version 1.128
    ([17]CVS log)
    $Date: 2007/08/16 09:16:42 $


   1. http://www.w3.org/
   2. http://www.w3.org/2007/08/08-wsc-irc
   3. http://www.w3.org/2007/08/08-wsc-minutes.html#agenda
   4. http://www.w3.org/2007/08/08-wsc-minutes.html#agenda_bashing
   5. http://www.w3.org/2007/08/08-wsc-minutes.html#demo_infrastructure
   6. http://www.w3.org/2007/08/08-wsc-minutes.html#IdentitySignal
   7. http://www.w3.org/2007/08/08-wsc-minutes.html#ActionSummary
   8. http://www.w3.org/2007/08/01-wsc-minutes
   9. http://www.w3.org/2007/08/08-wsc-minutes.html#action01
  10. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
  11. http://www.w3.org/2007/08/08-wsc-minutes.html#action02
  12. http://www.w3.org/2007/08/08-wsc-minutes.html#action03
  13. http://www.w3.org/2007/08/08-wsc-minutes.html#action01
  14. http://www.w3.org/2007/08/08-wsc-minutes.html#action03
  15. http://www.w3.org/2007/08/08-wsc-minutes.html#action02
  16. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  17. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 16 August 2007 09:19:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC