On Mon, Dec 19, 2022 at 4:40 PM Brian Campbell <[email protected]> wrote:
> Hi Rifaat, > > I certainly didn't expect a response over the weekend. Apologies if the > timing of my message (late afternoon Friday my timezone) unintentionally > encouraged weekend work. But with that said, my attempt at a reply is > below. > > No worries :) > On Sun, Dec 18, 2022 at 1:42 PM Rifaat Shekh-Yusef < > [email protected]> wrote: > >> >> On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell < >> [email protected]> wrote: >> >>> >>> On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef < >>> [email protected]> wrote: >>> >>> >>> >>>> * 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? >> > > Per RFC2119 sec 3 <https://www.rfc-editor.org/rfc/rfc2119.html#section-3>, > SHOULD and RECOMMENDED are basically stating the same level of requirement. > And required itself isn't a normative keyword. So I don't think there's a > contradiction here. But perhaps using SHOULD and tweaking a few words would > make the sentence more easily digested? Or maybe I'm misunderstanding? I do > get the feeling we've maybe been talking past one another. But I'm going to > stop speculating and just propose this updated language for that sentence > to see if we can move forward: > > "Although [OIDC > <https://www.ietf.org/archive/id/draft-bertocci-oauth-step-up-authn-challenge-01.html#OIDC> > ] leaves the authorization server free to decide how to handle the > inclusion of acr in ID Token when requested via acr_values, when it comes > to access tokens in this specification, the authorization server SHOULD > consider the requested acr value as necessary for successfully fulfilling > the request." > > Does that text work better for you and/or allay the concern? > Yes, this does address my comment, and it feels clearer to me at least 😃 Feel free to submit a new version with the updated text, and I will then start working on the document shepherd write-up. Regards, Rifaat > > > > *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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
