Re: [OAUTH-WG] Re-Chartering: What Items to work on?
On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: 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? I agree with Justin's suggestion, let the server figure the token type. The server should be able to do that anyhow. 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. There are cases when the server cannot revoke the access tokens associated with a refresh token (static access tokens for example). That being said, I think the server SHOULD revoke all access tokens if possible. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Re-Chartering: What Items to work on?
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
Re: [OAUTH-WG] Re-Chartering: What Items to work on?
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 [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
Re: [OAUTH-WG] Re-Chartering: What Items to work on?
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 HannesBlaine 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
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
