Accept and Verify JSON Web Tokens¶
We made changes to API authentication. Access to the API is now authenticated, and
users can provide a URI to the keyset used to sign the JWT bearer tokens. Users can
also provide a JSON pointer into the JWT claims for the Chronicle identity. A Chronicle
AuthId with a verified external ID can then be found in the GraphQL context.
We also converted the
AuthId variant to be a structure of both a json-pointer
-derived scalar and JWT claims.
Anonymous Identity Variant¶
By default, Chronicle allows unauthenticated access to the GraphQL API, classifying such a user as "anonymous". Adds an identity variant emanating from GraphQL or CLI, not authorized, allowing for the option to pass a transactor key as a CLI argument, or, if not, to generate an ephemeral transaction signing key for the anonymous agent.
Chronicle's GraphQL API will accept anonymous access as default unless disallowed
with the new
--require-auth option. Only with that option must a JWKS server be
specified for JWT verification.
We introduced new interfaces for OPA policy execution and loading. The
PolicyLoader interfaces provide a flexible and straightforward way to evaluate
OpaExecutor interface takes a Chronicle
AuthId identity and an arbitrary
JSON context, which it evaluates against an OPA policy. The
evaluates OPA policies compiled to .wasm for execution.
PolicyLoader interface offers two implementations. The
implementation loads an OPA policy rule that is compiled to .wasm from a Sawtooth
CliPolicyLoader implementation provides support for loading an OPA
policy .wasm file via CLI arguments for a file path and policy entrypoint.
Chronicle integrates OPA execution at its GraphQL API endpoint and in its Transaction Processor to ensure access control and policy compliance.
opa-tp command-line interface (CLI) is used to interact with the Chronicle
OPA-TP (Transaction Processor) for Public Key Infrastructure (PKI) and OPA rule storage.
Chronicle now has
opactl, which enables users to submit transactions to the Sawtooth
network, specifying operations on OPA (Open Policy Agent) policies stored on the
ledger. With this tool, users can inspect, modify, and query OPA policy states on
the network, provided they have the policy ID.
No Changes, No Dispatch¶
We added API methods and responses to check whether Chronicle operations resulting
from API calls will result in changes in state. If they don't, they won't be submitted
to the Transaction Processor, instead returning
with GraphQL data containing
context and a
In-Domain Documentation Capabilities¶
Chronicle now provides users with the ability to generate a Chronicle domain with documentation by using a domain.yaml file and adding documentation comments to it.
Chronicle now uses
async-sawtooth-sdk in this update, which contains generic client
types used by
opa-tp-protocol. The transition to this new SDK has led to several
LedgerWriter client abstractions are now in common, with
specialization for transactions and events in the
modules. The simulated transaction processors now use the actual Chronicle and OPA
TransactionHandlers during tests and in
Chronicle now supports the
wasAttributedTo PROV-O relationship.
Endpoint offering JSON by IRI¶
Now, running Chronicle with the
serve-api command, users can visit
http://localhost:9982/data/chronicle:agent:my-agent-id and see a JSON summary,
which they can also do for entity and activity.
OPA TP, Protocol, and Skeletal CLI¶
We introduced an OPA policy and key registration transaction processor in this update. The OPA policy and key registration transaction processor share similarities in design with the Chronicle TP. Tested at the protobuf level, this feature is designed to operate independently of the rest of the Chronicle project.
Move from SQLite to PostgreSQL¶
Chronicle now utilizes PostgreSQL instead of SQLite as its local database. This change brings several benefits, such as increased scalability and better performance for large-scale data management.
AuthId Identity Type¶
We introduced an identity union in this update, which offers a versatile and flexible approach to identity management. This new feature can be created from any of the following options:
- Chronicle root key, identified by the agent name "chronicle"
- an agent along with its corresponding key pair
- a pointer into a JWT structure, for retrieving the external id to use for the agent and its key pair
The identity union includes the identity, public key, and signature, providing a comprehensive solution for managing identities in the Chronicle application.
Chronicle Domain Linter¶
Chronicle now includes a domain linter from which Chronicle users can get helpful comments on fixing any formatting issues in their domain.yaml domain files.
Input Either ExternalId or Id in Relational Mutations and *ById Queries¶
Where relational mutations and queries previously required
EntityId inputs, Chronicle now makes available the
EntityIdOrExternal input types. In such cases, Chronicle
users can now use either simply the
ExternalId or the full
See Recording Provenance for examples.
Query Agents, Entities, and Activities by Type¶
Chronicle users can now query agents, entities, and activities by type.
In addition to
Bool, Chronicle users can now
add generic JSON data
to activities, agents, and entities.
The 0.3 release font loads a number of breaking changes to address usability and consistency:
New Completion Mechanism¶
Before 0.3, contradictions would result in a no-operation, but with no notification to clients. 0.3 contains various protocol changes to notify Chronicle and connected clients of contradictions.
Before 0.3, submission was not independently notified from commit, and had no ability to carry an error result. There is now a 2 stage notification for chronicle operations.
name is now
externalId and will no longer be disambiguated by Chronicle when
creating entities, activities, or agents. Previously, re-using a name in these operations
would result in it being postfixed with an index. We discovered that stable
external identifiers are far more useful in practice and will enable batching
operations and convenience methods for revision in future releases.
Short Form IRIs¶
Chronicle ids will now be written in their short form with a prefix of
http://btp.works/chronicle#ns, operations will continue
to accept the long form for backwards compatibility.