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

[Benjamin Kaduk <[e-mail]>]

On Wed, Nov 27, 2019 at 03:31:16PM +0000, Ludwig Seitz wrote:
> 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?

It does; thanks for putting the pieces into the proper context for me.

> 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?

It means you're free to wait, yes.  (If you want to update anyway that's
also fine.)

-Ben