We are using John's/Nat's conference bridge again:
https://www3.gotomeeting.com/join/695548174
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
This discussion seems to take one step into the territory that I think of as
"deep" AS/RS communications. Solving token introspection all by itself means
that a whole bunch of stuff must have been settled out of band/statically/in
proprietary fashion. It's for this reason that UMA spec'd out "de
Hi Justin,
I have couple of questions related to "valid" parameter...
This endpoint can be invoked by the Resource Server in runtime...
In that case what is exactly meant by the "resource_id" in request ?
IMO a token to be valid depends on set of criteria based on it's type..
For a Bearer toke
But what is the motivation for a malicous client to request to revoke
remaining access tokens?
Justin Richer 写于 2013-02-08 00:06:07:
> This, I think, points out that the RO is generally more concerned
> with revoking an authorization grant than a token itself, with the
> latter potentially e
It validates the token, which would be either the token itself in the
case of Bearer or the token "id" part of something more complex like
MAC. It doesn't directly validate the usage of the token, that's still
up to the PR to do that.
I nearly added a "token type" field in this draft, but held
Okay.. I was thinking this could be used as a way to validate the token as
well. BTW even in this case shouldn't communicate the type of token to AS?
For example in the case of SAML profile - it could be SAML token..
Thanks & regards,
-Prabath
On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
This, I think, points out that the RO is generally more concerned with
revoking an authorization grant than a token itself, with the latter
potentially encompassing several tokens. The revocation draft isn't
really intended to solve that problem, as Torsten points out below.
-- Justin
On 02/
"valid" might not be the best term, but it's meant to be a field where
the server says "yes this token is still good" or "no this token isn't
good anymore". We could instead do this with HTTP codes or something but
I went with a pure JSON response.
-- Justin
On 02/06/2013 10:47 PM, Prabath S
Mike,
Thanks for reviewing the latest draft.
First, it's my understanding that the role of the editor is not merely
to express the gestalt of the working group (though that's a very
important part of it) but also to drive that discussion to it's best
technical end. I put this revision togethe
Hi all,
if you plan to present your document at the next IETF meeting please drop us a
note.
We would like to start compiling the agenda.
Ciao
Hannes & Derek
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
During the four grant types of Oauth,
1. authorization code: RO knows the authorization code upon which
access-tokens-to-be-revoked are issued
2. implicite flow: RO knows the access-tokens-to-be-revoked
3. password and client credential types: RO has no way of knowing access
tokens.
So,I
11 matches
Mail list logo
