Thanks, Murray, for the quick turnaround! On that first SHOULD. The reasons for not prompting the user in that particular example are more about user experience than protocol considerations. Here we avoid the MUST to ensure that those scenarios can be handled without creating bad user experiences, but I am not sure whether giving experience advice here is in scope for the spec- especially considering that this would just be an example among many.
On the second SHOULD. The current language in the draft says: Section 5.5.1.1 of [OIDC] establishes that an authorization server receiving a request containing the acr_values parameter MAY attempt to authenticate the user in a manner that satisfies the requested Authentication Context Class Reference, and include the corresponding value in the acr claim in the resulting ID Token. The same section also establishes that in case the desired authentication level cannot be met, the authorization server SHOULD include in the acr claim a value reflecting the authentication level of the current session (if any). Furthermore, Section 3.1.2.1 [OIDC] states that if a request includes the max_age parameter, the authorization server MUST include the auth_time claim in the issued ID Token. That seems to make it explicit that what we are doing here is quoting from [OIDC]. We are a bit reluctant to compress that into a simple reference to OIDC because we feel it would raise the cyclomatic complexity of the spec, forcing the reader to open a different spec, locate the right section, perhaps build a bit of context by reading the adjacent parts... whereas here we are providing a digest of the salient aspects that apply to the access token centric scenario described here. On Thu, Apr 13, 2023 at 12:25 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > Hi Vittorio, thanks for the quick response. > > On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci < > vittorio.berto...@okta.com> wrote: > >> On the SHOULD on top of S4. There are pretty common situations in which >> failing to get a response from an API is an acceptable outcome, and >> presenting an interactive prompt isn't. A classic example is a background >> update that the client can use to proactively fetch fresh data, that isn't >> critical for the application function and wasn't initiated by the user. As >> such, an interactive prompt could disrupt the user experience by requiring >> an action without clear context and not in pursuit of a goal the user >> expressed. A MUST would force a complying client to act on the challenge, >> making those scenarios hard to handle. >> >> On the SHOULD on top of S5. There we are just describing what the OIDC >> specification mandates for ID tokens, hence not providing any new normative >> guidance.We echo what OIDC mandates for ID tokens there because we want to >> apply the same logic for access tokens, as we later describe in the same >> section. In that description we don't introduce a more restrictive MUST >> because that would make it hard for the (many) existing authorization >> server+OIDC implementations to comply, limiting adoption and for a >> relatively small return. >> > > I think it would be good to say something like what you just said for the > first one, and maybe make it clear that you're relaying normative guidance > from OIDC and not making a new assertion. Or you could just say > implementers need to meet the constraints around ID tokens specified by > OIDC. > > -MSK > -- _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
