approve minutes

wsc-usecases updates

tlr: no closed action items
... tyler, can you give us an update?

tyler: in tracker, only one
action open against note to incorporate tjh's review
... that action is marked pending review, expecting tjh to go
through doc and make sure it's good
... also got an email from Al Gillman, problem when reading
note using screen reader. The table doesn't come out well
... he has people who will contact tyler re: how to reformat
that
... want to turn table into list, tyler not so keen on because
it's not so good pointing out what isn't covered

tlr: what table?

tyler: at the top of the list of
scenarios is a table

tlr: takeaway is there is some
editorial stuff left, tlr happy to provide help if he can

tlr: see this email
... lengthy discussion thread re: plugins and how all of this
applies to plugins
... should we go forward taking effectively a mix of the text
that Mez had proposed in Dec. with the change that Mike had
proposed, or...?

ifette: i have no problem with
the text in the email that the link tlr posted contains

tlr: reads text

yngve: would like to see the new
version in written form
... should post somewhere

luis: only minor changes to
proposed text, just clarifications
... first one is about user experience
... according to original text, says content should be designed
to offer same UX, that's difficult, propose to change this,
only thing web designers control is trust and TLS consistency,
UX is on client side

tlr: so let me understand
... by the same argument, tls consistency is a UA question as
well
... after all, the UA selects the key of trust roots
... direction is to say that having the same security
experience is a goal which designers should aim for
... disinclined to say TLS and trust anchor consistency
... suggests for first part, instead of "designed to offer"
-> "designed to enable"
... "designed to enable a consistent UX"

luis: maybe something more
releaxed
... enabled more relaxed, better

<tlr> "designed to enable a
consistent user experience across..."

tlr: happy to do that

luis: second comment
... about website owners operating tls protected sites should
anticpate mobile use
... may have constrained capabilities OR restricted trust
anchors
... sounds like two options
... but really one is a consequence of the other

yngve: point about certificates,
it is possible for a CA that is not embedded in clients to be
cross-signed by another CA
... similar to EV

tlr: let's keep that out of our
document
... have any concrete proposals?
... my inclination would be to take the text for first comment
as agreed above, and taking luis's second change as is
currently phrased

RESOLUTION: issue
closed, move on

tlr: suggests yngve takes issue
to phrase your problem more generally
... and tlr should close out 130

ISSUE-114: Self-signed certificate
changeover

tlr: what is currently proposed
is a UX that makes cert changeover for SSCs basically
impossible
... how do we deal with it
... any way to have changeover to a different SSC is a way to
have a MITM attack
... no compelling solutions
... ideas?

yngve: think X509/PKIX had a
mechanism for telling what's the next key/whatever
... problem is that SSCs are going to be made by people not
aware of it

tlr: doesn't fit use case

yngve: might work for some minor
use cases
... not general use case

tlr: can always say that there
should be an interaction that provides ample warning and a
reasonably complex user interaction that makes it hard to
casually accept cert, but we end up having a coin toss between
an attack going through and a new legit cert
... we might in fact be best served by saying MAY do
override
... tempted to throw out that as a proposal for resolution

tyler: will interested parties be
at f2f?

tlr: some, some will be on
phone

<bill-d> good drop off

tyler: sort of thing that mez was
talking about, fast-track?

tlr: no resolution

RESOLUTION:
none

ISSUE-129: Should we say anything about scoring
techniques?

<tlr> ISSUE-129?

<trackbot-ng> ISSUE-129 --
Should we say anything about scoring techniques? -- OPEN

tlr: tjh had proposed a
rewrite
... not sure he sees a rewrite in there
... wonder if current status is to merge in

<Zakim> ifette, you wanted to
jump on this issue

ifette: no
... very against merging language into the document
... feel very strongly against SHOULD
... because a non-binary score is useless to users
... changes in score might be useful as a signal that we should
warn something
... but a user seeing some number of bars, a percent, a score,
a meter, is totally useless

tlr: will defer this issue
... thanks for having shown up here
... one of the shorter calls in a while, see some of you next
week in Palo Alto