- Ensure that when invoking a capability with a chain depth of 2, i.e.,
it is delegated directly from the root capability, that
expires
is properly checked against the current date or otherdate
param.
- BREAKING: Use
jsonld-signatures@11
to get better safe mode protections when canonizing.
- BREAKING: Convert to module (ESM).
- BREAKING: Require Node.js >=14.
- Update dependencies.
- Lint module.
- Ensure a zcap is not delegated after its parent (during delegation proof generation).
- Ensure
maxClockSkew
is considered when checkingmaxDelegationTtl
against current time. - Use
[email protected]
to address reported vulnerability with dev dependencykarma
.
- Include
capability
andverificationMethod
as details when a zcap invocation/delegation fails verification because the capability controller does not match the verification method (or its controller). If this information causes undesirable correlation, i.e., the controller of a root zcap is private in some way, do not include it when transmitting errors to a client. This information can be omitted by deletingdetails
from the error or constructing a new error that omitsdetails
.
- Include
dereferencedChain
in purpose result when verifying a capability invocation or delegation proof.
- Update dependencies.
- BREAKING: Rename package to
@digitalbazaar/zcap
.
- Add
createRootCapability
helper function to construct root zcaps from a root invocation target and a root controller. - Add local validation during delegation to prevent accidental delegation of zcaps that violate delegation rules that a verifier would always reject.
- Add
maxClockSkew
param that defaults to300
seconds. This parameter defines the maximum clock skew that will be accepted when comparing capability expiration date-times against the current date (or other specified date) and when comparing a capability invocation proof against the capability's delegation proof.
- BREAKING: Root zcaps MUST specify an
invocationTarget
. This eliminates optionality, simplifying implementations. - BREAKING: Root zcaps MUST be passed by reference to their ID when invoking and they will be expressed by reference (just their ID) in a capability invocation proof. Delegated zcaps MUST be fully embedded (pass full object) when invoking and they will be fully embedded in a capability invocation proof.
- BREAKING: When creating a capability delegation proof, a new parameter
parentCapability
MUST be passed so that the chain can be auto-computed. PassingcapabilityChain
is no longer permitted. - BREAKING: Require
capabilityAction
when creating capability invocation proofs andexpectedAction
when verifying proofs; removing previous optionality simplifies implementations. - BREAKING: Changed default to check for chain date monotonicity and removed the option to do otherwise. This was an expected change for the next major breaking release.
- BREAKING:
expires
is not permitted on root capabilities and is required on delegated capabilities. Removing optionality here simplifies implementations and improves security by reducing surface and providing an "out" for zcaps that can not be easily revoked by causing them to always expire eventually. - BREAKING: Combine
currentDate
anddate
parameters that were serving the same purpose. These params are only used for verification and thedate
parameter is used by the base class provided by jsonld-signatures, so thecurrentDate
parameter has been removed; usedate
instead, it is only used for verification of proofs, not creation of proofs. - BREAKING:
invocationTarget
MUST be specified in capability invocation proofs, it will not default to theinvocationTarget
specified in the capability. Removing this optionality removes complexity in implementations. - BREAKING:
capabilityChain
andcapabilityChainMeta
that are passed toinspectCapabilityChain
include entries for the root capability. TheverifyResult
isnull
for the root zcap. - BREAKING:
allowTargetAttenuation=true
allows both path- or query-based invocation target attenuation. Turning this on means a verifier will allow accept delegations (and invocations) where a suffix has been added to the parent zcap's invocation target (invoked zcap's invocation target). The suffix must starts with/
or?
if the invocation target prefix has no?
and&
otherwise.
- BREAKING: Removed support for using
invoker
anddelegator
properties. Onlycontroller
is now permitted and it isrequired
, i.e., a ZCAP MUST have acontroller
property, the value of the ZCAP'sid
property is not considered a default controller value for the ZCAP. This change simplifies ZCAP implementations and better reflects the fact that a delegation cannot actually be restricted -- a system can only force users to use data model and protocol-external mechanisms to delegate. This change keeps all delegation within the data model/protocol for improved auditability. - BREAKING: Removed support for vocab-modeled custom caveats. Custom caveats should instead be modeled a combination of capability actions and path- or query-based attenuation of invocation targets. This approach provides the flexibility required to model custom caveats without the overhead of building and maintaining custom contexts and vocabularies. The common case is that custom caveats are specific to particular APIs rather than shared commonly across many different standardized APIs -- so it is unnecessarily burdensome to require the creation ofLinked Data vocabularies and contexts to represent them when using localized API-specific capability actions and invocation target paths will suffice. Common caveats such as expiration dates are provided as a part of the core model -- and should any other common caveats become evident, they can be added to the core model over time.
- BREAKING: Removed support for allowing the last delegated zcap in a capability chain to be expressed by reference. Instead, if the last zcap in the chain is delegated, it MUST be fully embedded. All other zcaps MUST be expressed via reference to their ID. Therefore, a capability chain MUST always consist of: the root zcap ID, any non-last delegated zcap IDs, and, for chains longer than 1 (excluding the final zcap or 2 if inclusive), the fully embedded last delegated zcap. This simplifies implementations, removes any concerns around mutability in dereferenced zcaps, and guarantees that all zcaps in a chain are available in an invocation. It does require that the invoker send the entire chain, however, this considered the best trade off.
- BREAKING: Removed ability to expire a root capability. There is no use case for this, so the complexity has been removed.
- BREAKING: Removed support for zcaps expressed using contexts other than the zcap-ld v1 context. The zcap spec will be updated to describe zcaps as JSON in a way that JSON-LD compatible, eliminating the need for supporting and JSON-LD context transformations beyond those used to create and verify proofs. This approach will not prohibit the future use of CBOR-LD to represent zcaps over the wire to greatly reduce size.
- Add optional
maxDelegationTtl
to enable checking that all zcaps in a delegation chain have a time-to-live that is not greater than a certain value. This check will have a default value shorter thanInfinity
in a future breaking version. - Add optional
requireChainDateMonotonicity
to enable checking that all zcaps in a delegation chain have delegation proofs that were created using dates that monotonically increase (i.e., no delegated zcap was delegated any later than its parent). This check will be required in a future breaking version.
- Ensure
invocationTarget
from an invocation proof is checked against the capability used and theexpectedTarget
. TheinvocationTarget
from the proof must both be in theexpectedTarget
list (or a direct match if a string value is used forexpectedTarget
vs. an array) and it must also match theinvocationTarget
in the capability used (ifallowTargetAttenuation=true
then the capability'sinvocationTarget
may be a path prefix for theinvocationTarget
from the proof).
- Enable zcap context to appear anywhere in a context array when checking proof context because it is a protected context.
- Ensure
proof
uses an expected context during proof validation.
- Updated jsonld-signatures to 9.3.x. This brings in an optimization for controller documents that are JSON-LD DID documents.
- Expose
ZCAP_CONTEXT
inconstants
as a convenience. - Add
documentLoader
to expose a convenience document loader that will loadZCAP_CONTEXT
. - Add
extendDocumentLoader
for adding a custom document loader that extenddocumentLoader
to load other documents.
- BREAKING: LD capability invocation proofs now require
invocationTarget
to be set in order formatch()
to find proofs based onexpectedTarget
. This helps ensure that the proof creator's intendedinvocationTarget
is declared (important for systems that support RESTful attenuation) and it enables more efficient proof verification when documents include multiple capability invocation proofs that may have different invocation targets.
- Ensure
expectedAction
is checked when looking for a matching proof, notcapabilityAction
.
- BREAKING: Use
[email protected]
and refactorfetchInSecurityContext
API. - Use
@digitalbazaar/[email protected]
.
- Use
jsonld-signatures@9
. - Update test dependencies and fix tests.
- Skip
jsonld.compact
step when a JSON-LD document has specific contexts. This is a temporary measure until a zcap context is created.
- BREAKING: Changed package name from
ocapld
to@digitalbazaar/zcapld
. - BREAKING: Only support Node.js >=12.
- Update dependencies.
- Use new
@digitalbazaar/ed25519-signature-2018
and@digitalbazaar/ed25519-verification-key-2018
dependencies for testing.
- BREAKING: Remove
bitcore-message
dependency. It's for a specialized use case. - BREAKING: Remove browser bundles.
- BREAKING: An
invocationTarget
must be specified in all delegations. - Improve test coverage.
- Properly validate
allowedAction
in capabilities.
- Add verification of
expires
as a core feature. - Add the ability to specificy a
maxChainLength
when verifying capability delegations. - Add an optional
allowTargetAttenuation
flag which allows theinvocationTarget
of a delegation chain to be increasingly restrictive based on a hierarchical RESTful URL structure.
- Use jsonld-signatures@5.
- Implement validation for embedded capabilities in
capabilityChain
.
- Adjust the parameters to
inspectCapabilityChain
to support more general use cases. See in-line documentation for parameter details.
- Add an optional
inspectCapabilityChain
parameter toCapabilityDelegation
andCapabilityInvocation
.inspectCapabilityChain
must be an async function used to check the capability chain. It can, for instance, be used to find revocations related to any of the capabilities in the chain.
- Address issues in
verifyCapabilityChain
helper that resulted in some proofs not being properly verified.
- Support multiple values for
expectedTarget
andexpectedRootCapability
for use cases such as where capabilities are given for reading/writing any item in a collection instead of only individual items.
- Use [email protected] Use with support for Node 12 native Ed25519 crypto.
- Handle case where a capability lists list multiple controllers/invokers/delegators.
- Add
expectedRootCapability
to allow a root capability to specify aninvocationTarget
different from itsid
. This allows zcaps to be used to manage authority for resources that cannot express their own zcap authority information such as binary files or resources that use JSON or JSON-LD but, for whatever reason, cannot expresscontroller
,invoker
,delegator
, or key information.
- Check
allowedAction
against expectedcapabilityAction
. - Fix expected action check.
- Fix capability chain check.
- Ensure root caps are dereferenced and have a valid target.
- Handle case where
invocationTarget
is an object.
- Support
controller
on capabilities asdelegator
andinvoker
.
- Update webpack and babel.
- Switch to eslint.
- Upgrade jsonld-signatures to version 4.
- Change jsonld-signatures to a regular dependency.
- Distribute webpack built dist files.
- Use webpack 'externals' for jsonld and jsonld-signatures.
- Initial release.
- See git history for changes.