Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt

- 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, > >

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 op

Re: [OAUTH-WG] I-D on token revocation submitted

ady 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

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

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

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

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

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 th

Re: [OAUTH-WG] Versioning

f 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

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 modif