Right, I was just trying to recount what had happened and say that it was my understanding that the URI registrations were the ones you'd expressed concern with and moved to early registration while the topic of this thread was about parameter names. I guess it doesn't really matter but it seemed like a distinction worth making when I wrote that last week.
On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk <ka...@mit.edu> wrote: > On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > > > The token-exchange draft defines both the "resource" and "audience" > > parameters for use in the context of a > > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to > the > > token endpoint. There is a lot of overlap between "resource" and > "audience" > > and I'm not sure there was necessarily a good reason to have the two but > it > > just kind of unfolded that way (the use of a client ID as an audience is > > one case that's mentioned that isn't a URI). That document is in IESG > > evaluation (which is towards the end of the RFC process) and had a few > > DISCUSS ballot positions raised against it. Resulting from one of those > > DISCUSSes, which was unrelated to "resource"/"audience" but rather > because > > of the OAuth URIs as far as I understand, one of the IESG members steered > > us in the direction of, and facilitated, the early registration requests. > > That was me. The conclusion to go for early registration was not (AFAICT) > out of a desire to get the actual value registered more quickly than it > would have been otherwise (which should be pretty fast, since IANA > generally makes the live registries reflect changes shortly after IESG > approval, not even waiting for AUTH48 or final RFC publication), but just > from it seeming to be the least-effort way to approve and publish the > document while still following the required process. (Basically, the I-D > sent to the IESG was "codepoint squatting", having text in the document > that claims that a specific URI value will be used, but with no guarantee > from IANA that that specific value will end up being the one registered. > I didn't think the IESG should grant its seal of approval to a document > that was jumping the process in that way, and the other options we could > think of would require fairly invasive changes to the text that would > just have to be undone by the RFC Editor.) > > -Ben > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
