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
<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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
