Elisa Authentication

generated: '2026-08-27'
method: probed
source: https://elisa.tech/wp-json/ (authentication block) + openapi/elisa-events-calendar-openapi.json
provider: ELISA
providerId: elisa
description: >-
  Authentication profile for the ELISA API surface at https://elisa.tech/wp-json/. Established by
  reading the authentication block the WordPress REST root advertises about itself and by making
  live unauthenticated calls against the published operations.
summary: >-
  Reads are open; writes are WordPress-capability gated behind HTTP Basic with an Application
  Password. The OpenAPI document declares no securitySchemes at all, so the auth model is carried
  entirely by the platform rather than by the contract — a real gap for any agent that plans from
  the spec alone.
spec_declares_security_schemes: false
schemes:
  - id: anonymous
    type: none
    applies_to: all GET operations
    verified: probed
    evidence: >-
      GET https://elisa.tech/wp-json/tribe/events/v1/events?per_page=1 returned 200 with a real
      ELISA event payload (7,701 bytes) on an unauthenticated request, 2026-08-27.
  - id: application-passwords
    type: http
    scheme: basic
    applies_to: all POST and DELETE operations
    verified: probed
    authorization_endpoint: https://elisa.tech/wp-admin/authorize-application.php
    evidence: >-
      The /wp-json/ root document advertises
      authentication.application-passwords.endpoints.authorization =
      https://elisa.tech/wp-admin/authorize-application.php, and it is the only scheme it names.
    detail: >-
      A WordPress Application Password is a per-user, per-application credential presented over
      HTTP Basic (username plus the generated password). It is not scoped — it inherits the full
      capability set of the WordPress user it belongs to. There is no OAuth, no OIDC, no API-key
      header, and no mTLS on this surface.
    obtain: >-
      A site administrator generates one from the user profile screen in wp-admin, or the
      application initiates the authorize-application.php flow. ELISA does not publish a
      self-service developer signup for API credentials; write access implies a WordPress account
      on elisa.tech.
authorization_model:
  style: wordpress-capabilities
  scopes: none
  note: >-
    Permission is decided by WordPress capabilities (edit_posts, delete_posts and the Events
    Calendar equivalents), not by scopes. This is why scopes/ is deliberately absent for this
    provider rather than empty — there is no scope surface to document.
observed_denials:
  - operation: GET /wp-json/wp-abilities/v1/abilities
    status: 401
    body: '{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}'
    note: >-
      The WordPress Abilities API namespace (wp-abilities/v1) is registered on this site — it is an
      agent-facing capability registry — but its abilities listing is authenticated. The namespace
      index at /wp-json/wp-abilities/v1 is readable anonymously; the abilities themselves are not.
gaps:
  - The OpenAPI declares no securitySchemes and applies no security to any operation, so a client generated from the spec has no way to know that POST and DELETE need credentials.
  - No published developer-credential path — obtaining write access requires an ELISA WordPress account, which is not a self-service developer program.
cross_references:
  conventions: conventions/elisa-conventions.yml
  well_known: well-known/elisa-well-known.yml