text: VQ: We will try to explore the entire security area.
  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:
  <noah> Henry's mail in turn links email from James Bryce Clark:
  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
  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
  Reviewed by EdR, NM and NW
  ER: I've sent a long list of comments, mostly editorial
  <Norm>
  <noah> Date space copy of draft finding:
  <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:
  ... 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
  <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 ->
  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]
  <scribe> ACTION: Norm, Noah to review new version when it comes out [recorded in]
  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]
  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