ARC60 (new) - arb data signing AUTH, random, caip122

[ehanoc]

NEW ARC60 Proposal

This new proposal achieves the following:

• For the purpose of AUTH (at least for now) sign truly arbitrary data without colliding with known data structures (TXs, LSIGs, etc)

• Compatibility with several authentication mechanisms. i.e custom auth mechanisms, FIDO2 / Passkeys / CAIP-122

• Takes into consideration the implementation constraints of hardware wallets

Reference Implementation is available

[k13n]

Thanks @ehanoc. I really hope that this iteration of ARC-60 finally makes it past the finish line!

[emg110]

on custom (Algorand ecosystem internal usage) AUTH scope and custom auth message, this is 100% good to go and flawless, IMHO.
But for other sub-scopes of AUTH (FIDO2, CAIP122,...):

• I think the FIDO2 and WebAuthn scopes need test cases to be verified by standard well-known libraries (which is the case when these scopes are used by developers), e.g. "fido2-lib" and "jsonwebtoken".
• I would like to add to the list above OAuth2 and OIDC under which the token to be signed is actually two base64 strings concatenated by a ".", which has not been seen on the sign function (the second base64 after split by "." will be the payload to sign). For these as well, verification by standard well-known libraries would be nice to be added.

On the other hand, now that we have extension mechanisms in ARCs, may I suggest this ARC-60 to be limited only to custom and random arbitrary data signing (for which it is complete and good to go final IMHO) and then in the future after we add successful verification with standard well-known libraries on each sub-scope, we add those as extensions to this ARC. E.g. for Fido2/WebAuthn, for OAuth2/OIDC, and for simple JWT/JWS.
This way everyone who needs this ARC for simple AUTH scope usage would be satisfied and also the more complex use-cases like those subscopes can enjoy more attention and preparation to be more complete and verified by well-known standard tools as well to make sure the standard fits the requirement.

[SudoWeezy]

The term authenticatedData (in the spec) is referred to as authenticationData (in the Code).

[nullun]

I just had a play with the latest tests after updating my Ledger Flex to 2.3.6. Everything passed as expected, but I'm interested to know how much heavy lifting we expect the ledger-algorand-js library to do, rather than the Ledger device itself.

Is this update expecting to open the flood gates to all kinds of arbitrary data signing, or is ARC60 supposed to be the single standard way for right now? I ask because the Ledger device itself doesn't seem to do much validation on this data. So little infact that I can provide 64 bytes of anything I like and have the Ledger sign it, regardless of what's displayed on the screen.

Below is a proof of concept using ledgerctl to talk to the Ledger. It requests the first account of the Ledger to sign a logicsig that does nothing but int1; return, resulting in a valid signature that can be applied to any delegated logicsig transaction without any further use of the Ledger. The data displayed shows absolutely nothing related to this data, nor is it validated to be correct.

echo -n 80100100b90000000050726f6772616d0b810143803341414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414158585858003030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303000000004DEADC0D37b226c65676974223a747275652c226d616c6963696f7573223a66616c73657d | ledgerctl send -