Andrew,
Looking at CTP 3, it looks like you've implemented the above and while
I think there are merits to this approach, I do have some questions.
How do you revoke a token in your scenario? Say a user authorizes a
3rd party app and we issue a token with a relatively long lifespan.
Then later the user revokes that app's access but using the
cryptography method I see in CTP 3, since we are not going back to the
Authorization Server via a back channel on each request we wouldn't
know the token has been revoked and would still be granting access or
have I missed something?
I understand we could set a low lifespan and use the refresh token
procedure, but this would still allow a window of unauthorized
access...
Further to this (and I haven't examined the source in any detail), is
there a way to use DotNetOpenAuth without this cryptography
implementation? My personal feeling is that I don't like the idea of
self describing tokens as they incur cryptography CPU processing
overhead on both the signature check and the decryption while a token
look up can be implemented very efficiently with caching etc.
In all, I think the work you have done here is first class, but I
would like to be able to choose whether or not to go with self
describing tokens or not.
Regards,
Marcus
On Jun 14, 2:16 pm, Andrew Arnott <
andrewarn...@gmail.com> wrote:
> Yes, although "just been released" might be a bit premature to say. The
> files are available for download as of this morning from TeamCity, but I'm
> expecting to upload them to SourceForge later today and then post the link.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> 2011/6/14 Hjörtur Stefánsson <
hjortu...@gmail.com>