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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
