From 691e772eddad94acdfd2bd84e43097e2f8521a38 Mon Sep 17 00:00:00 2001 From: JohnMoehrke Date: Fri, 7 Aug 2026 12:43:12 -0500 Subject: [PATCH] Add cross-references for section 7.3 guidance --- input/includes/link-list.md | 1 + input/pagecontent/b2b.md | 2 +- input/pagecontent/changelog.md | 1 + input/pagecontent/consumer.md | 2 +- input/pagecontent/discovery.md | 2 +- input/pagecontent/general.md | 2 +- input/pagecontent/registration.md | 2 +- 7 files changed, 7 insertions(+), 5 deletions(-) diff --git a/input/includes/link-list.md b/input/includes/link-list.md index 1bfc729..db053ee 100644 --- 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 index 73e2c7d..513537b 100644 --- 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 index 7121fde..3441ed5 100644 --- a/input/pagecontent/changelog.md +++ b/input/pagecontent/changelog.md @@ -8,6 +8,7 @@ In addition to the tickets below, this version includes changes necessary to mov |---------|----------| |[FHIR-56931](https://jira.hl7.org/browse/FHIR-56931)|Move common requirements to a separate menu bar tab| |[FHIR-57937](https://jira.hl7.org/browse/FHIR-57937)|Clarify that complete redirection URIs are required for registraton| +|[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| ### Version 2.0.0 diff --git a/input/pagecontent/consumer.md b/input/pagecontent/consumer.md index 4856064..c803ddd 100644 --- 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 index 68203f9..5f7d586 100644 --- 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 scopes_supported required - An array of one or more strings containing scopes supported by the Authorization Server. The server MAY grant different subsets of these scopes for different client types or entities. Example for a server that also supports SMART App Launch v1 scopes:
+ An array of one or more strings containing scopes supported by the Authorization Server. The server MAY 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:
["openid", "launch/patient", "system/Patient.read", "system/AllergyIntolerance.read", "system/Procedures.read"] diff --git a/input/pagecontent/general.md b/input/pagecontent/general.md index bcdb1f0..41ef0cf 100644 --- 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 index f238160..e01e462 100644 --- 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].