*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
__
13 matches
Mail list logo
