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: 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
http://www.w3.org/2001/tag/doc/state.html
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
<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]
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