Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B671A1DE2 for ; Tue, 2 Dec 2014 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gznaHLl6uhPM for ; Tue, 2 Dec 2014 09:34:03 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84301A1BF8 for ; Tue, 2 Dec 2014 09:34:02 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so10899123lbi.18 for ; Tue, 02 Dec 2014 09:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=6xubfpdyA5bMEr0LiBJ1Imw7VoPoMyRsrxzYrxeB1k4=; b=D86rBwx0FxxRnfTJCdMEsSGAEjc9vKdVuz6WhAwlvPGGRB5UzEM17CAr/y+TVVHpnw UkVfuBEPgYSMlXVztKumkx5+HZiyD88jP3Ir1qBHJz3JkCTRFppPqZyZdGcuQ2JhNkHG q6zm8efsH5HG2TSv8foR8n2deZy7gbhgRhUMkLB/b2OWxY5UHI9mqlYKw+vq29nyUx0v EpTLrzgSh11GRVa7nlmbhjmTg4B7eaNLyPItUnQtN0jIz4UoHfwIyjMZPKfRha9cA2RG i9B/FhzCaO5+WOQawpLh7Pe1oyJALQnpz9pouQ/HD92UlG2W29w0Aug7JFDJWyoKDVfw Y2Uw== X-Received: by 10.152.115.230 with SMTP id jr6mr479858lab.2.1417541632371; Tue, 02 Dec 2014 09:33:52 -0800 (PST) MIME-Version: 1.0 References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> From: Thomas Broyer Date: Tue, 02 Dec 2014 17:33:51 +0000 Message-ID: To: Donald Coffin , Justin Richer , Hannes Tschofenig , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c3674273b3a205093f21d7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wj415Kk3xvVxKvEM6i5nHhOg5Zk Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:34:11 -0000 --001a11c3674273b3a205093f21d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So what? The request is OK (no missing parameter, etc.) so a 400 is not appropriate (it could still be used, but you couldn't tell what went wrong without *also* having some well-defined error response document format; and an "invalid_token" error code wouldn't work if you're also using token authentication passed in the form-encoded body =E2=87=92 too much confusion= , not worth it). 401 or 403 are obviously not appropriate either. I'm +1000 on keeping the 200 OK response with {"active":false} JSON response. On Tue Dec 02 2014 at 18:27:03 Donald Coffin wrote: > Hi Justin, > > > > I believe you will find the answer to which HTTP Status code the AS shoul= d > return if the token is INACTIVE in Section 3.1 Error Codes of =E2=80=9CTh= e OAuth > 2.0 Framework: Bearer Token Usage=E2=80=9D [RFC6750] which states: > > > > 3.1. Error Codes > > When a request fails, the resource server responds using the appropriate > HTTP status code (typically, 400, 401, 403, or 405) and includes one of t= he > following error codes in the response: > > > > *invalid_request* > > The request is missing a required parameter, includes an unsupported > parameter or parameter value, repeats the same parameter, uses more than > one method for including an access token, or is otherwise malformed. The > resource server SHOULD respond with the HTTP 400 (Bad Request) status cod= e. > > > > *invalid_token* > > The access token provided is expired, revoked, malformed, or invalid for > other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorize= d) > status code. The client MAY request a new access token and retry the > protected resource request. > > > > *insufficient_scope* > > The request requires higher privileges than provided by the access token. > The resource server SHOULD respond with the HTTP 403 (Forbidden) status > code and MAY include the scope attribute with the scope necessary to acce= ss > the protected resource. > > > > If the request lacks any authentication information (e.g., the client was > unaware that authentication is necessary or attempted using an unsupporte= d > authentication method), the resource server SHOULD NOT include an error > code or other error information. > > > > For example: > > HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example" > > > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 22751 El Prado Suite 6216 > > Rancho Santa Margarita, CA 92688-3836 > > > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > > > *From:* Justin Richer [mailto:jricher@mit.edu] > *Sent:* Tuesday, December 2, 2014 6:06 AM > *To:* Hannes Tschofenig; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > > > > Hannes, thanks for the review. Comments inline. > > On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: > > Hi Justin, > > > > I have a few remarks regarding version -01 of the token introspection > > document. > > > > * Terminology > > > > The token introspection protocol is a client-server protocol but the > > term "client" already has a meaning in OAuth. Here the client of the > > token introspection protocol is actually the resource server. I believe > > it would make sense to clarify this issue in the terminology section or > > in the introduction. Maybe add a figure (which you could copy from > > Figure 4 of > > http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. > > > > Maybe you want to call these two parties, the introspection client and > > the introspection server. > > > I tried to avoid the word "client" for this very reason. The draft used t= o > say "client or protected resource" throughout, but in a few years of > deployment experience it's become clear that it's pretty much just > protected resources that need to do introspection so I changed that text > throughout. I don't think that "introspection client" will help here > because the party already has a name from OAuth and we should inherit it. > > > * Scope > > > > I think the document needs to be very clear that is only applicable to > > bearer tokens (and not to PoP tokens). This issue was raised at the last > > IETF meeting as well. > > > I think the document should be clear that it *specifies* the mechanism fo= r > bearer tokens, since that's the only OAuth token type that's defined > publicly right now, and that the details for PoP will have to be specifie= d > in another spec -- that's exactly what Appendix C is there for, and if th= at > can be clearer, please suggest better text. > > However, I think it's very clear how PoP tokens would work. You send the > value returned as the "access_token" in the token endpoint response, whic= h > is effectively the public portion of the PoP token. Just like a bearer > token, this value is passed as-is from the client to the RS and would be > passed as-is from the RS to the AS during introspection. The AS can then > use that to look up the key and return it in an as-yet-unspecified field = so > that the RS can validate the request. The RS wouldn't send the signature = or > signed portion of the request for the AS to validate -- that's a bad idea= . > But these are all details that we can work out in the PoP-flavored > extension. As I noted in the other thread, we'll have to make a similar > extension for Revocation, so I still don't think it makes sense to hold u= p > this work and wait for PoP to be finished because it's useful now, as-is. > > > > > > > * Meta-Information > > > > You have replicated a lot of the claims defined in > > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 > > and I am wondering why you have decided to not just re-use the entire > > registry from JWT? > > > > If you want to create a separate registry (which I wouldn't recommend) > > then you have to put text into the IANA consideration section. > > > The idea was to inherit JWT's syntax and semantics, at least on the wire, > and add additional fields. It probably makes sense to just inherit the JW= T > registry, so we can do that. > > > When you write: > > > > " > > The endpoint MAY allow other parameters to provide further context to > > the query. > > " > > > > You could instead write that the token introspection MUST ignore any > > parameters from the request message it does not understand. > > > Noted, will add. > > > Of course, there is the question whether any of those would be security > > critical and hence ignoring them would cause problems?! > > > Anything security critical would be provider-specific, in which case it > wouldn't ignore them. > > > * Security > > > > The requirement for authenticating the party issuing the introspection > > request to the token introspection endpoint is justified in the security > > and the privacy consideration section. The security threat is that an > > attacker could use the endpoint to testing for tokens. The privacy > > threat is that a resource server learns about the content of the token, > > which may contain personal data. I see the former as more dangerous than > > the latter since a legitimate resource server is supposed to learn about > > the authorization information in the token. An attacker who had gotten > > hold of tokens will not only learn about the content of the token but he > > will also be able to use it to get access to the protected resource itsel= f. > > > > In any case, to me this sounds like mutual authentication should be > > mandatory to implement. This is currently not the case. On top of that > > there is single technique mandatory-to-implement outlined either (in > > case someone wants to use it). That's in general not very helpful from > > an interoperability point of view. Yet another thing to agree on between > > the AS and the RS. > > > I had similar thoughts when putting draft -01 together but didn't want to > make a normative change like that without the WG input. I'm fine with > strengthening this to a MUST, since as far as I'm aware that's how it wor= ks > in all existing implementations (can anyone else comment on this?). I'm > less comfortable with making one particular mechanism MTI, since I know o= f > implementations that use either a special set of credentials passed just > like client credentials to the token endpoint, or an OAuth token > specifically for the introspection endpoint. If we do standardize on one > MTI form, I'd suggest that we make it the OAuth bearer token. > > > * SHOULDs > > > > This is my usual comment that any SHOULD statement should give the > > reader enough information about the trade-off decision he has to make. > > When should he implement something and when should he skip it? > > > Noted, thanks. > > > * Minor items > > > > You write: > > > > " > > These include using > > structured token formats such as JWT [JWT] or SAML [[ Editor's Note: > > Which SAML document should we reference here? ]] and proprietary > > inter-service communication mechanisms (such as shared databases and > > protected enterprise service buses) that convey token information. > > " > > > > Just reference the JWT since that's what we standardize. > > > I'm fine with that, didn't want to offend the SAML cabal but we can cut i= t. > > > * 'Active' claim > > > > you write: > > " > > active REQUIRED. Boolean indicator of whether or not the presented > > token is currently active. The authorization server determines > > whether and when a given token is in an active state. > > " > > > > Wouldn't it make more sense to return an error rather than saying that > > this token is not active. > > > It's not an error, really. It's a valid request and valid response saying > that token isn't any good. It would be easy enough to change the returned > error code on the {active:false} response, but to which code? The request > isn't Forbidden, or Not Found (the token could have been found but it's > been deactivated or just not available to the RS that's asking for it), o= r > Unauthorized, or even a Bad Request. So my logic is that the response is > "OK", but the content of the response tells you the metadata about the > token, which is that it's not active. > > > * Capitalization > > > > Reading through the text I see bearer token/Bearer Token, Client/client, > > etc. issue. > > > Thanks, still breaking old Bad Habits of capitalizing Terms In The > Document. Tried to clean it up, will do more. > > > * AS <-> RS relationship > > > > You write: > > " > > Since > > OAuth 2.0 [RFC6749] defines no direct relationship between the > > authorization server and the protected resource, only that they must > > have an agreement on the tokens themselves, there have been many > > different approaches to bridging this gap. > > " > > > > I am not sure what you mean by "defines no relationship" between the AS > > and the RS. Of course, there is a relationship. The AS issues tokens for > > access for a specific RS. The RS needs to understand the tokens or if it > > does not understand them it needs to know which AS to interact with to > > learn about the content. > > > > In a nutshell, I am not sure what you want to say with this paragraph > > particularly since you state that they have to have an agreement about > > the tokens. > > > What I was trying to point out is that it doesn't define the nature of th= e > relationship between the two components. Specifically, it says: > > The methods used by the resource > > server to validate the access token (as well as any error responses) > > are beyond the scope of this specification but generally involve an > > interaction or coordination between the resource server and the > > authorization server. > > This spec provides one mechanism for this validation. So we could > reference this directly if that's helpful. > > -- Justin > > > > > > > > > Ciao > > Hannes > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c3674273b3a205093f21d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So what?

The request is OK (no missing parameter, etc.) so a 40= 0 is not appropriate (it could still be used, but you couldn't tell wha= t went wrong without *also* having some well-defined error response documen= t format; and an "invalid_token" error code wouldn't work if = you're also using token authentication passed in the form-encoded body = =E2=87=92 too much confusion, not worth it).

401 o= r 403 are obviously not appropriate either.

I'= m=C2=A0+1000 on keeping the 200 OK response with {"active":false}= JSON response.

On Tue Dec 02 2014 at 1= 8:27:03 Donald Coffin <donald.coffin@reminetworks.com> wrote:
=

Hi Justin,<= /p>

=C2=A0

I believe you will find the answer to wh= ich HTTP Status code the AS should return if the token is INACTIVE in Secti= on 3.1 Error Codes of =E2=80=9CThe OAuth 2.0 Framework: Bearer Token Usage= =E2=80=9D [RFC6750] which states:

=C2=A0

3.1.=C2=A0 Error Codes=

When a request fails, the resource server responds using the appropri= ate HTTP status code (typically, 400, 401, 403, or 405) and includes one of= the following error codes in the response:

=C2=A0=

invalid_request

The requ= est is missing a required parameter, includes an unsupported parameter or p= arameter value, repeats the same parameter, uses more than one method for i= ncluding an access token, or is otherwise malformed. The resource server SH= OULD respond with the HTTP 400 (Bad Request) status code.

=C2=A0

invalid_token

The access token provided is expired, revoked, malformed, or invalid fo= r other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorize= d) status code. The client MAY request a new access token and retry the pro= tected resource request.

=C2=A0

insuffici= ent_scope

The request requires hi= gher privileges than provided by the access token. The resource server SHOU= LD respond with the HTTP 403 (Forbidden) status code and MAY include the sc= ope attribute with the scope necessary to access the protected resource.=

=C2=A0

If the request lacks any authentication = information (e.g., the client was unaware that authentication is necessary = or attempted using an unsupported authentication method), the resource serv= er SHOULD NOT include an error code or other error information.

=C2=A0

For example:

=C2=A0 HTTP/1.1 401 U= nauthorized=C2=A0 WWW-Authenticate: Bearer realm=3D"example"

=C2=A0

=C2=A0

Best regards,

Don

Donald F. Coffin

Founder/CTO=

=C2=A0=

REMI Networks

22751 El Pr= ado Suite 6216

Rancho Santa Margarit= a, CA=C2=A0 92688-3836

=C2=A0=

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949)= 636-8571

Email:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=

=C2=A0=

From: Justin Richer [mailto:jricher@mit.edu]
Sent: T= uesday, December 2, 2014 6:06 AM
To: Hannes Tschofenig; oauth@ietf.org
Subje= ct: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

=C2=A0=

Hannes, thanks for the review. Comme= nts inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:=

Hi Justin,
=C2=A0
I have=
 a few remarks regarding version -01 of the token introspection
document.
=C2=A0
* Terminology
=C2=A0
The=
 token introspection protocol is a client-server protocol but the=

term "client" already has a meaning in OAuth. Here=
 the client of the
token introspection protocol is =
actually the resource server. I believe
it would ma=
ke sense to clarify this issue in the terminology section or<=
/pre>
in the introduction. Maybe add a figure (which you could copy fro=
m
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.<=
u>
=C2=A0
Maybe you want to ca=
ll these two parties, the introspection client and
=
the introspection server.


I tried to avoid the word "client" for this very reason= . The draft used to say "client or protected resource" throughout= , but in a few years of deployment experience it's become clear that it= 's pretty much just protected resources that need to do introspection s= o I changed that text throughout. I don't think that "introspectio= n client" will help here because the party already has a name from OAu= th and we should inherit it.


* Scope
<= pre>=C2=A0
I think the document needs to be very cl=
ear that is only applicable to
bearer tokens (and n=
ot to PoP tokens). This issue was raised at the last
IETF meeting as well.


I think the document should be clear that it *specifies* the mechan= ism for bearer tokens, since that's the only OAuth token type that'= s defined publicly right now, and that the details for PoP will have to be = specified in another spec -- that's exactly what Appendix C is there fo= r, and if that can be clearer, please suggest better text.

However, = I think it's very clear how PoP tokens would work. You send the value r= eturned as the "access_token" in the token endpoint response, whi= ch is effectively the public portion of the PoP token. Just like a bearer t= oken, this value is passed as-is from the client to the RS and would be pas= sed as-is from the RS to the AS during introspection. The AS can then use t= hat to look up the key and return it in an as-yet-unspecified field so that= the RS can validate the request. The RS wouldn't send the signature or= signed portion of the request for the AS to validate -- that's a bad i= dea. But these are all details that we can work out in the PoP-flavored ext= ension. As I noted in the other thread, we'll have to make a similar ex= tension for Revocation, so I still don't think it makes sense to hold u= p this work and wait for PoP to be finished because it's useful now, as= -is.


=C2=A0
=C2=A0<=
/pre>
* Meta-Information
=C2=A0
You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-jso=
n-web-token-31
and I am wondering why you have =
decided to not just re-use the entire
registry from=
 JWT?
=C2=A0
If you want to=
 create a separate registry (which I wouldn't recommend)<=
/pre>
then you have to put text into the IANA consideration section.=


The idea was to in= herit JWT's syntax and semantics, at least on the wire, and add additio= nal fields. It probably makes sense to just inherit the JWT registry, so we= can do that.


When you write:
=
=C2=A0
"
The endpoint MAY=
 allow other parameters to provide further context to
the query.
"
=C2=A0
You could instead write that the token introspecti=
on MUST ignore any
parameters from the request mess=
age it does not understand.


Noted, will add.


Of course, there is the ques=
tion whether any of those would be security
critica=
l and hence ignoring them would cause problems?!


Anything security critical would be provid= er-specific, in which case it wouldn't ignore them.


= 

=
* Security
=C2=A0
The requi=
rement for authenticating the party issuing the introspection=

request to the token introspection endpoint is justified in the =
security
and the privacy consideration section. The=
 security threat is that an
attacker could use the =
endpoint to testing for tokens. The privacy
threat =
is that a resource server learns about the content of the token,<=
/u>
which may contain personal data. I see the former as more dan=
gerous than
the latter since a legitimate resource =
server is supposed to learn about
the authorization=
 information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he= 
will also be able to use it to get access to the p=
rotected resource itself.
=C2=A0
In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the ca=
se. On top of that
there is single technique mandat=
ory-to-implement outlined either (in
case someone w=
ants to use it). That's in general not very helpful from<=
/pre>
an interoperability point of view. Yet another thing to agree on =
between
the AS and the RS.

I had similar thoughts when putting draf=
t -01 together but didn't want to make a normative change like that wit=
hout the WG input. I'm fine with strengthening this to a MUST, since as=
 far as I'm aware that's how it works in all existing implementatio=
ns (can anyone else comment on this?). I'm less comfortable with making=
 one particular mechanism MTI, since I know of implementations that use eit=
her a special set of credentials passed just like client credentials to the=
 token endpoint, or an OAuth token specifically for the introspection endpo=
int. If we do standardize on one MTI form, I'd suggest that we make it =
the OAuth bearer token.


* SHOULDs
=C2=A0
This is my usual comment that any SHOULD st=
atement should give the
reader enough information a=
bout the trade-off decision he has to make.
When sh=
ould he implement something and when should he skip it?
=


Noted, thanks.


<= u>

*=
 Minor items
=C2=A0
You wri=
te:
=C2=A0
"=

These include using
=C2=A0=C2=A0 str=
uctured token formats such as JWT [JWT] or SAML [[ Editor's Note:
=C2=A0=C2=A0 Which SAML document should we reference her=
e? ]] and proprietary
=C2=A0=C2=A0 inter-service co=
mmunication mechanisms (such as shared databases and
=C2=A0=C2=A0 protected enterprise service buses) that convey token inform= ation.
"
=C2=A0=

Just reference the JWT since that's what we standardi=
ze.


I'm fine= with that, didn't want to offend the SAML cabal but we can cut it.
= 

* 'Active' claim
=C2=
=A0
you write:
"
=C2=A0=C2=A0 active=C2=A0 REQUIRED.=C2=A0 Boolean indicator of =
whether or not the presented
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 token is currently active.=C2=A0 The authorization server determi=
nes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether and when=
 a given token is in an active state.
"=

=C2=A0
Wouldn't it make more =
sense to return an error rather than saying that
th=
is token is not active.


It's not an error, really. It's a valid request and valid r= esponse saying that token isn't any good. It would be easy enough to ch= ange the returned error code on the {active:false} response, but to which c= ode? The request isn't Forbidden, or Not Found (the token could have be= en found but it's been deactivated or just not available to the RS that= 's asking for it), or Unauthorized, or even a Bad Request. So my logic = is that the response is "OK", but the content of the response tel= ls you the metadata about the token, which is that it's not active. 

* Capitalization
=C2=A0
Reading through the text I see bearer token/Bearer Token, Clie=
nt/client,
etc. issue.


Thanks, still breaking old Bad Habits of cap= italizing Terms In The Document. Tried to clean it up, will do more.

* AS <-> RS relationship
=
=C2=A0
You write:
"=

=C2=A0=C2=A0 Since
=C2=A0=C2=A0 OAut=
h 2.0 [RFC6749] defines no direct relationship between the
=C2=A0=C2=A0 authorization server and the protected resource, only =
that they must
=C2=A0=C2=A0 have an agreement on th=
e tokens themselves, there have been many
=C2=A0=C2=
=A0 different approaches to bridging this gap.
&quo=
t;
=C2=A0
I am not sure wha=
t you mean by "defines no relationship" between the AS<=
/u>
and the RS. Of course, there is a relationship. The AS issues=
 tokens for
access for a specific RS. The RS needs =
to understand the tokens or if it
does not understa=
nd them it needs to know which AS to interact with to
learn about the content.
=C2=A0
In a nutshell, I am not sure what you want to say with this paragra=
ph
particularly since you state that they have to h=
ave an agreement about
the tokens.


W= hat I was trying to point out is that it doesn't define the nature of t= he relationship between the two components. Specifically, it says:

=C2=A0=C2=A0 The methods used by the resource
=C2=A0=C2=A0 server to validate the access token (as well as any e=
rror responses)
=C2=A0=C2=A0 are beyond the scope o=
f this specification but generally involve an
=C2=
=A0=C2=A0 interaction or coordination between the resource server and the
=C2=A0=C2=A0 authorization server.
This spec provides one mechanism for this validati=
on. So we could reference this directly if that's helpful. 

=C2=
=A0 -- Justin


=C2=A0
=C2=
=A0
=C2=A0
Ciao
Hannes
=C2=A0



_____________________________=
__________________
OAuth mailing list=

OAuth@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0<=
/u>
_______________________________________________ OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--001a11c3674273b3a205093f21d7--