Re: Proposal Work Item | Credential Chaining

On Mon, Jan 31, 2022 at 10:56 AM Daniel Hardman <daniel.hardman@gmail.com>
wrote:

> I am not bringing up this prior art to forestall a new work item,
> necessarily. However, I would like there to be good awareness that
> substantial work already exists on the topic, and that some of it goes by
> the name "chained credentials." It would be good to understand the
> differences, and perhaps to choose a different term, if it this new work
> item is truly tackling new territory. If it is not tackling new territory,
> then it would be good to explain how the efforts are different, so people
> can make informed choices about which approach meets their needs.
>

I too would like to see better definitions for the different mutlisig
signature types, and which of those types are orthogonal (i.e. any
signature operation might have multiple orthogonal types.)

I'm not suggesting these terms, but on my list for better consensus on
naming are:

* multisig accountable signature & multisig non-accountable signatures: In
the former, you know who signed, in the latter the signers are blinded thus
you only know it was properly signed according to the rules (for instance,
a quorum). A challenge in naming here is that in non-accountable
signatures, those who specifically signed in a quorum may be anonymous, but
the list of who possibly can sign might not be blinded. So this is not an
"anonymous" signature.

* cosign & chain sign: In the former, multiple parties sign at the same
time. In the second, additional signatures are added over time.

* partial signatures — a state of multisig where some of the signatures
exist, but not sufficient that meet the rules (typically a quorum). The
signature isn't quite "invalid", it just is "insufficient". Some partial
signatures have an expiration date for completion where

* group signatures: slightly different than cosigning/chain-signing — a
"group" is signing, not any specific individuals. Particularly important
for entities with some personhood, like corporations, where the legal
liability is limited to not be on the individual signers but the group as a
whole. Technically it can also be different.

* notarize/witness — the signer has verified certain properties of
something signed by someone else, but is not a cosigner or chain signer.
This might be to add a timestamp for the whole, a statement about the
signer such as  "proof of personhood" or "no coercion" (required for
international notarization), or a statement about some portion of what was
signed "was verified at the time".

* Revokable anonymous — the signer (single sig or not) is blinded or not
identifiable, but the signer can reveal later a proof of identity that
revokes that anonymity retroactively.

* blinded signatures & signature blinding & proof blinding — to be clear on
the difference between a blinded signature where the signature is on
blinded content), vs. signature blinding where the signature or some
information about the signature is blinded, vs. proof blinding where some
portion of the proof is offline and requires additional effort (or
authentication) to verify the verifier before the verifier can verify.

* zk-* signatures — lots of complicated options to hide various information.

* Oracle/Adjunct/Adapter/Atomic signatures: Where the signature on one item
is proof to make a separate signature on a different object verify as
valid. This is harder to explain, for instance, a signed statement is only
cryptographically valid while a particular Oracle is cryptographic valid
(this is somewhat what a revocation list does, but cryptographically, and
the utility is broader, for instance, valid only while the company is legal
in a jurisdiction oracle, or only when a blockchain account balance is >1M.
).  Another example with Liquid I can sign an unblinded statement to give
my CPA with who to, amounts, etc. but isn't valid unless my blinded
signature without that information has been accepted on the blockchain.
Another: I can sign one of two statements that atomically makes another
statement valid if either one is signed (used for atomic transfers in
Lightning and between different blockchains in DeFi, but could be used in
other ways), or even make a hash tree of statements valid up to a point on
that tree. To be clear, all of these are cryptographic operations — there
are clearly computational ways to do these functions when verifying a
regular signature, but these technique use cryptography to allow for
greater decentralization or eliminate certain third-party risks.

I'm certain that I'm missing a few other interesting cryptographic options,
and even more business processes that need more permissionless
cryptographic signature operations that could be addressed with current
technology.

-- Christopher Allen