Parts of the text in section 4 capture discussions of potential solutions and reasons why we decided in favor of a certain solution. I think this will be useful in the future and it has already proven useful for me, e.g. in the recent discussions around PoP vs audience restriction.
> Am 25.11.2019 um 21:55 schrieb Aaron Parecki <aa...@parecki.com>: > > +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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
