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 <michael_b_jo...@hotmail.com>
Sent: Thursday, October 10, 2024 10:54 AM
To: Murray S. Kucherawy <superu...@gmail.com>
Cc: The IESG <i...@ietf.org>; draft-ietf-oauth-resource-metad...@ietf.org;
oauth-cha...@ietf.org; oauth@ietf.org; rifaat.s.i...@gmail.com
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 <superu...@gmail.com<mailto:superu...@gmail.com>>
Sent: Thursday, October 10, 2024 8:22 AM
To: Michael Jones
<michael_b_jo...@hotmail.com<mailto:michael_b_jo...@hotmail.com>>
Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>;
draft-ietf-oauth-resource-metad...@ietf.org<mailto:draft-ietf-oauth-resource-metad...@ietf.org>;
oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>;
oauth@ietf.org<mailto:oauth@ietf.org>;
rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>
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
<michael_b_jo...@hotmail.com<mailto:michael_b_jo...@hotmail.com>> 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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
