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 givin
Igor,
The intention of the draft draft-vrancken-oauth-redelegation was to specify a
mechanism for doing exactly what Thomas has described:
> ... User#1/Client#1 asks for
> an access token (to a given resource) with the
> intention of later handing over the access-token to
> a different User#2/C
Thomas,
It looks to me like the intention in this use case is similar to that of
the "multilegged OAuth" (later renamed to the politically-correct
"recursive delegation"). This use case has been published in Bart's and
Zachary's draft. which has expired now. This case has moved into the
overa
__
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> Sent: Wednesday, August 25, 2010 4:29 PM
> To: Thomas Hardjono
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML
> people
>
> Agai
Aaron,
Actually, I never fully understood the "password" access grant type, as
technically it is against the very spirit of OAuth, which, I thought,
was to avoid divulging the password.
TLS provides confidentiality, and so you ought to be able to rely on
TLS, although I have no idea what kin
