Executive Summary

The evidence supports a focused conclusion: OAuth grants, browser extensions, and SaaS integrations should be governed as an access lifecycle, not as separate technical settings. Modern platforms distinguish between different authorization contexts, permission scopes, user consent, administrator consent, application identities, and extension capabilities. Those differences matter because the same application name can represent very different access depending on the permissions granted, the identity acting, the resource reached, and the way access is reviewed or removed. [1] [2] [3]

This report synthesizes current digital-identity guidance, Microsoft consent and permission documentation, current OAuth scope documentation from Okta and Zoom, Google Workspace consent guidance, Chrome extension-permission documentation, and an IETF OAuth security specification. The sources do not establish that any named organization has excessive grants, unsafe extensions, unmanaged integrations, or weak identity controls. CyberTech Intelligence uses them to build an operating model for discovering connected access, classifying it by capability and business purpose, assigning approval authority, constraining unnecessary access, monitoring change and use, revoking stale access, validating the result, and governing exceptions and evidence.

The strategic objective is not to eliminate every third-party application or browser extension. It is to make connected access reviewable. Leaders should be able to answer which applications and extensions are connected, who or what identity they act as, what resources they can reach, which permissions are delegated or app-only, who approved the access, why the business needs it, whether the access is still used, what changed since the last review, and how the connection can be removed without creating an unmanaged workaround.

Research Methodology and Source Selection

This report is a secondary-research synthesis and CyberTech Intelligence operating-model analysis. Sources were selected for authority, direct relevance, current applicability, and the ability to distinguish identity federation, consent, scopes, delegated permissions, application permissions, extension capabilities, and revocation-oriented governance. NIST guidance is treated within its stated Federal digital-identity scope. IETF material is treated as protocol guidance within its specification scope. Vendor documentation is treated as evidence of the named platform's control model and terminology, not as proof of an organization's local configuration.

Quantitative adoption claims were intentionally excluded because the campaign does not need a market percentage to establish the governance problem. A current platform control or protocol requirement can support a specific statement about permission design, consent, or access capability. It cannot prove that a target account uses that control, has a weakness, experienced an incident, or has active buying intent. The research therefore privileges direct technical and administrative evidence over generalized market statistics.

Evidence Universe and Assumptions

The evidence universe includes NIST SP 800-63C-4 on federation and assertions; Microsoft Entra guidance on user consent and the distinction between delegated and application permissions; Okta's current OAuth 2.0 scope catalog; Zoom's granular OAuth scope documentation; Google Workspace OAuth consent and scope guidance; Chrome's manifest permission model; and IETF RFC 9207 for authorization-server issuer identification. [1] [2] [3] [4] [5] [6] [7] [8]

In this report, 'connected access' means a relationship in which an application, integration, extension, or service identity has been granted or configured with access to a protected resource or browser capability. 'SaaS identity risk' does not mean every connection is dangerous. It means access relationships can outlive the business purpose, change scope, become difficult to inventory, or sit outside the ownership model used for employee accounts. Readiness is therefore evaluated through local evidence rather than inferred from the presence of OAuth, an extension, or a third-party app.

Evidence Grading

Table 1. Evidence Grading and Permitted Use

  • Grade A — Final government standards or final government digital-identity guidance with a defined scope. Permitted use: identity federation and assertion requirements, terminology, and control principles within the publication's stated scope.
  • Grade B — IETF standards-track or best-current-practice material. Permitted use: OAuth protocol behavior, security properties, and implementation context within the specification's scope.
  • Grade C — Current primary platform documentation. Permitted use: the named platform's permission, consent, extension, app-management, or revocation behavior. It is not local readiness proof for a target organization.
  • Grade D — CyberTech Intelligence synthesis derived from cited evidence. Permitted use: inventory models, readiness tools, decision-rights structures, metrics, maturity levels, and implementation guidance clearly labeled as CTI analysis.

Research Limitations

No external source can provide a complete denominator for an individual organization's connected applications, extension estate, permission grants, service identities, or business ownership. Platform documentation describes available controls, not whether a company configured them well. OAuth scopes express requested or granted capability within a specific resource model; they do not by themselves prove misuse. Extension permissions describe capabilities available to an extension; they do not establish malicious behavior. This report therefore does not convert permission breadth, an OAuth grant, or an installed extension into a security incident or risk score.

