TAG f2f, day 2, morning

13 Jun 2006

Ben Adida (invited guest), Tim Berners-Lee, Dan Connolly, Noah Mendelsohn, Dave Orchard, Vincent Quint, TV Raman, Ed Rice, Thomas Roessler (guest, in part, by phone and IRC), Henry S. Thompson, Norm Walsh
Vincent Quint
Henry S. Thompson


VQ: We will try to explore the entire security area.

Review of today's agenda

VQ: Conclusion of URNsAndRegistries-50 discussion from yesterday; Security; CURIEs


TBL: At IRW2006 workshop, at WWW2006, Steve Pepper presented his PRI proposal (Public Resource Identifiers), using http URIs
... Proposal to make a serious effort to promote this, take it to ISO, IETF, OASIS to try to get this accepted as the way to do http URIs for persistent identifiers
... Maybe organised via an XG at W3C
... Would be a positive alternative to XRIs, etc. . .

NM: Is this just an organisational thing, or is there technical content?

DC: Well, it does take us back to NamespaceDocument-8 -- Pepper's proposal isn't specific wrt what is at the end

NM: So the PRI for my budget will get me my budget. . .

NW: Per the slides, what you get is always a PRD, which has a to-be-agreed structure

TBL: Concerned that underspecification of PRD will let in a lot of stuff that doesn't really belong there. . .

ht: I think Tim raised this now because what we have in the finding is negative in tone, wheras this is a positive proposal.

ht: I am not sure how we put it into a draft finding.

ht: I am not actually happy with sections 4, 5 and 6.
... I think the conclusion one shoul ddraw is not obvious.
... Sounds too much like "HTTP doesn't work for this".
... I'd like to understand what we should do about it.
... Noah's question was a good one: is this a finding or a finding and a note?

DO: Noah said the style was a bit argumentative. I disagree. We have been asked to evaluate URNs and registries, and we should lay out the facts and conclusions abiout using URNs for namespace names.

NM: Not so much section 4 I was pushing back on so much as section 5, which was much more specifically critical of XRIs as of this particular date

DO: Perhaps could be toned down, certainly the high-road should be taken, but I do think we should be explicit about XRIs

TVR: Could just focus on the properties of XRIs w/o looking at the XRI proposal as such

DO: Well, I tried that, but people pushed back because it wasn't grounded in reality, focussing on the real thing really helps

DC: I agree, we need the detailes, but should tone down the rhetoric

NM: If the detail helps the next guy, that's good, but if it's going to be dated in a year. . .

TBL: Is what we commented on going forward, or changing?

<noah> Link to Henry's mail on state of XRI proposal: http://lists.w3.org/Archives/Public/www-tag/2006Jun/0013.html

<noah> Henry's mail in turn links email from James Bryce Clark: http://lists.oasis-open.org/archives/xri/200605/msg00025.html

HST: I believe they've put their existing draft to one side and are reworking it

HST: Based on some minutes of their work that I've seen, they seem to be focussing on identification of organizations, etc.

DC: They don't say they're "withdrawing" it.

HST: Right, but it looks like there will be a difference in focus, although the underlying technology may be similar.

HST: Original focus was on identifiers for existing resources like namespaces, documents, books.

HST: My sense is that they are shifting to more RDF-like focus, I.e. identifiers for people, institutions, etc.

DO: No idea what that TC is going to do
... I think we should answer the state of the world as we see it publicly

HST: I agree

TBL: Message http://lists.oasis-open.org/archives/xri/200605/msg00030.html says to me that they're just gathering momentum
... and planning to dispel misunderstandings and promote the business case

HST: Net-net, is this doesn't affect what we do now

DC: Are we agreed that it's too pointy, we need to pull back from that a bit

NM: I think we need to try harder to understand their perspective
... There are things they're doing with the sub-structure of the XRI which you can't do with URIs

DC: I thought I showed how you could in fact do them

HST, DO: We can take this another round now

DO: Absolutely my intention to walk in their shoes

VQ: Are we done?
... What about splitting the document?

HST: Not much support

NM: I'm OK with that

HST, DO: We'll try to get another draft by 27 June

Security; State in Web Application Design


Reviewed by EdR, NM and NW

ER: I've sent a long list of comments, mostly editorial

<Norm> http://www.w3.org/2001/tag/doc/state.html

<noah> Date space copy of draft finding: http://www.w3.org/2001/tag/doc/state-20060419

<DanC_lap> Ed's review of draft state finding

ER: Any user-identifying information should be the way of talking about it, not specific phrases such as passwords, names, etc.
... The risk is that learning that I bank at xxx bank, means that seeing my acc't number in the URI allows them to join up the dots
... So distinguishing name from account number, as section ??? does, is a mistake, should all go via https

