generated: '2026-09-06' method: derived source: >- wadl/ (37 first-party WADL contracts from https://api.elsevier.com/documentation/) and openapi/ (7 first-party Swagger 2.0 documents from https://dev.elsevier.com/elsdoc/) supporting_sources: - https://www.elsevier.com/security - https://dev.elsevier.com/tecdoc_api_authentication.html - https://dev.elsevier.com/tecdoc_cors.html - https://www.elsevier.com/.well-known/tdmrep.json provider: Elsevier providerId: elsevier description: >- Which cross-cutting and domain standards the Elsevier contracts actually declare, with the evidence pointing at the place in the contract that declares it. Nothing here is taken from a marketing claim. conformance: - id: counter-sushi-cop5 name: COUNTER Code of Practice Release 5 (SUSHI / NISO Z39.93) domain_standard: true conforms: true evidence: >- https://api.elsevier.com/documentation/SUSHICOP5API.wadl — a complete SUSHI R5 endpoint set at base https://api.elsevier.com/sushi/ : /status/, /members/, /reports/, /reports/{platform}, /reports/{database}, /reports/{title}. The contract's own doc text says it delivers "COUNTER compliant usage statistics" per "COUNTER Code of Practice 5 standards." note: >- This is the domain standard for scholarly-publishing usage reporting, and Elsevier implements the actual COUNTER_SUSHI API path shape rather than a bespoke reporting endpoint. A library consortium that already speaks SUSHI can pull Elsevier usage with no bespoke connector — which is the whole point of the standard. - id: counter-sushi-cop5.1 name: COUNTER Code of Practice Release 5.1 domain_standard: true conforms: true evidence: >- https://api.elsevier.com/documentation/SUSHICOP51API.wadl — the same endpoint set at base https://api.elsevier.com/sushi/r51/, versioned as a separate release per "COUNTER Code of Practice 5.1 standards." note: >- Shipping R5 and R5.1 side by side, on distinct bases, is the correct migration shape for this standard and the one place in Elsevier's whole surface where versioning is handled cleanly. - id: orcid name: ORCID identifier domain_standard: true conforms: true evidence: >- openapi/elsevier-scival-swagger.json — GET /author/orcid/{orcid} (operationId getAuthorByORCID), a first-class lookup path keyed on the ORCID iD, added in the 2019-09-12 release notes. - id: doi name: DOI (ISO 26324) as a first-class resource identifier domain_standard: true conforms: true evidence: >- openapi/elsevier-retrieval-swagger.json — /abstract/doi/{doi}, /article/doi/{doi}, /article/entitlement/doi/{doi}, /object/doi/{doi} and its ref variants. DOI is one of five interchangeable identifier schemes across the retrieval surface (DOI, EID, PII, PubMed ID, Scopus ID). - id: crossref-tdm name: Crossref Text and Data Mining client tokens domain_standard: true conforms: true evidence: >- wadl/elsevier-article-retrieval.wadl and wadl/elsevier-object-retrieval.wadl declare the CR-TDM-Client-Token and CR-Clickthrough-Client-Token headers (5 methods each) — the cross-publisher Crossref TDM credential, not an Elsevier-proprietary one. - id: tdmrep name: W3C TDM Reservation Protocol domain_standard: true conforms: true evidence: >- https://www.elsevier.com/.well-known/tdmrep.json (HTTP 200) reserving TDM rights for location "/", plus tdm-reservation and tdm-policy response headers observed on every api.elsevier.com response including a live 401 on 2026-09-06. - id: odrl name: W3C ODRL 2.2 policy expression conforms: true evidence: >- https://www.elsevier.com/tdm/tdmrep-policy.json — an ODRL Offer (@context http://www.w3.org/ns/odrl.jsonld) with permission/constraint/duty terms keyed on stm:eu-dsm-article3. - id: rdf name: RDF/XML representation conforms: true evidence: >- application/rdf+xml is a declared response representation on 26 methods across the article and object retrieval WADLs. - id: atom name: Atom Syndication Format conforms: true evidence: >- application/atom+xml is a declared response representation on 5 methods; the Authentication API documents it as an Accept value. - id: cors name: W3C Cross-Origin Resource Sharing conforms: true evidence: >- https://dev.elsevier.com/tecdoc_cors.html — CORS is documented and keys are provisioned with an allowed origin. Note the default allowed origin is https://dev.elsevier.com, not the caller's own site. - id: oauth2 name: OAuth 2.0 conforms: true evidence: >- https://id.elsevier.com/.well-known/oauth-authorization-server (HTTP 200, probed 2026-09-06) — RFC 8414 authorization-server metadata for issuer https://id.elsevier.com, declaring authorization, token, introspection, revocation, dynamic-registration and device-authorization endpoints, 11 grant types and PKCE S256. The server is reached by Elsevier's own redirect from https://dev.elsevier.com/apikey/manage (302, client_id ELSAPI-PROD). Saved to well-known/elsevier-id-oauth-authorization-server.json. gap: >- Upgraded from partial on 2026-09-06 — the machine-readable metadata does exist, on a host the docs never name. What still does not exist is any binding between that server and the Research Products APIs: none of its 35 scopes governs an api.elsevier.com operation, api.elsevier.com serves no RFC 9728 oauth-protected-resource document (404), and dev.elsevier.com publishes no grant walkthrough. See scopes/elsevier-scopes.yml. weaknesses: - implicit and password grants advertised - 'id_token_signing_alg_values_supported includes "none"' - id: oidc name: OpenID Connect conforms: true evidence: >- https://id.elsevier.com/.well-known/openid-configuration (HTTP 200, probed 2026-09-06) — a complete OpenID Provider configuration: userinfo endpoint, JWKS, 44 claims_supported, 7 response types, back-channel and front-channel logout, pairwise subject identifiers. Saved to well-known/elsevier-id-openid-configuration.json. note: >- Corrects the 2026-09-06 morning finding of `false`, which probed dev.elsevier.com, api.elsevier.com and www.elsevier.com (404/404/403) but not id.elsevier.com. This governs Elsevier account sign-in across ScienceDirect, SciVal, Pure, Mendeley and the developer portal — not API authorization. - id: rfc9457 name: 'RFC 9457 Problem Details for HTTP APIs' conforms: false evidence: >- Errors use two proprietary envelopes (service-error, error-response) served as application/json, never application/problem+json. Observed live 2026-09-06. - id: rfc8594 name: 'RFC 8594 Sunset HTTP header' conforms: false evidence: >- No Sunset or Deprecation header on any observed response; no deprecation marker on any of the 153 operations in the harvested contracts. - id: rfc9238-ratelimit-headers name: IETF RateLimit header fields conforms: false evidence: >- Elsevier uses the legacy X-RateLimit-Limit / -Remaining / -Reset triple and emits no RateLimit-Policy and no Retry-After. Documented at https://dev.elsevier.com/api_key_settings.html. - id: opensearch-pagination name: OpenSearch-style result paging conforms: true evidence: >- Search responses carry opensearch:totalResults / startIndex / itemsPerPage and typed link relations, documented across the search WADLs and the per-product search-tips pages. - id: iso-27001 name: 'ISO/IEC 27001' conforms: claimed evidence: >- https://www.elsevier.com/security — "We maintain compliance with leading security frameworks and hold certifications such as ISO 27001." note: >- A corporate claim on a marketing page, not a certificate, scope statement or audit report. No trust portal serves the artefact — https://trust.elsevier.com returns 403. - id: gdpr name: EU General Data Protection Regulation conforms: claimed evidence: >- https://www.elsevier.com/security and https://www.elsevier.com/legal/privacy-policy — GDPR and CCPA are named as the governing privacy regimes. - id: soc2 name: 'SOC 2' conforms: false evidence: No SOC 2 report, bridge letter or trust-portal listing is published publicly. summary: entries: 19 conforms_true: 13 domain_standards_declared: 6 primary_domain_standard: COUNTER Code of Practice 5 / 5.1 (SUSHI)