generated: '2026-09-02' method: searched source: >- Assertions read from the anonymously-served OIDC/UMA discovery documents at auth.solvewithvia.com (saved under well-known/), the VIA ZTF documentation at https://documentation.ztf.solvewithvia.com/, and the published tutorial sources at https://github.com/viascience/ztf-tutorial. Every row cites the exact location the evidence came from. name: VIA (Via Science, Inc.) — standards conformance standards: - id: oauth2 conforms: true evidence: >- RFC 6749 authorization server. authorization/token/introspection/revocation endpoints and ten grant types are declared in https://auth.solvewithvia.com/auth/realms/qt/.well-known/openid-configuration (HTTP 200). source: well-known/via-science-qt-openid-configuration.json - id: oidc conforms: true evidence: >- OpenID Connect Core 1.0 Discovery document served per realm with issuer, jwks_uri, userinfo_endpoint, id_token signing algorithms and the standard openid/profile/email/ address/phone scopes. source: well-known/via-science-qt-openid-configuration.json - id: rfc8414-oauth-authorization-server-metadata conforms: true evidence: >- /auth/realms/ztf_demo/.well-known/oauth-authorization-server returns HTTP 200 with a complete RFC 8414 metadata document. source: well-known/via-science-ztf-demo-oauth-authorization-server.json - id: rfc7636-pkce conforms: true evidence: 'code_challenge_methods_supported: ["plain","S256"]; the live QT login flow issues an S256 challenge.' source: well-known/via-science-qt-openid-configuration.json - id: rfc9449-dpop conforms: true evidence: dpop_signing_alg_values_supported present (PS/RS/ES/EdDSA family). source: well-known/via-science-qt-openid-configuration.json - id: rfc9126-pushed-authorization-requests conforms: true evidence: >- pushed_authorization_request_endpoint published; require_pushed_authorization_requests is false (supported, not mandated). source: well-known/via-science-qt-openid-configuration.json - id: rfc8705-mtls-client-auth-and-bound-tokens conforms: true evidence: >- tls_client_auth listed in token_endpoint_auth_methods_supported and tls_client_certificate_bound_access_tokens is true; mtls_endpoint_aliases published. source: well-known/via-science-qt-openid-configuration.json - id: rfc8628-device-authorization-grant conforms: true evidence: device_authorization_endpoint published; urn:ietf:params:oauth:grant-type:device_code advertised. source: well-known/via-science-qt-openid-configuration.json - id: rfc7662-token-introspection conforms: true evidence: introspection_endpoint published with five client-auth methods. source: well-known/via-science-qt-openid-configuration.json - id: rfc7009-token-revocation conforms: true evidence: revocation_endpoint published. source: well-known/via-science-qt-openid-configuration.json - id: rfc7591-dynamic-client-registration conforms: true evidence: registration_endpoint published at /clients-registrations/openid-connect. source: well-known/via-science-qt-openid-configuration.json - id: rfc8693-token-exchange conforms: true evidence: urn:ietf:params:oauth:grant-type:token-exchange in grant_types_supported. source: well-known/via-science-qt-openid-configuration.json - id: openid-ciba conforms: true evidence: >- backchannel_authentication_endpoint published; backchannel_token_delivery_modes_supported ["poll","ping"]. source: well-known/via-science-qt-openid-configuration.json - id: openid-front-channel-and-back-channel-logout conforms: true evidence: frontchannel_logout_supported and backchannel_logout_supported both true, session-aware. source: well-known/via-science-qt-openid-configuration.json - id: uma2 conforms: true evidence: >- /auth/realms/ztf_demo/.well-known/uma2-configuration returns HTTP 200 with resource_registration_endpoint, permission_endpoint and policy_endpoint, and urn:ietf:params:oauth:grant-type:uma-ticket is an advertised grant. source: well-known/via-science-ztf-demo-uma2-configuration.json - id: jwt conforms: true evidence: >- "A JSON Web Token (JWT) is an industry-standard type of security token" — https://documentation.ztf.solvewithvia.com/definitions/ source: https://documentation.ztf.solvewithvia.com/definitions/ - id: rfc9457-problem-details conforms: false evidence: >- No error contract is published for any VIA product surface; no problem+json media type appears in any document reachable anonymously. - id: fapi conforms: false evidence: >- No FAPI profile claim anywhere on the VIA surface. The building blocks are present (PAR, DPoP, mTLS-bound tokens, private_key_jwt) but the realms still advertise the implicit and password grants, which a FAPI 2.0 profile forbids. - id: pagination conforms: false evidence: No REST resource contract is published, so no pagination convention is observable. - id: idempotency conforms: false evidence: No idempotency header or key is documented on any public VIA surface. domain_standards: - id: w3c-verifiable-credentials conforms: true market: decentralized identity / zero-trust access evidence: >- ZTF is built on Verifiable Credentials and Verifiable Presentations as first-class components — "A tamper-resistant digital credential that represents claims about a subject in a cryptographically secure format", with named Issuer, Verifier, Holder (VIA Wallet) and DID Registry roles, at https://documentation.ztf.solvewithvia.com/via-ztf-components/. The VIA Wallet page states "Decentralized authentication using W3C 2.0 credentials". source: https://documentation.ztf.solvewithvia.com/via-ztf-components/ note: >- VIA names the roles and the credential/presentation model but does not cite a W3C VC Data Model version, JSON-LD context, or DID method in any anonymously readable page — so this is a documented architectural conformance, not a verifiable profile claim. - id: w3c-decentralized-identifiers conforms: true market: decentralized identity evidence: >- "Decentralized Identity (DID) Registry — Self-sovereign identity management", listed as a core ZTF component, described as a server storing ephemeral keys for end-to-end encrypted communication between parties. source: https://documentation.ztf.solvewithvia.com/via-ztf-components/ note: No DID method name or did:*-prefixed identifier is published anonymously. - id: nist-fips-203-ml-kem conforms: true market: post-quantum cryptography evidence: >- The ZTF DID Registry uses "a hybrid Key Encapsulation Mechanism combining ECDH (P-384) and ML-KEM-1024" — ML-KEM is the NIST FIPS 203 post-quantum KEM, and P-384 is NIST FIPS 186 / SP 800-186. This is the most specific cryptographic conformance VIA publishes and it is stated in the contract-bearing documentation, not on a marketing page. source: https://documentation.ztf.solvewithvia.com/via-ztf-components/ - id: walletconnect-v2 conforms: true market: web3 wallet session protocol evidence: >- ZTF step-up authentication is implemented over WalletConnect v2; the published Angular WalletConnectService exposes initialize / connect / sendTransaction / disconnect. source: https://documentation.ztf.solvewithvia.com/integration/ compliance_claims: - claim: >- "rigorously tested by the U.S. Department of Defense"; VIA states ZTF is approved for use by the U.S. Air Force, Navy and Space Force, and describes VIA Secure Chain (VSC) as "the world's first U.S. Department of Defense accredited blockchain". source: https://www.solvewithvia.com/via-ztf/ verified: false note: >- Stated by VIA on its own product pages and in the ztf-tutorial README. No accreditation letter, ATO reference, certificate number or third-party attestation is published, and VIA operates no trust center. Recorded as a provider claim, not as a verified certification. - claim: >- "NIST-compliant, quantum-resistant credentials" for SLAM AI. source: https://www.solvewithvia.com/slam-ai/ verified: false certifications_published: [] certifications_note: >- VIA publishes no SOC 2, ISO 27001, PCI DSS, HIPAA or FedRAMP certification, no trust center, and no subprocessor list. trust.solvewithvia.com does not resolve. The only compliance-shaped assertions are the DoD statements above, which are prose claims on marketing pages.