On Wed, Nov 27, 2019 at 03:31:16PM +0000, Ludwig Seitz wrote:
> Hi Ben,
>
> replies inline.
>
> /Ludwig
> ________________________________________
> From: Benjamin Kaduk <ka...@mit.edu>
> Sent: Tuesday, November 26, 2019 12:04 AM
> To: Ludwig Seitz
> Cc: ace@ietf.org
> 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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
