Sorry, my email client ate the first line of my reply, which was *Thanks Murray for the comments!*
On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci <vitto...@auth0.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. > > 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
