feat: add tests using invocation test vectors

[alanshaw]

I made 20 test vectors for invocations and added tests here that use them against the implementation.

Some are failing. I believe 1 because of #75 but please lets discuss the others :)

refs ucan-wg/spec#195

[alanshaw]

Summarised the failures here:

 === RUN   TestFixtures/valid_self_signed
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	at least one delegation must be provided to validate the invocation
        	Test:       	TestFixtures/valid_self_signed
        	Messages:   	execution should have been allowed for invocation with no proofs, the subject is the issuer so no proof is necessary

^^^ Probably needs discussion - do we need a delegation in this case? I had assumed no if the invocation is signed by the subject.

 === RUN   TestFixtures/valid_multiple_proofs
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	delegation proof chain doesn't connect the invocation to the subject: delegation bafyreieamqfgpp7qwkxgak7d7svyi2wa4zbk4hfceccmhjdth5wzed5heq, expected did:key:z6MkgGykN9ARNFjEzowVq4mLP2kL4NsyAaDGXeJFQ5qE1bfg, got did:key:z6MkmT9j6fVZqzXV8u2wVVSu49gYSRYGSQnduWXF6foAJrqz
        	Test:       	TestFixtures/valid_multiple_proofs
        	Messages:   	execution should have been allowed for invocation with a proof chain more than one delegation long

^^^ I possibly have the delegations the wrong way around in the vectors. go-ucan assumes proofs are provided in order of invocation -> root, but the fixtures proofs are provided starting from root and ending with the proof for the invocation.

I think the language in these two sections has caused this confusion:

• https://github.com/ucan-wg/invocation#proofs
• https://github.com/ucan-wg/invocation#proof-chains

=== RUN   TestFixtures/valid_multiple_active_proofs
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	delegation proof chain doesn't connect the invocation to the subject: delegation bafyreieamqfgpp7qwkxgak7d7svyi2wa4zbk4hfceccmhjdth5wzed5heq, expected did:key:z6MkgGykN9ARNFjEzowVq4mLP2kL4NsyAaDGXeJFQ5qE1bfg, got did:key:z6MkmT9j6fVZqzXV8u2wVVSu49gYSRYGSQnduWXF6foAJrqz
        	Test:       	TestFixtures/valid_multiple_active_proofs
        	Messages:   	execution should have been allowed for invocation with a proof chain more than one delegation long where one or more proofs have a not before time in the past

^^^ I think this one is actually the same problem as above.

 === RUN   TestFixtures/valid_powerline
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	func called on wrong kind: "AssignNull" called on a DID node (kind: INVALID), but only makes sense on <empty KindSet>
        	Test:       	TestFixtures/valid_powerline
        	Messages:   	execution should have been allowed for invocation with a proof chain with a powerline delegation (null value for subject)

^^^ I believe this one might be failing because of #75

[MichaelMure]

^^^ I possibly have the delegations the wrong way around in the vectors. go-ucan assumes proofs are provided in order of invocation -> root, but the fixtures proofs are provided starting from root and ending with the proof for the invocation.

We had discussion with Brooke about this very question, pretty sure go-ucan is doing the right thing. Also, I believe https://github.com/hugomrdias/iso-repo/tree/main/packages/iso-ucan is doing the same.

I'll need to find some time to look at the rest.

[alanshaw]

^^^ I possibly have the delegations the wrong way around in the vectors. go-ucan assumes proofs are provided in order of invocation -> root, but the fixtures proofs are provided starting from root and ending with the proof for the invocation.

We had discussion with Brooke about this very question, pretty sure go-ucan is doing the right thing. Also, I believe https://github.com/hugomrdias/iso-repo/tree/main/packages/iso-ucan is doing the same.

ACK. Yes it looks that way. I'll fix the vectors and send a PR to clarify the spec language.

[alanshaw]

Ok fixed the proof ordering in the vectors and now we're down to just the 2 failures:

=== RUN   TestFixtures/valid_self_signed
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	at least one delegation must be provided to validate the invocation
        	Test:       	TestFixtures/valid_self_signed
        	Messages:   	execution should have been allowed for invocation with no proofs, the subject is the issuer so no proof is necessary
=== RUN   TestFixtures/valid_powerline
    fixtures_test.go:64: 
        	Error Trace:	/home/runner/work/go-ucan/go-ucan/token/invocation/fixtures_test.go:64
        	Error:      	Received unexpected error:
        	            	func called on wrong kind: "AssignNull" called on a DID node (kind: INVALID), but only makes sense on <empty KindSet>
        	Test:       	TestFixtures/valid_powerline
        	Messages:   	execution should have been allowed for invocation with a proof chain with a powerline delegation (null value for subject)

[MichaelMure]

execution should have been allowed for invocation with no proofs, the subject is the issuer so no proof is necessary

Is that a thing? What would be the purpose?

[alanshaw]

execution should have been allowed for invocation with no proofs, the subject is the issuer so no proof is necessary

Is that a thing? What would be the purpose?

It's a smaller payload for this case and it is redundant to include a proof for it.

For example, perhaps you crate a bucket identified by did:key:bucket and want to upload files to the bucket, so provided you kept the private key for the bucket you could send a /bucket/put invocation to the upload service, using the bucket as the subject and sign with the bucket key. The bucket doesn't need a delegation to itself.

You might also want to use this when a service needs to perform some other task on itself as part of a larger invocation. Like a /console/log invocation or something. So a service can log on itself but also accept logs from other places.

[MichaelMure]

Closed in favor of #119