Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

[Brian Campbell <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Vittorio, thanks for the quick response.
>
> On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci <
> [e-mail]> 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._