OK, I see the use case, although I don't find it particularly 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-oa
The use case for a client revoking a token is one of a well-behaved and
well-intentioned client being "logged out", uninstalled, or otherwise
decommissioned. In these cases, you want to have a mechanism for a
client saying to the AS, "Hey, I don't need this token anymore, get rid
of it. Inciden
I think a resource server might validly revoke a token, but that a client will
not.
-bill
- Original Message -
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; Torsten Lodderstedt
; Justin Richer ; "oauth@ietf.org
WG"
Sent: Tuesday, September 11, 2012 1:49 AM
Subj
Folks,
As some of you may know, the OASIS SSTC is currently starting work on
updating the SAML2.0 specifications. OASIS will be holding a free
webinar on the plans for SAML2.1.
The date is Tuesday 25 September 2012 (11AM-East).
Registration is below.
---
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
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 would request revocation is if the client
> thinks the token is comprom
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
On Sep 11, 2012, at 7:52 AM, William Mills wrote:
>> It could even, theoretically, be included in the Access Token!
>
> It certainly could, this is the simplest form of holder of key in fact.
The IETF has certainly lots of experience with that approach.
__
I certainly agree. That would then even look like Kerberos ;-)
On Sep 10, 2012, at 4:14 PM, Derek Atkins wrote:
> It could even, theoretically, be included in the Access Token!
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo
