Merge pull request #15 from panva/back-to-scope

Author: panva

draft-ietf-oauth-rfc7523bis.xml

@@ -355,9 +355,6 @@
 		used as the audience of the JWT;
 		this includes that the token endpoint URL of the authorization server
 		MUST NOT be used as an audience value.
-		To simplify implementations,
-		the <spanx style="verb">aud</spanx> claim value MUST
-		be a JSON string, and not a single-valued JSON array.
 		The authorization server MUST reject any JWT that does not
 		contain its issuer identifier as its sole audience value.
 	      </t>
@@ -375,12 +372,10 @@
 	the following requirement is added:
 	<list style="empty">
 	  <t>
-	    Client authentication JWTs MUST be explicitly typed by using the
+	    Client authentication JWTs SHOULD be explicitly typed by using the
 	    <spanx style="verb">typ</spanx> header parameter value
 	    <spanx style="verb">client-authentication+jwt</spanx>
-	    another more specific explicit type value defined by a specification profiling this specification.
-	    Client authentication JWTs not using the explicit type value
-	    MUST be rejected by the authorization server.
+	    or another more specific explicit type value defined by a specification profiling this specification.
 	  </t>
 	</list>
       </t>
@@ -529,6 +524,18 @@
             The authorization server MUST reject any such JWT that does not
             contain its own issuer identifier as the sole audience value.
 	  </t>
+	  <t>
+	    The introduction of strong typing for JWTs (using explicit <spanx style="verb">typ</spanx>
+	    values) serves as a signal to distinguish between tokens produced in accordance with
+	    specifications published prior to these updates and those incorporating them. However,
+	    the primary security protection comes from the tightened audience requirements. Since
+	    strong typing alone does not prevent the attacks described in <xref
+	      target="private_key_jwt.Disclosure" /> and <xref target="Audience.Injection" />, the
+	    use of explicit typing is suggestion for clients enabling them to signal their intention of sending
+	    a JWT conforming to the requirements herein. This approach balances security signaling with practical
+	    deployment considerations, avoiding disruption to client deployments that already
+	    conform to the tightened audience requirements but have not yet adopted explicit typing.
+	  </t>
 	</list>
       </t>
     </section>
@@ -799,6 +806,15 @@
       </t>
 
       <t>
+	-03
+	<list style="symbols">
+	   <t>
+	    Relaxed client requirement to use strong typed JWTs. SHOULD instead of MUST.
+	  </t>
+	  <t>
+	    Do not restrict the "aud" claim's type. Allow it to be a an array with a single member.
+	  </t>
+	</list>
 	-02
 	<list style="symbols">
 	  <t>