Adding optionality here does not improve interoperability or security. Clients can consistently determine and express their access needs at launch time, and servers are free to use this information in informing downstream access, or (if they choose) to ignore the requested scopes in favor of defaults determined out-of-band. Asking clients to be specific here helps ensure consistent behavior and is a "nudge" to avoid over-broad requests by default (i.e., by defaulting to scopes established at registration-time). — We considered and rejected the following... Update "scope" parameter on the authorization request from "required" to "optional" Change : "Must describe the access that the app needs, including clinical data scopes like  patient/*.read ,  openid  and  fhirUser  (if app needs authenticated patient identity) and either:" To say : "Clients SHOULD include a scope parameter but MAY omit it. When the scope parameter is omitted, servers SHALL infer a default set of scopes, for example based on data supplied by the client at registration time. When present, this parameter describes the access that the app needs on this launch, including clinical data scopes like  patient/*.read ,  openid  and  fhirUser  (if app needs authenticated patient identity) and either:..."