generated: '2026-08-13' method: derived source: >- openapi/_original/pavoot-openapi.json, well-known/pavoot-well-known.yml (probed clerk.pavoot.com discovery documents), and live probes of api.pavoot.com name: Pavoot standards conformance summary: >- What the Pavoot surface does and does not conform to, each with evidence. The strong results all come from the Clerk-hosted identity layer; the application API itself conforms to little beyond OpenAPI 3.1 syntax. standards: - id: openapi name: OpenAPI Specification conforms: true version: 3.1.0 evidence: >- https://api.pavoot.com/openapi.json returns a valid OpenAPI 3.1.0 document — 241 paths, 248 operations, 56 component schemas. Auto-generated by FastAPI. caveats: - No servers[] block, so the document does not name its own host. - info.title is the framework default "FastAPI"; info.version is "0.1.0". - No tags on any of the 248 operations. - No components.securitySchemes and no security requirements anywhere. - Every 200 response has an empty schema, so no response is typed. - id: oidc name: OpenID Connect Discovery 1.0 conforms: true evidence: >- https://clerk.pavoot.com/.well-known/openid-configuration returns 200 with a complete discovery document — issuer, authorization/token/userinfo/revocation/ introspection endpoints, jwks_uri, scopes_supported, claims_supported, id_token_signing_alg_values_supported RS256. - id: oauth2 name: OAuth 2.0 (RFC 6749) conforms: true evidence: >- Authorization-code grant with refresh tokens, advertised at https://clerk.pavoot.com/oauth/authorize and /oauth/token. - id: rfc8414 name: OAuth 2.0 Authorization Server Metadata conforms: true evidence: >- https://clerk.pavoot.com/.well-known/oauth-authorization-server returns 200 with a conformant metadata document. - id: rfc7636 name: PKCE conforms: true evidence: code_challenge_methods_supported = ["S256"] in both discovery documents. - id: rfc7517 name: JSON Web Key Set conforms: true evidence: >- https://clerk.pavoot.com/.well-known/jwks.json returns 200 with an RSA signing key (use=sig, kty=RSA, alg=RS256). - id: rfc7519 name: JSON Web Token conforms: true evidence: >- Clerk session credentials are RS256-signed JWTs verified against the JWKS above. - id: rfc9728 name: OAuth 2.0 Protected Resource Metadata conforms: false evidence: >- https://api.pavoot.com/.well-known/oauth-protected-resource returns 404. The resource server does not advertise its authorization server, so an agent holding no prior knowledge cannot discover that clerk.pavoot.com protects api.pavoot.com. - id: rfc6750 name: OAuth 2.0 Bearer Token Usage conforms: partial evidence: >- Credentials are presented as Authorization: Bearer, but the 401 from https://api.pavoot.com/me carries NO WWW-Authenticate challenge header — the response headers are only date, content-type, content-length and server. RFC 6750 §3 requires the challenge. - id: rfc9457 name: Problem Details for HTTP APIs conforms: false evidence: >- Errors are application/json with a bare `detail` key, never application/problem+json. No type, title, status or instance members. - id: rfc9116 name: security.txt conforms: false evidence: 404 on /.well-known/security.txt across all four hosts probed. - id: rfc8594 name: Sunset HTTP Header conforms: false evidence: No Sunset or Deprecation header; zero deprecated operations in the spec. - id: rfc9110-ratelimit name: RateLimit header fields conforms: false evidence: >- No RateLimit-*, X-RateLimit-* or Retry-After in the spec or in observed responses. - id: idempotency-key name: Idempotency-Key HTTP header (IETF draft) conforms: false evidence: >- No idempotency key header or request-token mechanism in any of the 248 operations. Two handlers describe themselves as naturally idempotent; that is not a contract. - id: rest name: REST resource semantics conforms: partial evidence: >- Predominantly RPC — camelCase verb-noun paths, destructive operations behind POST (/deleteImages, /deleteFolder), and no uniform resource identifiers. A newer minority of paths are resource-shaped (/projects/{project_id}/images/retry-tagging, /shares/{id}/images, /org/permissions/*). - id: pagination name: Consistent pagination conforms: false evidence: >- 16 of 248 operations paginate, in three incompatible styles (page+pageSize, limit+offset, limit-only). No cursor pagination. 232 operations return unbounded sets. - id: json-api name: 'JSON:API' conforms: false evidence: No JSON:API media type, envelope or conventions. - id: asyncapi name: AsyncAPI conforms: false applicable: false evidence: >- Pavoot publishes no event or webhook surface. The three /emit_* operations are internal fan-out calls into the tagging pipeline, not a subscriber-facing event catalog. Nothing was written to asyncapi/ — this dimension is not applicable rather than failed. - id: mcp name: Model Context Protocol conforms: false evidence: https://api.pavoot.com/mcp returns 404. No hosted or packaged MCP server exists. - id: a2a name: A2A Agent Card conforms: false evidence: >- 404 on /.well-known/agent-card.json and /.well-known/agent.json on pavoot.com, api.pavoot.com and clerk.pavoot.com; HTML catch-all 200s on app.pavoot.com were rejected. compliance_certifications: published: false soc2: unknown iso27001: unknown gdpr_posture: >- Pavoot publishes a Data Processing Agreement (https://pavoot.com/client/dpa), a general privacy policy (https://pavoot.com/privacy), a separate attendee-facing privacy notice (https://pavoot.com/privacy-attendees) and a browser-extension privacy policy (https://pavoot.com/extension-privacy). A DPA is a GDPR processor commitment, but it is not a certification. note: >- No trust center, no named certification (SOC 2 / ISO 27001 / PCI / HIPAA / FedRAMP) and no audit report is published anywhere on the site. No Compliance pointer is emitted — a DPA alone is not a published compliance program. probes: - url: https://pavoot.com/trust status: 404 - url: https://pavoot.com/security status: 404 data_residency: region: eu-central-1 evidence: >- api.pavoot.com resolves to an AWS Lambda function URL in eu-central-1 (ec-bfdeb82aabcf4e709cc0dc9f4dcd8d0e.ecs.eu-central-1.on.aws). Relevant to GDPR posture given the biometric face data the platform processes, but Pavoot does not document residency itself. biometric_note: >- The platform enrolls attendee faces into AWS Rekognition collections and makes a face photo mandatory at attendee registration. That places it in scope of biometric-data regimes (GDPR Art. 9 special-category data, and US state biometric privacy statutes such as BIPA). Pavoot publishes an attendee-specific privacy notice but no biometric-specific policy, retention schedule or consent artifact that could be verified anonymously.