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! On Wed, Apr 12, 2023 at 9:59 PM Murray Kucherawy via Datatracker < nore...@ietf.org> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
