It's not uncommon for a resource server (or API or protected resource) to
have a client id established with the AS. Typically that's used in the
context of the resource server acting as a client (and authenticating with
the AS) when calling the AS for access token introspection.  Using that id
as the audience of an access token is certainly a possibility. But for
other client's to know and use the client id of a resource server as the
value of ‘resource’ parameter seems somewhat awkward and unlikely to work
particularly well. Also the syntax of the values don't quite match up.
n
On Wed, Feb 27, 2019 at 12:46 AM Jaap Francke <jaap.francke=
[email protected]> wrote:

> Hi all,
>
> I have some questions/thoughts on the new draft for resource indicators.
> I didn’t do an in-depth study but would like to share my thoughts with you
> anyway.
>
> 1. In this draft, the Resource is identified by ‘resource’ parameter. For
> example, when the resource is an API, I would expect that API to validate
> the access_token at the resource server. The protocol for this would be
> based on the API’s client_id, so from that angle using the the client_id
> could be a different way to indicate the intended recipient of the access
> token.
>
> 2. I also think that the ‘resource’ parameter would be closely related to
> the “aud” claim specified by the OpenID Connect specifications. I think it
> is getting more and more common to use the OIDC-protocol “on top of OAuth”,
> so I’m wondering how the resource parameter would relate to that. The
> values of the ‘aud’ parameter are also client_id’s.
>
> Thanks in advance for responding to my views.
> Ciao!
>
> Jaap Francke
>
>
>
> On 26 Feb 2019, at 21:00, [email protected] wrote:
>
>    draft-ietf-oauth-resource-indicators-02
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to