Not persuasive for a few reasons: performance user-level authorization backward compatibility   Smart backend services requires client authentication and uses that as an authorization grant, so there is one step to get an access token and a separate step to use that access token in a request. In CDS, hooks, The client just directly presents an authentication token as part of its API request. SMART Backend services uses system-level authorization, but CDS Hooks service's should have user-level authorization. An example of why this is important – the user seeing the card could definitely be restricted from seeing some information available over the CDS Client's FHIR server, let's say, VIP patient. Without tying the backend CDS service's authorization to the current user's, or requiring the backend CDS client to re-implement the authorization rules of the CDS Client's authorization server, we're virtually guaranteeing that the backend CDS service will show information to the user that the user isn't supposed to have access to. We're trying to minimize the number of backward compatibility breaks in this STU2 to only those that are important and necessary.