Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[Stefanie Gerdes <[e-mail]>]

Hi all,

On 09/10/2020 02:10 PM, Stefanie Gerdes wrote:

> We also should decouple the AS request creation hints from the
> explanation of the AS discovery mechanism. The hints have the additional
> purpose that they may contain the resource server's cnonce that the
> resource server can later use to validate the access token.
> Therefore, the AS URI should be optional in the AS request creation
> hints, and we should make section 5.1.1 section 5.2.

Looking at section 5.1, I think that we would need to change the text in
there, too.

old:
In order to determine the AS in charge of a resource hosted at the RS, C
MAY send an initial Unauthorized Resource Request message to RS.  RS
then denies the request and sends the address of its AS back to C.

Instead of the initial Unauthorized Resource Request message, other
discovery methods may be used, or the client may be pre-provisioned
with an RS-to-AS mapping.

new:
C must discover the AS in charge of RS to determine where to request the
access token. To do so, C must 1. find out the AS URI to which the token
request message must be sent and 2. MUST validate that the AS with this
URI is authorized to provide access tokens for this RS.

In order to determine the AS URI, C MAY send an initial Unauthorized
Resource Request message to RS.  RS then denies the request and sends
the address of its AS back to C (see section 5.2). How C validates the
AS authorization is not in scope for this document. C may, e.g., ask
it's owner if this AS is authorized for this RS. C may also use a
mechanism that addresses both problems at once.

Viele Grüße
Steffi