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

[Laurens Van Houtven]

Hi,



As some of you probably know I'm trying to beat OAuth2.0 into submission.
I'm using twisted.cred to do it. The restriction that avatarIds need to be
strs is somewhat getting in my way, and I'm not sure if the correct way to
do it is:
1) ignore the restriction (credentials types are so specific to OAuth that
it's very unlikely you'll find anything already pluggable...)
2) use the mind object (but then it becomes somewhat wonky what goes on the
mind object and what should be the avatarId)

I'll give you a practical example:
An OAuth client makes a request for an access token. This basically means he
trades some credentials in for an access token (I use the expression
trade-in because most of the credentials can only be used once). It presents
some credentials, which can be grouped into two parts:

1) credentials that authenticate the client itself
2) credentials for the access grant (eg I've got this thing that says I
should have access)

Because (1) is pretty much always the same (and is common to other parts of
txOAuth) and (2) depends on the specific kind of request, this results in
two portals:

1) for authenticating the client, which returns an IClient
2) for authenticating the credentials (which includes the authenticated
client, since credentials are client-specific), which returns the token

Coming from Perspective Broker I think the Client would be an apt mind
object for the second portal, since it represents the entity on the other
side trying to do auth.

The appropriate credentials checker in the second portal checks (and
invalidates, since most of the credentials are single use) the credentials.
What avatarId is sent to the Realm? The Realm is also responsible for
requesting the new token, so it needs to know details about the credential
that the credential checker just checked (and in doing so, invalidated).
These are not available through the IClient mind object.

The alternative design is that all of the credentials checkers know how to
request tokens, and instead give the tokenId as avatarId. This is still
insufficient, because tokens can include extra information, such as scope,
expiration time... That can again be solved by sending an opaque string
value which contains all of the data in the token response, but in that case
the Realm is completely useless and the checkers do all of the work.
Additionally, this seems stupid because cred checkers are for checking
credentials, not checking credentials + a bunch of other stuff.

Here's my theory:
13:43 <lvh> aa_: fwiw I *think* it's because cred's supposed to be pluggable
13:43 <lvh> aa_: so avatarId is supposed to be the equivalent of a username
13:44 <lvh> aa_: and it's str not unicode because there's a helluva lot more
things
that store bytes than unicode objects

So um, any thoughts from people that understand cred? Is it ever okay to
send richer things than strings to a Realm?

thanks
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20100907/8a581006/attachment.html>