Under-specified format for revocation structure

[cdata]

Regarding the section on revocation: https://github.com/ucan-wg/spec#66-revocation

A structure is prescribed to record a revocation:

{
  "iss": did,
  "revoke": ucanCid,
  "challenge": sign(did.privateKey, `REVOKE:${ucanCid}`)
}

The types of the fields in this structure are not specified. It seems reasonable to assume that did is a DID string.

But, what is the form of ucanCid? A base64-encoded CID string? Or some other form?

And what is the form of the challenge?

[matheus23]

Agreed.

Given ucanCid is re-used in a string splice & it's all JSON, let's assume ucanCid is base-something encoded that fits into ASCII, so either base32, base64, base58, base16? (Or should we rather standardize on what it is, so basically require base32 as the standard for now?)

The result of sign should probably be encoded as base64url, similar to how signatures in JWTs are encoded.

Also, did.privateKey seems to indicate that did is not a string, which may be confusing. We could rework this to say didPrivateKey or privateKeyFor(did).

[expede]

But, what is the form of ucanCid? A base64-encoded CID string?

Yeah, fair.

CIDs

I don't think that we can enforce a specific encoding of the CID without forcing a specific encoding of CIDs throughout the entire system. For purposes of caching revocations, the CID should be a normalized hash (likely to binary), rather than using the specifically text-encoded hash. This is the strategy in IPFS for caching, too. We could standardize on a specific hash function, since (e.g.) SHA2 and SHA3 will give a different hash for the same content.

Signatures

We probably need to add the algorithm type to the signature, especially now that there's systems that use e.g. EIP-191.

DIDs

The DID is a DID string, which is described in the relevant DID spec

[expede]

Let's fix this on 0.10

[expede]

Closed by #132