See also: IRC log
tlr: lots of people not showing
up
... FF3B5 near code freeze? Losing yngve early today b/c he's
traveling
... brief reminder about f2f, minutes to approve, and then want to
go briefly through action items, and then want to talk about
shuffling around in section 7, review petname proposal tyler
circulated, and then some floating text in 7.1.4 and 8.1
tlr: anyone want to change?
... good
tlr: it's coming. be there.
... and register
<tlr> http://www.w3.org/2002/09/wbs/39814/wscf2fosl/
ifette: wondering if anyone has been able to reserve the hotel?
tlr: not tried
<tlr> ACTION: yngve to check reservation code for f2f hotel [recorded in http://www.w3.org/2008/03/19-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-403 - Check reservation code for f2f hotel [on Yngve Pettersen - due 2008-03-26].
yngve: checking into it, lots of people are on vacation
tlr: made an action
... any other questions?
... or anyone else know if they are going / not going?
tim: calling in
billd: calling in probably
sschutzer: on vacation
<rachna> I'm calling in.
<tlr> s/steven/schutzer/
tlr: pelase submit your answers to the online form
<tlr> Draft: http://www.w3.org/2008/03/05-wsc-minutes.html
tlr: that was 5.3.2008, no comments
on mailing list, any changes?
... any objections?
RESOLUTION: minutes approved
<tlr> trackbot-ng, close ACTION-401
<trackbot-ng> ACTION-401 Document/Screencap Larry as a lo-fi prototype candidate for the identity signal closed
tlr: think ACTION-401 is done
... things relevant to june last call, still have one pending to
clean up error message text in spec, think that's the only
blocking
... some stuff to be merged, incl. petname
... anil is to drop in some acknowledgements
... some confusion around an action relating to ISSUE-124
ISSUE-124?
<trackbot-ng> ISSUE-124 -- Safe Form Bar: reliable text -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/124
tlr: any idea what this is about?
anil: Need to prepare a draft, get tyler's feedback
tlr: On list, you were asking for
input, tyler was also confused
... do you think you have required input?
Anil: No, will have next week
tlr: chats with Anil
<tlr> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0011.html
tyler: Given that this is about material in an appendix, does it make sense to spend cycles on it?
tlr: not urgent, but saw
communication issues
... moving on to section 7 stuff
tlr: has moved material not making it
to LC into an appendix, has renumbered as a result
... tried to bring Robustness into a shape that looks like what we
discussed at f2f
... on a high level, chrome and UI best practices in 7.1, user
attention, and APIs
... summarizs new section 7. Read it.
<stephenF> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Robustness
Stephen: Does 7.1 imply mobile device must use shared secret?
tlr: Probably needs further elaboration, intent is that where technique makes sense, use it
<tlr> ACTION: stephenF to propose wording for 7.1 (chrome and UI practices) to weaken requirement to stuff that makes sense in a given context [recorded in http://www.w3.org/2008/03/19-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-404 - Propose wording for 7.1 (chrome and UI practices) to weaken requirement to stuff that makes sense in a given context [on Stephen Farrell - due 2008-03-26].
<Zakim> ifette, you wanted to say that I dont really understand what interactions 7.1 is talking about
ifette: what interactions fall under 7.1?
tlr: Two angles, on one hand these are things that you may do...
ifette: hold on
tlr: specific interactions... two
hooks at this point that go into 7.1
... one is very initial text in 7.1, when you signal security
context info outside of an interaction specifically invoked to do
so,
... unsolicited security information, at least one must be
used
... rest are additional
... second hook is from 6.4
... serge's language on error interactions
... 6.4.1 is new,
<stephenF> also just noticed that 7.1 says you MUST do 7.1.1 or 7.1.2 but 7.1.1 only has single MAY => doing nothing is ok?
ifette: questions about what it means to cross the chrome content boundary
<tlr> Web user agents SHOULD use difficult-to-spoof UI elements that cross the chrome-content border where appropriate.
tlr: original text was phrased as follows
<tlr> ACTION: tlr to get johnath to clarify applicability and description of crossing chrome-content border, or find other volunteer [recorded in http://www.w3.org/2008/03/19-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-405 - Get johnath to clarify applicability and description of crossing chrome-content border, or find other volunteer [on Thomas Roessler - due 2008-03-26].
tlr: trying to figure out how to word what Stephen pointed out
Stephen: suggestst just dropping the MUST, say that it's best practice, take it
tlr: any other thoughts?
... worries about blurring conformance model
<Zakim> ifette, you wanted to bash on conformance model
ifette: conformance model already a nightmare
<tlr> ifette: +1 to "best practices", maybe "SHOULD make use of these"
<tlr> ... I've kind of given up on the conformance model, fine with best practice ...
<tlr> rachna: What should be best practice, waht shouldn't?
<tlr> ifette: both
<tlr> rachna: whole document?
<tlr> ifette: oh
<stephenF> So 1st sentence of 7.1 might be "Sections 7.1.1 and 7.1.2 document best practices for display of security information. Web user agents SHOULD adopt these where they make sense (e.g. if display of chrome is possible)"
ifette: this would be a great f2f
topic
... our lack of conformance model
<Zakim> rachna, you wanted to ask what is difference between 7.1.4 and 8.1
rachna: what is difference between 7.1.4 and 8.1?
tlr: which 8.1?
rachna: current
tlr: 7.1.4 is old 8.1, current 8.1 is
old 9.1 and is a requirement for conent
... 7.1.4 is requirement on UAs
... 7.1.4 is about favicons in trusted places, 8.1 is about
padlocks in form control
<Zakim> stephenF, you wanted to ask about 7.1.2 being a bit vague on whether the site or UA does the trick
Stephen: 7.1.2, seems to be a bit
vague as to whether UAs or websites are doing this
... is that the right thing? or ask if UA does it make it clear
that it's the UA doing it
... confusing
... want mez' input
<tlr> http://www.w3.org/2006/WSC/track/issues/new
tlr: anything else about
restructuring / changed content?
... heads up, if something about this part you expect to change as
a result of f2f and hasn't changed yet, tlr forgot and give him a
heads up
<tlr> trackbot-ng, close ACTION-383
<tlr> trackbot-ng, close ACTION-384
<trackbot-ng> ACTION-384 Propose lang about currently interacted primary chrome always visible on screen [do jointly with ACTION-383, restructure 8.2-8.4] closed
<tlr> trackbot-ng, close ACTION-383
<tlr> trackbot-ng, close ACTION-383
<trackbot-ng> ACTION-383 Change editor's draft as outlined above [restructure 8.2-8.3] closed
tlr: anything else on Section 7?
ifette: clarify where this text is going. In LC document or some spinoff?
tlr: his recollection is that something like what tyler suggested could be sufficiently low hanging as to make it into LC, no decision yet
tyler: intent of process is to see whether usable for last call, not examining for future document
tlr: tyler, introduce?
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0097.html
tyler: just sent another
email...
... one from last week on updated implementation proposal for
petname on its own separate from webform editor was taking user
task of recognizing hostnames and putting a user interface on
that
... doing it this way addresses PHB and Stephen and Hal's
concerns
... about new ways about using info in certificate
... attempting to implement using only existing HTTPS spec
algorithms as applied to x509
... only extracting host names and matching there
... no new matching algorithms
... if you visit a "Strongly TLS protected" website, user can
assign petname
... create binding in browser, between petname and host
identifiers
... from then on, when you get a strongly tls protected site with
cert that has bound hostname, display that petname
... includes pinned SSCs
... user can edit/delete petname
... browser should compare petnames, make sure it's not
"similar"
... no duplication
<Zakim> stephenF, you wanted to ask if wildcards in DNS names in certs must all be covered by the same petname (don't mind just wondering)
stephen: likes changes, questions about wildcards
tyler: using existing mechanisms for
matching. If wildcard on *.f00.com, it is for *.f00.com
... same petname
ifette: what if there's a *.foo.com and also a xyz.foo.com cert (someone has both)
tyler: if you try to assign same petname there, browser would warn user that there's no known relationship between the two cert chains
<stephenF> thing I wanted to think about is whether NameConstraints ought influence petname associations; thing is that that probably won't be visible to layer about SSL
tyler: underlying quandary present in
underlying protocol
... foo.com would be presenting an incoherent set of certs to the
user
... no matter how the user views them, it's incoherent
ifette: is this may/should/must
tyler: for now, attempting to define
petname presentation
... and this is how it should work
... then hash out whether the browser MAY/SHOULD/MUST implement
this
tlr: one way this could fit in is to
say that UAs that allow people to assign names SHOULD display in
identity signal...
... xyzblah
... this has a wierd interaction with bookmarks
... good thing to do in identity signal, and if you take user
assigned names into identity signals this is how you do it
ifette: are you saying bookmark is petname iff displayed in identity signal?
tlr: no. typical bookmark interaction
is not a useful source of info for identity signal
... that is side effect here
<stephenF> tlr: why not?
tlr: if names are part of identity signal, this is how they should describe
ifette: so there's no onus for a browser to implement this?
<stephenF> tlr: type this rather than say it
<tlr> 1. Browsers SHOULD use petnames.
ifette votes against this strawman proposal
and has real concerns
<tlr> 2. If browsers do anything with user-assigned names in the identity signal, then MUST follow petname logic.
<tlr> ?
phb: bunch of things here
... interaction with bookmarks should be discussed further
... might want to have hybrid of bookmarks + petnames
... reduce interaction cost
ifette: what if I bookmark a page
deep in
... e.g. xyz.com/foo/bar/d.html and I call that "privacy
policy"?
phb: the more we get into the face of
the user and interrupt workflow, more we can expect them to take
notice and expect them to be more secure
... as long as they dont turn off feature
... two issues, asking for too much from browsers/users we dont get
what we need. tension between making systems more secure and
acceptable
... talks more
... talks about other ideas like in vista and leopard
... blacking screen, other ideas
tlr: one point I want to pick up on,
that is bookmark interactions
... tyler, don't have your language present, anything about
bookmarks?
... or how initial petname definiton achieved?
tyler: when you visit strongly tls protected page, user can assign a petname
tlr: one thought, in prototype or
spec language, is to say "if people are on a site that is strongly
tls and they bookmark a page on that site, there should be an offer
as part of that interaction to assign petname to entire site"
... dont know if that fits
tyler: moving in that direction takes
us further in towards form filler
... can key off of form editor or bookmark
ifette: focus in FF3 is making bookmarks less cognatively burdened
tlr: dont know
... a thought
<Zakim> stephenF, you wanted to ask what if wildnames get defined later (how'd I differentiate a wildname from a petname?)
Stephen: Tending towards having as
MAY
... could be convinced
... should have more experience with
... more discussion about why petnames/bookmarks are same different
or related, but can do later
... question: if you are doing petnames, text will define how you
do it, that makes sense
... what if, sometime later, someone defines XYZName instead of
PetName?
... how will I understand difference?
tyler: unsure right now
tlr: part of my strawman is that "if there are user entered strings or names as part of identity signal, they must follow the petname scheme"
stephen: difficulty understanding UX
eventually, string popus up, my bank etc
... occur in other contexts
<PHB> I am tending towards MAY as well
stephen: how to make sure that when user interprets sth as a petname, it is a petname?
tyler: thomas had claimed entire space of user assigned names to authenticated entities. comfortable?
stephen: user might call it
mybank.com
... what if some other reputation service uses a similar
name?
... choices can collide
<stephenF> +1 to ifette's concern about this being a SHOULD (I do like it as a MAY implement)
ifette: cocerns about requring new things that haven't been widely tested
tyler: one of the reasons this WG was
formed is that browser vendors didn't want to change UI not in
unison
... that's part of why this WG was formed
<Zakim> ifette, you wanted to say the WG has failed that already
<tlr> ifette: there was a point where browser vendors were hesitant to act out of unison
<tlr> ... that seems to change now, FF and IE are out of unison right now ...
<tlr> ... we don't have enough from them here ...
ifette: we're deluding ourselves if we think this working group represents browser vendors coming together to change security user interfaces in unity
tlr: what I hear is that this sounds like something that is good-practice-ish as a positive, and a good interaction to drop in the spec in some way
<stephenF> if petnames do get used, then they could become a BCP, but not yet
tlr: what I would like to get a sense for is whether this is low hanging enough to get into last call for june
tyler: making it into LC means it gets out for feedback
tlr: sense is prioritizing for feedback
ifette: Think this is too far out. Could live with it as a may, but is too far out
tyler: wrote resposne to rachna, believe it's lower user burden
tlr: have short time left, won't
tacke user burden today
... would ask to send mail in response to tyler's message, pinpoint
where undue burden is created
<tlr> ACTION: ifette to point out user burden concerns w/ petnames in detail [recorded in http://www.w3.org/2008/03/19-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-406 - Point out user burden concerns w/ petnames in detail [on Ian Fette - due 2008-03-26].
Stephen: Too much to make it a should, can make it a may, don't share ian's concerns re optional things causing us to lose adoptiveness
<tlr> ACTION: tyler to refine petname proposal in light of 2008-03-19 call's discussion [recorded in http://www.w3.org/2008/03/19-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-407 - Refine petname proposal in light of 2008-03-19 call's discussion [on Tyler Close - due 2008-03-26].
<stephenF> ifette, so what? specs get revised in the light of experience
<stephenF> +1 to tlr not wanting broad implementation experience a gate before LC