Greetings WG,
In section 2.1 of RFC 7009, it says:
"The authorization server first validates the client credentials (in
case of a confidential client) and then verifies whether the token
was issued to the client making the revocation request. If this
validation fails, the request is
> ...what's the intended way that the "request is refused and the client
is informed of the error" when the the token was not issued to the client
making the revocation request?
We return an error_code of "invalid_request" and an appropriate error
message.
Todd Lainhart
Rational software
I
FWIW, we return unauthorized_client.
Le 31 janv. 2014 18:06, "Todd W Lainhart" a écrit :
> > ...what's the intended way that the "request is refused and the client
> is informed of the error" when the the token was not issued to the client
> making the revocation request?
>
> We return an error_c
Hi all,
I have been working with the co-authors of these two documents to get
the shepherd write-ups written:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
The shepherd write-ups can be found here:
https://github.com/ha
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Assertion Framework for OAuth 2.0 Client
Authentication and Authorization Grants
Authors
Just updated a couple of references.
-- Forwarded message --
From:
Date: Fri, Jan 31, 2014 at 3:49 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-14.txt
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
A New Internet-Draft is available from the on-line Internet-Draf