AM
To: Donald F Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott Crowder';
'Dave Robin'; 'John Teeter'; pmad...@pingidentity.com; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlne
Robin'; 'John Teeter'; pmad...@pingidentity.com;
'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne
Hendry'; 'Lynne Rodoni'; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
OAu
x27;John Teeter'; pmad...@pingidentity.com; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni';
oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
OAuth doesn'
OAuth doesn't get into the business of what the UI for managing grants
is like. Having the user, admin, or resource owner revoke, downscope, or
otherwise alter a grant needs to happen with user interactions that are
going to be different depending on the provider and use case.
-- Justin
On 0
Torsten,
Thanks for the response. What is the “respective portal belonging to the AS”?
I haven’t seen anything in the OAuth 2.0 Authorization Framework that describes
a “portal” on the AS a Resource Owner can log into to view a valid list of
authorization grants. Is this an out-of-band im
Hi Donald,
thank you for sharing your thoughts with us. I've never seen revocation as
change of scope of the authorization, but it sounds reasonable. The current
design handles the issues you raised differently.
The AS is involved in the revocation process as it exposes the revocation
endpoint
Torsten,
A colleague of mine and I were discussing what should occur when a Retail
Customer desires to change the existing authorized access of a Third Party.
During our discussion they asked "How does the Retail Customer know the
Third Party actually issued a Token revocation request? Isn't t
PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:oauth-boun...@ietf.org
I'm fine with this solution as well. --George
On 2/5/13 3:45 PM, Torsten Lodderstedt wrote:
I know, that's why I asked. I think this is the simplest way to deal with
this type of error. I
s.ibm.com>*
From: "Richer, Justin P." <mailto:jric...@mitre.org>>
To: George Fletcher mailto:gffle...@aol.com>>,
Cc: OAuth WG mailto:oauth@ietf.org>>
Date: 02/04/2013 04:10 PM
Subject: Re
eet, Littleton, MA 01460-1250
>>> 1-978-899-4705
>>> 2-276-4705 (T/L)
>>> lainh...@us.ibm.com
>>>
>>>
>>>
>>>
>>> From:"Richer, Justin P."
>>> To:George Fletcher ,
>>> Cc:
.com>*
From: "Richer, Justin P." mailto:jric...@mitre.org>>
To: George Fletcher mailto:gffle...@aol.com>>,
Cc: OAuth WG mailto:oauth@ietf.org>>
Date: 02/04/2013 04:10 PM
Subject: Re: [OAUTH-WG] draft-iet
> 2-276-4705 (T/L)
> lainh...@us.ibm.com
>
>
>
>
>
> From:"Richer, Justin P."
> To:George Fletcher ,
> Cc: OAuth WG
> Date:02/04/2013 04:10 PM
> Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation
et, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com
From: "Richer, Justin P."
To: George Fletcher ,
Cc: OAuth WG
Date: 02/04/2013 04:10 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:oauth-boun...@ietf.org
uot;
To: Torsten Lodderstedt ,
Cc: OAuth WG
Date: 02/04/2013 03:42 PM
Subject:Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:oauth-boun...@ietf.org
On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt
wrote:
> Hi all,
>
> before I publish a new revision
On Feb 4, 2013, at 3:57 PM, George Fletcher
wrote:
>
> On 2/4/13 3:41 PM, Richer, Justin P. wrote:
>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt
>> wrote:
>>
>>
>>> - invalid_token error code: I propose to use the new error code
>>> "invalid_parameter" (as suggested by Peter and Geor
On 2/4/13 3:41 PM, Richer, Justin P. wrote:
On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt wrote:
- invalid_token error code: I propose to use the new error code
"invalid_parameter" (as suggested by Peter and George). I don't see the need to
register it (see http://www.ietf.org/mail-archi
On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt wrote:
> Hi all,
>
> before I publish a new revision of the draft, I would like to sort out the
> following issues and would like to ask you for your feedback.
>
> - Authorization vs. access grant vs. authorization grant: I propose to use
> "au
Yes on token_type
Sent from my Windows Phone
From: Torsten Lodderstedt<mailto:tors...@lodderstedt.net>
Sent: 2/3/2013 6:02 AM
To: OAuth WG<mailto:oauth@ietf.org>
Subject: [OAUTH-WG] draft-ietf-oauth-revocation
Hi all,
before I publish a new rev
arty Burns'; 'Uday
Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
Hi Donald,
Am 03.02.2013 12:57, schrieb Donald F Coffin:
[Don] A typical Third Party applic
On 03/02/13 13:01, Torsten Lodderstedt wrote:
Hi all,
before I publish a new revision of the draft, I would like to sort out
the following issues and would like to ask you for your feedback.
- Authorization vs. access grant vs. authorization grant: I propose to
use "authorization grant".
- inva
: Torsten Lodderstedt
To: OAuth WG
Sent: Sunday, February 3, 2013 5:01 AM
Subject: [OAUTH-WG] draft-ietf-oauth-revocation
Hi all,
before I publish a new revision of the draft, I would like to sort out the
following issues and would like to ask you for your feedback.
- Authorization vs. access
Hi Hannes,
Am 03.02.2013 14:10, schrieb Hannes Tschofenig:
Hi Torsten,
On 02/03/2013 03:01 PM, Torsten Lodderstedt wrote:
- invalid_token error code: I propose to use the new error code
"invalid_parameter" (as suggested by Peter and George). I don't see the
need to register it (see
http://www
Hi Torsten,
On 02/03/2013 03:01 PM, Torsten Lodderstedt wrote:
- invalid_token error code: I propose to use the new error code
"invalid_parameter" (as suggested by Peter and George). I don't see the
need to register it (see
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but
w
Hi Donald,
Am 03.02.2013 12:57, schrieb Donald F Coffin:
Perhaps the section on the *Server’s Revocation Policy* should address
a few of the reasons why a client may want or need to revoke a token.
The current description provides no consideration for the relationship
between tokens and scope
Hi all,
before I publish a new revision of the draft, I would like to sort out
the following issues and would like to ask you for your feedback.
- Authorization vs. access grant vs. authorization grant: I propose to
use "authorization grant".
- invalid_token error code: I propose to use the n
Hi Donald,
Am 03.02.2013 12:57, schrieb Donald F Coffin:
[Don] A typical Third Party application built to use the ESPI Standard
will interact with a Retail Customer and their energy provider. The
nature of interaction with the Retail Customer will utilize short
interactive sessions. Howeve
t; John Adkins; Scott Crowder; Dave Robin; John Teeter;
> pmad...@pingidentity.com; Edward Denson; Marty Burns; Uday Verma; Ray
> Perlner; Anne Hendry; Lynne Rodoni; oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
>
> First, just want to say this is a great
Marty Burns; Uday Verma;
Ray Perlner; Anne Hendry; Lynne Rodoni; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
First, just want to say this is a great write up of the situation. Thanks!
A couple of additional thoughts regarding token management and processing...
1. If all t
First, just want to say this is a great write up of the situation. Thanks!
A couple of additional thoughts regarding token management and processing...
1. If all tokens being revoked are tokens issued by the same
Authorization Server (AS) then it can easily mark which are refresh and
which are
new text
6. I think clarifying words would help here
7. I prefer the wording you responded with and not the current text as it puts
a requirement on the client
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Saturday, January 26, 2013 10:33 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
anuary 26, 2013 10:33 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Hi Tony,
thanks for your review comments.
*** @Justin: thanks for jumping in. ***
I would like to recap the results of the discussion so far and
propose some changes.
Am 24.01.2013 00:54, schrieb
Hi Tony,
thanks for your review comments.
*** @Justin: thanks for jumping in. ***
I would like to recap the results of the discussion so far and propose
some changes.
Am 24.01.2013 00:54, schrieb Anthony Nadalin:
Review:
1.Since not stated I assume that the Revocation Endpoint can exist o
Hi Hannes,
Am 11.01.2013 09:18, schrieb Hannes Tschofenig:
Thank you Torsten for updating the document.
Two issues have been raised:
1) Terminology: Authorization vs. access grant vs. authorization grant
There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/w
Hi Hannes,
Am 11.01.2013 09:18, schrieb Hannes Tschofenig:
Thank you Torsten for updating the document.
Two issues have been raised:
1) Terminology: Authorization vs. access grant vs. authorization grant
There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/
.@mitre.org]
*Sent:* Thursday, January 24, 2013 8:55 AM
*To:* Anthony Nadalin
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
1. We have WebFinger lets use that as we have already been through the
discovery issues, point being there are security issues at
again. The code path is very simple and straightforward and
is exactly the same whether or not you're using the revocation endpoint.
-- Justin
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc:
htforward and is exactly the same whether or not you're using the
revocation endpoint.
-- Justin
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oa
; -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Thursday, January 24, 2013 6:17 AM
> To: Anthony Nadalin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
> Not to jump in and answer for Torsten,
ver is allowed to also nuke any access tokens that it
wants to, but if the client wants to be really, really sure, it can
revoke all of its access tokens separately.
-- Justin
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 24, 2013 6:17 AM
To:
t: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Not to jump in and answer for Torsten, but I thought I'd offer at least my
understanding of the document:
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
> 1. Since not stated I assume that the Revocation Endpoint can exist on
Not to jump in and answer for Torsten, but I thought I'd offer at least
my understanding of the document:
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it assu
Review:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it assumed that they are
1), if so how is the Revocation Endpoint found?
2. Any token type that is supported can be revoked, including refresh
tok
Thank you Torsten for updating the document.
Two issues have been raised:
1) Terminology: Authorization vs. access grant vs. authorization grant
There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html
I personally don't have an op
Hi Hannes,
thanks for providing feedback to the draft. I adopted the text you
proposed with minor tweaks.
Does this work for your?
OAuth 2.0 allows deployment flexibility with respect to the style of
access tokens. The access tokens may be self-contained so that an
resource server needs no
Hi Torsten,
thanks for the draft update. It looks good to me.
I only have a minor wording suggestion for Section 3.
Instead of
"
Depending on the authorization server's token design, revocation of
access tokens might be a costly process. For example, revocation of
self-contained acc
Hi Hannes,
thanks for your review and feedback. Please find my comments inline.
Am 08.10.2012 13:52, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Hi all,
I went through draft-ietf-oauth-revocation-01 to what has changed
between version -00 and -01.
A few minor comments:
Title: maybe you shou
Hi all,
I went through draft-ietf-oauth-revocation-01 to what has changed
between version -00 and -01.
A few minor comments:
Title: maybe you should change it from "Token Revocation" to "Revocation
of OAuth Access and Refresh Tokens" to make it a bit more informative.
The abstract is also a bi
*To:* William Mills
*Cc:* Hannes Tschofenig ; Torsten Lodderstedt
; "oauth@ietf.org WG"
*Sent:* Tuesday, September 11, 2012 8:58 AM
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
The use case for a client revoking a token is one of a well-behaved and
well-intentioned client being
compelling.
*From:* Justin Richer
*To:* William Mills
*Cc:* Hannes Tschofenig ; Torsten Lodderstedt
; "oauth@ietf.org WG"
*Sent:* Tuesday, September 11, 2012 8:58 AM
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
The use case for
her ; "oauth@ietf.org
> WG"
> Sent: Tuesday, September 11, 2012 1:49 AM
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
>
> Hi Bill,
>
> if I read your post correctly then you are saying that you do not like what
> is in
>
> Did I understood you
out the token.
From: Torsten Lodderstedt
To: Justin Richer
Cc: "oauth@ietf.org WG"
Sent: Monday, September 10, 2012 12:55 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
+1
Am 10.09.2012 15:49, schrieb Justin Richer:
That requires the client and/or resource server to run an e
12 1:49 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
Hi Bill,
if I read your post correctly then you are saying that you do not like what is
in
Did I understood you correctly?
Ciao
Hannes
On Sep 11, 2012, at 7:45 AM, William Mills wrote:
> Well, the only way the client
It's perfectly reasonable that the AS needs to revoke an Access Token,
yes; but why does the client need to know ahead of time? The client will
find out as soon as it tries to use the bad token at the RS, won't it?
It's a different question entirely of how the RS finds out that a token
has bee
>
> From: Torsten Lodderstedt
> To: Justin Richer
> Cc: "oauth@ietf.org WG"
> Sent: Monday, September 10, 2012 12:55 PM
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
>
> +1
>
> Am 10.09.2012 15:49, schrieb Justin Richer:
> > That requir
Hi Justin,
I completely agree that a mechanism for the Authorization Server to notify the
Clients may not be desireable in all cases.
However, if the Authorization Server hands out long lived tokens then it may
want to notify the Clients (particularly when those are Web servers) about
revoca
5:25 AM
Subject: [OAUTH-WG] draft-ietf-oauth-revocation-00
The current draft defines an additional endpoint, the token revocation
endpoint, so that clients can request the revocation of a particular token.
Wouldn't it make sense to also allow Authorization Servers to tell Clients or
Resour
should already have all of the information it needs about the token.
From: Torsten Lodderstedt
To: Justin Richer
Cc: "oauth@ietf.org WG"
Sent: Monday, September 10, 2012 12:55 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
+1
Am 10.
+1
Am 10.09.2012 15:49, schrieb Justin Richer:
That requires the client and/or resource server to run an endpoint of
their own at all times, and it requires the AS to keep track of all
instances of a client and RS. This isn't likely to be particularly
desirable, scalable, or usable. I don't se
That requires the client and/or resource server to run an endpoint of
their own at all times, and it requires the AS to keep track of all
instances of a client and RS. This isn't likely to be particularly
desirable, scalable, or usable. I don't see too much harm in trying to
define it, but I do
The current draft defines an additional endpoint, the token revocation
endpoint, so that clients can request the revocation of a particular token.
Wouldn't it make sense to also allow Authorization Servers to tell Clients or
Resource Servers to revoke tokens?
Ciao
Hannes
__
60 matches
Mail list logo