Clarify dual use of iss parameter: SMART launch URL vs RFC 9207

input/pages/app-launch.md

@@ -121,7 +121,7 @@ Servers that support purely browser-based apps SHALL enable [Cross-Origin Resour
 
 #### Related reading
 
-Implementers can review the [OAuth Security Topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16) guidance from IETF as a collection of Best Current Practices.
+Implementers can review the [OAuth Security Topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16) guidance from IETF as a collection of Best Current Practices. When supported by the authorization server, clients are encouraged to validate the `iss` parameter in the authorization response as defined in [IETF RFC 9207](https://tools.ietf.org/html/rfc9207) to mitigate authorization server mix-up attacks.
 
 Some resources shared with apps following this IG may be considered [Patient Sensitive](http://hl7.org/fhir/security.html#Patient); implementers should review the Core FHIR Specification's [Security Page](http://hl7.org/fhir/security.html) for additional security and privacy considerations.
 
@@ -254,6 +254,8 @@ The following parameters are included:
 Identifies the EHR's FHIR endpoint, which the app can use to obtain
 additional details about the EHR including its authorization URL.
 
+Note: This `iss` parameter applies to the app launch URL, where it conveys the FHIR server base URL. In OAuth 2.0 authorization responses, an `iss` parameter may also be present as defined by [IETF RFC 9207](https://tools.ietf.org/html/rfc9207), where it represents the authorization server issuer. These uses are distinct and occur at different stages of the SMART App Launch flow.
+
       </td>
     </tr>
     <tr>
@@ -523,6 +525,15 @@ risk of leaks.
       <td><span class="label label-success">required</span></td>
       <td>The exact value received from the client.</td>
     </tr>
+    <tr>
+      <td><code>iss</code></td>
+      <td><span class="label label-info">optional</span></td>
+      <td>
+
+The authorization server issuer identifier as defined by [IETF RFC 9207](https://tools.ietf.org/html/rfc9207). If present, this value identifies the authorization server and SHALL NOT be used to determine the FHIR server base URL (which is established during the app launch sequence).
+
+      </td>
+    </tr>
   </tbody>
 </table>
 
@@ -531,6 +542,14 @@ redirect URL and SHALL ensure that the state value is securely tied to the
 user’s current session (e.g., by relating the state value to a session
 identifier issued by the app).
 
+If an `iss` parameter is present in the authorization response, it SHALL be
+interpreted as the authorization server issuer identifier as defined by
+[IETF RFC 9207](https://tools.ietf.org/html/rfc9207). Clients MAY validate
+this value against the expected authorization server issuer, for example as
+discovered from the SMART `.well-known/smart-configuration`. Clients SHALL NOT
+use this parameter to determine the FHIR server base URL, which is established
+during the app launch sequence.
+
 ###### *For example*
 
 Based on the `client_id`, current EHR user, configured policy, and perhaps

input/pages/references.md

@@ -10,3 +10,4 @@
 * [RFC7521, Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants](https://tools.ietf.org/html/rfc7521)
 * [RFC7523, JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://tools.ietf.org/html/rfc7523)
 * [RFC7591, OAuth 2.0 Dynamic Client Registration Protocol](https://tools.ietf.org/html/rfc7591)
+* [RFC9207, OAuth 2.0 Authorization Server Issuer Identification](https://tools.ietf.org/html/rfc9207)