Resolution : Prior to the "Scopes for requesting clinical data" section add the following section: // SMART's scopes are used to delegate access SMART's scopes allow a client to request the delegation of a specific set of access rights; such rights are always limited by underlying system policies and permissions. For example: If a client uses SMART App Launch to request  user/*.cruds  and is granted these scopes by a user, these scopes convey "full access" relative to the user's underlying permissions. If the underlying user has limited permission, the client will face these same limitations. If a client uses SMART Backend Services to request  system/*.cruds , these scopes convey "full access" relative to a pre-configured client policy. If the pre-configured policy imposes limited permissions, the client will face these same limitations. Neither SMART on FHIR nor the FHIR Core specification provide a way to model the "underlying" permissions at play here; this is a lower-level responsibility in the access control stack. As such, clients can attempt to perform FHIR operations based on the scopes they are granted — but depending on the details of the underlying permission system (e.g., the permissions of the approving user and/or permissions assigned in a client-specific policy) these requests may be rejected, or results may be omitted from responses. For instance, a client may receive: 200 OK  response to a search interaction that appears to be allowed by the granted scopes, but where results have been omitted from the response Bundle 403 Forbidden  response to a write interaction that appears to be allowed by the granted scopes. Background > In the case patient/*.cruds has been granted. Does this allow writing of all resource? As we state in the introduction, "access is also limited based on the privileges of the user in context". So in this example, like all SMART scopes, this is used for delegation: it's a way of delegating permissions that a user might have; if the authorizing user lacks permission to write something, the app won't  gain this permissions. It's a way for the user to say "I authorize the app to write any data I'm authorized to write data, associated with this patient". > Can I grant patient/*.cruds scope and still refuse the writing of some resources as they are not allowed to be written by the user? Absolutely. > Does this require sending a list of scopes detailing exactly what is and is not allowed? The SMART scope language isn't intended to act as a standalone arbiter of authorization policy; it's purely about what permissions the user is delegating to an app — FHIR-I Discussion Christiaan: can't a user's actual permissions be transformed into some computable set of scopes? It might not always be expressible as a SMART on FHIR scope Gino: In general, having a scope doesn't guarantee you'll succeed in an operation (e.g., reads may fail; you don't have unfettered access)