[OAUTH-WG] Re: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

[Michael Jones <[e-mail]>]

I’ve applied one change to https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/62 suggested by Amanda Baber of IANA – changing a “they” to “the Designed Experts”.  As it turns out, I was on a call with the IANA people for another reason and was able to review the new text with them in real time.

                                                                -- Mike

From: Michael Jones <[e-mail]>
Sent: Thursday, October 10, 2024 10:54 AM
To: Murray S. Kucherawy <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/62 describes the motivations for the IANA registration procedure, as requested, and closes the loophole.  Let me know if you’d like any changes before we merge and publish.

                                                                Thanks again,
                                                                -- Mike

From: Murray S. Kucherawy <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 10, 2024 8:22 AM
To: Michael Jones <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Murray Kucherawy's Discuss on draft-ietf-oauth-resource-metadata-11: (with DISCUSS and COMMENT)

Hi Mike,

On Wed, Oct 2, 2024 at 11:01 PM Michael Jones <[e-mail]<mailto:[e-mail]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I concur strongly enough with John Scudder's comment about the IANA registry
that I'd like to discuss it.  Moreover, Section 4 of BCP 26 says:

   [...]  Newly minted policies,
   including ones that combine the elements of procedures associated
   with these terms in novel ways, may be used if none of these policies
   are suitable; it will help the review process if an explanation is
   included as to why that is the case.

Is that explanation available anywhere?  I think John's right, this is a
peculiar loophole, and it would be helpful to know why the WG thinks this is
necessary.  There's already a debate in progress about whether an I-D (which
expires) is viable in a Specification Required registry, and we're about to
charter a WG to revise BCP 26, so this is actually quite topical.

Mike> The explanation for the OAuth registration language is that we want to give authors of specifications proposing to register OAuth parameters the benefit of review by designated experts *before* the spec is completely done, so that if problems are found, they can iterate and fix them before making their specifications final.  I've been in many situations, both as the party registering and as the Designated Expert, where this pre-final review was priceless and resulted in improvements in the specification.  I'd be open to different (possibly more standard) language that still achieves this possibility.

Mike> For what it's worth, remember too that this language was written before RFC 8126 was.  If there's a more modern equivalent you can suggest, I'm all for it.

Irrespective of that BCP's timeline, I always prefer to err on the side of explaining too much versus too little when doing something procedurally unusual.  In this case, I think the explanation you gave here is simple and would be beneficial to include, especially since future authors might take it as an example of the minimum you need to get some kind of custom policy through IESG Evaluation.  I would encourage such a sentence or two to be added here.

My main concern with the policy as written is that there's a possible leak: If the DE approves something because she is relatively certain a registration is going to happen, but then for some reason that process is never completed, we're left with a dangling registration.  What might we do for this registry in such a situation?  Should a DE be further empowered to deregister something if this condition were to arise?  It would be nice to plug this hole.

I'll clear my DISCUSS now, since the discussion happened, but I'd encourage consideration of some review of these two points with Deb, and I'm happy to continue the conversation too if necessary.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 [...]

In Section 2.1, second paragraph, the RECOMMENDED and SHOULD seem bare to me.
Why would we allow anything other than what's specified, especially since BCP
47 prescribes a particular behavior?

Mike> This is exactly the same language as used for OAuth Client metadata at https://www.rfc-editor.org/rfc/rfc7591.html#section-2.2.  Since this spec is entering the same OAuth ecosystem, I'm reluctant to make it different in any way.

Mike> I look forward to hearing back from you, particularly about the IANA registration goals and language.

Well, that's unfortunate.  But this part was only a COMMENT.

-MSK