Cross-platform comparison also requires care. Microsoft, Google, Okta, Zoom, Chrome, and other platforms use different permission taxonomies and administration models. A control should be mapped to its actual platform, tenant, resource, identity, and business process rather than normalized into a false universal label.

Key Terminology Distinctions

Table 2. Key Terms

  • OAuth grant — an authorization relationship created when permissions are granted under an OAuth flow or platform consent model. The grant must be interpreted using the platform's permission model and current configuration.
  • Delegated permission — access used by an application on behalf of a signed-in user, bounded by the permissions granted and, in platforms such as Microsoft Entra, by what the user is authorized to access. [3]
  • Application permission — app-only access used without a signed-in user in Microsoft Entra terminology. Such permissions can give the application direct access to the resources covered by the app role and generally require administrator consent. [3]
  • Scope — a named permission request describing an access level or resource operation. Scope naming and granularity are platform-specific. Okta and Zoom both publish explicit scope catalogs that show why scope-level inventory matters. [4] [5]
  • Browser-extension permission — a capability declared by an extension, including API permissions, host permissions, content-script matches, and optional permissions. Permission declaration indicates capability, not maliciousness. [7]
  • Access owner — the accountable business or technical owner who can explain why the connection exists and participate in a keep, narrow, revoke, or exception decision.
  • Reviewable evidence — information sufficient to reconstruct what access exists, why it was approved, what changed, who reviewed it, and how the resulting state was validated.
  • Readiness score — an internal CyberTech Intelligence assessment aid based on eleven evidence domains; not a certification, audit, legal conclusion, product rating, security guarantee, or prediction.

Research Framework

Findings are organized through the CyberTech Intelligence SaaS Identity Access Governance Framework™: Discover, Classify, Approve, Constrain, Monitor, Revoke, Validate, and Govern. The framework is a CTI operating synthesis. It connects recurring source themes to the business decisions required when applications, browser extensions, users, service identities, consent, permissions, tokens, and resource access coexist across multiple SaaS platforms.

Executive Findings

  • NIST's current federation guidance reinforces that federated identity depends on explicit relationships and assertions between separately administered parties. The practical CTI implication is that SaaS access should be governed as a relationship between identities, applications, and relying resources rather than as a static application list. [1]
  • Microsoft Entra separates delegated access from app-only access and explains that delegated permissions let an application act on behalf of a user, while application permissions allow access without a signed-in user. A connected-access inventory should therefore record access context, not only the app name. [3]
  • Microsoft also lets administrators configure when users may consent to applications and recommends limiting user consent to verified publishers and selected lower-impact permissions. This is Microsoft-specific guidance, but it demonstrates that permission approval can be policy-based rather than an unbounded user choice. [2]
  • Okta's current scope catalog includes scopes for profile data, offline access, client administration, workflow invocation, and universal logout. Zoom publishes granular scopes tied to individual API operations. These platform examples show why permission review should be based on actual scopes and resource operations rather than broad labels such as 'connected app.' [4] [5]
  • Google Workspace's consent-screen guidance recommends selecting the minimum scopes required and distinguishes non-sensitive, sensitive, and restricted scopes, with additional verification requirements for higher-access categories. This is a Google platform rule, not a universal risk taxonomy. [6]
  • Chrome extensions declare API permissions, content-script matches, host permissions, and optional permissions. Host permissions can enable interaction with matching sites, while optional permissions can be granted at runtime. These capabilities make browser extensions relevant to access governance, but the permission list alone does not prove harmful behavior. [7]

Inventory Before Policy

A connected-access program starts with local evidence. A policy that says 'approved apps only' is not enough if the organization cannot enumerate the apps, extensions, grants, service identities, scopes, owners, and users to which the policy applies. The inventory should connect every material relationship to the business service and identity context it affects.

For an OAuth-connected application, useful fields include application name and identifier, publisher or developer, platform, user or service identity, delegated versus app-only context where applicable, granted scopes or roles, resource boundary, approval source, business owner, affected population, last-known use, credential or token lifecycle, and documented revocation route. For a browser extension, add extension identifier, installation source, declared permissions, host access, managed policy state, user population, business purpose, owner, and review date.

