Abstract
The initial framework began from a narrow problem: applications often depend on algorithm names, provider coordinates, key-store structures and library behavior even when the business requirement is simply to sign, verify, encrypt or establish a key. It proposed moving those implementation choices behind a stable, testable boundary without erasing security-relevant differences.
At the time, the work used Crypto Agility Algorithm Protocol (CAAP) for the proposed control and interaction boundaries and Common Crypto API for the consumer-facing contract. The project now uses Cryptographic Abstraction Layer Interface (CALI) as its canonical name. This page preserves the initial terminology as historical context; it does not describe a separate current standard.
Research question
Can two independent implementations accept the same consumer request, obtain the same policy decision, select a compatible provider, execute the same operation semantics, and return the same class of result or failure without private coordination?
This question is narrower than enterprise cryptographic governance. It is intended to be tested with schemas, adapters, positive and negative vectors, and independent implementations.
Why an abstraction layer is difficult
Cryptographic mechanisms are not interchangeable merely because they appear under the same high-level verb. Message signing and digest signing differ. Key custody, deterministic behavior, encodings, protocol compatibility, provider authorization and assurance properties differ. A useful abstraction must preserve those distinctions while allowing applications to depend on stable operation semantics.
The initial framework therefore made four separations:
- consumer intent from provider configuration;
- policy decision from broker enforcement;
- logical key references from provider coordinates and secret material; and
- portable result categories from provider-specific diagnostics.
Prior art and proposed contribution
The framework does not claim that cryptographic abstraction, provider interfaces or centralized policy are new. PKCS #11 defines a cryptographic token interface; KMIP defines managed objects and operations; cryptographic libraries and KMS APIs provide established execution surfaces; and NIST crypto-agility guidance addresses inventory, policy, transition, testing and governance.
The proposed contribution is a smaller seam that can be evaluated independently: a consumer contract, a separate policy-decision contract, bounded broker enforcement, an adapter-facing provider contract, explicit failures and reproducible decision evidence. Novelty and interoperability remain claims to test, not assumptions.
Initial logical architecture
Design principles
- Express the operation, not the implementation. Intent belongs to a defined operation class with typed inputs, outputs and non-negotiable constraints.
- Keep policy decision separate from enforcement. The authority decides; the broker authenticates, authorizes, pins and checks the decision.
- Preserve security-relevant differences. Providers are interchangeable only when they preserve the required semantics.
- Use opaque references, not opaque claims. A logical key reference does not prove hardware protection, non-extractability or portability.
- Fail explicitly. Ambiguity, inactive policy, downgrade, authorization failure, capability mismatch and invalid key state remain distinct failures.
- Make decisions reproducible. Results identify the request, policy version, selected profile, provider reference, outcome and timing without exposing secrets.
From framework to implementation
The current alpha implements part of this model: policy evaluation, broker enforcement, capability discovery, key creation, signing, verification, rotation, successor transformation, signed evidence and candidate conformance vectors. It does not yet answer the original interoperability question because there is no independent second implementation.
Continue to the executable implementation
Limitations of the initial framework
The framework is conceptual research, not a production design or standards proposal with consensus. Authentication bindings, policy distribution integrity, durable state, independent adapters, full operation semantics, protocol compatibility and governance were left for later specification and evaluation. The current implementation narrows some of those gaps while leaving others explicit.