Summary

Problem

The current fixtures mix validation and capability checks into verify and refute tasks.

Impact

The task intention for the fixtures is confounded and would be clearer if broken into more task categories.

Solution

Break the fixtures into groups like

1. validate (the UCAN is valid)
2. prove (the UCAN grants some capability with respect to some issuer)
3. refute (the UCAN is invalid)
4. disprove (the UCAN does not grant some capability with respect to some issuer)

Names not final! But the idea is that we would separate out tests that require a check for capabilities, and provide extra context like which capabilities should be available and a timestamp when they should be available.

Additionally, we may be able to add build fixtures where an implementation creates proofs and UCAN, puts the proofs in a store, then checks that their UCAN satisfies some capability check. This would replace the flawed build fixtures referenced in #14.

Summary

Problem

We want capability semantics to generate fixtures that demonstrate delegation.

Impact

The fixtures will be uninteresting without some delegation.

Solution

Borrow capabilities schemes from rs-ucan. Note that they wnfs capabilities may need to be updated.

Summary

Problem

We do not have a mechanism to make the fixtures available to implementations.

Impact

Implementations cannot test without the fixtures.

Solution

Add GH pages that serves from the fixtures directory. It should include an index with a high-level description of the fixtures and links to the fixtures themselves.

The fixtures should be namespaced into directories matching their UCAN version.

Detail

Describe alternatives you've considered

There are options! An implementation could pull in the fixtures as a git submodule or copy-paste directly into their project. Making the fixtures available on endpoints makes them easily accessible.

Summary

Problem

We need identity and key support to create and sign UCANs.

Impact

We get nowhere.

Solution

Add identity and key support. Some of this can be borrowed from the rs-ucan test fixtures.

Summary

Problem

We have some fixtures that are marked as invalid when they expire after their proofs. But a UCAN may be valid for only some capabilities, which means we can't directly correlate time bounds against a single proof.

Impact

The fixtures are invalid and may indicate incorrect information about time bounds. Time bounds should be checked at invocation with the associated proof as context.

Solution

Remove the relevant fixtures.

Summary

Problem

We want to generate fixtures that test toCID functionality in implementations.

Impact

If implementations generate CIDs incorrectly, proofs may not be resolved.

Solution

Generate toCID fixtures. Given a token and a hasher, the output should be some CID.

Summary

Problem

The build fixtures are not possible to test against because the signature is dependent on the representation of serialized JSON, which may vary depending on the JSON encoder.

Impact

Fixtures that can't easily be tested. Implementer frustration.

Solution

Remove the build fixture generator code and the build fixtures. (The fixtures are on #13 at the moment.)

Summary

Problem

Fixtures currently include a proof map like:

      "proofs": {
        "bafkreie3bfwr2pxtzphzpspb3plvdrh3obq5yiyibfuuiqj2m3kcrrexpu": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJkaWQ6a2V5Ono2TWtmZkRaQ2tDVFdyZWc4ODY4ZkcxRkdGb2djSmo1WDZQWTkzcFBjV0RuOWJvYiIsImNhcCI6e30sImV4cCI6OTI0NjIxMTIwMCwiaXNzIjoiZGlkOmtleTp6Nk1razg5YkMzSnJWcUtpZTcxWUVjYzVNMVNNVnh1Q2dOeDZ6TFo4U1lKc3hBTGkiLCJuYmYiOjEsInVjdiI6IjAuMTAuMCJ9.qvC6-4agkAxd72ZKNardHy8YHpKGAhz9sbNlWMys0LBoccifGCl-9Yz3bpy4SuosAbWy-W2tc5MGzFCNRmLpAw"
      }

but the ucan-http-bearer-token spec has been updated to put all proofs in a UCAN proof array: https://github.com/ucan-wg/ucan-http-bearer-token#23-example

Impact

The original intuition for proofs in a map no longer applies. In addition, an implementer might incorrectly cache proofs rather than computing their CIDs.

Solution

Present proofs as an array of tokens.

Summary

Problem

We want to generate fixtures that can be checked by implementations.

Impact

No fixtures, nothing for implementations to check.

Solution

Generate a set of valid and invalid fixtures.

ETA: 2023-08-18

Summary

Problem

We want to generate fixtures that test whether an implementation can correctly build a UCAN and emit a token.

Impact

Without these fixtures, an implementation might emit invalid tokens.

Solution

Generate build fixtures. Given key material, algorithm, and a payload, an implementation should be able to emit a token.

Summary

Problem

UCAN libraries do not have a set of conformance tests to verify they have correctly implemented UCAN 0.10.0.

Impact

Library authors aren't able to easily verify their implementation.

Solution

Add a set of fixtures at UCAN 0.10.0.

ETA: 2023-09-01