Hi Ben, replies inline.
/Ludwig ________________________________________ From: Benjamin Kaduk <[email protected]> Sent: Tuesday, November 26, 2019 12:04 AM To: Ludwig Seitz Cc: [email protected] 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
