On Thu, Apr 13, 2023 at 2:57 AM Daniel Fett <m...@danielfett.de> wrote:
> > Most of the SHOULDs here seem unsupported to me, in the sense that I'm not > clear what interoperability breaks if I decide not to do what it says. Some > prose about that would be helpful to include. > > Looking at the draft again, we have only a few SHOULDs and for all of them > I think it is clear what the consequences are of not doing it. > > For example, the first one reads "To reduce the likelihood of false > negatives, servers SHOULD..." which implies that not following the SHOULD > means risking false negatives. The other instances are concerned with > providing information to clients in DPoP challenges. I think it is > sufficiently clear that not providing this information may make it harder > for the client to respond properly and to debug errors. > The SHOULD in 7.1 is perhaps a better example. Is there an interoperability failure if I elect not to include an error parameter? Or is this more of a UX issue? > > I know this isn't the first OAUTH document I've reviewed, but I still find it > strange that claim names are not quoted or in all-caps or something. In > prose, > they just look like typos to me. > > As I wrote in the thread for Step-Up Authn: > > "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)." > Thanks, I didn't have this background. It's a bit weird that we're willing to settle for this, but so it goes. -MSK
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
