HL7 · JohnMoehrke · Aug 7, 2026 · Aug 11, 2026
diff --git a/input/includes/link-list.md b/input/includes/link-list.md
@@ -27,6 +27,7 @@
 [Section 7.1.3]: general.html#jwt-headers
 [Section 7.1.4]: general.html#jwt-claims
 [Section 7.2]: general.html#authorization-code-flow
+[Section 7.3]: general.html#scope-negotiation
 [Section 7.4]: general.html#certifications-for-client-applications
 [Section 7.5]: general.html#using-this-guide-with-the-smart-app-launch-framework
 [CapabilityStatement]: StructureDefinition-udap-security-capabilitystatement.html

diff --git a/input/pagecontent/b2b.md b/input/pagecontent/b2b.md
@@ -28,7 +28,7 @@ Client applications registered to use the authorization code grant **SHALL** req
 
 Servers **SHALL** handle and respond to authorization code requests as per [Section 4.1.2](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2) of RFC 6749.
 
-Client applications and Authorization Servers using the authorization code flow **SHALL** conform to the additional constraints for authorization code flow found in [Section 7.2] of this guide.
+Client applications and Authorization Servers using the authorization code flow **SHALL** conform to the additional constraints for authorization code flow found in [Section 7.2] of this guide. The related requirements for the state parameter and PKCE handling are described in [Section 7.2.1] and [Section 7.2.2], and the related scope negotiation rules are described in [Section 7.3].
 
 ### Obtaining an access token
 

diff --git a/input/pagecontent/changelog.md b/input/pagecontent/changelog.md
@@ -9,6 +9,7 @@ In addition to the tickets below, this version includes changes necessary to mov
 |[FHIR-52960](https://jira.hl7.org/browse/FHIR-52960)|Specify requirements regarding GET and POST support for authorization requests|
 |[FHIR-56931](https://jira.hl7.org/browse/FHIR-56931)|Move common requirements to a separate menu bar tab|
 |[FHIR-56881](https://jira.hl7.org/browse/FHIR-56881)|Clarify the rationale to have hl7-b2b and the requirements to the server when receiving it|
+|[FHIR-57236](https://jira.hl7.org/browse/FHIR-57236)|Add references to Section 7.2 and Section 7.3 sub-sections from related workflow guidance|
 |[FHIR-57840](https://jira.hl7.org/browse/FHIR-57840)|Clarify that a person may be assigned more than one (iss,sub) pair|
 |[FHIR-57844](https://jira.hl7.org/browse/FHIR-57844)|Clarify that registration modifications are validated in same manner as new requests|
 |[FHIR-57937](https://jira.hl7.org/browse/FHIR-57937)|Clarify that complete redirection URIs are required for registraton|

diff --git a/input/pagecontent/consumer.md b/input/pagecontent/consumer.md
@@ -14,7 +14,7 @@ Client applications **SHALL** request an authorization code as per [Section 4.1.
 
 Servers **SHALL** handle and respond to authorization code requests as per [Section 4.1.2](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2) of RFC 6749. 
 
-Client applications and Authorization Servers **SHALL** conform to the additional constraints for authorization code flow found in [Section 7.2] of this guide.
+Client applications and Authorization Servers **SHALL** conform to the additional constraints for authorization code flow found in [Section 7.2] of this guide. The related requirements for the state parameter and PKCE handling are described in [Section 7.2.1] and [Section 7.2.2], and the related scope negotiation rules are described in [Section 7.3].
 
 ### Obtaining an access token
 

diff --git a/input/pagecontent/discovery.md b/input/pagecontent/discovery.md
@@ -92,7 +92,7 @@ The metadata returned from the UDAP metadata endpoint defined above **SHALL** re
       <td><code>scopes_supported</code></td>
       <td><span class="label label-success">required</span></td>
       <td>
-        An array of one or more strings containing scopes supported by the Authorization Server. The server <strong>MAY</strong> grant different subsets of these scopes for different client types or entities. Example for a server that also supports SMART App Launch v1 scopes:<br>
+        An array of one or more strings containing scopes supported by the Authorization Server. The server <strong>MAY</strong> grant different subsets of these scopes for different client types or entities. Scope negotiation requirements and related constraints are described in [Section 7.3]. Example for a server that also supports SMART App Launch v1 scopes:<br>
         <code>["openid", "launch/patient", "system/Patient.read", "system/AllergyIntolerance.read", "system/Procedures.read"]</code>
       </td>
     </tr>

diff --git a/input/pagecontent/general.md b/input/pagecontent/general.md
@@ -166,7 +166,7 @@ The Authorization Server **SHALL** return an error in response to a token reques
 
 A wildcard scope is a scope that can be alternatively represented as a set of non-wildcard scopes. An example of a wildcard scope is the SMART App Launch v1.0.0 scope `patient/Observation.*` which can expanded to the set of two non-wildcard scopes: `patient/Observation.read` and `patient/Observation.write`. Granting the wildcard scope to a client application is equivalent to granting the corresponding expanded set of non-wildcard scopes.
 
-The constraints enumerated below apply for scope negotiation between client applications and servers. Unless otherwise specified, these constraints apply for both registration requests and access token requests made by client applications, and the corresponding responses returned by servers.
+The constraints enumerated below apply for scope negotiation between client applications and servers. Unless otherwise specified, these constraints apply for both registration requests and access token requests made by client applications, and the corresponding responses returned by servers. These requirements are referenced by the discovery, registration, consumer, and B2B workflows described elsewhere in this guide.
 
 1. Client applications and servers **MAY** support wildcard scopes.
 1. The `scopes_supported` metadata **SHALL** be present in the .well-known/udap object and **SHALL** list all scopes supported by the server including all supported wildcard scopes.

diff --git a/input/pagecontent/registration.md b/input/pagecontent/registration.md
@@ -14,7 +14,7 @@ The dynamic registration workflow is summarized in the following diagram:
 
 To register dynamically, the client application first constructs a software statement as per [Section 2](https://www.udap.org/udap-dynamic-client-registration-stu1.html#section-2) of UDAP Dynamic Client Registration.
 
-The software statement **SHALL** contain the required header elements specified in [Section 7.1.3] of this guide and the JWT claims listed in the table below.  The software statement **SHALL** be signed by the client application operator using the signature algorithm identified in the `alg` header of the software statement and with the private key that corresponds to the public key listed in the client's X.509 certificate identified in the `x5c` header of the software statement.
+The software statement **SHALL** contain the required header elements specified in [Section 7.1.3] of this guide and the JWT claims listed in the table below.  The software statement **SHALL** be signed by the client application operator using the signature algorithm identified in the `alg` header of the software statement and with the private key that corresponds to the public key listed in the client's X.509 certificate identified in the `x5c` header of the software statement. Scope negotiation requirements for registration and token requests are described in [Section 7.3].
 
 <table class="table">
   <thead>