Question: I'm developing a new experimental web-application framework, and I decided to give RESTful some attention. I've read up on the basics, and feel like I have a pretty good understanding of RESTful as a concept.

I've got a system up and running, using URLs strictly to define 'nouns' in the system and take the 'verbs' from the HTTP request methods. I'm using javascript ajax calls to provide access to the DELETE and PUT methods which HTML forms cannot provide. (I realize these measures aren't strictly required to be RESTful, but it satisfies the 'Uniform Interface' requirement).

The problem comes with stateless-ness and cacheability with authentication. The standard model for user authentication on websites involves a "login" authentication event, after which (if successful) a user is "inside the wall" with a persistent secure session and may see and do things on subsequent requests which unauthenticated users may not. This persistence of authentication seems to break RESTful-ness. Caching and statelessness appear to be broken, because the authenticated user will probably see HTML which is different from that which a non-authenticated user will see for the same request (for instance, there might be a login form in a sidebar for the logged-out user).

Using www-authenticate strategies to authenticate a user only on the requests which require authentication seems to be a step in the right direction, as it doesn't involve the concept of a persistent secure session. However there's still the question of how to portray a "logged in" appearance to the end user in keeping with what we've all come to expect from websites.

So in the current thinking, what's the preferred way to handle authentication and permissioning of a webpage in a strictly RESTful way, while still allowing for logged-in decorations in the HTML?

Answer: 
"The standard model for user authentication on websites involves a "login" authentication event, after which (if successful) a user is "inside the wall" with a persistent secure session"

1. This isn't really correct. It's partly true, but only for web sites that invent their own authentication.
2. If you use "digest authentication" the browser must send the credentials with each request.

Digest authentication -- credentials with each request -- is totally RESTful.

Do that.

To make things slightly more streamlined, you can compute the digest authentication Nonce based on time so that it's good for some period of time (6 minutes, 0.1 hr is good). Everyone few minutes a request will send a 401 status and require recomputation of the digest.
"This persistence of authentication seems to break RESTful-ness. Caching and statelessness appear to be broken, because the authenticated user will probably see HTML which is different from that which a non-authenticated user will see for the same request"

It is ok if the representation of the resource is slightly different based on the authentication information. The auth information is part of the message and therefore the message is still "self-descriptive". Conceptually you are still accessing the same resource, and the edit and delete links are allowed transitions, not additional pieces of data. Controlling what transitions are available based on who accesses the resource seems valid to me.