The inventory should also record evidence quality. A catalog populated from one admin portal may miss user-authorized apps in another SaaS service, unmanaged browsers, service-to-service credentials, or extensions installed outside the managed population. 'Unknown' is therefore a valid evidence state. It is more useful than silently treating an incomplete discovery source as complete coverage.

Separate Delegated, Application, Extension, and Service Access

Permission context changes the governance question. Delegated access is tied to a signed-in user's authority; application permission may allow an application to act without a user in the loop; browser extensions can interact with browser APIs and matching sites; and service integrations can use long-lived credentials or platform-specific tokens. Grouping all of these under one 'SaaS app' field hides the access path that determines review depth.

Microsoft's permission model provides a useful concrete distinction: delegated permissions allow access on behalf of a user, while application permissions are app-only and generally require administrator consent. [3] This does not make one category automatically safer. It means reviewers need to know which identity context is in effect, what resource is reachable, and who has authority to approve the relationship.

The same principle applies to scopes. Okta's scope catalog and Zoom's granular scope model show how permissions can represent very different operations. [4] [5] The review question should therefore be 'What can this connection do in this environment?' rather than 'Is this application on an approved list?'

Approval Must Follow Business Purpose and Permission Scope

Approval is not a one-time reputation check. The reviewer needs enough context to compare requested access with the business purpose. An application that requires profile information to perform a narrow workflow should not automatically receive unrelated administrative permissions. A tool that legitimately needs broader access should have the owner, business rationale, affected resource, and exception boundary recorded.

Microsoft Entra gives administrators several user-consent policies and recommends limiting user consent to verified publishers and selected lower-impact permissions. [2] Google Workspace recommends choosing the minimum scopes required and distinguishes sensitive and restricted scope categories for its own platform. [6] These are different vendor models, but both support the operating principle that consent depth should be proportional to the access being requested.

Approval should also include a review trigger. Permission changes, publisher changes, ownership changes, a new integration mode, expansion from user-level to tenant-wide access, or a material business-process change can justify renewed review. Without that trigger, a connection may remain 'approved' even though the basis of the original decision changed.

Usage, Permission Change, and Revocation Must Be Proven

A defensible access state needs more than an approval date. Reviewers should know whether the connection is still used, whether the permissions changed, whether the owner still exists, and whether the underlying business process remains valid. A stale integration can remain technically functional long after its business purpose disappears.

Revocation should be designed before it is needed. The owner should know which platform action removes the grant, which token or session states can remain, which user or service workflows might break, who communicates the change, and how the team will validate the result. The goal is not indiscriminate removal. It is controlled reduction of access that no longer has an evidenced purpose.

IETF RFC 9207 demonstrates the broader security principle that OAuth systems need explicit identity and context at protocol boundaries: it defines issuer identification in authorization responses to address authorization-server mix-up attacks. [8] This report does not generalize that specific protocol control into a universal administrative requirement. It uses the specification to reinforce a narrower point: connected-access decisions are stronger when identity, issuer, permission, and resource context are explicit rather than assumed.

Browser Extensions Belong in Identity Governance

Browser extensions often sit outside the traditional identity-governance inventory, yet they can request access to browser APIs and websites used for business. Chrome documents several permission categories, including permissions, optional permissions, content-script matches, host permissions, and optional host permissions. Host permissions can support actions such as accessing matching hosts, reading sensitive tab properties with the relevant API, injecting content scripts, accessing cookies, or interacting with network requests. [7]

Those capabilities are review inputs, not threat verdicts. A broad permission can be justified by a legitimate function, and a narrow permission does not prove a trustworthy extension. Governance should combine permission evidence with installation source, publisher or developer identity, business need, managed policy state, affected user population, update path, and the organization's own testing or assurance requirements.

The most useful browser-extension question is therefore operational: can the organization identify which extensions are installed in managed populations, what access they request, which users need them, who owns the business justification, what changes trigger re-review, and how the extension is disabled or removed when the need ends?

Readiness Should Scale With Local Evidence

External standards and platform documentation can shape a control model, but they cannot establish local readiness. A Microsoft consent policy does not prove a tenant is configured that way. Google's scope guidance does not prove a particular app requests only minimum access. Chrome's permission declarations do not prove an extension is safe or unsafe. An Okta or Zoom scope catalog does not prove which scopes are granted in a customer environment. [2] [4] [5] [6] [7]

