Re: Proposal Work Item | Credential Chaining

On Mon, Jan 31, 2022, at 1:56 PM, Leonard Rosenthol wrote:
> > * cosign & chain sign: In the former, multiple parties sign at the same time. In the second, additional signatures are added over time.
>  
>  
> IN the PDF industry, we refer to those concepts as parallel signatures and serial signatures respectively.  
>  
> And while not specific to multiple signatures, you should also consider
>  
> - Certifying Signatures: signatures applied by an entity to declare that they “stand behind” (certify) the thing being signed.
>  
> - Sealing Signatures: applied as the **last** signature in a serial/chain signing workflow to declare all modifications complete.

I like the simplicity of these options. Keeping the semantics of the cryptography simple is going to be key.

One thing that concerns me about generalized chainable claims is the dangers of open ended semantics. We can do this already in the existing VC framework, where one VC includes claims about another VC or about parties referenced in another VC, such  a VC3 with claims that VC1 is my mom's passport and VC2 is my birth certificate, signed by the child in the birth certificate. This is possible with todays' spec, but there are no standards for the semantics of it. 

The problem is that each step in the chain is a risky game of "operator" where semantic ambiguity can lead to misinterpretations of intent by signers and verifiers alike. Statements of simple correlation, eg., did:abc (in vc1) is the same as did:xyz (in vc2) seems tractable and Leonard's examples feel like the same level of simplicity: simple enough to have a good chance at maintaining rigor.

More than that is a foot-gun machine and should be treated with great care. I appreciate Christopher's list of multi-sig capabilities, but without clear semantics, the crypto, IMO, is just as likely to give a false sense of rigor when the actual intention of the signer is a mismatch with the expectation of the verifier, but, "Hey! the math verifies, so it must be good, right?" 

It doesn't matter if the math is valid if the meaning is misinterpreted.

All of this is an argument in support of a work item that helps standardize these kinds of semantics, especially if simplicity is a core goal.

-j

>  
> Leonard
>  
> *From: *Christopher Allen <ChristopherA@lifewithalacrity.com>
> *Date: *Monday, January 31, 2022 at 3:42 PM
> *To: *daniel.hardman@gmail.com <daniel.hardman@gmail.com>
> *Cc: *Credentials Community Group <public-credentials@w3.org>
> *Subject: *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
>  
>  
>  

--
Joe Andrieu, PMP                                                                              joe@legreq.com
LEGENDARY REQUIREMENTS                                                        +1(805)705-8651
Do what matters.                                                                            http://legreq.com <http://www.legendaryrequirements.com/>