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 <rifaat.s.i...@gmail.com> 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