CyberTech Intelligence therefore treats readiness as an evidence state. A team can claim stronger readiness when material SaaS services have current access inventories; permissions are classified by capability and identity context; owners and approval authorities are named; review triggers are defined; permission changes and usage are observable; revocation paths are tested; resulting access states can be validated; and exceptions have explicit expiry or re-review dates.

Where these conditions are weak, the next action is to improve evidence and ownership rather than to infer a breach, exposure, or urgent project from the existence of connected apps.

Board-Level Evidence and Decision Metrics 

  • Inventory coverage: percentage of critical SaaS services with a current view of connected applications, browser extensions, service identities, permissions, owners, and evidence sources.
  • Ownership completeness: percentage of material connected-access relationships with a current business owner and a technical or platform owner.
  • Permission review: percentage of priority connections reviewed against current business purpose, granted access, and identity context within the defined review period.
  • Change visibility: number and age of material permission or scope changes awaiting review; percentage of priority applications with a defined change trigger.
  • Revocation readiness: percentage of priority connections with a documented removal path, named owner, workflow-impact check, and validation method.
  • Exception health: count and age of exceptions without an expiry, compensating control, accountable owner, or next review date.
  • Browser-extension governance: percentage of managed-browser populations with extension inventory, permission evidence, policy state, owner, and review date for priority extensions.
  • Evidence freshness: age and completeness of platform exports, admin decisions, owner confirmations, usage evidence, and validation records used for executive reporting.

Twelve-Month Implementation Roadmap

  • 0–90 days: select critical SaaS services and managed-browser populations; build the connected-access inventory; identify delegated, app-only, service, and extension access; map permissions, scopes, owners, consent routes, and removal paths; establish evidence-quality labels; and identify high-impact or poorly owned relationships for review.
  • 3–6 months: standardize approval and re-review criteria; classify permission impact within each platform; define change triggers; create a review queue for aged or ownerless access; document revocation playbooks; and validate that business workflows can survive removal or narrowing of access.
  • 6–9 months: automate or operationalize recurring inventory refresh, owner attestation, permission-change detection, extension-policy review, and exception expiry; test revocation on representative integrations; measure workflow impact and corrective action; and connect results to executive reporting.
  • 9–12 months: expand proven patterns across additional SaaS services and browser populations; reduce aged exceptions and unknown owners; strengthen service-identity governance; integrate access-review evidence into procurement and offboarding processes; and use measured results to tune review frequency and decision thresholds.

Strategic Takeaway

SaaS identity access is not governed by approving a product once. It is governed by maintaining a current relationship between identity, application, permission, resource, business purpose, owner, and removal path. OAuth, browser extensions, and integrations become manageable when the operating model can discover what is connected, classify what it can do, approve access with accountable authority, constrain unnecessary capability, monitor change and use, revoke access that no longer has a purpose, validate the resulting state, and govern evidence and exceptions.

Governance and Decision Rights

Figure 1. CyberTech Intelligence SaaS Identity Access Decision-Rights Matrix

  • Inventory definition — Accountable owner: SaaS identity / access-governance owner. Required evidence: critical services, applications, extension inventory, identities, permissions, owners, approval source, usage evidence, and gaps. Exit criterion: inventory is current enough to support approval and revocation decisions.
  • Approval policy — Accountable owner: security/identity governance with business service owner. Required evidence: business purpose, requested permissions, identity context, resource boundary, publisher or developer evidence, affected population, exception need. Exit criterion: approve, narrow, reject, or route for higher authority with rationale recorded.
  • Permission-change review — Accountable owner: platform or application owner. Required evidence: changed scopes, roles, host permissions, release or publisher change, user population, business impact. Exit criterion: changed access is explicitly accepted, narrowed, or removed.
  • Revocation — Accountable owner: application or service owner with platform administrator. Required evidence: removal method, affected workflows, token/session considerations, communication owner, rollback or alternate process, validation plan. Exit criterion: access removed or narrowed and resulting state verified.
  • Exception and residual access — Accountable owner: business/risk owner. Required evidence: reason, current facts, compensating action, expiry, next review trigger, affected resource and identity. Exit criterion: exception remains time-bound and reviewable or is closed.

