Hi,<div><br></div><div><br></div><div><br></div><div>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:</div>
<div>1) ignore the restriction (credentials types are so specific to OAuth that it's very unlikely you'll find anything already pluggable...)</div><div>2) use the mind object (but then it becomes somewhat wonky what goes on the mind object and what should be the avatarId)</div>
<div><br></div><div>I'll give you a practical example:</div><div>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:</div>
<div><br></div><div>1) credentials that authenticate the client itself</div><div>2) credentials for the access grant (eg I've got this thing that says I should have access)</div><div><br></div><div>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:</div>
<div><br></div><div>1) for authenticating the client, which returns an IClient</div><div>2) for authenticating the credentials (which includes the authenticated client, since credentials are client-specific), which returns the token</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Here's my theory:</div><div><div>13:43 <lvh> aa_: fwiw I *think* it's because cred's supposed to be pluggable</div><div>13:43 <lvh> aa_: so avatarId is supposed to be the equivalent of a username</div>
<div>13:44 <lvh> aa_: and it's str not unicode because there's a helluva lot more things</div><div>that store bytes than unicode objects</div></div><div><br></div><div>So um, any thoughts from people that understand cred? Is it ever okay to send richer things than strings to a Realm?</div>
<div><br></div><div>thanks</div><div>lvh</div>