platform. The PC may communicate with the SP API using a standard, such as the Open Service Broker API specification, and with the Platform using platform specific authentication mechanism ( e.g ., Basic Authentication, OAuth tokens, etc.). [0018] For example, the PC may be periodically synchronized with the SFR for a list of services to be published on the platform and the corresponding constraint information that may be applied to limit service plan visibility and scope. Additionally, the Platform Component may perform various tasks including synchronizing with the SFR periodically to onboard services to a marketplace component, allowing for service discovery and consumption. Platform Component may also scope services based on type, location, cloud platform type, environment and/or other parameters. Other tasks may include encrypting and/or decrypting credentials provided by the service as well as adding firewall rules to enable bi-directional communication from applications to service instances. [0019] Service Framework Registry (SFR) may represent a component that stores information about services that are whitelisted to be consumed by platforms and further stores constraint and policy metadata. The metadata may be used to identify various services, including Scope Services by location, Scope Services by environment, etc. For example, Scope Services by location may include zone, data center, region, etc. The policy metadata may specify locations where services are run as certain service providers that may not have the infrastructure to run in a specific location or may not have the necessary regulatory clearance to run (e.g., General Data Protection Regulation (GDPR), etc.) [0020] According to another example, Scope Service plans may be identified by environment. The constraint metadata may specify locations where services are run as certain services and plans may only be consumed by applications running in less privileged