Ambiguous requirement of auditor signatures

[arner]

The token params allow specifying multiple auditors (with the --auditors flag in tokengen).

In the validation (token/core/common/validator_auditing.go), only one auditor signature suffices for the token transaction to succeed. It is not immediately clear for the user that this is the case: one could assume that all auditor signatures are required.

Whether we want to accept "1 out of n" or "n out of n" auditor signatures, it should be clear from tokengen and perhaps readme or code comments how the validator behaves.

[sid200727]

Thanks for raising this, I agree this is ambiguous from a user’s point of view.

From reading the issue and the current validator behavior, it seems like the implementation effectively follows a “1-of-N auditor signatures” model, but that isn’t clearly documented and could easily be interpreted as “N-of-N required”.

I’d like to contribute here by:
• Auditing the current behavior in token/core/common/validator_auditing.go
• Making the effective signature requirement explicit (1-of-N vs N-of-N)
• Updating relevant documentation (README / token-gen docs) and adding clarifying comments where appropriate

Before proceeding, I just want to confirm:
• Is the intended model 1-of-N auditor signatures by design?
• Or is this ambiguity meant to be resolved by making the requirement configurable?

Once clarified, I’m happy to put together a PR to address this

[arner]

Thanks for the offer!

As far as I'm aware, the auditor requires the secret parts of the token inputs. In other words, if you receive a token in a transaction that is co-signed by Auditor 1, and then try to spend that token with a signature of Auditor 2, the second transaction will fail because it cannot find the cleartext information. If that's true, it would be risky to allow 1-of-N, because the network could get fragmented and some tokens could become unspendable (unless the developer implemented their own measures against that). I could be wrong about that though! @adecaro, can you weigh in here please?

[sid200727]

Thanks for the clarification, that makes sense.

If the auditor needs access to the secret parts of the token inputs, then allowing 1-of-N signatures could indeed lead to fragmentation or unspendable tokens, as you described.

I agree that this is likely intended behavior rather than just a documentation gap, but it would be great to confirm the exact design expectation (1-of-N vs N-of-N).

Once clarified, I’m happy to:
• Update the documentation to clearly describe the intended signature model
• Add comments in the validator code to make the behavior explicit
• Ensure token-gen usage reflects the correct semantics

Looking forward to @adecaro’s input, thanks again for the detailed explanation.

[adecaro]

Thanks both @arner and @sid200727 .

So, let's first look at what the current token drivers do. Both fabtoken and dlog require only one signature from any of the public keys listed as belonging to the auditors. It like having 1-out-of-N behavior.
The drivers do not check that these public keys belong to the same entity. So we can have the following situations:

• There is only one auditor entity. During a key rotation phase, two valid public keys can be present at the same time.
• There are multiple auditors each having one or more public keys in the list.

So, ultimately, it is the token driver that needs to decide which policies are supported.
Tokengen only loads these public keys in the public parameters, nothing else.

I would update the documentation with these details and leave to others the implementation of other policies in the current drivers or other drivers.

Wdyt?

[sid200727]

Thanks for the clarification, that helps a lot.

Based on this, I understand that:

• The current behavior in both fabtoken and dlog drivers is 1-of-N auditor signatures.
• The validator does not enforce same-entity checks.
• Multiple auditor public keys may coexist (e.g., during key rotation).

To remove ambiguity, I propose to:

1. Make the 1-of-N behavior explicit in the validator code (token/core/common/validator_auditing.go) via comments.
2. Update the README and token-gen documentation to clearly state that auditor verification currently follows a 1-of-N policy.
3. Clarify that alternative policies (e.g., N-of-N or entity-based checks) are not currently enforced by drivers.

If that sounds good, I’ll prepare a PR focusing on documentation and clarifying comments (no behavior changes).

Please let me know if you'd like anything else included.

[sid200727]

Thanks for the clarification, that makes the current behavior clear.

I’ll proceed with a PR that:

1. Makes the 1-of-N behavior explicit in the validator code via comments.
2. Updates documentation to clearly state that auditor verification currently follows a 1-of-N policy.
3. Clarifies that same-entity or N-of-N policies are not enforced by current drivers.

I'll avoid behavior changes and focus on eliminating ambiguity.

Thanks!