Am 12.01.2011 22:19, schrieb Richer, Justin P.:
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.
What do others think?
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.
the token_type does not control whether the server deletes all access
tokens associated with a refresh token.
This depends on the authorization servers policy.
regards,
Torsten.
-- Justin
________________________________________
From: Torsten Lodderstedt [tors...@lodderstedt.net]
Sent: Wednesday, January 12, 2011 4:07 PM
To: Richer, Justin P.
Cc: oauth@ietf.org
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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Torsten
Lodderstedt [tors...@lodderstedt.net]
Sent: Tuesday, January 11, 2011 5:22 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
