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.
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.
Thanks,
Ben
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
