ContextResolvers: Provider/Auth-scoped Context Namespaces + Deterministic Views without wildcards

[ntt-matthias-fleschuetz]

Problem Statement

ContextResolvers write capability results into a single, capability-defined Request.Context target path. This makes it impossible (or unsafe) to use the same capability multiple times for different Identity Providers and/or different AuthSession contexts (e.g., Entra + AD, or multiple Entra sessions), because results collide/overwrite each other.

As a result:

• Workflows cannot safely combine multiple identity systems for the same capability (e.g., IdLE.Entitlement.List from Entra and from AD).
• Conditions, Preconditions, and Template Substitution cannot reliably reference “the right” context source when multiple providers/sessions are used.

Proposed Solution

This issue implements a breaking but consistent design with the following guardrails:

1. No wildcard paths in Get-IdleValuePath / condition path resolution (e.g. no Providers.*.*).
2. A provider/auth-scoped namespace becomes the source of truth for all ContextResolver outputs.
3. “Wildcard-equivalent” use cases are supported via deterministic, engine-defined Views, not by wildcard path semantics.
4. A step-relative view is supported for execution-time evaluation (Current), derived from the step/resolver Provider/Auth settings.
5. No additional action is required for Entitlements pattern matching beyond the ongoing PR/Issue introducing pattern-based condition operators (see Additional Context).

1) Provider/Auth-scoped Context Namespace (Source of Truth)

Introduce (or standardize) a provider/auth-scoped structure under Request.Context:

• Source of truth path format:
  • Request.Context.Providers.<ProviderAlias>.<AuthSessionKey>.<CapabilityRoot>.<...>

Where:

• <ProviderAlias> is the provider name used in IdLE (e.g., Entra, AD) and must be a valid path segment.
• <AuthSessionKey> is:
  • Default when no With.AuthSessionName is specified
  • otherwise the exact With.AuthSessionName

Examples:

• Request.Context.Providers.Entra.Default.Identity.Profile
• Request.Context.Providers.Entra.CorpAdmin.Identity.Entitlements
• Request.Context.Providers.AD.Default.Identity.Entitlements

Implementation rule: ContextResolvers MUST write their results into the scoped namespace above (in addition to any engine-defined Views, see below).

2) Deterministic Views (Wildcard-equivalent Without Wildcards)

Add engine-defined “Views” for common “wildcard” use cases.

• Global view (all providers, all auth sessions):

  • Request.Context.Views.<CapabilityRoot>.<...>

• Provider view (one provider, all auth sessions):

  • Request.Context.Views.Providers.<ProviderAlias>.<CapabilityRoot>.<...>

Examples (Entitlements):

• Request.Context.Views.Identity.Entitlements (all providers, all auth)
• Request.Context.Views.Providers.Entra.Identity.Entitlements (Entra only, all auth)

View semantics are capability-specific and must be explicitly defined and tested.
No view implies no merge.

Entitlements View Semantics (required)

For IdLE.Entitlement.List results:

• Source of truth:
  • Request.Context.Providers.<ProviderAlias>.<AuthSessionKey>.Identity.Entitlements
• Views:
  • Request.Context.Views.Identity.Entitlements = merge/flatten of all scoped entitlement lists
  • Request.Context.Views.Providers.<ProviderAlias>.Identity.Entitlements = merge/flatten of all scoped entitlement lists for that provider

Additionally, each entitlement entry MUST include source metadata:

• SourceProvider (string)
• SourceAuthSessionName (string, Default if not specified)

This enables:

• “don’t care where membership comes from” (use global view)
• “provider-specific checks” (use provider view or source-of-truth path)
• auditing/debugging (source metadata always present in merged lists)

3) Step-relative Context Alias (Execution-time)

Introduce a step-relative alias path:

• Request.Context.Current.<CapabilityRoot>.<...>

Resolution rule:

• Current is resolved using the Provider/Auth context of the executing unit:
  • For step execution / preconditions: from Step.With.Provider + Step.With.AuthSessionName (or Default)
  • For ContextResolvers: from the resolver’s Provider/Auth settings

Scope restriction:

• Request.Context.Current.* MUST NOT be used in plan-time conditions (where there is no single execution context).
• It MAY be used in preconditions and other execution-time evaluations.

4) Reference Behavior (Conditions, Preconditions, Template Substitution)

• Provider/Auth may be referenced:
  • explicitly via source-of-truth paths (Request.Context.Providers...)
  • implicitly via deterministic Views (Request.Context.Views...)
  • relatively via Request.Context.Current... (execution-time only)

No wildcard support is added to path resolution.

5) Consistency + Validation

Add strict, consistent validation rules:

• Provider alias and AuthSession key MUST be valid path segments (fail-fast during plan build).
• ContextResolver output writing must be idempotent and deterministic.
• View building must be deterministic:
  • stable ordering for merged lists (documented and tested)
  • source metadata must be present for each entry

6) Breaking Change Notes

This change is breaking because:

• Existing workflows that rely on single-target capability context paths may observe different structures and/or need to update references.
• When multiple providers/sessions are in use, referencing unscoped paths is no longer sufficient; workflows must use scoped paths or views.

No deprecation phase is required; implement the new model consistently.

Implementation Plan (No Open Questions)

Core changes (IdLE.Core):

1. Extend context-path computation utilities so a ContextResolver can compute:
   • scoped target root: Request.Context.Providers.<Provider>.<Auth>...
   • view roots (global/provider) where applicable for the capability
2. Update ContextResolver execution so that:
   • results are written to scoped targets
   • views are (re)built deterministically after resolver execution for supported capabilities
3. Add Current alias support in execution-time evaluators (preconditions and step execution context), without changing plan-time condition evaluation semantics.

Step packs / providers:

• No provider-specific behavior changes required beyond ensuring resolver outputs are written to the new scoped paths.
• Where entitlement objects are created, ensure SourceProvider and SourceAuthSessionName are set (engine may also enrich during merge if necessary).

Validation & tests (Pester):

• Unit tests covering:
  • two providers writing the same capability without collision
  • multiple auth sessions for same provider without collision
  • global view merge + provider view merge semantics for entitlements
  • Current path resolution during execution-time evaluation
  • fail-fast on invalid Provider/Auth path segments

Docs & examples:

• Update docs to explain the new Request.Context.Providers... namespace, Views, and Current.
• Add examples:
  • Entra + AD entitlements resolution
  • provider-specific vs global checks in conditions/preconditions
  • template substitutions using scoped paths and views

Alternatives Considered

1. Wildcard paths (e.g., Providers.*.*) for path resolution
   Rejected due to complexity and ambiguity in:

   • resolvability checks
   • evaluation semantics (single vs list-of-values)
   • documentation and testing burden

2. Single segment <Provider-AuthSession> (string concatenation)
   Rejected because it reduces structure and makes later schema/type validation harder.

3. Require explicit Provider/Auth in all references (no views)
   Rejected because it makes common checks verbose; deterministic views provide a clean, consistent alternative.

Impact

• Does this affect existing workflows?
  • Yes (breaking). Workflows may need to update references to provider-scoped paths and/or views.
• Any backward compatibility concerns?
  • The new model intentionally avoids implicit wildcard behavior. Views provide the “non-explicit” reference option in a deterministic way.

Additional Context

• This issue intentionally does not add further work for Entitlements pattern matching beyond the ongoing PR/Issue that introduces pattern-based condition operators (e.g., for Like / Contains scenarios).
• This change is required to support scenarios like: “Use the same capability (e.g. entitlements list) for Entra and AD in one workflow without collisions.”