Current state of editor's draft / IdentitySignal

The current state of the editor's draft is visible online:

  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html

This version needs grammar, spelling, and style checking, and a lot
of work, but I hope it's useful as input for next week.

Note that I haven't yet discharged my action item from today's call,
so the favicon material is lingering in the form in which I put it
in before the call.  I'll work on that later, as it's not in the
critical path for next week.  (If it is, MEZ, let me know.)

The draft reflects the structure that I had circulated last week.
You'll find the IdentitySignal proposal plus elements material from
SecureLetterhead, EV Certificates, and the self-signed certificate
handling proposal in section 5.1.

RecRevisitingPastDecisions is not yet reflected.

  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal

The requirements in 5.1.1 are almost vanilla from Johnath's
proposal.

Obvious open questions there:

>User agents SHOULD rely on technologies which are accepted as
>industry standards of identification when populating this indicator.

>User agents MAY augment the information presented in industry
>standard identity technologies with supplementary information from
>other sources, if this serves to better identify the site for the
>user.

This is basically an open-ended normative reference to undefined
"industry standards."  I'd suggest to remove this.  

Instead, I propose to use the following language:

>User agents MAY augment the information presented with supplementary
>information from others ources, if this serves to better identify
>the site for the user. User agents MUST ensure that any such
>information is sufficiently trustworthy, and sufficiently
>authenticated.

(This is still too fuzzy for a final version, but probably good
enough for the moment.  I might rephrase between now and the call.)


In the techniques part, 5.1.2, I've dropped in material that mirrors
other proposals.  The wording is new; it's actually not obvious
whether we'd want to sell this as mandatory techniques or as
requirements -- the effect is essentially the same.

You'll notice that some of this material relies quite heavily on
terms and definitions found elsewhere in the draft.  Most of these
terms are links to the respective definitions, so it should be
reasonably easy to track down what's meant there; some probably
point to anchors that don't exist. (*) If you stumble over one, ping
me.

(*) As an aside, Tyler, that defies the hypothesis that one person
will come up with the same nickname for the same concept in a way
that is usefully compared by a machine. ;-)

You'll notice that most of the TLS-related discussions that we had
(self-signed and "what is a secure page") are masked behind these
definitions; they essentially describe the components for a browser
state / history based trust model which would be concretized in the
interaction and error handling sections.

Anyway, for the purposes of next week's discussion, I'd suggest that
we take the definitions as working hypotheses, and focus on 5.1.1
and 5.1.2.

Obvious substantive questions in 5.1.2 (beyond the one whether we're
talking about a fundamentally useful proposal) include:

- When should logotypes be displayed?  (EV, trusted CA, whenever
  present in a successfully used cert?)

- What logotypes?  (Issuer, CA, community?  Any?  All?)

- What identifying information should be displayed?  The current
  draft has the Issuer and Subject fields' Organization attribute
  from the certificate if the certificate can be trusted
  (simplifying a bit here); there might be address or jurisdiction
  information worth exploring.




Before we can go into fine-tuning chapter 4 (and into addressing the
issues called out in parts of the draft), the following steps need
to occur:

- Many of these definitions (in particular the TLS-related ones)
  need refinements and changes before they can be considered as
  actually useful; yet, the text should give a good sense of the
  general direction that's suggested. (Most of them simply try to
  capture common concepts that we need to deal with anyway.  The
  interesting ones relate to what is considered trusted and what
  isn't.)

- I'd expect the trust model aspect inherent to this to lead to
  quite a bit of discussion as we move forward; this relates to our
  goal of minimizing trust decisions.

However, both of these aspects should be sufficiently orthogonal to
the IdentitySignal discussion to be outside the critical path for
next week's meeting.



Finally, you'll also notice a new conformance model in section 2.1,
and a very basic interaction and content model in section 3.  The
section on conformance labels (2.2) is currently a placeholder.

I'm confident enough about the basics of 2.1 and 3 that I think
review and input on the list is useful at this stage.  I expect that
section 3 will grow with material from the glossary as we move on.

"Web User Agent" and "Web Page" are taken from WCAG 2.0; I hope that
helps obtain consistency with the WAI folks.

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 3 August 2007 10:38:18 UTC