generated: '2026-07-25' method: searched source: | https://auth.cccis.com/.well-known/openid-configuration; https://auth.cccis.com/.well-known/oauth-authorization-server; https://api.cccis.com/v1 (401 challenge); https://www.cccsecureshare.com/Faq; CCC Security Addendum (SA 110425) linked from https://docs.cccis.com/insurers/legal note: | CCC publishes no OpenAPI, so nothing here is derived from a spec. Conformance is asserted only where a live probe or a CCC-published document proves it. "conforms: false" entries are recorded findings, not gaps to be filled later by inference. standards: - id: oauth2 name: OAuth 2.0 (RFC 6749) conforms: true evidence: api.cccis.com/v1 returns an RFC 6750 Bearer challenge; auth.cccis.com serves an OAuth 2.0 authorization server with authorize/token/introspect/revoke. - id: rfc6750-bearer name: OAuth 2.0 Bearer Token Usage (RFC 6750) conforms: true evidence: 'www-authenticate: Bearer realm="null",error="invalid_token" on the production gateway.' - id: oidc-discovery name: OpenID Connect Discovery 1.0 conforms: true evidence: well-known/ccc-intelligent-solutions-openid-configuration.json (HTTP 200, issuer https://auth.cccis.com). - id: rfc8414-as-metadata name: OAuth 2.0 Authorization Server Metadata (RFC 8414) conforms: true evidence: well-known/ccc-intelligent-solutions-oauth-authorization-server.json (HTTP 200). - id: rfc7636-pkce name: PKCE (RFC 7636) conforms: true evidence: code_challenge_methods_supported ["S256"] on both authorization servers; connect.cccis.com issues an authorization-code + PKCE request. - id: rfc7662-introspection name: OAuth 2.0 Token Introspection (RFC 7662) conforms: true evidence: introspection_endpoint published on both authorization servers. - id: rfc7009-revocation name: OAuth 2.0 Token Revocation (RFC 7009) conforms: true evidence: revocation_endpoint published on both authorization servers. - id: rfc8628-device-grant name: OAuth 2.0 Device Authorization Grant (RFC 8628) conforms: true evidence: urn:ietf:params:oauth:grant-type:device_code in grant_types_supported; device_authorization_endpoint published. - id: rfc9449-dpop name: OAuth 2.0 Demonstrating Proof of Possession (RFC 9449) conforms: partial evidence: dpop_signing_alg_values_supported [RS256 RS384 RS512 ES256 ES384 ES512] is advertised by the Okta authorization servers. This is IdP capability, not a CCC API requirement - no CCC resource server is documented as requiring DPoP. - id: cieca-bms name: CIECA Business Message Suite (BMS) conforms: true evidence: CCC Secure Share is described by CCC as "a cloud-based application program interface (API) that allows collision repairer licensees of CCC ONE Estimating to control their sharing of data with registered third-party app developers via a secure channel using the CIECA BMS data standard"; CCC is a CIECA founding member and was named CIECA Electronic Commerce Company of the Year in January 2025. docs: https://www.cccsecureshare.com/Faq - id: cieca-ems name: CIECA Estimate Management Standard (EMS) conforms: true evidence: CCC maintains parallel EMS support; the Security Addendum names "the Collision Industry Electronic Commerce Association Estimate Management System ('EMS') extract" as a contractual data-sharing mechanism. Publicly described as the legacy format Secure Share supersedes. - id: nist-csf-2 name: NIST Cybersecurity Framework v2.0 conforms: true evidence: 'CCC Security Addendum s1(b): safeguards "are defined and maintained in accordance with an industry-standard risk management framework such as the National Institute for Standards and Technology (NIST) Cyber Security Framework v2.0."' - id: nist-800-88 name: NIST SP 800-88 media sanitization conforms: true evidence: 'Security Addendum s1(f) commits to the Clear and Purge sanitization methods defined in NIST 800-88.' - id: soc2-type-ii name: SOC 2 Type II conforms: partial evidence: 'Security Addendum s7 (Audit): "Customer may request CCC''s standard privacy and security questionnaires (SIG), third party reports (SOC2 Type II), and documentation to demonstrate compliance with this Security Addendum." Reports are made available to contracted customers on request; no public attestation letter or certification badge is published.' - id: cvss name: Common Vulnerability Scoring System conforms: true evidence: 'Security Addendum s2(a): "very high", "high", or "medium" vulnerabilities per CVSS, or ratings higher than 4.0, "will be promptly remediated and retested at CCC''s expense."' - id: rfc9457-problem-details conforms: false evidence: Live error bodies use the Apigee fault envelope and the Okta error envelope; no application/problem+json observed. See errors/. - id: rfc9116-security-txt conforms: false evidence: /.well-known/security.txt returns 404 on every CCC host (405 on the Okta-fronted auth host). See well-known/. - id: rfc9727-api-catalog conforms: false evidence: /.well-known/api-catalog returns 404/405 on every CCC host. - id: acord name: ACORD standards conforms: false evidence: CCC's standards identity is CIECA, not ACORD. The only ACORD mention located on cccis.com is a citation of the ACORD Insurance Digital Maturity Study inside a CCC Payments marketing post - no ACORD XML, AL3, NGDS or ACORD-certified claim. - id: openapi conforms: false evidence: No OpenAPI/Swagger document is published on any CCC-controlled host; re-probed 2026-07-25 across api.cccis.com, api.cccsecureshare.com, www.cccsecureshare.com and docs.cccis.com. - id: asyncapi conforms: false evidence: No event catalog, webhook reference or AsyncAPI document is published. - id: graphql conforms: false evidence: No /graphql surface found on any CCC host. - id: fhir-r4 conforms: false evidence: CCC runs first- and third-party casualty medical bill review but publishes no FHIR endpoint, capability statement or claim of FHIR support. - id: mcp name: Model Context Protocol conforms: false evidence: No hosted MCP server; mcp.cccis.com does not resolve, api.cccis.com/mcp 404s.