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

["Murray S. Kucherawy" <[e-mail]>]

Hi Mike,

On Wed, Oct 2, 2024 at 11:01 PM Michael Jones <[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