Example 5 contradicts spec statement

[wip-abramson]

The spec states:

A root zcap MUST have an @context field that is a string with the value https://w3id.org/zcap/v1.

However, example 5 is as follows:

{
  "@context": [
    "https://w3id.org/zcap/v1"
  ],
  "id": "urn:zcap:root:https%3A%2F%2Fexample.com%2Ffoo",
  "controller": "did:key:example",
  "invocationTarget": "https://example.com/foo"
}

The context is an Array not a string?

Which is correct? I ran into this while using the zcap library which expects a string value here. https://github.com/digitalbazaar/zcap.

Also wondering why you wouldn't add https://w3id.org/security/v2 to the context. Is that because the root capability is never signed so has no proof?

[dlongley]

The context is an Array not a string?

Hmm, it's a JSON-LD-ism that an array with a single value and a string with that same value are technically considered equivalent. I have a preference to require it to be just a string for root zcaps as the spec says today -- but if there's an implementation problem with that we could relax it. Hopefully not. IMO, we should proceed as if the example is faulty and it should just be a string (and the example should be fixed when someone has time to do a PR).

Also wondering why you wouldn't add https://w3id.org/security/v2 to the context. Is that because the root capability is never signed so has no proof?

Yes, a root zcap is never signed and has no proof. As a side note, the https://w3id.org/security/v2 context is essentially deprecated. It doesn't use the @protected keyword and has a number of other issues due to its age at this point -- so it would be best not to use it in newer applications generally. The VCWG is working on new data integrity specs that will include a new data integrity context that would be suitable to use here for proofs (on delegated zcaps). There's an Ed25519Signature2020 context that can be used today for proofs, but the data integrity context will be preferred once it's ready.