- From: Thomas Roessler <tlr@w3.org>
- Date: Thu, 16 Aug 2007 11:19:22 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 8 August have been approved:
http://www.w3.org/2007/08/08-wsc-minutes.html
Regards,
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
8 Aug 2007
See also: [2]IRC log
Attendees
Present
ifette, MaryEllen_Zurko, Thomas, Chuck_Wade, +1.408.748.aaaa,
Audian, johnath, DanSchutzer, tyler, PHB, rachna
Regrets
Maritza_J, Tim_H, Anil_S, Bill_D, Shawn, D
Chair
Mez
Scribe
Audian, tlr
Contents
* [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.
[8]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 [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>
[10]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
[11]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
[12]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
Summary of Action Items
[NEW] ACTION: audian to check on linux platform - due 2007-08-22
[recorded in
[13]http://www.w3.org/2007/08/08-wsc-minutes.html#action01]
[NEW] ACTION: thomas to implement resolution to drop "user agents MAY
augment industry standards" [recorded in
[14]http://www.w3.org/2007/08/08-wsc-minutes.html#action03]
[NEW] ACTION: thomas to rewrite first four requirements in 5.1.1 in
view of call discussion [recorded in
[15]http://www.w3.org/2007/08/08-wsc-minutes.html#action02]
[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 $
References
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