ARC-0031 : Authentication with Algorand accounts

[deanstef]

This PR introduces a refined version of ARC-0031 Authentication with Algorand accounts and replaces #84. The PR proposes the following changes/improvements to the old one:

• Allowing signing of only random bytes - no transactions;
• Allowing authentication with rekeyed accounts;
• Allowig authentication with multisig accounts.

The ARC also includes a reference implementation (providing a simple authentication process - no rekey/multisig - with MyAlgoWallet) credits to mrcointreau

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[ehanoc]

Just throwing a consideration here. Perhaps we should use challenge instead of nonce.

There are similar auth standards being developed and proposed (DIDAuth, FIDO U2F / HID)

Might be a small thing, but operating close to auth standards might be useful with integrations, complaince, etc.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[aldur]

Minimum recommended length?

[0x9090]

15 characters minimum, which must include upper case and lower case letters and numbers. Nonce checking must be case sensitive. Nonce must be derived from a cryptographically strong PRNG. This would give a search space of 7.82 x 10^26 making it impossible to guess

[ultrade-dev]

Hope this will get done soon. We definitely could use it.

[scholtz]

Hope this will get done soon. We definitely could use it.

How do you see usage of ARC14? Arc14 does not require usage of signdata, but is using the txn.sign to authenticate person, so that it can be used now with any wallet connect capable wallets.

[emg110]

The living web standard, WebAuthn (Web Authentication API) supports the ed25519 elliptic curve and is also verifiable using other web standard API (Web Crypto through Crypto.subtle methods) or TweetNACL if that's your thing!
The process is clear and standard and also comprehensive and extendible (WebAuthn Extension points)! It is some how a superset of many standards now: FIDO Alliance, U2F, PassKey, Passwordless and many other unified under or derived from WebAuthn somehow (although backward compatibility with some much older versions is Iffy)!

The living standard, WebAuthn (Web Authentication API) supports the ed25519 elliptic curve and is also verifiable using other web standard API (Web Crypto through Crypto.subtle methods) or TweetNACL if that's your thing!
The process is clear and standard is comprehensive and extendible (WebAuthn Extension points)!

Very nice extensions like appId extension, User Verification Method extension and Credentials properties extension make it possible to add what ever data, metadata or procedure elements needed under Algorand scope and still comply to standard!

It has separated the two major concerns: Attestation and Assertation so that devs are free to implement limitless scenarios of identity and AAA using WebAuthn.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

https://www.w3.org/TR/webauthn-2/#sctn-intro

https://www.iana.org/assignments/cose/cose.xhtml#algorithms

Just a humble suggestion, that's all!

[emg110]

I humbly believe that using the composability of WebAuthn and Algorand (ASCs, ASAs and ATs plus Accounts) with a little team effort, a very well-structured identity and AAA framework can emerge that using federated identities can transparently and natively bridge Algorand blockchain identities to Web 2.0 identities via OAuth, Auth0, SAML,...
and also easy to integrate and comply with DiD standards of Web!

[emg110]

Given the status of ARC60 and also the fact that essence of this ARC (the arbitrary data signing and aside from process and flow) are there and in order to avoid redundant standardization, and also given the ARC80 which includes exactly the neccessary process and flow which complements ARC60, I propose to retire this ARC in favor of ARC60+ARC80 and given the fact that it is a bit too opinionated to be used with known third party Authentication frameworks like Oauth and OIDC (on top of Oauth) out of the box.
I also suggest all discussed best practices (rekeyed accounts, multisig support,...) to be moved from this to ARC60 to make it most efficient and comprehensive.
Briefly : ARC60 + ARC80 make a complete solution for authentication on Algorand which is 100% compatible with all known web standard frameworks and IETF RFCs.