Jar: This is a draft not a proposal
... came out of our discussion of capabilities

<noah> Could you say a bit more about the Google Calender use case in particular? What are they doing?

Jar: URIs to carry secrets are used all over the web. Finding should talk about this
... Scope of finding is not limited to public URIs
... There is a web interface and you can say "share this calendar"... it mints a URI and says send this URI to your friend
... If you send URI to friend and he clicks on it, the calendars are shared

Noah: Does it carry authority as well as allow sharing?

<noah> Crucial case is that the URI carries not just the identification, but also the authorization.

JAR: Yes, carries authority

<noah> Speaking for myself, I don't like that, and don't want to encourage it.

<masinter> "click here to unsubscribe" also

<noah> I think AWWW is right to make identity and authorization orthogonal

JAR: Tyler Close says this is used and it is good

<DKA> Is it a one-time use URI?

JAR: the person getting URI could publish it and then everyone has access

<noah> DKA, I don't think so. Sounds like you can explicitly kill it.

JAR: but capability can be retracted

<jar> Google docs is another example

DKA: Is this a one time use? It is a pattern they use.

<noah> One time use seems break GET/safe

JAR: For calendar it is one time use
... in Google docs you can send to many people

Raman: URL works only if you are in the ACL for document
... you can manage access control

<masinter> Adobe Buzzword (acrobat.com) has similar options: "open to anyone who has the URL" is an access control option

Noah: Is this also true of Calendar?

Raman: Calendar has different model. Events have URLs
... if private no one can see it
... there is a single sign-in mechanism
... access to URL does not give access

<jar> code.google.com/apis

Noah: Crucial question: Should a URI ever give access control?

<masinter> "Allow anyone with a link to view this document" is a access control option that the user can set

<Zakim> Noah, you wanted to question the appropriateness of the use case

Larry: I can create a doc from acrobat.com and I can create a doc and share it
... describes sharing options

<noah> I think the question is: how much do you bend what you would otherwise do with Web architecture to enable Larry's case, which he acknowledges as "weak"

<Zakim> Masinter, you wanted to propose drafting a document and getting review of it in the security community

<Zakim> Noah, you wanted to say, I take Larry's point

Noah: Seems like passwords in clear discussion
... its a weak security mechanism. URIs are widely shared. Not like private key.

<masinter> +1 that this is like password in the clear

Noah: but people use it because it's convenient
... people use it and understand the risks

JAR: Why do they give 64-bit URIs if it is not a protection scheme?

<masinter> obfuscation is a useful technique. I don't think anything about "protected channels" doesn't really help much

JAR: Key word is "trade-offs". Finding should describe trade-offs

Noah: Finding says access control should be done orthogonally. I think this is right.

<masinter> obfuscation isn't "access control"

Noah: We should not be vague about that.

<DKA> After just trying to share a Google calendar I can confirm that that seems to be how it works. The URI does not allow automatic access to the calendar. It seems to encode expected access credentials but still requires a credentials check (authentication).

JAR: If finding says do not do the Google Calendar case we lose ccredibility.

<noah> account number 456123. A malicious worker at an Internet Service

<noah> Provider notices these URIs in his traffic logs, and determines the

<noah> bank account numbers for his Internet customers. Furthermore, if

<noah> access controls are not properly in place, he might be able to guess

<noah> the URIs for other accounts, and to attempt to access them.

<noah> Good Practice: URI assignment authorities SHOULD NOT put into URIs

<noah> metadata that is to be kept confidential.

<noah> """

<masinter> Yes, so the use case I gave above would be a violation of the finding.

Noah: Says only a little about access control.

Larry: The finding is too strong.

<noah> Unconvinced

JAR: Finding rules out common usecase.

Ashok: Noah and JAR disagree on what finding says and should say

<jar> https

<Zakim> masinter, you wanted to say I would rather findings be couched in terms of making people aware of the consequences, rather than telling them what to do

Larry: Try and write findings based on consequences of doing things one way instead of another
... so finding should say use this mechanism if risks a acceptareble
... Some of these exposures are over the long run instead of short run

Noah: A similar example is abt GET being safe
... I'm happy we said GET is unsafe

<Zakim> Masinter, you wanted to suggest review on public-web-security

Noah: Just because it is widespread we should not condone the practice

Larry: Need more discussion of public-web-security

Noah: I would feel better if we had better framing of the issue

<noah> q

<Zakim> DKA, you wanted to note that there seem to be a number of use cases here that look similar but are actually different - maybe the WSC group has already enumerated these?

DKA: We need a list of usecases and need to categorize them

Noah: How is Web Securiry Context connected with public-web-security

Larry: JAR could send note to public-web-security and see if we can get discussion started

Noah: We should try and get some shared terminology

Larry: Next step?

JAR: Spell out use cases more clearly?

Noah: Some disagreement. Some feel just because it is a commen usecase it should be condoned.

JAR: We should say what the finding is about

Noah: We have differeing assumptions about what people can put in URIs

JAR: Notion of URI is much broader than these public URIs
... URIs used in all sorts of situations. Web is just one use.

<masinter> I think the point that putting the secret in the FragID rather than in the main URI itself is interesting.

Noah: Way private keys are managed is fundamental to their use

JAR: You are saying URIs have a connotation to a public space on the web
... I don't agree with this.

<masinter> maybe this is also a justification for Origin vs. Referer? because Origin doesn't include private keys

<masinter> might add the acrobat.com one too while you're at it; let me know if you need more details

<noah> AM: I hear Noah and Jonathan disagreeing about how URIs are used? Will doing use cases fix that?

<noah> NM: Not sure it will, but it may clarify the context for the discussion.

<masinter> Ashok: I think the finding needs to be more nuanced, and that different kinds of security situations will need different advice. Having use cases will help us understanding of the situations and thus what kind of contextual advice to give.

Noah: There is no harm in any of us coming up with new text. This could spark useful discussion.

ACTION-372: Redrafting of HTML for resource vs. representation

<trackbot> ACTION-372 -- Larry Masinter to tell the HTML WG the TAG encourages the direction Roy's headed on resource/representation and endorse his request for more time. -- due 2010-01-20 -- PENDINGREVIEW

Noah: Some WGs communicate with other WGs. The WG votes on this and someone is asked to send the msg.
... the TAG has as part of its charter to help WGs do their work
... in some cases TAG will ask individuals to talk with WGs

Larry: I got a response and I don't think the WGs response is in line with what was requested

Noah: The process is fine ... we need to decide what to do?
... Larry, what should TAG do?

Larry: If we are happy to give on this that's ok with me

<masinter> i'm not sure they acknowledged hearing our opinion

Dan: I don't understand why Roy cannot do the 2 edits?

<masinter> Roy said: "Honestly, unless you can prove to ME that there is a substantial ...

<masinter> burden being imposed upon *someone* by reordering the entirely random order that chairs have decided to call for consensus, then it should be obvious that *MY* constraints are more important than whatever you personally think the procedure should be. Otherwise, you are just railroading a particular conclusion.

Dan: I can understand if they close this; we might say we don't like it, but unless we have a proposal...

<masinter> Write clear definitions of all affected terms, possibly in the form of suggested edits to the terminology section, and demonstrate correct usage of the terms by suggesting specific edits to one or two representative sections.

Larry: The above is something the TAG could take on.

<masinter> The definitions of these terms don't belong in HTML, they belong in Webarch

<masinter> Defining the terms of the web architecture seems like a fine job for the TAG, and that there is no other group more authoritative.