Web Security Context Working Group Teleconference

<trackbot> Date: 06 August 2008

<tlr> ScribeNick: tlr

convene

mez: hi folks, it's a small call, but still

<Mez> http://www.w3.org/2008/07/16-wsc-minutes.html

RESOLUTION: approved, to be installed in location above

<Mez> http://www.w3.org/2006/WSC/track/actions/open

items at risk / how to plan for CR entry

<scribe> ScribeNick: ifette

Items at Risk

<Mez> http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk for candidate entry

mez: Here's the table for planed implementation details

<Mez> http://www.w3.org/TR/2008/CR-WCAG20-20080430/

mez: WCAG has an items at risk section, we might have a similar section
... wanted to talk about our options here

<tlr> Scribe: IanFette

mez: look items at risk section
... look at success criteria 1.4.8
... mez reads
... we have basic and advanced conformance levels
... basic is MUST, advanced is MUST + SHOULD

<Mez> http://www.w3.org/TR/wsc-ui/#conformance-levels

mez: for any MUSTs we need at least 2 implementations (period).

tlr: correct

mez: For any SHOULDs

tlr: Question as to whether it makes sense to look at this on a feature-by-feature basis, or also a performance level basis
... You need to have at least two implementations for each feature. What we make out of that is up to us
... we have some leeway in how we design things
... what makes sense? Something like "We want to have 2 for each must, 2 for each should, at least 1 that can show basic, at least 1 that shows advanced"
... that could be one way to go
... dont know if that criteria would succeed
... We already skirt must and should already by having multiple conformance levels
... so we should follow WCAG's lead

ifette: does advanced have a chance of being implemented?

mez: dunno
... that's the point of items at risk

<tlr> http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

tlr: look at entrance criteria
... should be able to demonstrate two implementations
... if we come out of last call without too much change, can go into candidate rec, and say "here are the features we might remove"
... present document is clear that the WG must identify in detail what features are at risk
... how do we demonstrate this in a useful way is the question

mez: somewhere there was "should have 2 interoperable implementations"

tlr: yes
... we have a bunch of must not and should not that are operational enough
... other point that was interesting is that they were not deeming implementation by "not exercising" a requirement sufficient

<tlr> ... e.g., logotypes not being implemented

mez: As tlr pointed out, being conformant but not implementing a feature doesn't count towards 1 of the 2 implementations of the feature
... going in, I would argue philisophically that as a starting place for each one, we really want two interop. implementations for anything that is MUST/MUST NOT
... feel same way about SHOULDs

phb: SHOULD NOT might be tricky
... if we have a situation where a certain browser does something, and we would like it to do things similar to that to make sure that they do not do something in a particular way, we're unable to talk about that area at all

<Mez> good point

<Mez> is there a downgrade path?

<Mez> there is no MAY NOT

phb: one of the things we're trying to say is that if you do a feature, it must not screw the pooch

<Mez> but we did make some MAY negative somewhere I thought

phb: still want to be able to talk about features that people may not do because if they do them badly, it will cause security issues

tlr: to clarify, we have had at least one case where we say UAs MAY do something blah blah
... if that is the case the interface MUST be task centric
... by itself it's sane
... however, if nobody implements that MAY
... would assume that we would strike it totally
... tricky

mez: would like to find a concrete example of what phil is referring to

<Mez> http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk

phb: Part of this anticipates things such as mobile web
... only just starting
... some of what we are trying to do is get ahead of the curve

mez: example?

phb: where we talk about flash and pdf and so-on being integrated more tightly

tlr: where we talk about conformance in the presence of plugins
... thought we solved that one
... dont think that's an example of being ahead of the curve

mez: will play by ear
... MAYs OTOH don't know how we feel about 2 vs 1 implementation
... given that it says all features SHOULD have two, doesn't break down to must/should/may
... but MAY is our out to say something even w/ no backing implementation

tlr: do we have any MAYs that come without context of accompanying MUST/SHOULD

mez: petnames

tlr: petnames themselves have requirements though

tyler: all MAYs

<tlr> http://www.w3.org/TR/wsc-ui/#sec-petnames

tlr: yes, earlier point re: trivial
... would argue that any MAY that comes with a set of criteria like this
... actually should have some implementation support

mez: 1/2?

tyler: partially done
... will have at least 1

tlr: if conditioned on a MAY, does that relax the criteria for the MUST/SHOULD?
... do not believe anywhere we say a browser MUST implement TLS

ifette: happy with zero for MAYs, one would be gravy

mez: anything re: accessibility is closer to zero
... audio logotypes etc

<PHB> got to go, traffic accident means I have to pick up kid

tlr: what is at risk is presumably the criteria about rendering of audio logotypes

phb: writing up in cab forum

tlr: suspect high risk

tyler: with altnames in certificates, firefox provides no apis
... (question to phb)
... follow-up offline

tlr: this is totally optional, implementations may or may not support this, but if they do support we have comformance language
... similar to petnames

mez: you seem to believe that if there are must or shoulds that you can get around by not implementing, you would still argument for two implementations

tlr: yes
... also something around independent implementations
... if you look at "exit criteria" in wcag

<tlr> http://www.w3.org/TR/2008/CR-WCAG20-20080430/#statusnote1

tlr: there are at least for the websites an explicit criteria that the websites should be distinct and independently developed
... to what extent do we address this
... thing we can defend is two implementations

mez: two different versions of same browser might not be interesting

ifette: firefox + firefox extension does not count as two implementations of the same feature

tlr: yes, but if we had two separate extensions that exercised a feature
... that would be different
... two distinct implementations of a feature
... precise meaning in presence of plugins is interesting question
... subtle implications

mez: sounds good
... feeling good about general discussion on this topic
... anything else on this topic?
... SHOULD/MUST/MAY discuss now?

tlr: next step?

mez: next step is to fill out the table
... map out what we need to do to get to CR entry
... for anything where we don't have a statement from two somebodys
... we need to have a heartfelt discussion around that, flag as at risk
... claro?

tyler: who is responsible for writing code? FF, Opera, Tyler with Petname?

mez: nobody else she knows of

tlr: staikos has wandered off
... could be interesting to ask him for review, if he is interested

mez: paul doing anything?

tlr: ping

NOTE: generalize into we might want to ping some of the less active WG members

mez: OK, that's it for today
... next time on our favorite show...
... ready to talk about testing, or wait for a while?

tlr: would prefer if that discussion included a few choice people
... rachna, maritza, serge would be good peepz

mez: could we at least talk about the non-usability testing?

tlr: sure

ifette: I may be in beijing next week

mez: adjourned