See also: IRC log
<tlr> http://www.w3.org/2007/04/04-wsc-minutes
minutes approved unimanimously
I would reather use my own mute
<tlr> all agree, ACTION-154 ACTION-157 ACTION-160 ACTION-166
tahnks
<Tyler> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0217.html
<tlr> PROPOSED: defer; Dan Schutzer to present at a later time
topic deferred
<ses> <---got only 90 minutes of sleep last night so may not be here in much more than electronic form only.
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0051.html
PHB: ssl as designed assumes one to one between IP addr and certificate
host name checking is not checked carefully
but when it it is it causes problems
starting to cause problems
with EV certificates
<tlr> hal, for continuation lines, please use this syntax:
<tlr> ... this goes on ...
<tlr> ... and on ...
ok
<tlr> Also, please attribute what's said.
<tlr> It'll all make you rlife much easier when you get to clean-up. ;-)
scribe: fix is being deployed
... only on client side
... need server side support
<Zakim> tlr, you wanted to ask what the recommendation in scope for us would be
phb: clients support tls hostname extension
<tlr> PHB: client providers ought to support TLS host name extension, server providers support use of that feature
tlr: what about error condition - page
reload?
... from airport hotspot
(sorry can follow usecase can you type it)
cant
phb: related piece is can solve by being more lax in checking redirects
<tlr> tlr: related, hotspots doing benevolent SSL MITM. Do we need a "override, but just send GET / HTTP/1.0" instead of doing the post here?
phb: people don't type the "www" part of domain
name
... so redirect gives error
... before you could get by
... now doing checking at TLS level, before redirect
chuck: related issue mapping IP names to
certs
... multiple servers or caching servers
... will break a lot of existing solutions
... will IETF fix solve all these
phb: will not solve all the issues
... cause is checking things more carefully
... will see more errros if not careful
... another fix which could be used is wildcard domains
... currently prohibited by EV rules
... revocation can be an issue
... IETF fix allows multiple sites on physical servers
chuck: problem EV certs my produce too many
errors
... users will work around, undermine effectiveness
<serge> Zakim mute me
<Zakim> tlr, you wanted to ask about technical constraints that are in EV guidelines
chuck: don't have answers
tlr: + 1 to chuck
... question to phb are EV x.509 profile published
phb: is a profile of PKIX profile
tlr: can share pointer?
<tlr> ACTION: hallam-baker to share pointer to CABforum profiling of PKIX [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action01]
<trackbot> Created ACTION-189 - Share pointer to CABforum profiling of PKIX [on Phillip Hallam-Baker - due 2007-04-18].
phb: propose we point to work of others, not design
<tlr> ACTION: hallam-baker to attempt summary of discussion and proto recs re EV and virtual hosting in wiki [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action02]
<trackbot> Created ACTION-190 - Attempt summary of discussion and proto recs re EV and virtual hosting in wiki [on Phillip Hallam-Baker - due 2007-04-18].
<Chuck> The CA Browser forum appears to have links to download the relevant documents (cleverly hidden) at the very top of their home page at: <http://cabforum.org/index.html>
<tlr> http://www.w3.org/2006/WSC/wiki/PersonallyIdentifiableInformationEditorBar
tyler: want to get indication to user when
about to enter sensitive data
... user will type into editor widget
... login scenario
... remembers text used for login
<tlr> I'd suggest calling the thing "Sensitive Information Bar" or some such.
tyler: lets you select one to use
... moves cursor to editor widget
... provides indication that have provided password previously
... interupts normal flow if at different site
... next to it is petname tool
... can show no relationship to site
... or just msg talking to stranger
BobP: question select password from pull down?
tyler: no, will have list of sites in pull down
bob: would see password?
tyler: have some choices, could have it displayed or have stars
bob: display could allow others to see it
tlr: I would avoid PII term here
... call it your information entry
... interaction mode when entering data?
tyler: other aspects
... try to implement failure case
... use of petname tool to identify site
<tlr> I had suggested that a high-level description of this would be to (a) put users into different interaction mode when they think they are making another trust decision, and (b) leverage stored information to signal that user is actually repeating a prior security decision.
<Zakim> Thomas, you wanted to note that the reliability issue is better dealt with in HTML WG and to also come back to PII discussion
tlr: reason not to use PII brings up rathole,
want to control when we treat these issues
... data can be not PII in some cases
... not accurate decsription of what we are talking about
... reminded me of HTML form idea of filling fields
... can deal with in w3 forms group
tyler: not good idea to make html specific
thanks
tyler: need hal: cant do form fill combined with stars display
sduffy: how determine previously trusted site
tyler: petname tool does it - explicit user choice
tlr: need to seperate abstract concept from detailed interface
<tlr> ACTION: tyler to update TrustMe proposal in wiki [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action03]
<trackbot> Created ACTION-191 - Update TrustMe proposal in wiki [on Tyler Close - due 2007-04-18].
<tlr> http://www.w3.org/2006/WSC/wiki/UrlRecommendation
mez: in favor of short recommendations to
discuss
... 1st is URLs
... talked about how they are used, mostly for security
... heard some browsers were doing more with contents of URL
... want to discuss this, what are browsers doing?
... have heard users cannot understand URLs
... few restrictions, no mechanisms to insure understandable by users
... 2 levels of risk
... low and no risk situations, can be identified?
... in this case can be presented for usability, not security
... in medium to hi risk, meaningful and robust presentations required
... what about display?
<tlr> "Your flight has been cancelled."
mez: only way to get at understandable properties in URL is from history of interation
tyler: assumes part of URI is of interest to user, what part?
mez: ties to something about authority
faliliarity trustworthiness
... may note be substring
tyler: better not to display URL
... want to pin down value if any of URL display
tlr: you're mixing display and entry of URLs. I sense that it might be useful to have a generic "drop URL bar" discussion. Please draft a proposal.
tyler: seems to be some overlap
<tlr> ACTION: tyler to draft "let's drop the URL bar" proposal [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action04]
<trackbot> Created ACTION-192 - Draft \"let\'s drop the URL bar\" proposal [on Tyler Close - due 2007-04-18].
chuck: different take, nobody understands URLs,
things get entered by click
... used to just be reference
scribe: some useless some dangerous
... need to consider what info is actually being provided
... sometimes intentionly invisible
scribe: potentially complex
... what is boundary?
mez: not just browsers location bar
... glad you brought in relationship between click link and URL value
... will update wiki
<tlr> http://www.w3.org/2001/tag/doc/state.html
<tlr> I think I provided a high-risk example on IRC. "Your flight has been cancelled."
mike: are display only cases which are hi risk,
will provide examples on request
... main point most users ignore location bar
... but need to consider those who do
... browsers don't indicate domain
... consider https to be more reliable indicator than padlock
<tlr> ACTION: mcCormick to provide high-risk display-only use cases [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action05]
<trackbot> Created ACTION-193 - Provide high-risk display-only use cases [on Michael McCormick - due 2007-04-18].
hal: dont understand about https, only requires port 443
mike: should get rid of favacon, makes it easy for phishers
<tlr> ACTION: zurko to refine UrlRecommendation - due 20 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action06]
<trackbot> Created ACTION-194 - refine UrlRecommendation [on Mary Ellen Zurko - due 2007-04-20].
<tlr> http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge
mez: techniques for weak identification
... shared between sites, like mothers maiden name is anti pattern
... looking for input
tlr: aim at generic case
... finding that cute icon distracts users from real security info
... anti pattern
chuck: have scars
<tlr> I'm taking that from the Emperor paper
<ses> We could call out "presenting security steps that are necessary as sufficient" as something we'd want to advise against.
chuck: need to be careful about how to
characterize SPK
... used by orgs to additional confidence
... mother's maiden name is always bad
... but others may be usuable
chuck: real issue is frequency of use
... key is whipping boy
... some people get irate over SPK term
<ses> In response to the statement that SiteKey is used to authenticate clients, I would disagree. SiteKey is to reauthenticate people. (Once they believe the user of the browser is authentic, they THEN make a transitive assumption that the client belongs to the user)
chuck: some effectively use data shared between
user and site
... potential for social engineering - giving the illusion of confirming
... very complex, not always anti pattern, need to say what should be done
mez: agree but should work in parrallel
<tlr> ACTION: zurko to capture discussion on SharedPublicKnowledge in wiki and refine proposal - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action07]
<trackbot> Created ACTION-195 - capture discussion on SharedPublicKnowledge in wiki and refine proposal [on Mary Ellen Zurko - due 2007-04-25].
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0138.html
tlr: based on article about warnings given in
specific case more effective
... and article about how mashups get auth info
... user enters credentials for A at B
... browser could detect this case
<ses> There's a paper by Microsoft at the next WWW that create a toolbar that looked for password reuse.
tlr: looking for input
<Mez_> hal: prohibits extremely common habit
<ses> "A large-scale study of web password habits" by Florencio and Herley
<Mez_> ... how do you manage 50 passwords?
<ses> It supports what Hal is saying right now.
<ses> (One problem with the proposal is that you don't know its the same password until it has been typed. A malicious site can send characters back one at a time as they are typed.)
tlr: would learn past trust decisions, could
suppress question the 2nd time
... space to optimise it
<ses> http://research.microsoft.com/~cormac/Papers/www2007.pdf
<Zakim> Thomas, you wanted to note that we can talk about deployment techniques
chuck: many problems at server side
tlr: agree, charter allows deployment
practice
... need concrete proposals
chuck: need mutual security
... one sided approch is always vulnerable
tlr: would like to hear specifics
chuck: group is oriented towards client exclusively
<tlr> ACTION: chuck to turn ramblings about deployment and server side into coherent written material - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action08]
<trackbot> Created ACTION-196 - turn ramblings about deployment and server side into coherent written material [on Chuck Wade - due 2007-04-25].
bill: added section in ?? covering servers
<Zakim> MEZ, you wanted to comment that we should try to make it smarter about trust domains
<tlr> bill-d: offer to help Chuck with ACTION-196; section about web server and connection to user agent
bill: comments to note discuss servers
mez: can consider trust domains
<tlr> ACTION: thomas to incorporate discussion about Contextual Password Warnings into Wiki - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action09]
<trackbot> Created ACTION-197 - incorporate discussion about Contextual Password Warnings into Wiki [on Thomas Roessler - due 2007-04-25].