Proposal: compose Google products with explicit authentication requirements #102

When building a Google app spanning several products, I want to select its capabilities from the catalog and connect each Google identity through one coherent authorization flow. The catalog should make clear which services can share that flow and which have additional requirements.

This is a preliminary discussion before proposing a contribution.

Current source

At 4d3a9866481665aa673f64f15a91d7259673968d:

• curated/google.json groups per-product interfaces under Google, describes one OAuth flow, and records their scopes.
• generate-google-specs.ts imports Executor's presets and Discovery converter to generate the hosted specs.
• Executor also has its own Google bundle and hosted-client scope policy. A service appearing here does not establish that the hosted client can authorize it.

Proposed direction

Could the curated Google record provide a clear, machine-readable composition path for one app using multiple Google products, while preserving the individual product entries?

The useful outcome would be:

• Select services and derive the appropriate consent scope union without duplicating operations.
• Expose additional requirements such as a custom OAuth client, Workspace administration/delegation, or a separate API key.
• Make the relationship between this catalog, Executor's Google presets and the hosted-client policy explicit.
• Keep future contributions to product coverage synchronized with the generator rather than editing generated JSON alone.

The exact schema and whether composition belongs here or entirely in Executor are open maintainer decisions. This is not a claim that the existing record is broken.

Related work

#71 introduced the hosted product specs. #83 repaired paths, hosts and defaults. The open #85 and #86 address accepted per-operation scope alternatives while preserving existing consent. This request is adjacent: composing products and exposing authentication prerequisites, not replacing that work or broadening consent as a side effect of importing a spec.

Companion proposal: UsefulSoftwareCo/executor#2492 covers broader hosted Google OAuth coverage. Extending the catalog alone cannot grant access through its production OAuth client.

Completion criteria

Agree the owning repository and representation for multi-product composition and authentication prerequisites, identify any remaining catalog coverage gaps, and define generator/importer compatibility checks for a later focused PR.

Individual product definitions should remain usable. No code or PR is proposed yet.