Home > Uncategorized > Authorization and meaning

Authorization and meaning


I’m reviewing the issue-57 discussion at the recent TAG F2F and I notice that you hammer repeatedly against the connection between meaning and service:

  • I don’t think it should cost energy to mean something
  • I’m concerned [about] the way you’re describing the pattern – [dependency on running web server] … if you do a GET on the string, web server must be running when you do that GET.

and so on.

These IRC comments were ignored at the time. Now I will try to answer them.

If I ever talk about meaning being determined by GET, it is only a shorthand for a more nuanced story about authorization; I don’t really mean it. I’m sorry if that’s confusing.

My understanding of this from HTTPbis is that a “representation” (or other response), over whatever protocol (including any inter-brain protocol), is authorized for an http: URI by the domain name owner. That is, it is not correct for a cache or proxy to deliver a representation for a dereference of that URI that is not so authorized. The HTTP protocol is one way to express such an authorization, and because of Expires: the authorization can last for up to a year. But it does not take any energy for a representation to *be* authorized for a URI. The domain owner’s server can shut down completely, but copies cached in disks or on the sides of buses or inside brains can continue to be authorized.

You might even be able to find out whether a representation is authorized by, say, calling the current domain owner on the phone (not sure whether HTTPbis allows this). And other URI schemes have their own ways for a representation to be authorized. For example, RFC 2397 and your duri: draft authorize representations for a whole bunch of URIs for a very long time (forever).

But regardless of the URI scheme, representation-related meaning is either cached (maybe in your brain), looked up, or calculated by an authorized formula (as in the case of data:), and while perhaps no energy is needed for meaning itself, there is no caching or lookup or calculation apparatus that does not require energy to maintain. (Of course you know this distinction, sorry if I seem to lecture.)

If there were a legitimate way to authorize an http: representation for a very long period of time, such as true domain name ownership, then maybe we wouldn’t have to worry so much about meanings in http: space changing every year. RFC 2397 seems to do a pretty good job of authorizing representations forever; but the future is inherently unpredictable, so even the meanings of data: and duri: URIs is uncertain. Perhaps their meanings will be redefined by HTML6, in order to accommodate the way deployed infrastructure understands them. … unless by “meaning” you mean duri:2011:word:meaning… oh wait…

Now I’m mostly with you on http: not necessarily being the best basis for civil discourse (which requires citations, quite separately from up-to-date links), and duri: being superior in many ways. But issue-57 is not the best place, in my opinion, to address persistence concerns, given choices that have already been made by the affected community. I think it belongs with issue-50.

(Footnote: by “authority” throughout I mean the nice kind, the kind that’s granted, not imposed.)

(Footnote: someday I’ll figure out a ZBAC way to analyze all this. Not there yet.)