DO: Two conflicting thoughts. . .
... Using SSL is a common thread in a lot of WS Security work
... But a lot of other folk are saying no, that doesn't work, doesn't deal with intermediaries

ER: Well, even if you don't want to commit to SSL, you need to say "not in the clear" about a range of stuff

TBL: So what do we recommend?
... I can't bookmark my checking account

ER: You should be able to, you don't need to have your account number in the clear in that URI

<tlr> For that discussion, I think the first question should be why don't you want your account number in the URI?

<tlr> If it's because it connects to your offline existence, then use some other online identifier and put that into the URI

TVR: So you use a hash of the acc't number in the URI

NM: This interacts with the metadata-in-URI issue

TBL: So what do we propose

ER: http://mybank.com/checks/12345
... Takes you there after authentication

NM: Back to accounts, not checks
... Bank has to decide whether the account number is sensitive or not
... If they decide/we advise that it is sensitive, then obviously it shouldn't be in the URI

TBL: We think it is a danger

<noah> Thought experiment. We're looking for rules. Maybe some of the rules should be:

ER: the ambiguity of the check URI above is just like myyahoo, I can't pass it to you

<noah> 1) Don't put into a URI information that needs to be protected from widespread view

<noah> 2) Access control should be orthogonal to ability to name. In many cases, there will be a URI to Tim's bank account and if I reference it the system will >try< to reference the same thing as when he does. Access control will decide whether I can indeed access his account.

TBL: Contrast http://mybank.com/858f6f432xxx/check/12345

. . . where 858... is a hash including tim's acct

<tlr> I'm not sure about 1) -- often, the fact that I'm accessing a certain resource (even when it's public) might be privacy-sensitive.

TVR: The business rules for managing such URIs is the bank's business

<tlr> Where's the line between that and "protected from widespread view"?

TBL: What the thing identifies is a matter for the TAG, the behaviour follows after

TVR: So it could be that it identifies "TBL's check 155 to TVR" or "The current logged-in user's check 155"

TBL: The second is a bad idea

<timbl> We are at tyhe generic resource issue

TVR: But consider a parcel post company -- surely giving out a "Status of last five parcels for the logged-in user" is perfectly reasonable

NM: Good practice is that the URI refers unequivocally to e.g. a particular check of a particular account

<tlr> 1. user identifies themselves -> http://parcel.com/user/hisnumber

NM: That's orthogonal to access control -- he can send me that URI, I can try to dereference it, then authentication takes over and I may or may not get anything

<tlr> (actually, the user in this case identifies the resource he wants to access)

<tlr> 2. authorization decision based on identifying the accessor and authenticating them.

TBL: So the starting point is that I have a screen of my account, the URI at the top is what it is, my session times out, I hit 'Refresh', get reauthenticated -- I should get back to where I was, and today that doesn't happen

NM: Right

ER, TBL: Two points -- shouldn't have account numbers in the clear, should have reusable URIs

NM: So that access control mechanism has to work

TVR: Handing out the hash is different in at least this way -- it doesn't allow exploring an account number neighborhood

BA: It's also crucial that the authenticaiton process for the hash doesn't take you to a screen which shows the account number

HST: Hash also different because it doesn't give away a piece of the puzzle

TBL: Yes, it does -- black hat has found my mother's maiden name, can try to use the hash, give MMN when can't come up with password

TVR: Most existing attacks are not very sophisticated technically, mostly social engineering. . .

TBL: So we've agreed that public stable URIs are OK, where we don't think publishing account numbers is OK, because the technology gives additional protections compared to paper. . .

NM: We shouldn't be giving advice to banks, just explaining the tradeoffs

<tlr> I wouldn't go into details about hashes -- if you just hash a, say, 10 digit bank account number, then it's easy enough to brute-force that.

<tlr> What you really mean is "some random string that can be mapped back to the account number in the bank's systems." I'd leave it at that...

ER: So are we saying that Yahoo should give Tim a URI for hisyahoo that he can send to me

??: They could, but they don't have to

NM: We're connecting up to the generic URI paper from TV

BA: There was a stand for Flexi at the WWW conference which provided a plugin to log all the URIs I visited -- weak access control

TVR: If some of the 'auth' bits are going in the URL, that's a red flag.

<benadida> the flexi (forgetting spelling) plugin generates a large random auth token, which it provides in the URL for viewing my "list of past searches." If you click on one of these past search results, the token is sent in the referrer log. That's the kind of site we need to help educate

VQ: Let's take a break here
... Resuming

ER: After enumerating different kinds of state, and how it's done, then a very short conclusion
... Missing a set of recommendations for what the right thing to do for each kind is

DO: Just not clear what the right answer is in each case

NM: Reluctant to give advice if it's not absolute?

DO: Not at all. Consider stateful vs. stateless -- Roy F. said go stateless, but there are lots of people building very useful stateful apps for good reason
... If you need performance for e.g. a banking app, you have to go stateful. . .

NM: So say that -- here's the cost, here's the benefit, do what you have to do

TVR: This is the standard REST vs. WS argument -- we should draw out the tradeoffs

DO: I appreciate this, and have tried to get there, sounds like I should try to take this a bit further in giving advice in the context of the tradeoffs
... One of the problems, in the meta-tradeoff for me as editor between length and completeness, is the question of properties of interest. Roy F's thesis only considers network performance properties, not ease of development, etc. . .
... But then that gives me too much material before I get to the core questions. . .

TVR: We need to step back and consider what we're trying to achieve. If we get feedback saying "You didn't tell me enough" that's a victory -- they read it, they understood enough to know they wanted more

NM: We're acting as if it's already long, only going to get longer -- I think there's a way to get some of it out , do some surgery and reduce a tutorial section to a brief reminder. . .
... Focus on tradeoffs, good practices
... I think the finding could be shorter, and still do the job

ER: I didn't mind the length

NM: Some shortening is just editorial, but some of it read more like an XML.com article than a TAG finding. . .

<DanC_lap> "mumblyfratz" <- 10 points for anybody who can work that word into a finding ;-)

