Web Security Context Working Group Teleconference
8 Aug 2007

 <trackbot-ng> Date: 08 August 2007

<tlr> ScribeNick: Audian

Mez: Minutes from last meeting are approved.

http://www.w3.org/2007/08/01-wsc-minutes

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 people

<scribe> ACTION: audian to check on linux platform - due 2007-08-22 [recorded in 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal

 IdentitySignal

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 issues

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 agent...
... should there be an indicator that is persistent regardless of user mode?...
... 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 apps?)

<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 ins...
... 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 "identity"?

<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 http://www.w3.org/2007/08/08-wsc-minutes.html#action02]

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

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

<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 http://www.w3.org/2007/08/08-wsc-minutes.html#action03]

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

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

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

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

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

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

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

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

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

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 identifier?...
... 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 cert...

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

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