+1, I'm only comfortable making recommendations in this BCP if they are in fact, the best current practice. In my mind that means nothing aspirational, only things that are well established and that people can act on today.
---- Aaron Parecki aaronparecki.com On Mon, Nov 25, 2019 at 12:50 PM Daniel Fett <f...@danielfett.de> wrote: > > +1. We should only discuss solutions if we would be okay with people actually > implementing them. (See also my feedback to Guido's review.) > > -Daniel > > Am 25. November 2019 20:41:45 MEZ schrieb Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org>: >> >> >> >> On Fri, Nov 22, 2019 at 11:46 PM Benjamin Kaduk <ka...@mit..edu> wrote: >>> >>> On Wed, Nov 20, 2019 at 03:40:34AM +0000, Mike Jones wrote: >>> > SUBSTANTIVE >>> > >>> [...] >>> > >>> > 4.8.1.1. Metadata - This section suggests the use of a "resource_servers" >>> > metadata value. This isn't defined by RFC 8414 nor do I see it the IANA >>> > OAuth Authorization Server Metadata registry at >>> > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata. >>> > Is this something that's been standardized elsewhere? If so, please >>> > add a citation. If not, please clearly say that this metadata value is >>> > not standardized, and is therefore unlikely to be interoperable. >>> >>> I would go further and say that we should not document "best practices" >>> that involve non-standardized values. >>> >>> > 4.8.1.1. Metadata - This section suggests the use a >>> > "access_token_resource_server" token response value. Please likewise >>> > clearly say that this parameter isn't a standard. >>> >>> (ditto) >> >> >> The document has a number of occurrences similar to these where a particular >> solution is discussed even though it's not been standardized and/or isn't >> actually a recommendation of the document. Such discussions can instructive >> and have valuable information. But I wonder if it might be more appropriate >> to omit them from the BCP? When the document is read and understood in its >> full context, I do think the scope and intent of such discussions are made >> reasonably clear. However, they could be pretty easily misunderstood by >> someone just reading individual subsections or from citing parts of the >> document text without the larger context. I guess I'm thinking/suggesting >> that it'd be better if the BCP only focused on the actionable >> recommendations it is making. And omit background type discussion of >> alternative approaches that didn't get used for whatever reason. Or, if they >> do stay in the document, de-emphasize them even further like maybe moving >> them into an appendix rather than the main body of the doc. >> >> >> 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. > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