HST: Another tradeoff worth looking at would be scale -- a stateless app can easily be done by one person with a modest investment of effort
... Stateful apps require signficantly more effort, more technologies are involved, etc.

NM: Yes, I think talking about management complexity would be good -- there are management costs, so what's the benefit that balances that

<dorchard> State, including cookies, portals, banks

<dorchard> State, including cookies, portals, and tracking users

TBL: I'm worried about the title -- if this was called the "Cookie Finding", we'd have better chance of get the people will really want to read this to do so

<dorchard> State: REST, cookies, portals and more:

<noah> Stateful applications considered harmful?

<dorchard> State: REST, cookies, portals, accounts for dummies

<Norm> State on the Web: Cookies, Portals, and Tracking User Information

<dorchard> stateless applications considered harmful?

<EdR> State: ways of keeping track of your customers

TVR: Intended audience is someone aware of the two big alternatives, but struggling to figure out how to understand the real significance of the difference

<dorchard> State on the Web: Cookies, Portoals, and Tracking User Information

<dorchard> State on the Web: Cookies, Portals, and Tracking User Information

<benadida> "Cookies, Portals, Shopping Carts, and Personalization: State in Web Applications"

<dorchard> Cookies, Shopping Carts and Personalization: State in Web Applications

<DanC_lap> Personalization, Cookies, and Shopping Carts: State in Web Applications <- TV's suggestion

<noah> Cookies, Shopping Carts, Personalization, etc.: State in Web Applications

<timbl> and stuff like that

<timbl> Choose your perfect URI policy

DO: Hope to get a new draft this summer

<scribe> ACTION: DO to revise CSCP State finding [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action01]

<scribe> ACTION: Norm, Noah to review new version when it comes out [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action02]

Passwords in the clear

ER: Easy to write a one-sentence "Don't do that" finding
... Do we articulate this in various directions, e.g. XML packages
... What about the fact that the W3C website sends passwords in the clear

DC: Yes, that's a real embarrassment, but v. hard to fix

ER: How far to go -- credit cards, or not?

DC: Just passwords

NM: Passwords narrowly, just enough to tell that story

TBL: Who is this for -- web site developers?

Tutti: Yes

TBL: What should we recommend
... Digest? SSL?

BA: These are different -- SSL means the app sees the clear password
... Whereas Digest that (rarely) happens
... Digest does store passwords in the clear on the server

DC: That was a barrier to deployment in the beginning
... I think that's been fixed, not sure of details

BA: Another approach is Yahoo Javascript client-side hashing

ER: New servers do this in hardware, much cheaper

NM: Another issue -- post-authentication, https is expensive for servers e.g. to encrypt a large mailbox

DC, BA: Much more valuable to focus tightly on this now

TBL: A finding can be a single page

ER: Database login via XML (Web Services)

TBL: Three classes: Basic authentication; Form-based authentication; Web Services

<scribe> ACTION: ER to produce a first draft of a "No passwords in the clear" by 27 June [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action03]

Note we already have DC and VQ as reviewers

BA: Back to question of audience

TBL: Site owners, UA developers

BA: MUST NOT for site owners, SHOULD NOT for UA developers

TBL: Flip it: MUST support Digest

VQ: Break for lunch until 1:30

Summary of Action Items

[NEW] ACTION: DO to revise CSCP State finding [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action01]
[NEW] ACTION: ER to produce a first draft of a "No passwords in the clear" by 27 June [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action03]
[NEW] ACTION: Norm, Noah to review new version when it comes out [recorded in http://www.w3.org/2001/tag/2006/06/13-morning-minutes.html#action02]