CyberTech Intelligence SaaS Identity Access Governance Framework™

Figure 2. Eight-Layer Research Framework

01 — Discover: Build and maintain an inventory of OAuth-connected applications, SaaS integrations, browser extensions, service identities, users, permissions, resources, owners, approval sources, and evidence gaps.

02 — Classify: Classify access by delegated, application, service, or extension context; business purpose; permission capability; resource sensitivity; user reach; and uncertainty.

03 — Approve: Route access through the appropriate user, administrator, business, security, or platform decision authority with source-linked evidence and recorded rationale.

04 — Constrain: Reduce unnecessary scopes, roles, host access, populations, persistence, and exception breadth where platform capability and business need allow.

05 — Monitor: Refresh inventory, detect material permission or ownership changes, observe continued use where evidence exists, and track aged grants and exceptions.

06 — Revoke: Remove or narrow access that is no longer justified using documented platform procedures, workflow-impact checks, and accountable change ownership.

07 — Validate: Re-check the resulting permission or connection state, test required business workflows, confirm owner acceptance, and update evidence.

08 — Govern: Maintain decision rights, evidence standards, review cadence, exception expiry, metrics, source boundaries, and executive accountability.

SaaS Identity Access Readiness Score™

Rate each domain from 0 to 4: 0 = absent; 1 = informal; 2 = documented; 3 = implemented and tested; 4 = measured and continuously improved. Maximum score: 44. Readiness percentage = total score divided by 44, multiplied by 100. Suggested interpretation: Basic 0–24%; Developing 25–49%; Defined 50–69%; Managed 70–84%; Adaptive 85–100%. This is an internal CyberTech Intelligence assessment aid, not a certification, external rating, audit, legal conclusion, security guarantee, or forecast.

  • Connected Application Inventory & Visibility — Can the team identify material OAuth apps and SaaS integrations for critical services? Ready-state evidence: current inventory with app identifiers, platform, identities, permissions, owners, approval source, and review date.
  • Browser Extension Inventory & Policy — Can managed-browser populations identify installed or allowed priority extensions and their relevant permissions? Ready-state evidence: extension inventory, IDs, permission/host access, policy state, owner, business purpose, and review date.
  • Delegated vs. Application Access Classification — Can the team distinguish user-delegated access from app-only or service access where the platform supports those models? Ready-state evidence: identity context, permission type, resource boundary, user reach, and owner.
  • Consent & Approval Governance — Are user consent, administrator consent, business approval, and exception routes defined for material access? Ready-state evidence: policy, reviewer roles, permission criteria, decision record, and escalation route.
  • Permission & Scope Minimization — Are material permissions compared with current business purpose and reduced when unnecessary? Ready-state evidence: scope review, impact classification, approved minimum access, exceptions, and rationale.
  • Ownership & Business-Purpose Evidence — Does every priority connection have a current accountable owner and evidenced purpose? Ready-state evidence: owner confirmation, process dependency, affected users or service, and next review trigger.
  • Usage & Change Monitoring — Can the team identify material changes in permissions, ownership, publisher, or usage evidence? Ready-state evidence: refresh cadence, change alerts or comparison records, review queue, and corrective action.
  • Revocation & Offboarding Readiness — Can unnecessary access be removed without relying on undocumented manual knowledge? Ready-state evidence: documented removal procedure, affected workflows, owner, validation, and offboarding linkage.
  • Service Identity & Token Lifecycle — Are non-user identities, credentials, refresh tokens, and persistent access paths governed within platform-supported visibility? Ready-state evidence: identity inventory, credential/token owner, rotation or expiry policy, removal method, and audit record.
  • Governance, Decision Rights & Exceptions — Are approval, change, revocation, residual-access, and completion decisions assigned to named owners with evidence thresholds? Ready-state evidence: decision matrix, exception record, expiry, risk owner, and review cadence.
  • Validation & Continuous Improvement — Are post-change states re-verified and lessons used to improve access policies? Ready-state evidence: re-check of grants/permissions, workflow tests, metrics, incidents or issues, corrective action, and updated framework.

