On Mon, Dec 19, 2022 at 3:38 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote:
> > > On Mon, Dec 19, 2022 at 4:40 PM Brian Campbell <bcampb...@pingidentity.com> > 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 < >> rifaat.s.i...@gmail.com> wrote: >> >>> >>> On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell < >>> bcampb...@pingidentity.com> wrote: >>> >>>> >>>> On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef < >>>> rifaat.s.i...@gmail.com> 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. > Done and thank you! -- _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
