Spec has contradicts itself in regards to order in which proofs should appear

So in first place it says

Line 307 in 445f444

    
           The `prf` field lists the path of authority from the [Subject] to the [Invoker]. This MUST be an array of CIDs pointing [Delegations][Delegation] starting from the root Delegation (issued by the Subject), in strict sequence where the `aud` of the previous Delegation matches the `iss` of the next Delegation.

starting from the root Delegation (issued by the Subject)

Which I interpret as

{ iss: 'did:key:zAlice', sub: 'did:key:zAlice', aud: 'did:key:zBob' } → { iss: 'did:key:zBob', ...}

But then linked section o the spec says

invocation/README.md

Line 339 in 445f444

    
           A Task MUST include the entire [UCAN Delegation] proof chain in the `prf` field. The chain MUST form a direct line of authority, starting with the delegation with an `aud` that matches the Invoker, and ending with a delegation where the `iss` matches the `sub`. The `sub` throughout MUST match the `aud` of the Invocation.

starting with the delegation with an aud that matches the Invoker

Which seems to suggest the oppsite

{ iss: 'did:key:zBob', ...} <- { iss: 'did:key:zAlice', sub: 'did:key:zAlice', aud: 'did:key:zBob' }

@alanshaw

Unless I'm mistaken rs-ucan assumes order that is opposite of what's in the https://github.com/ucan-wg/spec/blob/main/fixtures/1.0.0/invocation.json

@alanshaw, @expede, @hugomrdias would be good to clarify what order each implementation assumes and align spec language along with fixtures to be consistent

I believe that we landed on sub->delegations as the easiest to reason about

{
  iss: bob,
  prf: [sub->alice, alice->bob]
}

Thoughts?

I believe that we landed on sub->delegations as the easiest to reason about
{
  iss: bob,
  prf: [sub->alice, alice->bob]
}
Thoughts?

I had it this way in Ucantone but then I changed it there and in the fixtures because go-ucan and the JS implementation had it the other way.

@alanshaw

Both orderings work, and I can see arguments on both sides, and a minor preference (now that I've been convinced by I think Hugo) that we should order them as above.

@alanshaw do you have a strong opinion about not changing the existing code? "For historical reasons" is completely valid here

No opinion - good to get it sorted. I'll send PRs to update the fixtures, go-ucan and ucantone. If someone could send a PR to clarify the spec that would be much appreciated.

Okay I'll clarify the spec right now

WIP in #42 — just checking for any other places it needs to update in this spec

@alanshaw

Okay RFR #42 @alanshaw & @Gozala !

I also got a machine review and has a couple broken links and JSON syntax errors to fix, but will put those on a separate PR

Closed by #42

fix: update spec fixtures and remove prior workarounds

fix: update spec fixtures and remove prior workarounds (#195)

fix: invocation proof order (#2)

Navigation Menu

Repository navigation

Spec has contradicts itself in regards to order in which proofs should appear #41

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Spec has contradicts itself in regards to order in which proofs should appear #41

Description

Activity

Gozala commented on Feb 10, 2026

expede commented on Feb 10, 2026

alanshaw commented on Feb 10, 2026

expede commented on Feb 10, 2026

alanshaw commented on Feb 11, 2026

expede commented on Feb 11, 2026

expede commented on Feb 11, 2026

expede commented on Feb 11, 2026

expede commented on Feb 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions