See also: IRC log
<jvkrey> ScribeNick: luis
Mez: admin started
... two new persons in meeting: Tom & Claudio
Claudio from Opera and Tom from Microsoft
scribe: Tom is an observer
Mez: (around the table)
... yesterday we left in issue 200
... also commments from the team
... plugin
... 169 still on hold
... 199 also wait
... where we are on the way to last call
... not too bad
... now, what happens after june
<tlr> http://lists.w3.org/Archives/Member/member-wsc-wg/2008May/0004.html
<Mez> issue-200?
<trackbot-ng> ISSUE-200 -- Should an AA security indication include all elements in the evaluation, or just the top document -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/200
<joesteele> Is ISSUE-183 still OPEN?
<Mez> let me look
<Mez> would still be open if not executed
<Mez> joe
<jvkrey> ISSUE-183?
<trackbot-ng> ISSUE-183 -- Automatic Selfsigned Certificate acceptance/probation MUST NOT be implemented unless there is a history capability -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/183
<Mez> joe, have any issue other than client vs ua on that one? I sent you email; I think that's just an editorial change, and Luis pointed that out as well in his editorial changes.
NOTE: (waiting for Yngve to resume meeting)
<joesteele> yes --
joesteele: an issue on
email
... signalling with notification for pinning
... signalling with danger
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0033.html
joesteele: the decision was made and unclear why just warning
tlr: clarification behind
rationale ...
... risk with man in the middle attacks
... if user hasn't visited that site before
... though users would click yes anyway
... so the situation would not be worse than today
... changing from notification to warning ...
... is an idea
joesteele: still concerns
... user gets a SSC notification and would pin it
... and next time he would not see the notification
johnath: understand the concern
tlr: concern is that there is no explicit interaction
Mez: back to ISSUE-200
... comparing pure AA vs relaxing to strongly protected with
validated
... arguing is over?
... voting
<johnath> proposal 1: "A user agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting an AA certificate."
<johnath> proposal 2: "A user agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting a validated certificate, over strongly protected TLS connections."
<Mez> A) 1
<Mez> B) 2
<Mez> C) do nothing
<Mez> D) abstain
<ifette> I vote B
<yngve> A
<ifette> I vote B
<johnath> B
<luis> B
<PHB2> b
<joesteele> A
<anil> b
<csant> A
<jvkrey> a
<Mez> d
<tlr> d
<Mez> A yngve, joesteele, csant, jvkrey - 4
<Mez> B ifette, johanth, luis, phb, anil - 5
<Mez> D mez, tlr - 2
ifette: strawpoll or vote?
Mez: vote
ifette: vote per organization or per participant
<tlr> http://www.w3.org/2005/10/Process-20051014/policies.html#Votes
tlr: reading something
... in order to vote to resolve a substantive issue, an
individual MUST be a group participant in Good Standing. Each
organization represented in the group MUST have at most one
vote, even when the organization is represented by several
participants in the group (including Invited Experts)
<johnath> ifette: second para answers your question
<johnath> as luis has just pasted! :)
ifette: motivating his preference
tlr: a domain validation is not
fully secured
... if there is assumption on domain validation
... attacker can get hold of "validated" certs
johnath: why is that different
than EV (AA) certs?
... the domain validation in AA is like validated certs
... in either case the pointer is to a domain
PHB: EV is for shopping, banking
...
... extending to content ...
... CA issues certs chaining up to the domain, not to the
root
<Zakim> ifette, you wanted to say that this would hurt adoption, as if we require this, nobody will buy ev certs because so long as their ads and google-analytics dont use ev theres no
ifette: most browsers would yank
from the root
... those not doing proper validation
... EV adoption would be blocked if all resources must be
EV
johnath: agrees, no one would bother to deploy EV
yngve: mixing EV and non-EV may reduce trust onEV
johnath: it's risky in either way ...
Mez: what's the risk when mixing
content
... what would work in one case and not in the other?
PHB: Paypal has only EV certs
yngve: not for Paypal objects
johnath: BA would be a good example how EV would apply
PHB: worried on SSL pages containing non-SSL parts
johnath: where to draw the line?
Tom: agrees with johnath
... its the top level page that assurance is given on
Mez: this is imporant to cover
<Zakim> anil, you wanted to say that I feel that the top level assurance is not sufficient
Mez: majority vote is needed
anil: recaping on top-level
assurance
... though XSS is a risk that EV doesn't provide assurance
on
<johnath> *correction - Tom: ...its the top level page that assurance is given, as long as all subelements are delivered over secured, validated connections
yngve: concern that ads and so on. Payment process is not un EV
luis: (thnx johnath)
johnath: example with Paypal with EV giving assurance that the Visa resource is trusted
Mez: continues with the process
anil: what about redirect to other site
<anil> anil: during payment process on EV-certified site
ifette: the SCI for EV would be
shown only for the EV site
... if the redirected site is not EV, there the SCI would not
be shown
anil: something needs to be written in best practices
Mez: everybody is in good
standing
... reading the rules
... no invited experts
<johnath> proposal 1: "A user agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting an AA certificate."
<johnath> proposal 2: "A user agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting a validated certificate, over strongly protected TLS connections."
<johnath> A) 1
<johnath> B) 2
<johnath> C) No change
<johnath> D) Abstain
<yngve> A
<luis> B
<johnath> B
<ifette> Google votes B
<anil> RedHat votes B
<Mez> IBM votes B
<PHB2> VeriSign votes B
<joesteele> B
<tlr> I'd love to drop a "concur" ;-)
scribe: 7 B's and 1 A
<tlr> RESOLVED: Proposal 2 is adopted
scribe: anil to update draft
<Mez> issue-133?
<trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the Robustiness section interact? -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/133
<johnath> ACTION: anil to update section 5.3 to include proposal 2 text [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-450 - Update section 5.3 to include proposal 2 text [on Anil Saldhana - due 2008-05-21].
<johnath> Mez's text: http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0049.html
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0055.html
js23: proposing is an addition is
a cross reference
... pointing back to this section
Mez: formal MUST, SHOULD MAY were not used but natural language on purpose
<Zakim> johnath, you wanted to ask about conformance nature of mez' language
Mez: can you provide an example on back reference
johnath: language is not normative and that's OK
Mez: unclear what type of
extensions we were supposed to consider
... for conformance
tlr: two worries. last sentence
sounds like requirement for conformance
... proposing change with specific UA
... rather than being generic
... instead of testing conformance >> claiming
conformance
... 2nd worry: all this reads a fine list what an extension
would do to claim conformance
... proposing text and shuffling for claiming conformance to
capture attention
<joesteele> Mez -- is this what you had in mind? Plugin, extensions and external systems which interact with the browser should pay careful attention to avoid degrading the user agents conformance to this section.
<johnath> +1 to the proposal as-is, with joe's text additions in the obvious places
Mez: which section?
<johnath> (as-is with tlr's edits)
Mez: 5 , 6 & 7?
<ifette> -1 as well
<ifette> (to shoving in the back references scattered about the document)
tlr: better in the front of the spec rather than back reference
jonahth: make forward references
<Mez> here's the edited version from tlr's comments
jonahth: no need for back ref's
Mez: propose to put it in ??
tlr: thinking would be section 3
<Mez> swap 3 and 4 sez tlr
tlr: prefer everything in one place
johnath: interpreting Mez's that she wants in current section 4
tlr: discussion what's in 3 and 4
and agree
... what's on each
<Mez> A) add that paragraph after the other paragraphs on user agent and web page
<Mez> b) don't
<Mez> c) abstain
<tlr> a, with some editorial discretion
<ifette> a
<johnath> I believe the thing we're voting on is Mez's changes + tlr edits, without backreferences from later sections - wherever tlr wants to put them
<jvkrey> a
<johnath> A
<joesteele> a
<luis> A
<PHB2> a
<csant> a
<yngve> A
<anil> a
<Mez> c
<johnath> ACTION: tlr to add extension text to section 4.1, and possibly merge/reorg sections 3 and 4 [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-451 - Add extension text to section 4.1, and possibly merge/reorg sections 3 and 4 [on Thomas Roessler - due 2008-05-21].
<Mez> 31 minutes break
<Mez> back on the hour
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0056.html
<johnath> http://www.flickr.com/photos/matthewj/sets/72157604988911230/
<PHB2> heellllooooooooooooo
<johnath> coming back
<johnath> 2 hour timeout
<ifette> ScribeNick: ifette
<Mez> hi phil
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0056.html
ISSUE-169?
<trackbot-ng> ISSUE-169 -- Section 5.5.3 creates a burden on browsers to remember past certificates -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/169
<luis> trusted root certificate >> trusted anchor
johnath: This seems long
tlr: Not so long. parts are going
away
... including the part on revocation checking failure
... and another part (the last paragraph) is being moved up to
after the first numbered list
<johnath> current text for 5.5.1 - http://pastebin.mozilla.org/431034
johnath: Pastes URL that shows what 5.5.1 would look like after edits
ifette: this sounds nice
<johnath> +1
ifette: should store state or may store state. if you don't offer pinning, that extra info offers little value
tlr: keeping the state around enables UAs to respond more strongly to certain error conditions
ifette: fine
<johnath> Mez: wiki with changes highlighted - http://www.w3.org/2006/WSC/wiki/Revised551-May14
tlr: there is a question on whether we want to add anything re downgrading level of warning interaction if... trails off
<johnath> (since pastebin is not permanent)
tlr: the one question tlr has is
whether 4.3 in that list we would want to...
... trails off
... restarts
... we have currently in that list of 4 items basically making
a link b/t offering pinning and having a notification
interaction
... the one additional thing I could see would be for UAs that
keep state but doesnt do pinning is to say if it keeps state
around, and if there is a site with which the user has
interacted before and a validated cert has never been seen,
whether in that case it should be a warning or
notification
... that creates a certain hole but is probably the right thing
in my mind
... would be a slight weakening or in addition to point 4
... would like to put that on the table
... so the interaction in that case would be for a UA that does
not support pinning, you get a warning the first time, after
that it's just a notification message
... it is a rather weak model and i prefer the one with
pinning
johnath: inclined to say that if you want to solve this, just support pinning
tlr: Other question: pinning may/should/must
ifette: may
yngve: dont like notifications
unless based on previous knowledge
... could be interpreted as just not showing any indication to
user even on first time
johnath: 5.1.5 says uas may support pinning, such behaviour includes... (reads)
tlr: something wrong in 1st
sentence
... ponders
johnath: fine with proposed text as is
tlr: dont feel strongly about changing. move on.
mez: ok, big pause?
... silence...
... other issues?
yngve: consistent with 5.1.5 means if a webpage consistently presents a self signed cert
tlr: no
... it means that requirements further down should be
followed
... first part up to UAs may support pinning etc, is a
rationale
... this is about SHOULD NOT cause self signed certs to pinned
to more than one site, must not caused untrusted root to be
accepted for addl sites, should be considered sufficient auth
to allow petname association
... also MUST NOT do any automatic thing unless client has
history info mechanism about security info, which is weak
yngve: thinking about???
... may use notification
... think it should at least say if it's got historical
knowledge
tlr: would mean first interaction always warning, only later downgrade
yngve: concerned that we may lead implementers to ditch unknown self signed warnings
tlr: concern that they implement notification mechanism equal to not showing anything?
yngve: just showing a weak
notification
... giving a stronger warning first time
tlr: current idea precisely
that
... weak notification, UNLESS you have info that site is
usually validated
yngve: first time have no info,
has ssc
... notification or warning?
tlr: notification
yngve: problem?
... concerned could leave open for spoofing
tlr: does create a window
... if you dont want that dont implement that
yngve: would not interrupt users
tlr: yes
yngve: problematic
tlr: ok....?
<johnath> (poor ifette)
yngve: still can be used for
making spoof sites
... suspect that if this gets implemented wrong way, w/o
dialog, even more prevalent
ifette: why would phisher direct to https with warning when they could direct to http with no warning?
yngve: depends on what kind of
indicators are shown
... https, padlock, etc
tlr: following you... as far as
MITM attacks concerned
... not for phishing
... for MITM yes, we are saying this is creating an additional
risk in following scenario which is acceptable in big
picture
... and current UAs people click ok anyways
... question is is that risk acceptable
... and whether changing this first interaction is useful way
to mitigate risk
... SSCs at least get protection against passive
attackers
... better than http
... protect against active attackers as soon as is
possible
... does dialog make significant difference for first
interaction?
... not really opening up any new holes.
yngve: might be an idea to explain the risks in that section
tlr: trying to remember if we explain or not
yngve: risk assessment
... would like link
tlr: part of an editiorial fix, one thing that is spelled out is precisely this
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#mitm-initial
tlr: that we've been
discussing
... active attacks during initial attacks
... happy to add link from 5.1 to 9.1
... which already links back to 5.1
yngve: want risks linked in text
tlr: will change link in beginning of 9.1 to point to 5.5.1 which ismeant
luis: has a new thing on this
phrase
... in johnath's text
... three places where requirement to UA is phrased
... may offer pinning (in here twice)
... line number 16
... later on in line 26
... later in text in section 5.1.5
yngve: those two detail different
situations
... first one is if it already knows pinned, second is if it
doesnt have historical info
luis: requirements still the same
johnath: first set of bullets
governed by paragraph about what capabilities UA has
... next bullets for UAs not capable of
... refer to different categories of UAs
group: ... more back and forth on editorial changes
ifette: leave to editors?
group: yay
ifette: vote?
<johnath> proposal: text from pastebin/wiki + editorial changes to 5.1.5 to avoid "pinning" repetition
jvkrey: if you cant store state of certificates, why offer possibility to pin>
johnath: read as we dont store about whether a site presented a validated cert or not, but we are able to pin singular exceptions
yngve: same for opera
ifette: vote?
group: talks and feels good
mez: great lets vote
<johnath> proposal: text from pastebin/wiki + editorial changes to 5.1.5 to avoid "pinning" repetition
a) go with tlr's text
b) keep it
c) abstain
<johnath> A
<ifette >A
<PHB2> a
<jvkrey> a, I like it
<tlr> a
<luis> A
<csant> A
mez: C
<anil> A
<yngve> A
mez: ok
... give tlr an action
<johnath> ACTION: tlr to update 5.5.1 with wiki text, and possibly edit 5.1.5 to avoid "pinning" repetition [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-452 - Update 5.5.1 with wiki text, and possibly edit 5.1.5 to avoid \"pinning\" repetition [on Thomas Roessler - due 2008-05-21].
mez: takes us through and produces resoutions for all open issues except for ISSUE-199
tlr: new issue
<johnath> issue-203?
<trackbot-ng> ISSUE-203 -- Update Security Considerations -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/203
ISSUE-203?
<trackbot-ng> ISSUE-203 -- Update Security Considerations -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/203
tlr: should say where we rely on
specific user behavior, and where are the risks where users do
things we dont expect
... where are we creating additional exposure
... someone who is not an editor should go through spec and do
that pass
ifette: dont have edits folded in
yngve: +1
... review done after editing folded in
ifette: apologizes to mez
johnath: is that true?
tlr: can probably go through and
do that review
... at least in a raw form
... know where we came out on mixed content
... expect considerations from yngve
... one change that comes up in my mind that has real impact on
security considerations seciton
... might want to explictly say that we do not specify behavior
for failure conditions as network failures during revocation
checking
... these are the things from what I remember that would affect
security considerations
... other than that we can work from current draft
johnath: offers to write section 9.2 about revocation checking if that is helpful
mez: yes
johnath: :-)
yngve: phone?
mez: top down
... ?
tlr: yes
mez: yes
... anything in section 1
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Overview
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Conformance
ifette: confusion about first time
<luis> tlr: no conformance language for "first time"
ifette: would like to clarify first in 6.2
johnath: we do top level page
view
... was it typed into address bar, click link, tec
... top level docshell
... not good language for spec
... first time a user agent navigated to a page
mez: that's the change
... ?
tlr: no action on yngve to write security considerations about EV and mixed content
<Mez> is this what you meant ?
<Mez> 2. When the user first went to a web page with the current top level web page's domain.
ifette: close
<Mez> 2. When the user first visited a web page with the current web page's domain.
<tlr> ACTION: yngve to provide initial draft of security considerations for EV mixed with DV case [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-453 - Provide initial draft of security considerations for EV mixed with DV case [on Yngve Pettersen - due 2008-05-21].
<Mez> 2. When the user first visited a top level [ref web page] with the current top level [ref web page's] domain.
<Mez> 1. When the user most recently visited the domain of the [ref web page] in the past.
<Mez> 2. When the user first visited a top level [ref web page] with the current top level [ref web page's] domain.
<Mez> 3. How often the user visited the domain of the [ref web page] in the past.
<Mez> 1. When the user most recently visited the domain of the top level [ref web page] in the past.
<Mez> 2. When the user first visited a top level [ref web page] with the current top level [ref web page's] domain.
<Mez> 3. How often the user visited the domain of the top level [ref web page] in the past.
ifette: yay
luis: is this first visit info that can be flushed
ifette: yes. clear history
luis: not persistent
ifette: assume implementation, but in reality probably tied to history
mez: walkthrough... past section 3>
johnath: created proposed text for ocsp
<johnath> issue-205?
<trackbot-ng> ISSUE-205 -- Add security consideration for OCSP failure -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/205
mez: look at it?
ifette: +1
mez: gee, what happneed to 204?
ISSUE-204?
<trackbot-ng> ISSUE-204 -- Drop square brackets in section 6.1.1 -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/204
tlr: 204 is editorial
<johnath> proposal - that we adopt text from ISSUE-205
PROPOSAL: adopt text from ISSUE-205
mez: super cool groovy
<Mez> a) do it
<Mez> be) no
<Mez> c) abstain
<Mez> not to be
<johnath> A
<tlr> issue-205?
<trackbot-ng> ISSUE-205 -- Add security consideration for OCSP failure -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/205
<ifette> a
<Mez> a
<tlr> a
<yngve> a
<jvkrey> a
<johnath> other votes? PHB?
<csant> a
<johnath> anil?
<luis> C
<anil> A
<PHB2> a
mez: great
<johnath> ACTION: anil to add section 9.2 based on issue-205 text [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-454 - Add section 9.2 based on issue-205 text [on Anil Saldhana - due 2008-05-21].
mez: moving on to section 4
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#concepts
mez: will pick up with section 5
on ISSUE-203
... encourage people to look at this over lunch
<Mez> back in 60 minutes
<scribe> ScribeNick: csant
<Mez> http://www.w3.org/2006/WSC/Group/cheatsheet
<Mez> scribing and scribing action items sections, in the middle
<PHB2> going offline
<Mez> issue-203?
<trackbot-ng> ISSUE-203 -- Update Security Considerations -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/203
Mez: Picking up on section 5
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb
<anil> section 5.1.5
johnath: 5.1.5, fine - when talking about pinning self-signed certs, naive implementor might trust it too easily
tlr: last 2 paragraphs take care of that?
<Mez> section 5.1.2 - should we say that AAC don't protect against XSS?
<scribe> ACTION: johnath to dd that wording to 5.1.2 [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action06]
<trackbot-ng> Created ACTION-455 - Dd that wording to 5.1.2 [on Johnathan Nightingale - due 2008-05-21].
Mez: 5.1.3 - should we say whether validate certs are important?
tlr: might make sense to add a note to 5.1.3
<Mez> ACTION: tlr to say why validated certs are worthy of so much reliance, for security considerations [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action07]
<trackbot-ng> Created ACTION-456 - Say why validated certs are worthy of so much reliance, for security considerations [on Thomas Roessler - due 2008-05-21].
Mez: logotypes? 5.1.4
... needed to mention in security considerations?
PHB2: logotypes communicate
identity more directly to the user...
... helps user to identify easier...
<Mez> ACTION: phb to give overview of why logotypes are interesting in security considerations section [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action08]
<trackbot-ng> Created ACTION-457 - Give overview of why logotypes are interesting in security considerations section [on Phillip Hallam-Baker - due 2008-05-21].
Mez: 5.1.6, petnames?
ifette: most things in the spec most people in the group agree on, petnames i wouldn't be so sure.
anil: we need to introduce security consideration section, explaining what it really means.
ifette: why do we have a whole ssection on names?
<anil> ACTION: anil to add a couple of sentences about what the security consideration section means [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action09]
<trackbot-ng> Created ACTION-458 - Add a couple of sentences about what the security consideration section means [on Anil Saldhana - due 2008-05-21].
ifette: need to explain why this is actually included
johnath: there is a concern that
in the absence of petnames a user might rely on other, less
reiable means
... petnames help establishing a reliable association, mainly
for AA-cert sites
tlr: shouldn't the wording then be "should"?
johnath: requires users'
interaction, not really sure whether it's a safe
mechanism
... not sure we need to add a motivation for each item.
tlr: pure motivation arguments should be kept out of the security considerations.
<johnath> ISSUE-207?
<trackbot-ng> ISSUE-207 -- Add Section 9.3 - Certificates assure identity, not security -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/207
<johnath> proposal: that we adopt the text in ISSUE-207 as a new section in section 9
<Mez> a) 207 yes
<Mez> b) no
<Mez> c) ?
<yngve> a
<ifette> a
<johnath> A
<csant> A
<anil> A
<PHB2> A
<jvkrey> abstain
<luis> A with minor editorial on strongly protected ...
<tlr> a
<Mez> c
<Mez> ACTION: anil to do issue-207 [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action10]
<trackbot-ng> Created ACTION-459 - Do issue-207 [on Anil Saldhana - due 2008-05-21].
Mez: 5.2, types of TLS
... 5.3, yngve has an action on, 5.4 is gone.
<johnath> Issue-208?
<trackbot-ng> ISSUE-208 -- Add security consideration for "human readable" names - e.g. petnames -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/208
<johnath> PROPOSAL: That ISSUE-208 text be added to section 9 (with editorial changes as needed)
<ifette> A
<Mez> a) do it
<Mez> b) nope
<Mez> c) don't care
<johnath> A
<csant> a
<Mez> c
<tlr> a
<luis> A
<anil> A
<jvkrey> c
<yngve> a
<PHB2> A
<johnath> ACTION: tlr to include ISSUE-208 text in section 9 (with edits as needed) [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action11]
<trackbot-ng> Created ACTION-460 - Include ISSUE-208 text in section 9 (with edits as needed) [on Thomas Roessler - due 2008-05-21].
Mez: 5.5.2 ok, anything about
5.5.3?
... 6.2? 6.3?
... 6.4?
tlr: 6.4.1, why is there a MUST NOT in front of terms of art?
<ifette> "must not be phrased solely in temrs of art"
<ifette> "must not be phrased solely in terms of art, e.g. jargon"
<ifette> A
<johnath> A
<tlr> a
<csant> A
<PHB2> A
<anil> A
<Mez> a) buy Thomas many drinks tonight
<Mez> b) amend 6.4.1, 2nd paragraph, 1st sentence, adding ian's clause
<Mez> c) do nothing
<Mez> d) abstain
<ifette> oh boy...
<ifette> i like my text. I vote accordingly
<tlr> (the minutes will be faked accordingly)
<johnath> text++
<luis> D
<anil> B
<tlr> B
<jvkrey> d
<yngve> B
<PHB2> B
<csant> B
<Mez> d
resolution: approve text
<Mez> ACTION: anil to alter 6.4.1 accordingly [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action12]
<trackbot-ng> Created ACTION-461 - Alter 6.4.1 accordingly [on Anil Saldhana - due 2008-05-21].
<tlr> action-461?
<trackbot-ng> ACTION-461 -- Anil Saldhana to alter 6.4.1 accordingly -- due 2008-05-21 -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/461
Mez: 6.4.2, 6.4.3 ok
yngve: 6.4.3, 6.4.4 issue about message overload
Mez: 7.1.1, 7.1.2? 7.2?
... 7.3, 7.4?
anil: editorial question: should we link *all* uses of definitions?
tlr: tried to link first
occurence within each section
... 7.4.4: MAY or SHOULD needs to be cleared
Mez: was taken care of yesterday, there was an action.
<anil> ACTION: anil to correct link words that have a definition (such as Web user agents) in the first occurrence in a subsection [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action13]
<trackbot-ng> Created ACTION-462 - Correct link words that have a definition (such as Web user agents) in the first occurrence in a subsection [on Anil Saldhana - due 2008-05-21].
ifette: 8: what is that first sentence?
tlr: striking it.
ifette: some concerns about
8.3
... don' like the MUST, do not agree.
yngve: e.g. a cookie should be sent with the same security as other credentials
ifette: for many sites it is too expensive to be realistic.
<johnath> ISSUE-210
<johnath> ISSUE-210?
<trackbot-ng> ISSUE-210 -- Add section 9.5 - Warning Fatigue -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/210
<ifette> ISSUE-211?
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
<ifette> A
<Mez> a) make change
<Mez> b) don't
<Mez> c) don't care
<johnath> A
<maritzaj> a
<anil> A
<jvkrey> c
<tlr> a
<csant> c
<PHB2> A
<Mez> c
<yngve> A for 210
<johnath> ACTION: tlr to add ISSUE-210 text to section 9, with edit to reference "managing user attention" section [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action14]
<trackbot-ng> Created ACTION-463 - Add ISSUE-210 text to section 9, with edit to reference \"managing user attention\" section [on Thomas Roessler - due 2008-05-21].
<ifette> ISSUE-211?
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
Mez: keep going with issue 203: 8.4, 8.5?
<anil> ACTION: anil to merge acknowledgments (sections 10 and 2) to 2 [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action15]
<trackbot-ng> Created ACTION-464 - Merge acknowledgments (sections 10 and 2) to 2 [on Anil Saldhana - due 2008-05-21].
<ifette> ISSUE-211?
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
Mez: done with issue 203? trl, want to consider any other topics?
tlr: none.
<ifette> ISSUE-211?
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
Mez: ISSUE-203 to be closed
<tlr> ACTION: tlr to remove sqbrackets from identity signal section [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action16]
<trackbot-ng> Created ACTION-465 - Remove sqbrackets from identity signal section [on Thomas Roessler - due 2008-05-21].
<ifette> ISSUE-206?
<trackbot-ng> ISSUE-206 -- Smartphone Considerations -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/206
<johnath> we're dialing back in
<johnath> :)
<PHB2> ach, just wait till everyone has an iphone and this goes away
<jvkrey> a+
luis: has submitted changes to ISSUE-206 to the list
<Mez> jvkrey
jvkrey: phones' UI is constantly
shifting.
... would like to rethink the separation between primary and
secondary chrome
<Zakim> anil, you wanted to say "can we just make text generic to not refer to desktops or smart phones or hand held devices OR add a statement that this is applicable to future devices"
tlr: example of low-chrome phone UI is fine, but hesitant to add more details
<anil> ACTION: anil to create an issue for concrete proposals around "can we just make text generic to not refer to desktops or smart phones or hand held devices" [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action17]
<trackbot-ng> Created ACTION-466 - Create an issue for concrete proposals around \"can we just make text generic to not refer to desktops or smart phones or hand held devices\" [on Anil Saldhana - due 2008-05-21].
Mez: need to make changes to 6.1.1 proposal?
tlr: 2 changes:
... fullscreen mode should be changed to low-chrome
mode...
... and also suggest to keep it as an example of where we are
now, not to introduce something new.
jvkrey: not sure i understand the change from no-chrome (fullscreen) to low-chrome.
Mez: we'll wait for a round of updates via mail on ISSUE-206
ifette: contentious issue is 6.1.1
<tlr> action-433?
<trackbot-ng> ACTION-433 -- Anil Saldhana to change robustness-apis-obscure-security-ui to include For visual user agents, browser chrome SHOULD always be present to signal security context information. This requirement does not apply when UI is explicitly dismissed by the user, e.g. by switching to full screen mode." -- due 2008-05-20 -- PENDINGREVIEW
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/433
tlr: suggest to cut off action 433 before the "e.g."
<tlr> ACTION: anil to cut off "before " e.g. by switching to [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action18]
<trackbot-ng> Created ACTION-467 - Cut off \"before \" e.g. by switching to [on Anil Saldhana - due 2008-05-21].
<tlr> presentation mode in desktops. However, it does apply when user switches
<tlr> to full-screen mode in smartphones." from result from ACTION-433
<tlr> trackbot, close ACTION-467
<tlr> close ACTION-467
<trackbot-ng> ACTION-467 Cut off "before " e.g. by switching to closed
<johnath> ACTION: anil to make spelling changes in ISSUE-209 [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action19]
<ifette> ISSUE-211?
<trackbot-ng> Created ACTION-468 - Make spelling changes in ISSUE-209 [on Anil Saldhana - due 2008-05-21].
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
<tlr> ACTION: anil to cut off action433 result before the "e.g. by switching to ....." [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action20]
<trackbot-ng> Created ACTION-469 - Cut off action433 result before the \"e.g. by switching to .....\" [on Anil Saldhana - due 2008-05-21].
<ifette> ISSUE-211?
<trackbot-ng> ISSUE-211 -- Make 8.3 SHOULD not must -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/211
ifette: when we have a good idea, but there are reasons not to implement it, we should use SHOULD
yngve: this applies to sensitive transactions, therefore credentials MUST really be protected in the same way
<Zakim> anil, you wanted to "add levels of sensitivity"
anil: agree with both - but we are lacking a definition for level of sensitivity.
ifette: in real life these issues have been considered, and it didn't seem sustainable.
johnath: when making guidelines we should stick to what is actually more important from security reasons, not what is more viable economically.
ifette: if we are too strict, sites will not adopt this
tlr: proposal: change from MUST to SHOULD, but add a strong reccomendation and a warning on implications.
ifette: do people really have concerns about the current amazon handling of this?
csant: Mez and johnath do.
johnath: I sympathyze with the decisions, but I do not feel confortable with these solutions.
tlr: a MUST might really help contributing to give a push to sites to actually go for more secure solutions
ifette: rather skeptical about
tlr's statement.
... should authoring practices be moved to a separate
document?
Mez: maybe it would be a good exercise for the group.
<jvkrey> +1 to tlr
tlr: the first 7 chapters are
really not addressed at authors, so maybe we really should move
them to a separate document
... we should not get rid of the remaining chapters 8 and 9,
but they might be more useful in a separate doc.
johnath: rather make edits and remove uppercasing MUST and SHOULDs than moving them to a separate document.
<ifette> A) change MUST to SHOULD
<ifette> b) Make the authoring practices a separate document
<ifette> C) Make the section non-normative
<ifette> D) do nothing
<ifette> E) abstain
<Mez> straw poll - sense of the room - totally non binding
<ifette> B
<johnath> B
<ifette> C
<PHB2> b
<ifette> B/C
<tlr> b
<johnath> B-C
<Mez> b, then d
<luis> Ericsson votes C
<yngve> D preferably
<jvkrey> b, I think this document is needed, and the audience that *really* needs it will be lost in the first 7 sections.
<csant> b/c
<anil> D
<luis> B is OK too
Mez: any objections to go for B?
<johnath> ACTION: tlr to create FPWD of best practices for web authors, remove section 8 and references from wsc-xit [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action21]
<trackbot-ng> Created ACTION-470 - Create FPWD of best practices for web authors, remove section 8 and references from wsc-xit [on Thomas Roessler - due 2008-05-21].
<Mez> 26 minutes; see you then
<tlr> RESOLUTION: split authoring best practices into a separate rec-track deliverable
RESOLUTION: split authoring best practices into a separate rec-track deliverable
<tlr> issue-202?
<trackbot-ng> ISSUE-202 -- Conformance model section makes outdated assumption about spec content -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/202
<johnath> ScribeNick: johnath
ISSUE-212?
<trackbot-ng> ISSUE-212 -- devices and low-chrome mode -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/212
Mez: what is the motive here?
jvkrey: my motive is to remove some confusion wrt to no-chrome/full screen modes and also be clear that even though your browser has "little chrome" it would not be excused from requirements on chrome
Mez: there's no RFC2119 language here
jvkrey: this is an example - appended to the RFC2119 paragraph
Mez: this is in 6.1.1? Oh
yes.
... this is motivating the "SHOULD"
... I personally have no intuition into what is in a low chrome
mode
yngve: very few UI elements, no menus or that kind of thing - almost all content
Mez: please turn that around and tell me what chrome is expected
yngve: it could be none - or it
could be some minimum functionality, small menus, but I'm not a
UI guy
... in some cases, a very small addressbar that pops up on
hover
... you can have it slide back down when not hovered
Mez: and why don't we want identity in a low chrome mode?
jvkrey: you DO want identity there
yngve: this is to distinguish from presentation mode
Mez: but this seems to say that we don't want it
luis: I read it that way as well
(conversation on hold while we sort out network stuff)
Mez: let's continue since scribe
has network
... I'm still concerned that switching to low-chrome should not
be a reason to remove SCI
tlr: I continue to be confused by
this
... we have usage modes where chrome is present, and SCI always
have to be there
... we also have usage modes that have no chrome, and we exempt
SCI display requirements
... but now we have these intermediate modes saying that chrome
is available on demand
... and I would expect us to require SCI *when chrome is
displayed*
... I would like to leave it at that relatively simple
distinction
jvkrey: is your concern taken care of it "low"->"no"
tlr: yes, if we are strictly talking about chrome/nochrome
luis: but that was what was originally written
tlr: I think that, at least to luis, "full screen mode" is a term that means different things to desktops vs. smart phones
PHB2: I prefer presentation mode,
personally
... that gets to the heart of it in that presentation mode is
focused on presenting "only the content"
tlr: another example is youtube
in full screen video mode
... it's not *just* presentation mode, I think the basic
definition is right
(more network debugging)
<PHB2> content-only presentation mode
Mez: so, how does this change the proposal?
tlr: I would propose
that...
...
<tlr> For example, a Web browser which is interactively switched into a full-screen presentation mode that does not display any chrome need not preserve security indicators in primary user interface.
<tlr> Or: For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface.
tlr: does that cause a conflict?
Mez: I like the precision of the second one
tlr: okay, I'm happy with either of these
luis: do we need the second case there as well?
tlr: okay, new text coming
<tlr> On the other hand, a user agent such as a smart phone which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators.
<tlr> ... in such a mode.
luis: in full screen mode, presentation mode?
tlr: I don't know - as a spec
reader I don't think I want to have a term in there, since I
was surprised to learn it was overloaded
... I would also suggest we drop the example in the TLS
indicator section
luis: this is okay to me
<luis> OK for me
Mez: how are we feeling about this? Problems?
jvkrey: I don't like that part of the smartphone, it applies to anything with a small screen
<luis> handled device?
yngve: we are talking about
browsers displaying on devices with "limited screen area"
... it could be even on VGA devices, like browsing-on-TV
tlr: this is an example
<jvkrey> On the other hand, a user agent with limited screen estate which has a usage mode that makes minimal chrome elements available does neet to preserve security indicators.
yngve: it is an example, but it should be generic
Mez: is jvkrey's text the entire proposal?
jvkrey: that is in addition to the first line
<Mez> For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface. On the other hand, a user agent with limited screen estate which has a usage mode that makes minimal chrome elements available does neet to preserve security indicators.
<tlr> On the other hand, a user agent such as a smart phone, airline seatback or TV set which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators.
<tlr> For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface. On the other hand, a user agent such as a smart phone, airplane seatback or TV set which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators.
<luis> ... in such a mode?
<luis> For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface. On the other hand, a user agent such as a smart phone, airline seatback or TV set which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators in...
<luis> ...such a mode.
<tlr> For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface. On the other hand, a user agent such as a smart phone, air plane seatback or TV set which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators in such a mode.
<Mez> a) replacing the existing two sentences with this one in 6.1.1, end of 2nd paragraph
<Mez> b) do nothing
<Mez> c) don't care
<PHB2> a
<Mez> issue-212?
<trackbot-ng> ISSUE-212 -- devices and low-chrome mode -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/212
tlr: there is a separate part to this issue
<tlr> second part; Replace "Note that ...." in 6.3 by "As in the case of the identity signal, there may be usabe modes during which this requirement does not apply."
tlr: I think that qualifies as a "friendly ammendment"
<Mez> a) replace the text in both 6.1.1 and 6.3 with the proposed text
<Mez> b) do nothing
<Mez> c) abstain
<PHB2> a
<Mez> phil already voted a; unless he votes again, that counts
<Mez> phil is awake
<johnath> a
<luis> A
<jvkrey> a
<csant> a
<anil> A
<Mez> c
<tlr> a
<yngve> a
<tlr> ACTION: tlr to replace text in 6.1.1 and 6.3 as drafted above. [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action22]
<trackbot-ng> Created ACTION-471 - Replace text in 6.1.1 and 6.3 as drafted above. [on Thomas Roessler - due 2008-05-21].
Issue-206?
<trackbot-ng> ISSUE-206 -- Smartphone Considerations -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/206
Mez: do we have text for here
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0067.html
johnath: if I remember correctly, we blew through all but 6.1.1 and ACTION-433 text
Mez: okay, the 6.1.1 text is not
an issue any more
... so what was the deal with 433?
... so is there a third place that should have the change from
ISSUE-212?
luis: didn't we agree that for 433, we would just stop short before the "e.g."?
johnath: yes
Mez: so if we remove the 6.1.1 and action-433 parts, do we take the rest
johnath: I think the consensus was that in the other places we would just drop the word "desktop" before "web user agents"
luis: that's okay
<luis> ACTION: anil to drop "desktop" in 4.2.1 3rd and 5th paragraphs [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action23]
<trackbot-ng> Created ACTION-472 - Drop \"desktop\" in 4.2.1 3rd and 5th paragraphs [on Anil Saldhana - due 2008-05-21].
luis: is the text in 5.1.1 okay?
jvkrey: device manufacturers is more generic
<luis> ACTION: anil to add "device manufactures" to list in 5.1.1, 2nd paragraphs [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action24]
<trackbot-ng> Created ACTION-473 - Add \"device manufactures\" to list in 5.1.1, 2nd paragraphs [on Anil Saldhana - due 2008-05-21].
<luis> comments on 7.2?
jvkrey: I propose again removing the "desktop/smartphone" reference and just mention "browsers"
<luis> Change from: For example, the location bar commonly found on desktop browsers is
<luis> often used to both display the "padlock" security indicator,
<luis> to "For example, the location bar commonly found on browsers is often used to both display the "padlock" security indicator,
Mez: ready to vote?
<Mez> a) make the change
<PHB2> a
<jvkrey> a
<Mez> b) do nothing
<csant> a
<Mez> c) abstain
<johnath> a
<luis> A
<anil> A
<yngve> a
<Mez> c
<luis> ACTION: anil to drop word "desktop" in 7.2 1st paragraph [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action25]
<trackbot-ng> Created ACTION-474 - Drop word \"desktop\" in 7.2 1st paragraph [on Anil Saldhana - due 2008-05-21].
<Mez> issue-199?
<trackbot-ng> ISSUE-199 -- WebAPI does not specify any TLS error handling for XMLHttpRequest -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/199
Mez: alright, the only issue we have against wsc that does not have a resolution is ISSUE-199
(fallen off - redialing)
tlr: this is an issue against
another working group's last call, as much as our own
... if we can resolve it by LC, great, but basically I think
I'm ready to time-out on it
... there are two obvious ways to solve it, each of which
requires an obvious change to our spec
Mez: the message implied that they need to make changes
tlr: yes, but our change would be
to acknowledge their decision
... I think we've done what we need to do, and we can talk it
over with the chair tonight
Mez: we are out of issues
<all> : woohoo
Mez: other things before last call
<PHB2> woohoo
Mez: I think we should remove the appendices
johnath: I have to read them
again
... I'm in favour of removing them for june LC
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#appendices
Mez: any problems, any discussion?
tlr: question - where do we move
them?
... am I about to create another document?
Mez: too bad we can't preserve it
in a wiki.
... this version is around forever
... so they are not lost
tlr: I can take an action to move it to a separate directory called "post-june"
Mez: is that the "more correct" thing to do?
tlr: that's what I would do
Mez: alright
<Mez> a) remove the appendices, to another directory/file
<tlr> http://www.w3.org/2006/WSC/drafts/wsc-content/
<Mez> b) do nothing
<Mez> c) abstain
<tlr> (that's something else)
<tlr> a
<Mez> a
<anil> A
<csant> a
<luis> A
<johnath> A - with the assumption that we will revisit these, since many of the original authors are not present at the moment
<jvkrey> c
<PHB2> a
<yngve> A
<scribe> ACTION: tlr to move appendix content to a new document for "post-june" [recorded in http://www.w3.org/2008/05/14-wsc-minutes.html#action26]
<trackbot-ng> Created ACTION-475 - Move appendix content to a new document for \"post-june\" [on Thomas Roessler - due 2008-05-21].
Mez: anything else before LC?
tlr: one half-serious question is whether the current title remains relevant
Mez: I think there's Indicators, Experience, and Trust
tlr: So, where's "trust"
Mez: in the authorities, in our continued reliance on validated and AA certs
tlr: my point would be that I'd love us to come up with something that is more self-descriptive
luis: "Strong TLS algorithms" lacks definition
Mez: this is a recent issue, and
we resolved it
... ISSUE-128 generated ACTION-426 to resolve this
luis: I see, some text coming from bill
Mez: it will get taken care
of
... anything else?
tlr: FYI section 8 and the appendix are gone
Mez: Would it be appropriate to ask the group to take this to last call, presuming that the pending issues are resolved unsurprisingly?
johnath: +1 for me - I have no hidden issues or new suggestions
<luis> +1
<tlr> +1
<jvkrey> AOL
PROPOSAL: That the group take this document to last call, presuming that pending actions are resolved and issues closed unsurprisingly, along with minor editorial changes.
<jvkrey> = +1
<PHB2> +1
<csant> +1
<Mez> a) support the resolution
<Mez> b) do not support the resoution
<Mez> c) abstain
<johnath> A
<yngve> a
<jvkrey> a
<csant> a
<tlr> a
<PHB2> a
<anil> A
<luis> A
<Mez> a
<Mez> we resolve
RESOLUTION: The group will take this document to last call, presuming that pending actions are resolved and issues closed unsurprisingly, along with minor editorial changes.
Mez: editors - ETA on final document
anil: should be done by next week
tlr: overloaded through this
month, not making any promises till early june
... ETA June 10
<PHB2> can someone buy me a troll?
<Mez> phb, seriously?
Mez: I plan to focus on usability testing next week
ifette: I will take a first pass on cleaning up minutes, per tlr's request
<Mez> thank you all; have a fine day/ evening