= Service Catalog and Offering

The service catalog will be available publicly (without authentication), so that they can be discovered.
An authenticated user might see more or less services, depending on 1) the user rights and 2) the organization context and 3) the organization origin configuration.

Services will be registered in the portal database to make them available in the catalog.
Each service contains meta information (Description, logo, Links, etc.).

Services are made available through plans (zero, or more). A plan consists of:

* Meta information (Description, pricing, links, etc.)
* Kubernetes GVK (Group/Version/Kind)
* Control Planes offering this plan (named: "Service Provider Zone")
* Service spec per Control Plane
* Access control to the plan (who can see and access this plan? User and organization specific. Public or not.)

All Control Planes expose the service definition of the GVK (Group/Version/Kind) via Kubernetes APIs (Crossplane XRDs).
The Web Portal discovers these APIs and loads the definition from the https://kubernetes.io/docs/concepts/overview/kubernetes-api/#openapi-interface-definition[OpenAPI spec^] into the database (updated regularly).
With this OpenAPI spec, the fields of the service spec are dynamically built.
As the OpenAPI spec doesn't contain nice field names, we might want to be able to edit the service spec for the presentation in the web UI, or we add some heuristics to make them look nice.

If a plan doesn't link to a Control Plane or a service doesn't belong to a plan, the service or plan is "available on request".
This means we show a contact form for a customer to show interest.