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

[Daniel Fett <[e-mail]>]

Am 13.04.23 um 08:11 schrieb Vittorio Bertocci:
> 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.
>
> On the quotes: Brian has more experience in RFC authoring than I do, 
> but it's night on his part of the world hence I cannot consult him :) 
> However in the only other spec I authored (rfc9068) I did use quotes 
> for every claim occurrence in the text, hence I am confident we can do 
> the same here. Thanks for the catch!

Since the same comment was raised also for DPoP, my two cents on this:

We discussed this very topic when finalizing RFC9207. Back then, we 
noticed that when using the correct markup in the XML (<tt>), the HTML 
renders fine (gray background, monospaced font) but depending on how the 
textual format is created, there may or may not be quotes around the 
parameter. Adding quotes manually in the XML source does not make too 
much sense as they'll needlessly show up in the HTML as well. IIRC there 
was some version of xml2rfc that added quotes around <tt> parts but that 
was removed again.

So the consensus was that prioritizing proper HTML output makes sense 
and we did not add any quotes (with the blessing of the RFC editor).

-Daniel



>
> On Wed, Apr 12, 2023 at 9:59 PM Murray Kucherawy via Datatracker 
> <[e-mail]> wrote:
>
>
>       This message originated outside your organization.
>
>
>     Murray Kucherawy has entered the following ballot position for
>     draft-ietf-oauth-step-up-authn-challenge-14: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut
>     this
>     introductory paragraph, however.)
>
>
>     Please refer to
>     https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
>     for more information about how to handle DISCUSS and COMMENT
>     positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Thanks to Robert Sparks for the ARTART reviews and Mark Nottingham
>     for the
>     HTTPDIR review.  Please make sure the former was fully addressed
>     before
>     proceeding.
>
>     The SHOULD at the top of Section 4 is bare.  What happens if I
>     don't do that?
>     Or should this really be a MUST?
>
>     Same question for the first SHOULD in Section 5.  Is there ever a
>     legitimate
>     reason not to do what it says?
>
>     I feel that claim names such as "acr" should be quoted.  They look
>     like
>     misspelled words otherwise.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth