Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the client credentials and token are correct and verifiable, then the revoke should go through. A client wanting to revoke both a request token and an access token will have to make several calls to this, unless you want to put in a way to put multiple token values in. I don't recommend that though, as it seems to me an optimization for a problem nobody has yet.
-- Justin ________________________________________ From: Torsten Lodderstedt [[email protected]] Sent: Wednesday, January 12, 2011 4:07 PM To: Richer, Justin P. Cc: [email protected] Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? thank you for your feedback. So you would suggest to let the authorization server auto-detect the correct type? regards, Torsten. Am 12.01.2011 15:43, schrieb Richer, Justin P.: > I don't quite understand the need for "token_type" in the request. The token > being presented is going to have a type associated with it on the server -- > that is, that text blob is going to have been issued by the server as an > access token or a refresh token, no matter what the client claims in this > request. Seems like this is at best an optional sanity check. > > Unless of course you want to revoke all "related" tokens at once, in which > case I think you need a different mechanism to do so. > > -- Justin > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Torsten > Lodderstedt [[email protected]] > Sent: Tuesday, January 11, 2011 5:22 PM > To: Hannes Tschofenig > Cc: [email protected] > Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? > > I just posted a new revision of > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. > Please consider it for the re-chartering process. > > Additionally, Mark and me are still working on the security document. It > takes longer time than expected because of the topic's inherent > complexity. We plan to have a new revision ready for IETF-80. > > regards, > Torsten. > > Am 10.01.2011 10:55, schrieb Hannes Tschofenig: >> Hi all, >> >> In preparing the charter text we need your feedback. >> >> First, the new charter needs to include the two new items we had already >> accepted, namely >> * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> * The OAuth 2.0 Protocol: Bearer Tokens >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >> >> In the past (around September / October 2010 timeframe) we had also >> discussed other proposals. See attachment below. >> >> We cannot just add everything to the charter because we will never be able >> to finish it. >> To make it more complicated there were other proposals floating around but >> no drafts are available (e.g. security, discovery). >> >> It would be great to have a complete list of documents that should be >> considered. >> We would suggest to wait till the end of the month for new document >> submissions to show up. >> >> Then, we will start a Doodle poll to see your preference. >> >> Ciao >> Hannes& Blaine >> >> PS: Here are some of the other documents that people wanted to spend time >> on. There are more on the OAuth WG page. >> >> * Messaging Signing >> Examples: >> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ >> http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html >> >> * User Experience Extensions >> Example: >> http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ >> >> * Artifact Binding >> Example: >> http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ >> >> * Dynamic Client Registration >> Example: >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> * Token Revocation: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> * Use Cases >> http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
