Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt
Hi, I would prefer to keep the section general as Michiel suggested. Name it 'Cross-Origin support' and list CORS ans JSONP as examples. Could it be possible that other methods for Cross-origin support might come up in future? They would not be excluded than. - Stefanie Original-Nachricht > Datum: Thu, 07 Jun 2012 17:40:48 +0200 > Von: Torsten Lodderstedt > An: Michiel de Jong > CC: oauth@ietf.org, Marius Scurtescu , Stefanie Dronia > > Betreff: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt > Hi Michiel, > > I'm fine with both suggestions (also mentioning CORS or not mentioning > JSONP). What do my co-authors and other WG members think? > > regards, > Torsten. > > Am 29.05.2012 14:10, schrieb Michiel de Jong: > > Hi Torsten, > > > > No, it should indeed work fine with CORS. CORS is supported by IE8+, > > FF, Chrome, Safari and Opera12+ (with limited error handling and > > limited verb support in IE8 and IE9, but with POST you should be safe > > afaik). > > > > Note that if you want to support this in combination with implicit > > grant flow (unhosted html5 apps), then you need CORS. > > > > Which made me wonder why you are mentioning JSONP at all? Mentioning > > JSONP as a 'MAY' but not mentioning CORS could send people in the > > wrong direction IMO. So I would rename the section 'JSONP' to 'CORS > > and JSONP', or in general, 'Cross-Origin support', and then start with > > a sentence like: > > > > "The revokation end-point SHOULD support CORS if it is aimed at use in > > combination with the implicit-grant flow. For other flows, it is still > > recommended(?) to support CORS. In addition, for interop with legacy > > user-agents, it MAY offer JSONP. Clients should be aware that when > > relying on JSONP, the revokation end-point MAY ;) inject malicious > > code into the client." > > > > You can tell i don't speak spec lingo, but i hope i'm sort of getting > > my point across, that IMO, CORS is better here than JSONP. > > > > Or: simply not mention JSONP at all. Would that be an option? > > > > > > Cheers, > > Michiel > > > > On Sun, May 27, 2012 at 3:05 PM, Torsten Lodderstedt > > wrote: > >> Hi Michiel, > >> > >> shouldn't the revocation POST request work fine with CORS? Or is there > >> something we need to specify in order to make it work? > >> > >> best regards, > >> Torsten. > >> > >> Am 27.05.2012 13:20, schrieb Michiel de Jong: > >> > >>> awesome! just that - first thing that catches the eye right when you > >>> skim the table of contents is: > >>> > >>> why did you use JSONP instead of its CORS? You can read more about > CORS > >>> here: > >>> > >>> http://enable-cors.org/ > >>> > >>> > http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#CORS_relationship_to_JSONP > >>> > >>> On Sun, May 27, 2012 at 10:41 AM,wrote: > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>> directories. This draft is a work item of the Web Authorization > Protocol > >>>> Working Group of the IETF. > >>>> > >>>> Title : Token Revocation > >>>> Author(s) : Torsten Lodderstedt > >>>> Stefanie Dronia > >>>> Marius Scurtescu > >>>> Filename: draft-ietf-oauth-revocation-00.txt > >>>> Pages : 6 > >>>> Date: 2012-05-26 > >>>> > >>>>This draft proposes an additional endpoint for OAuth authorization > >>>>servers for revoking tokens. > >>>> > >>>> > >>>> > >>>> A URL for this Internet-Draft is: > >>>> > http://www.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> This Internet-Draft can be retrieved at: > >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt > >>>> > >>>> The IETF datatracker page for this Internet-Draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ > >>>> > >>>> ___ > >>>> 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 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Versioning
Hi, I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread "OAuth 1 Bridge Flow" and had some thoughts: I do not really see the necessity for such a flow. First of all, all participating parties have to be modified and rolled out: - the consumer's application to support (at least) the bridge flow (and OAuth 2 [1]), - the authz server to provide OAuth 2 and additionally the bridge flow and - the resource server to handle OAuth2. Then, sometime later, when at least the authz server doesn't support OAuth 1 anymore, the client application and the resource server should be cleared up - no more OAuth 1, only OAuth 2. Again a new version to roll out. The only (small) benefit I see, is that the user will not be asked for authorization again. But is it worth it to develop, implement and roll out a Bridge Flow? I do not think so - too much expense for a small user interaction. Better: directly go to OAuth 2, when it is needed. The other thing I'm missing, is how to migrate completely to OAuth 2 after performing the bridge flow. Issuing a refresh token in the response seems necessary. But this issue was still mentioned (but not solved) in the thread "OAuth 1 Bridge Flow" by Eran. Thanks, Steffi [1] if OAuth 2 will not be supported, a new modified client has to be rolled out at the latest, the resource server doesn't support OAuth 1 anymore. > Original-Nachricht > Datum: Tue, 6 Jul 2010 21:54:16 -0700 > Von: Marius Scurtescu > An: Rob Richards > CC: "oauth@ietf.org" > Betreff: Re: [OAUTH-WG] Versioning > > On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards > wrote: > > Eran Hammer-Lahav wrote: > >> > >> Hi Rob, > >> > >> I agree with you that a migration spec is important - please write > one. > >> > > > > Like I didn't see that coming :) > > I would like to help with this migration spec. Is this a good starting > point: > http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html > > Or, you had something else in mind? > > Marius > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Versioning
Hallo Marius, thanks for your statement. Your idea of a migration flow is quite good and necessary. But I still doubt, if the work and effort should be investigated to spare the user from some interaction (authentication and user consent). Latest he will be asked for his consent at the time, the refresh token expired (as long as the refresh token has a limited validity period [1]) and a new one is requested. With the additional aspects (OAuth 2 refresh token returned, OAuth 1 access token revoked), the flow might only be performed once? By the way, the revoke of the OAuth 1 token should not be optionally, but a must IMO. By that way, the consumer is enforced to process with OAuth 2 flows. Have a nice weekend! Steffi [1] That a refresh token has a limited validity period is not defined in the spec. But the authz server should be able to invalidate it. E.g. when the refresh token is issued, a long, but limited validity period is assigned to it. Each time, new access token(s) are requested with the refresh token as access grant, the refresh token's validity period is extended. If not, it gets invalid reaching the assigned limit. This flow represents the user's usage of the consumers application. (Quasi) Infinitely valid refresh token at continuous usage of the consumers application. Limited validity at rare or no usage. Revocation of the granted access is done automatically w/o user intervention. Am 08.07.2010 20:26, schrieb Marius Scurtescu: The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2 environment, it allows the consumer to obtain a token using signatures and then access protected resources with no signatures. Now that signatures are re-introduced in OAuth 2 I don't think there is a need for such an approach. That being said, migration can be done very similarly, differences from the bridge flow: - an OAuth 2 refresh token is also returned - optionally the OAuth 1 token is revoked Such a migration flow would allow a consumer/client that has OAuth 1 access tokens saved for its users to convert all of them to OAuth 2 refresh tokens without involving the users. Marius On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia wrote: Hi, I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread "OAuth 1 Bridge Flow" and had some thoughts: I do not really see the necessity for such a flow. First of all, all participating parties have to be modified and rolled out: - the consumer's application to support (at least) the bridge flow (and OAuth 2 [1]), - the authz server to provide OAuth 2 and additionally the bridge flow and - the resource server to handle OAuth2. Then, sometime later, when at least the authz server doesn't support OAuth 1 anymore, the client application and the resource server should be cleared up - no more OAuth 1, only OAuth 2. Again a new version to roll out. The only (small) benefit I see, is that the user will not be asked for authorization again. But is it worth it to develop, implement and roll out a Bridge Flow? I do not think so - too much expense for a small user interaction. Better: directly go to OAuth 2, when it is needed. The other thing I'm missing, is how to migrate completely to OAuth 2 after performing the bridge flow. Issuing a refresh token in the response seems necessary. But this issue was still mentioned (but not solved) in the thread "OAuth 1 Bridge Flow" by Eran. Thanks, Steffi [1] if OAuth 2 will not be supported, a new modified client has to be rolled out at the latest, the resource server doesn't support OAuth 1 anymore. Original-Nachricht Datum: Tue, 6 Jul 2010 21:54:16 -0700 Von: Marius Scurtescu An: Rob Richards CC: "oauth@ietf.org" Betreff: Re: [OAUTH-WG] Versioning On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards wrote: Eran Hammer-Lahav wrote: Hi Rob, I agree with you that a migration spec is important - please write one. Like I didn't see that coming :) I would like to help with this migration spec. Is this a good starting point: http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html Or, you had something else in mind? Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposal for OAuth dynamic client registration
Hallo Eve, I read your proposal, too. Thanks for providing it. Some questions: # first part of chapter 2 # enchanced OAuth RS, AS and client are mentioned. Does the enhancement just denote, that they support dynamic client registration or have any further requirements to be fulfilled by them? # The text is "... use an access token in approximately the normal OAuth fashion,...": What do you mean by "approximately" in this context? As far as I understood, after client registration, OAuth flows are performed as defined. # For registration, the client has to give its URL (parameter client_url in registration request). May it be used later for OAuth callback url, e.g. if client registration with pushed metadata is selected? And just a typo: Example chapter 7.1: "url" instead of "client_url" is printed. Regards, Stefanie Am 10.08.2010 21:31, schrieb Eve Maler: Folks-- The UMA group has produced the following I-D as input to the OAuth discovery/registration/binding discussion. We wanted to set forth our requirements (knowing that there may be other requirements from the wider community) and propose some solutions that meet them. If further discussion seems to warrant an updating of this draft, we're happy to do that. (If you have interest in getting involved in UMA-specific work, feel free to drop me a note.) Eve http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt Begin forwarded message: From: IETF I-D Submission Tool Date: 10 August 2010 12:23:59 PM PDT To:e...@xmlgrrl.com Cc:c...@comlounge.net,m.p.machu...@ncl.ac.uk Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully submitted by Eve Maler and posted to the IETF repository. Filename:draft-oauth-dyn-reg-v1 Revision:00 Title: OAuth Dynamic Client Registration Protocol Creation_date: 2010-08-10 WG ID: Independent Submission Number_of_pages: 20 Abstract: This specification proposes an OAuth Dynamic Client Registration protocol. The IETF Secretariat. Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ 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] Proposal for OAuth dynamic client registration
Hi Christian, thanks for clarification. Regards, Stefanie Am 11.08.2010 18:22, schrieb Christian Scholz: Hi! Am 11.08.10 16:36, schrieb Stefanie Dronia: Hallo Eve, I read your proposal, too. Thanks for providing it. Some questions: # first part of chapter 2 # enchanced OAuth RS, AS and client are mentioned. Does the enhancement just denote, that they support dynamic client registration or have any further requirements to be fulfilled by them? These are mostly examples from the User Managed Access (UMA) Working Group where we use components which have to do a bit more than simple OAuth. Out of this came the need for dynamic client registration which we thought might be useful in other OAuth contexts as well. So regarding the actual client registration they do not need to have further requirements other than the client registration capabilities described. In the final version we might want to get rid of the UMA specific text in order to prevent confusion. # The text is "... use an access token in approximately the normal OAuth fashion,...": What do you mean by "approximately" in this context? As far as I understood, after client registration, OAuth flows are performed as defined. Yes, again this relates to our UMA use cases where later on (after client registration) those components need to do a bit more. For this spec though this is irrelevant. # For registration, the client has to give its URL (parameter client_url in registration request). May it be used later for OAuth callback url, e.g. if client registration with pushed metadata is selected? Those parameters basically should represent what you otherwise would enter into a registration form like http://dev.twitter.com/apps/new Thus there probably need to be more fields in there but website url (or client_url) and callback_url should probably be 2 different attributes. The question regarding the client metadata is how much information really is needed. For manual registration the server can ask as much as it wants. For automatic registration I would like some basic set of attributes, some maybe being optional. The question might be which ones to take. And just a typo: Example chapter 7.1: "url" instead of "client_url" is printed. Right, thanks! -- Christian Regards, Stefanie Am 10.08.2010 21:31, schrieb Eve Maler: Folks-- The UMA group has produced the following I-D as input to the OAuth discovery/registration/binding discussion. We wanted to set forth our requirements (knowing that there may be other requirements from the wider community) and propose some solutions that meet them. If further discussion seems to warrant an updating of this draft, we're happy to do that. (If you have interest in getting involved in UMA-specific work, feel free to drop me a note.) Eve http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt Begin forwarded message: From: IETF I-D Submission Tool Date: 10 August 2010 12:23:59 PM PDT To:e...@xmlgrrl.com Cc:c...@comlounge.net,m.p.machu...@ncl.ac.uk Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully submitted by Eve Maler and posted to the IETF repository. Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: OAuth Dynamic Client Registration Protocol Creation_date: 2010-08-10 WG ID: Independent Submission Number_of_pages: 20 Abstract: This specification proposes an OAuth Dynamic Client Registration protocol. The IETF Secretariat. Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler ___ 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] survey: token revocation design options
Hi Torsten,
++2. No care about token formats or URL length problem.
-1: all options bring some problems along (as you already indicated).
Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not
an option from my point of view. Every overloading would be deployment
specific (or has to be defined by the OAuth spec???) and I doubt that it
is possible to overload this method with widely-used frameworks.
-1c: Introduction of token ids: If a token is addressed by its ID, it is
IMO not possible to verify in all cases that the client (who requests
revocation/modification) is same client that the token was issued for
before if the authorization server is stateless. So someone might catch
a token and then revokes it.
May there be other security issues?
Another drawback is that the access token response has to be extended.
What kind of modifications of tokens do you have in mind? (as you
commented with 1c)
Regards,
Stefanie
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
Hi all,
I intend to submit a I-D for token revocation. Based on previous
discussions on the mailing list and here at Deutsche Telekom, I see a
couple of design options. I would like to share those options with the
WG and try to reach consensus on a single option before investing the
time to write the I-D.
1) HTTP Delete on tokens endpoint
DELETE seems a natural way for revoking (deleting) tokens. Although
the HTTP spec is a bit vaque in this concern, current practice
prohibits a body for DELETE requests. So the token must be addressed
by the request's URI. Lets assume the token is passed as URI query
parameter as follows:
DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1
Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
But is it advisable to pass tokens as URI query parameters? The
current character set definition for access tokens (§5.1.1) is not
URL-safe since it includes URI reserved characters (e.g. '/').
Additionally, there is no definition of a refresh tokens character
set. So compliant authorization servers could issue tokens, which
cannot be safely passed as URI query parameters.
Note: As an additional challenge, self-contained tokens can be very
large. So passing them as URI parameter may exceed URL length limits.
I see the following alternatives to cope with the encoding problem:
a) Force usage of a URL-safe character set for access and request tokens.
- rather restrictive, will most likely collide with existing token
formats
- does not solve URL length problem
b) Force base64-URL-safe encoding for all tokens on transit.
- does not solve URL length problem
- significant API change
c) Authorization servers supporting revocation may additionally issue
a URL-safe token id in the access token response. This id is used to
reference the token in DELETE requests.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG/hhh/&%",
"access_token_id":"234567890",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8&&&#&",
"refresh_token_id":"asdfghjklhgf"
}
DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
Note: Since tokens become addressable resources on the authz server,
one could also query or modify token data using a GET/PUT requests
GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"scope":"abc",
"issued_on":"08/11/2010",
"last_usage":"08/13/2010" }
2) HTTP Post on dedicated revocation endpoint
An additional endpoint is used to revoke tokens. The token to be
revoked is sent as request body parameter.
POST /revocation HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
refresh_token=n4E9O119d
This option requires some support for the client to discover the
revocation endpoint.
Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest
additional design options.
regards,
Torsten.
___
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] issuing new refresh tokens
+1 Am 02.09.2010 19:42, schrieb Torsten Lodderstedt: +1 Am 02.09.2010 19:11, schrieb Eran Hammer-Lahav: Is this reasonable? "The authorization server MAY issue a new refresh token, in which case, the client MUST discard the old refresh token and replace it with the new refresh token." This is as much consensus as I was able to extract. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, July 14, 2010 2:33 PM To: Brian Eaton Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] issuing new refresh tokens On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt wrote: We plan to issue new refresh tokens for certain clients only (mobile, desktop), it's part of the client-related policy. So the behavior for a particular client is predictable. Nice. Would you be willing to expand on the current spec language a bit, to explain the use cases, and offer more normative language about how clients should handle refresh token exchange? This is a cool feature, but the current language is kind of vague. Cheers, Brian I'm not sure what you would like me to write. But let's get started: We expected the clients to discard the old refresh token and to use the newly issued refresh token instead. The old refresh tokens is revoked instantly. Any attempt to use it afterwards is interpreted as a potential misuse because the assumption would be that an adversary has copied the token or cloned the device. The client should notify the user of the problem and recommend him/her to check its application authorizations (refresh tokens) in our user self care portal. There, the user will have acces to information on when the token has been used the last time and therewith detect any odd behavior. The user could then revoke the token and/or alarm its providers helpdesk. regards, Torsten. ___ 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] I-D on token revocation submitted
Hallo Torsten, first of all thanks for providing this draft on the mailing list. Except for the following words, the draft is consistent. It defines the end of a token's life cycle, intended by the user. While reading it, I think that the following part of chapter 2 (Token Revocation) might cause problems a a certain situation: "If the processed token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server must also invalidate all access tokens issued for that refresh token." Situation: Authz Server(s) and Resource Server(s) are separate systems that are set in an open triangle (no communication between them e.g. to verify access tokens). Problem: How does the Resource Server(s) know that an access token was revoked and is not valid to access resources any more? => Communication between the servers necessary => benefit of open triangle architecture are lost for this case. I think that this is a problem with large scale systems. Although, if there are several Authz Server(s) , then there has to be communication between there or a shared data base to assure that revoked (refresh) tokens are invalid. => Is this requirement really a MUST? I don't think so. Any thoughts? Regards, Stefanie Am 08.09.2010 00:21, schrieb Torsten Lodderstedt: I just submited the first version of my I-D for token revocation. Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ The I-D proposes an additional endpoint, which can be used to revoke both refresh and access tokens. The objective is to enhance OAuth security by giving clients and users explicite control of the finalization of the token life cycle, e.g. to implement application logout or access authorization removal. Please take the time to review the document (2 pages, essentially) and give me feedback. My goal is that this draft becomes a working group document. regards, Torsten. ___ 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] I-D on token revocation submitted
Hi Brain, yes, you are right. I just went over that condition. On the other hand, this implies to me, that access token revocation is not possible in a constellation as described before. Regards, Stefanie Am 10.09.2010 00:38, schrieb Brian Campbell: Isn't that kind of situation exactly the reason that access token revocation was made optional? Invalidation of access tokens on revocation of a refresh token is only a MUST, if the deployment already supports revocation of access tokens. And if revocation of access tokens is supported, I'd assume the deployment already has an efficient means of invalidating them. Editorial note: shouldn't the "must" in that text be a "MUST"? On Thu, Sep 9, 2010 at 11:52 AM, Stefanie Dronia wrote: Hallo Torsten, first of all thanks for providing this draft on the mailing list. Except for the following words, the draft is consistent. It defines the end of a token's life cycle, intended by the user. While reading it, I think that the following part of chapter 2 (Token Revocation) might cause problems a a certain situation: "If the processed token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server must also invalidate all access tokens issued for that refresh token." Situation: Authz Server(s) and Resource Server(s) are separate systems that are set in an open triangle (no communication between them e.g. to verify access tokens). Problem: How does the Resource Server(s) know that an access token was revoked and is not valid to access resources any more? => Communication between the servers necessary => benefit of open triangle architecture are lost for this case. I think that this is a problem with large scale systems. Although, if there are several Authz Server(s) , then there has to be communication between there or a shared data base to assure that revoked (refresh) tokens are invalid. => Is this requirement really a MUST? I don't think so. Any thoughts? Regards, Stefanie Am 08.09.2010 00:21, schrieb Torsten Lodderstedt: I just submited the first version of my I-D for token revocation. Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ The I-D proposes an additional endpoint, which can be used to revoke both refresh and access tokens. The objective is to enhance OAuth security by giving clients and users explicite control of the finalization of the token life cycle, e.g. to implement application logout or access authorization removal. Please take the time to review the document (2 pages, essentially) and give me feedback. My goal is that this draft becomes a working group document. regards, Torsten. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 to split the spec into multiple parts Am 28.09.2010 08:25, schrieb Eran Hammer-Lahav: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It’s a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide. The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can’t agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need to find the right language to balance security concerns with the reality that many providers are going to deploy bearer tokens no matter what the IETF says. The OAuth 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS, and I would expect the same issue to come up with the current d
