Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

[Ludwig Seitz <[e-mail]>]

Hi Ben,

replies inline.

/Ludwig
________________________________________
From: Benjamin Kaduk <[e-mail]>
Sent: Tuesday, November 26, 2019 12:04 AM
To: Ludwig Seitz
Cc: [e-mail]
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

Hi Ludwig,

On Thu, Nov 21, 2019 at 03:16:03AM +0100, Ludwig Seitz wrote:
> Hello ACE,
>
> turns out -26 didn't cover one of the items in Ben's review, namely the
> question of using Client introspection to determine token expiration as
> a lower bound for key expiration. Since the whole issue of Client
> introspection was contentious between OAuth experts, we decided to
> remove the text describing that option.  This still leaves us with the
> two other options, so the problem is still covered.

Thanks for all the updates!  I'm just about ready to push the "request Last
Call" button, but wanted to check one thing first:

Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
checking Section 5.1.1's note about "unauthorized_client" error response against the
various options in 5.8.2, to see if we're internally consistent about when
we say to send errors vs. AS request creation hints.  My recollection is
that we can have all three of a response code, error response (e.g.,
"unauthorized_client"), and (our custom format of) response payload present
in the same response, so any potential conflict would be limited to just
the response code, but please correct me if I'm wrong about that.

[LS] Section 5.6.3 describes the interaction with the token endpoint at the AS. There we mirrored the behaviour of OAuth error responses.
Section 5.8.2 describes the interaction with the newly defined authz-info endpoint at the RS. We decided that this warranted more detailed error responses, so that a client gets some hint on what went wrong when an access token is rejected by the RS.
This is why we have added the  4.03 and 4.05 messages.
Section 5.1.1 describes an access request to a resource at the RS (other than the authz-info endpoint) and has yet another different error behaviour.
For the token endpoint (5.6.3), the response code is part of the HTTP/CoAP header, while the "error" parameter (with values such as e.g. "unauthorized_client") is part of the payload in certain error responses (which may also contain "error_description" and "error_uri"), this is just mirroring behaviour of OAuth.
For the authz-info endpoint (5.8.2) no such parameters are specified in the document (i.e. it just uses the response codes).
Does this clarify the issue?

Also, a few nits that could be treated as LC comments:

There's a stray 'W' in Figure 7

In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/

In Section 8.16 we removed the entire "Specifications are required for the
standards track range of point assignment[...]" bullet point.  I think that
only the first two sentences of that bullet point were redundant with RFC
8126, and the last two ("Specifications are needed for the first-come,
first-serve range if they are expected [...]") reflected new requirements.

[LS] Does the " LC comments" part mean I should wait with updating the draft?

/Ludwig