chore: make extra signers auditable in dlog metadata

[SurbhiAgarwal1]

Closes #993

Problem

In both IssueMetadata and TransferMetadata, the ExtraSigners
field was typed as []Identity. This created an auditability gap —
any third party with access to the metadata could not resolve or audit
these identities, unlike Issuer, Senders, and Receivers which
already carry full AuditableIdentity (identity + audit info).

Solution

Replace ExtraSigners []Identity with ExtraSigners []*AuditableIdentity
in both metadata structs, bringing them in line with every other
identity field in the same file.

Changes

File	Change
token/driver/protos/request.proto	Change repeated Identity extra_signers → repeated AuditableIdentity extra_signers in both TransferMetadata and IssueMetadata
token/driver/protos-go/request/request.pb.go	Update generated struct fields and getter methods accordingly
token/driver/request.go	Change ExtraSigners []Identity → []*AuditableIdentity; update ToProtos/FromProtos to use protos.ToProtosSlice/FromProtosSlice, consistent with other auditable fields
token/request.go	Extract .Identity when building public Issue/Transfer structs (which keep []Identity as their public API); fix extra-signer binding loop to use eid.Identity
token/metadata.go	Fix Match() comparisons to compare against es.Identity
token/driver/request_test.go, token/metadata_test.go, token/request_test.go	Update all test fixtures and assertions to use []*AuditableIdentity

Testing

• go test ./token/driver/... — PASS
• go test ./token/... — PASS
• go build ./token/... — clean
• go build ./token/core/... — clean

Notes

• No change to proto wire format field numbers — fully backward compatible
• Public Issue.ExtraSigners and Transfer.ExtraSigners APIs remain
  []Identity — only the internal metadata layer changes
• Diff is intentionally minimal and focused solely on this type change

[adecaro]

Hi @SurbhiAgarwal1 , thanks for the effort 🙏
Please, fix the linter/checks issues.

The PR is interesting cause it introduces a breaking point with metadata marshaled with the previous definition.
I would investigate the following:

• The introduction of regression tests for the management of the actions and their metadata.
• A way to avoid, if possible, this regression. At the current stage, we can introduce breaking changes if we think it is better for the future.

Around the end of the year, we will need to stop introducing these breaking changes and make the protocol evolve following versioning.

[adecaro]

also this one needs to be auditable

[adecaro]

ops, we need to fix the numbers here

[adecaro]

Hi @SurbhiAgarwal1 , okay, there was a bug in the definition of the protobuf as well. I left a comment on that.

So, actually, there is way to modify the protobuf without introducing a break with old generated messages.
Indeed, we have:

message ActionMetadata {
  oneof Metadata { // Oneof field containing either issue or transfer metadata
    IssueMetadata issue_metadata = 1; // Issue action metadata
    TransferMetadata transfer_metadata = 2; // Transfer action metadata
  }
}

This structure allows to introduce two new protobuf messages IssueMetadataV3 and TransferMetadataV3 with the right fields. Then, in the code, we have to make sure we handle all the versions. I say V3 becasue we have already in token/driver/request.go ProtocolV1 and ProtocolV2.

What do you think? Would you like to explore this retro-compatible extension

Thanks for your effort 🙏

[adecaro]

Hi @SurbhiAgarwal1 , I think we are going in the right direction.
Before we can merge this, we need to update our regression test pipeline in the following way: We need to generate valid token requests with their metadata and store both. Then, we need to instantiate an auditor and make sure the auditor approves, as expected, these token requests with their metadata.
After this, we can make sure that this PR does not break the regression tests.
Would you like to give a short at this in another PR?

Thanks for the effort so far 🙏

[SurbhiAgarwal1]

Hey @adecaro, thanks a lot for the detailed guidance — this really helped clarify the right direction 👍

I agree that introducing a V3 metadata layer using the existing oneof structure is a much cleaner and backward-compatible approach. I’ve started aligning the implementation in that direction so that previously serialized metadata remains valid while enabling auditable identities going forward.

Regarding the regression testing pipeline — that makes complete sense. I’ll work on a separate PR to:

• generate valid token requests along with their metadata
• persist them as fixtures
• validate them through an auditor flow to ensure expected approvals
• use these as regression tests to verify that the new changes don’t introduce breakages

I’ll also address the current failing checks (lint, tests, proto issues) and make sure everything passes locally before pushing updates.

Thanks again for the guidance — I’ll proceed with the regression test PR next and keep this one aligned with the V3-compatible approach 🙏

[SurbhiAgarwal1]

Hi @adecaro 👋

The Tests / utest (unit-tests-race) check is failing, but after investigating I believe it is not related to this PR's changes.

The failure is in integration/nwo/txgen packages which have no connection to the changes in this PR. None of the failing packages import or use any of the modified code (ExtraSigners, AuditableIdentity, ProtocolV3, metadata serialization).

Could you please confirm if this is a known flaky test, or advise if there is something specific I should look into? Happy to re-run the job if needed.

All other checks are now passing:

• golangci-lint
• Tests / checks (goimports, gofmt, govet)
• 49 successful checks

[adecaro]

Hi @SurbhiAgarwal1 , I believe we can close this issue for now. This was very helpful to reflect on the current issues around the protobuf that culminated in #1622.
I want to continue the discuss on that issue a bit more and then start with the implementation. I would be glad if you can take this on. I believe we need to address many points at the same time.

I would like to ask you an additional follow up: Please, could you check if we really need the Identity field in

type AuditableIdentity struct {
	Identity  Identity
	AuditInfo []byte
}

I believe we have it there just to simplify the code. Indeed, we need to make sure it matches the corresponding identity in the action. But, do we really need it? If there is a way to remove it, better to have something that is as lean as possible. What do you think?

[adecaro]

Hi @SurbhiAgarwal1 , I'll absorb this PR into #1622 . Therefore, I'll close this PR if it is okay with you. Thanks for the understanding and for triggering a full revision of the protobuf. Thanks much 🙏