Thanks for the review and shepherding Rifaat,
Please see inline below where I've endeavored to reply to your comments. A
-07 draft with the respective changes is forthcoming.
On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef
wrote:
> Vittorio, Brian,
>
> The following is my document shepherd review for the step-up
> authentication document:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html
>
>
> *Comments*
>
> * Section 4, first sentence:
>
>
> You might have a reason for using MAY, instead of SHOULD, but it is not
> obvious to me. Can you add some text to explain the reason for this?
>
Looking at it again, I think I concur with you and also think it should be
a SHOULD. I'll change it as such. I believe the reason behind the MAY
originally was trying to convey that a client is never obligated to act on
receiving a challenge by sending an authorization request. But that text
has more going on that muddies it somewhat and a SHOULD still allows for it
and would be more appropriate there anyway.
> * Section 5
>
> “when it comes to access tokens in this specification it is RECOMMENDED
> that the requested acr value is treated as required”
>
> Not sure why this sentence started in such a way. Why not just explicitly
> use MUST to make sure that the acr value is included in the access token?
>
The rest of Section 5 tries to put that into context better but basically
OIDC suggests that a successful auth response be sent when the requested
acr can't be satisfied but it does allow the AS to respond with an error auth
response. This draft wants to nudge the other way and suggest that an
error auth
response be sent when the requested acr can't be satisfied but still allow
for the OIDC suggested behavior. It's a bit of a fine line. But that's the
aim. Furthermore, I do think it's appropriate to always allow authorization
servers some latitude in handling the auth request with success or failure
as there may be other things that come into play during the user
authentication and approval interactions.
> * Section 9, last sentence
>
> I think we need to have a stronger statement here and not leave it wide
> open like this.
>
> Maybe state that the resource server SHOULD NOT return a challenge if the
> request did not include a valid token?
>
I'd suggest that there are legit cases where either behavior would be okay
and perfectly appropriate. We are pointing out the potential
implications/tradeoffs, which is appropriate for this in the
considerations. And allows RSs to do what is best for their situation
having been informed of those considerations.
*Nits*
>
> Section 2 - “not be necessarily hold true” -> drop the “be”
>
> Section 5 - Thee - > The
>
> Section 8 - any undesirable -> an undesirable
>
> Section 9 - {#Challenge} -> fix the reference
>
Thanks for catching these. Will fix 'em all.
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
