The change came from multiple feedback provided from AD and other reviews. MUST 
is required to guarantee forward compatibility with future extensions. This was 
a known issue in 1.0 when some clients added body_hash support and caused 
servers to fail for no reason.

A server that is unaware of a new extension will remain at the same security 
level if ignoring unknown extensions. The server can require new extensions. 
Please demonstrate how this can lead to a less secure implementation.

EH

From: Mike Jones 
<[email protected]<mailto:[email protected]>>
Date: Thu, 16 Feb 2012 11:16:04 -0700
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: [OAUTH-WG] Ignoring unrecognized request parameters

In core -23, the last paragraph of section 
3.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.1> now says:

                The authorization server MUST ignore unrecognized request 
parameters.

In -22, this said:

                The authorization server SHOULD ignore unrecognized request 
parameters.

In a security protocol, it seems unreasonable to require that information be 
ignored.  As I see it, it SHOULD be legal to return an error if unrecognized 
information is received.

Why the change?  And can we please have it changed back to SHOULD in -24?

                                                                Thanks,
                                                                -- Mike

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to