Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]>:
> 
> +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 <[e-mail]> 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=[e-mail]>:
>>> 
>>> 
>>> 
>>> On Fri, Nov 22, 2019 at 11:46 PM Benjamin Kaduk <kaduk@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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth