On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell <bcampb...@pingidentity.com> wrote:
> 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. > > I get that, but I am having a hard time with a sentence that states *RECOMMENDED* and *required* at the same time. Maybe a SHOULD is more appropriate then? Regards, Rifaar > > >> * 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