Categories: Uncategorized
  1. 2011-08-18 at 11:58

    re: … a “representation” (or other response), over whatever protocol (including any inter-brain protocol), is authorized for an http: URI by the domain name owner. That is, it is not correct for a cache or proxy to deliver a representation for a dereference of that URI that is not so authorized.

    I don’t think ‘authorization’ is the right model here. There does not need to be any intention, permission, authority at all. An intermediary in a communication whose role is to improve performance without changing the meaning of the communication is “correct” if the intermediary does’t change the meaning. I don’t think think there is any notion of “Simon says” or “mother may I” — granting of permission involved.

    Bringing in identity, authorization, intent, and telephone calls to the domain name owner adds complexity, edge cases (what happens if the domain name is sold) etc.

    “tdb” and “duri” don’t rely on or say anything about authority.

    • 2011-08-18 at 16:10

      Thanks for be willing to consider this.

      The idea of “authority” in the http: scheme that I use here is lifted straight from HTTPbis, so you can’t hold me accountable for it. See section 2.1 and 2.7.1 (of part 1), which in my reading are consistent with Roy’s theory of the world (he probably wrote them). The implication is that it’s incorrect to yield an unauthorized response. It doesn’t matter whether you’re a proxy or not. If you don’t like this idea I recommend you take this issue up with the HTTP WG.

      Let’s start with the word “correct” rather than “authority” since you seem willing to use that (not sure why you put it in scare quotes though). I think it’s safe to say you and I can have productive discussions or even arguments about whether any particular HTTP exchange (e.g. with a proxy) is “correct” or not. That is, we understand one another well enough to proceed. You and I both tend to respect specifications (within reason), and we probably respect many of the same ones.

      (I sometimes say that documents are “authorities” e.g. that 3986 is an “authority” for the use of URIs and related terminology. So, in understanding a URI and related concepts such as dereference and retrieval, I “authorize” RFC 3986 to tell me what is correct. 3986, in turn, “authorizes” 2616 (i.e. I respect 2616 because 3986 asked me to), and 2616 “authorizes” the domain owner. I admit that this is a confusing use of the word, and I will try to stop using it that way.)

      But the idea is, in trying to decide what’s correct, we look for evidence (specs and other documents, messages, etc.), and we assess the evidence for trustworthiness and usefulness before deciding. If we’re arguing, I try to get you to accept the evidence and lines of reasoning that I like, since if we have inadequate common ground, there’s no way we can argue or agree. Luckily we (i.e. LM and JAR) have some good starting points, namely the RFCs and so on, things we both accept. That’s why we can make progress. There is some process by which you and I can come to agree on admissibility of evidence in disputes over exchange correctness.

      For example, suppose the request URI is ‘data:,bit’ and the response is 200 with representation {content-type ‘text/plain’ and content ‘bite’}. If you say this is correct and I say it’s not, we can start with 3986, and it talks about scheme registrations, and then we both might agree to consult RFC 2397 says, and then it’s sort of vague on this matter but we would probably agree to interpret it as implying that the response was not OK, or OK. Or we might agree that it just doesn’t resolve the matter – then we have a choice, do we try to agree between us on some answer not implied by the evidence, or do we write a new spec that answers the question, or do we just give up? In any case, things are collegial because the rules of discourse are pretty clear.

      In the security world we speak of a request (to do something) as being “authorized” or not, and an “authority” is an agent that has rights, according to some idea of who has what rights. If the agent that has to carry out the request agrees about these rights, they’re willing to recognize that authority for that request. (There may be delegation chains, etc.) (Capabilities simplify this but that’s another story.) I respect 3986 (considered as a request to behave and/or speak in certain ways) not because I grant authority to Roy or IETF, but because I decided to respect that document, based on a complex private judgment partly based on assessing whether other people (like you) are going to respect the same document.

      Not sure what you’re saying about proxies. When I talk to a proxy I’m implicitly authorizing it to handle HTTP traffic for me. If I doubt whether a proxy’s response is correct, its defense according to HTTPbis would be that the origin server (as an agent of the domain owner), in conjunction with 2616, authorized it to deliver that response. (It probably accomplished the authorizing by sending the response to the proxy by HTTP, but who knows.) According to HTTPbis a proxy can’t correctly respond in any particular way to GET http://los.er/ unless the response is authorized (permitted) by the domain owner (in conjunction with the protocol spec). I didn’t make that up. How does it know it’s authorized? Because the upstream server is assumed to be correct, meaning any response it issues is going to be authorized (again, by combining what the origin says with transformations permitted by the protocol).

      The permission-granting in the case of a compressing proxy comes from three parties mutually agreeing to the protocol, i.e. implicitly giving one another permission to do the things that are allowed such as retrievals, chunking, authorized responses, etc.

      The question of whether a putative retrieval using a tdb or duri URI is correct is not so different from the question of whether retrieval using an http: URI is correct. You decide what specs (or hearsay or people or whatever) you want to pay attention to, you look for evidence such as records of packets received in the past, and you make a judgment. The correctness of an HTTP exchange that happened 3 minutes ago depends, according to HTTPbis, on who owned the domain 3 minutes ago and whether the observed response originated from an origin under their control, as well as the usual protocol rules (which permits caching, payload-preserving transformations, etc.). I don’t see that this is qualitatively different from duri: . An http: retrieval could be done just by prefixing duri: and the current time to the URI and using any service capable of doing duri: retrievals. Because http: can be faithfully embedded in duri:, if HTTPbis “authority” is involved in http: then it has to be involved in duri: .

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: