See also: IRC log
RESOLUTION: Minutes from last week approved
VQ: Next telcon 16 January
Regrets from DanC, timbl, DaveO (at risk)
VQ: Agenda accepted as published
ER: Comments on Noah's document are the most urgent item
NM: Agree we shouldn't lose it, but let's delay a bit in hopes DaveO will join
VQ: Agree to postpone that item
for a while
... Stuart, our new chair, cannot make this timeslot
... I'd like to have him join asap, even before he takes over
as chair
... We'll know the new participants by the end of this
week
... Everyone please send your timing constraints to
[email protected]
<noah> Noah's pretty sure he sent an email with scheduling guidance.
VQ: TV to scribe, or ER if TV cannot next week, to be confirmed
VQ: Created and announced this
per our discussion last week
... Waiting for input -- HST, DanC -- thoughts?
HST: Don't know anything about UTF7, no clue
<DanC> nor do I know about the security issue
DanC: Who voted this one on as an issue?
ER: Me, for one -- I'll do some fact-finding
NM: I'm also pretty ignorant -- it would be very helpful to get an entry-level summary of the issue and what the main positions are, thank you
[Dave Orchard joins the call at 25 past the hour]
VQ: Thanks to ER, will wait for his input
http://lists.w3.org/Archives/Public/www-tag/2007Jan/att-0007/TAGEnterpriseServicesWhitePaper.html
<noah> Note that a few minor typos, etc. that I intend to correct are at:http://lists.w3.org/Archives/Public/www-tag/2007Jan/0012.html
<DanC> my review, in sum, is "thumbs up"
ER: I sent my comments, I think
it's a good summary of where we stand
... It's a good document
DaveO: I like the focus on use
cases
... Not sufficient mention of two things we've discussed in the
past:
... 1) The 'technology gap' which discourages option (3), e.g.
EPR->URI conversion -- the limited discussion of this
doesn't go far enough
<noah> From the paper: Note that the SOAP Recommendation provides for such use of HTTP GET, though support for it is not widely deployed today.
DaveO:2) Just a history of the
TAG's interactions, w/o a discussion of the technology/state of
play
... I'd like to see more there, describing what we wished had
happened
<DanC> (I would appreciate a bit more rah-rah around "Web description languages (e.g. WADL or the WSDL 1.2 HTTP Binding)" )
NM: Wrt EPR->URI mapping, I
could mention that, I guess my scepticism about likely success
got in the way
... I'd rather look towards a 'best practice' of not using
Identifying params
... DaveO, would that help
DaveO: Yes
NM: There is the mention of SOAP via HTTP GET
DaveO: That's not what I was missing. . .
DanC: What were you looking for?
NM: I understand DaveO never liked that (SOAP via HTTP GET) approach
DaveO: What I was looking for was something along the lines of converting XML requests [?] into headerless SOAP requests
[Scribe unsure -- DaveO, please correct]
<DanC> (if Dave has a 1/2hr or whatever to suggest a few bullets/sentences about gaps and ideas for filling them, I think it's worth Noah's time to try to integrate those.)
NM: The lack of detail on the
history was because of the guidance I got to try to be positive
and forward looking
... I can be more forthcoming on the day, if I'm asked to
speak
DanC: I like the length as it
is.
... About gaps and how to fill them, it's a bit subtle, but the
detail is all there
... Emphasizing the solutions more, with help from DaveO, would
be good, but not required
NM: Two different directions: more technical details (e.g. SOAP MEPs)
<DanC> (yes, there are only so many gaps you can discuss in 5 pages; the WADL gap is one I'm interested in. I can see room for the EPR mapping, though I'm not as excited about it. I don't see room for much more.)
<dorchard> http://www.w3.org/2001/tag/doc/ws-uri.html
DaveO: The above pointer is one example of something which wasn't taken forward, which might have helped
DanC: What about the printer example?
<DanC> (yes, noting http://www.w3.org/2001/tag/doc/ws-uri.html in passing in the 3rd printer scenario seems worth a sentence or two)
DaveO: Well, at least some of the EPR-based SOAP requests could have been handled via GET given that proposal
<DanC> "Note that over the course of the last [n] years, a number of interesting proposals have been [darn]. including..."
NM: So, not to discuss in detail,
but frame a reference to this as a way of facilitating the
integration suggested in (3)
... and some others - - I would be happy to take suggestions -
- if others agreed?
DanC: three or four things?
DaveO: Yes -- the above, Sam Ruby's, ...
NM: Happy with mentioning both WADL and WSDL 2.0?
DaveO, DanC: Yes
NM: I'll integrate pointers when received from DaveO, look for a punchier way to discuss the description stuff, and make it valid XHTML
<DanC> (I'm more comfortable deciding today than last time, but I don't need a decision)
RESOLUTION: NM to submit on behalf of the TAG once that's done
VQ: M-E Zurko sent detailed comments -- ER?
Comments are at http://lists.w3.org/Archives/Public/www-tag/2007Jan/0009.html
Draft is at http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
ER: She was happy with most of
the Good Practices
... some discussion of password masking
... Also another bit of feedback contra password masking on
handhelds
DanC: New phone masks after a second or so
HST: ditto
NM: So, we say "you must mask, pretty quickly"?
ER: Update the discussion to cover the handheld case?
NM: Dilute things so that it stays a fully general rule
ER: But what's "a mobile device"
NM: That doesn't matter, it's a counter-example
<Zakim> ht, you wanted to say it's not a counter-example
HST: I think it's broken
... and we should say so
ER: The case in the email is the OCR case
<noah> From Ed Davie's mail:
<noah> "More substantially, PDAs which use handwriting recognition are good examples of devices where password masking is not a good strategy. Handwriting recognition is sufficiently unreliable that the user will want to see the characters entered to make sure they are correct. At the same time, with such devices it is easy to orientate the screen to avoid shoulder surfing."
ER: on my handheld, the characters show after recognition, but are then masked
DanC: A delayed mask is a mask
ER: The HTML says it's to be
masked
... without that information, there's no basis for detecting
password fields
DanC: This note isn't about authoring, it's about UA's. . .
ER: I agree there's flexibility in how 'masking' is done, e.g. after a delay
<DanC> (I prefer the formulation that says: if you mask on the screen, you have to scramble over the wire, actually.)
HST: How about saying "Exactly what masking amounts to will vary depending on input medium"
DanC: Not clear it's worth the screen space
NM: What are the current implications of "type='password'"
ER: Puts you into the space where this finding applies
NM, ER: Discussion about javascript submit-hooked scrambling
NM: I'm worried in the presence of javascript onsubmit, the UA can't implement the finding
[above is scribe's summary of longer discussion]
DanC: The conservative
interpretation (type=password + non-secure connection) will
warn in that case
... because detecting encryption in the Javascript is
impossible
<Zakim> ht, you wanted to ask how we're converging on a change, if any
NM: We've focussed too narrowly on the UA -- no way this finding covers the case where someone doesn't label a field as type='password', but uses the value as a password
HST: Need to focus discussion on what we can say with certainty
ER: I think we should drop it
DanC: I don't think just because it's hard we should drop it
HST: I'm not convinced we can't produce a useful result, by taking NM's idea of including the author in the mix
<Ed> its not that its hard, its that the TAG cannot make everyone happy in this one and we're not willing to make anyone unhappy to resolve the issue.
DanC: I'm inclined to ask Mary-Ellen if she has better wording. . .
<noah> MEZ says: It's not clear to me actual security and user trust are tightly coupled in general, or in the case of the Web. User trust comes from perception. The best work I've seen on that is from: Andrew S. Patrick, Pamela Briggs, and Stephen Marsh, "Designing Systems That People Will Trust", Security and Usability: Designing Secure Systems that People Can Use, ed. Lorrie Faith Cranor and Simson Garfinkel.
<noah> She was commenting on: "Security on the World Wide Web is an important issue which needs to be addressed or mistrust of the Web will limit its growth potential."
<noah> MEZ also says: "There are a bunch of other places passwords can leak, starting with server logs, and going on to any (temporary) files written by either the browser or server. My product experience is that users do not want their passwords in the clear anywhere. Bugs that leave passwords in the clear immediately heighten user mistrust of the system. I'm guessing that the finding is restricting itself to the transmission because there's where the sufficient tec
NM: Let's ask MEZ to propose wordingon any or all of the points she's raised.
DanC: +0
HST: I'm happy with both the MEZ situation and the masking, but not the Yahoo example
DanC: Please send that to www-tag
HST: Will do
NM: I am not sure we are describing Yahoo's usage correctly
HST: I'll be careful not to assume that
<scribe> ACTION: HST to send email about onsubmit hooking via javascript and its impact on PWintheclear to www-tag [recorded in http://www.w3.org/2007/01/09-tagmem-minutes.html#action01]
<DanC> Subject: sitemaps.org, siteData-36, standardizedFieldValues-51
<DanC> Date: Tue, 21 Nov 2006 08:55:06 -0600
VQ: DanC, what was the thing which reminded you of this
DanC: Please withdraw that old action, I am not going to do it
<DanC> http://lists.w3.org/Archives/Public/www-tag/2006Nov/0106.html
DanC: Google, Yahoo and Microsoft
have released a site-map story
... Norm said he was interested in discussing this
DaveO: Me too
<DanC> "Yahoo, Google, and Microsoft" -- http://www.sitemaps.org/terms.html
DanC: Is the only pblm that they're squatting on http address space, by using a well-known URI (robots.txt, sitemap.xml)?
DaveO: I don't know of a better
way
... This is part of discovery of widgets as part of the
light-weight services explosion
DanC: Summary: Noted, return to 'someday' pile
VQ: I'll drop DanC's old action,
the issue will go into 'sleep' mode
... Adjourned until next week