[Twisted-Python] twisted cred: why does avatarId need to be a str?

[Glyph Lefkowitz]

On Sep 8, 2010, at 8:12 PM, Laurens Van Houtven wrote:

> Actually, I believe much of the confusion is cleared up. Apparently I misunderstood what a Realm does. Oops!
> 
> The application in the original mail, which I will continue to talk about in this one, is a token endpoint. I've been told an explanation of what that is is in order. To start out: it is NOT the thing that actually serves protected resources, that's a resource server, which is a different beast entirely. The job of a token endpoint is to turn certain kinds of credentials into an access token; the access token, in turn, can be used to access protected resources. So basically, these credentials are about already provided access grants, that haven't been turned into access tokens yet. Examples of such credentials which can be turned in for access tokens:

(...)

> Does that help?
> Laurens

Somewhat, but it really casts the main issue into sharper focus:

for any given cred implementation, there are two key questions:

What is the avatar interface?
What is the associated mind interface?

If we're not talking about a system where the avatar interface (the one passed to 'login', the one that the realm must return something that gets implemented) is IResource, then that's the problem.  What is that interface that you're talking about?  Be very specific: what methods does it have and why?

It sounds like OAuth is very precisely implementing something that maps almost exactly onto the checker part of cred, but you're doing it by implementing a realm to allow applications to provide their own logic.  This might not be the wrong idea, but it needs to be spelled out very clearly.

As you describe it:

> token endpoints let you trade in some credentials that prove you're supposed to have access for a token that actually *gives* you that access

In cred-ese, that would be "checkers let you trade in some credentials that prove you're supposed to have access for an <avatar ID, which you give to a Realm> that actually *gives* you that access".  As far as the OAuth response is concerned, it's like a checker.  Looking at the individual parts, assuming that the avatar interface for the purposes of this discussion is IResource, it breaks down like this in my mind:

>     - the access token (an ascii string, mandatory)

Avatar ID.  (See, it's a str!)

>     - the expiration time (optional)

Implementation detail of the session.  Avatars are actually sessions, which expire: sometimes (as with POP) at the end of a connection, sometimes (as with nevow.guard's HTTP support) with a session timeout.

>     - the refresh token (another ascii string, similar to the access token, optional)

Implementation detail of the authentication protocol.  The client library and server library should be transparently refreshing this without telling either the client application code or server application code, right?

>     - scope (an ascii string consisting of a set of space-separated words, optional)


This part doesn't quite fit, but could be expressed in one of two ways: a modification to the avatar ID, or as some extra structure on the Mind that modifies what functionality the Realm bundles in to your avatar implementation (without changing the interface provided by that object, of course).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20100909/15a808ff/attachment.htm