>
> This won't work for several of the use cases discussed in this thread,
> e.g. access to a user's contacts, but not their other data, or
> read-only access to contacts.
>
You're right, I think I said that wrong. The principal "making the request"
is related to the one the OAuth token maps to (below called the delegater),
in that it may possess only a subset of the privileges of the delegater.
> A more useful mapping would be from oauth token to OAuth consumer
> identity, since the OAuth consumer is the one making the request. The
> question shouldn't be "Does user X have permission to modify user X's
> contacts", it should be "Does consumer K have permission to modify
> user X's contacts"
>
I disagree. The principal represented by the consumer has even less to do
with the principal making the request than the original delegater. Consumer
K never has permission to modify anything. If it did, user's wouldn't have
to give it OAuth tokens. I like your suggestion below better (where the
principal's getName() method shows both consumer and token (and perhaps
delegater, I guess), but where the getName() method is one of the less
useful methods on the principal).
getUserPrincipal should probably return some ornate string that no one
> will actually use for anything. This is too complicated to fit into a
>
you mean getUserPrincipal().getName(), right?
> The actual authorization should be based on calls on the principal object
> like:
>
> getAuthType
this would be HttpServletRequest, right?
> getOwner, getViewer, getGadget
> getOAuthMessage().get("oauth_consumer")
> getOAuthMessage().get("oauth_token")
> etc...
>
I was more leaning toward something like having a method checkAccess(String
httpMethod, String pathFromUrl) on that principal object, but mostly I would
suggest crossing the authorization bridge when we get there. For now, let's
just worry about authentication.
Dirk.