SaaS Identity Access Maturity Model

  • Reactive — Connected access is reviewed case by case; inventories, permission evidence, owners, extension policy, and revocation procedures vary by service. Leadership priority: map critical services and access relationships, assign owners, and establish the first review queue.
  • Defined — Priority applications, extensions, permission contexts, approval rules, owners, re-review triggers, and revocation paths are documented. Leadership priority: standardize inventory, decisions, evidence, and exception expiry.
  • Controlled — Consequential access is gated; inventory refresh, scope change, owner confirmation, revocation, exceptions, and validation are measured and reviewed. Leadership priority: reduce aged grants, ownerless access, broad exceptions, and stale evidence.
  • Adaptive — Review depth, permission constraints, approval routes, and monitoring change based on measured evidence, platform changes, and business need. Leadership priority: improve the operating model only where local data shows better control without unnecessary workflow friction.

Benchmark SaaS Identity Access Readiness

Score the eleven readiness domains against current evidence, not planned controls. Use the lowest-scoring domains to set the next executive review agenda. Repeat the assessment after a material permission-model change, a major SaaS rollout, an extension-policy change, a significant acquisition or divestiture, a revocation exercise, or an access-related incident so the score reflects demonstrated capability rather than documentation alone.

About CyberTech Intelligence

CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and claim-safe GTM planning.

Research and Citation Governance

External sources are used only within their stated scope. Government identity guidance, IETF specifications, and platform documentation are separate evidence types. CyberTech Intelligence frameworks and readiness tools are editorial operating models. No source is used to infer that a named organization has excessive OAuth grants, unsafe browser extensions, unmanaged integrations, weak consent controls, an active buying project, budget, incident, or specific security or commercial outcome without direct evidence. CTI tools are not certifications, audits, legal conclusions, product ratings, or security guarantees.

References

  1. National Institute of Standards and Technology, "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions," July 2025. https://csrc.nist.gov/pubs/sp/800/63/C/4/final (Accessed October 5, 2026. Relevance: final NIST federation and assertion guidance; used within its stated digital-identity scope to support relationship, federation, and evidence context.)
  2. Microsoft Learn, "Configure how users consent to applications," current Microsoft Entra documentation. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent  (Accessed October 5, 2026. Relevance: current controls for when and how users can consent to applications, including verified-publisher and permission-grant policy options; used only for Microsoft Entra consent-policy context.)
  3. Microsoft Learn, "Overview of permissions and consent in the Microsoft identity platform," last updated March 18, 2025. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-scopes  (Accessed October 5, 2026. Relevance: authoritative Microsoft distinction between delegated and application permissions and consent; used to classify access context.)
  4. Okta Developer, "OAuth 2.0 Scopes," updated September 18, 2026. https://developer.okta.com/docs/api/oauth2  (Accessed October 5, 2026. Relevance: current Okta scope catalog showing user-data, offline-access, administrative, workflow, and logout-related scopes; used only as an Okta permission-model example.)
  5. Zoom Developer Docs, "Granular scopes," current documentation. https://developers.zoom.us/docs/integrations/oauth-scopes-granular/ (Accessed October 5, 2026. Relevance: current Zoom mapping of API operations to granular OAuth scopes; used as a scoped example of fine-grained permission design.)
  6. Google for Developers, "Configure the OAuth consent screen and choose scopes," current Google Workspace guidance. https://developers.google.com/workspace/guides/configure-oauth-consent  (Accessed October 5, 2026. Relevance: Google guidance on selecting minimum required scopes and its non-sensitive, sensitive, and restricted scope categories; used only within Google Workspace scope and verification rules.)
  7. Chrome for Developers, "Declare permissions," current Manifest V3 documentation. https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions  (Accessed October 5, 2026. Relevance: Chrome extension permissions, optional permissions, content-script matches, host permissions, and related capabilities; used as browser-extension access evidence, not proof of malicious behavior.)
  8. Internet Engineering Task Force, "RFC 9207: OAuth 2.0 Authorization Server Issuer Identification," March 2022. https://www.rfc-editor.org/rfc/rfc9207.html (Accessed October 5, 2026. Relevance: standards-track issuer identification for OAuth authorization responses; used to illustrate the importance of explicit authorization-server identity and context within the specification scope.)