generated: '2026-09-14'
method: probed
source: >-
  https://login.aidentified.com/.well-known/oauth-authorization-server (HTTP 200) and
  https://login.aidentified.com/.well-known/openid-configuration (HTTP 200), both fetched
  2026-09-14 and saved verbatim under well-known/.
docs: null
docs_note: >-
  Aidentified publishes NO scopes or permissions reference page. These scopes were read from the
  provider's own live OAuth discovery documents, which is the authoritative machine-readable
  source, but a human integrator has nothing to read.
applies_to:
  resource: https://mcp.aidentified.com/mcp
  authorization_server: https://login.aidentified.com
  flows:
    - authorization_code
  pkce: S256

scopes:
  - name: openid
    description: Request an OpenID Connect ID token carrying the subject identifier.
    source: both
  - name: profile
    description: Basic profile claims for the authenticated Aidentified user.
    source: both
  - name: email
    description: Email address claim for the authenticated Aidentified user.
    source: both
  - name: phone
    description: Phone number claim for the authenticated Aidentified user.
    source: both
  - name: offline_access
    description: Issue a refresh token so an agent can act without re-prompting the user.
    source: both
  - name: full_access
    description: >-
      Full access. Advertised by the OpenID Connect discovery document only; absent from the RFC 8414
      authorization-server metadata. No published document defines what it grants.
    source: openid-configuration

scope_count: 6

findings:
  - >-
    The RFC 9728 protected-resource document for the MCP server declares scopes_supported as an EMPTY
    array, while the authorization server advertises six. An agent reading the resource metadata — the
    document the 401 challenge points it at — learns nothing about what to request.
  - >-
    Every scope except full_access is a standard OIDC identity scope. There is no API-capability scope
    (no read/write, no per-resource scope), so the token model is all-or-nothing with respect to
    Aidentified data.
  - >-
    full_access appears in only one of the two discovery documents and is undefined in prose anywhere.