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

ehanoc · 2024-09-27T10:27:00Z

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

Signed-off-by: ehanoc <[email protected]>

k13n

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

k13n · 2024-10-03T12:16:53Z

ARCs/arc-0060.md

+| `data` | `string` | string representing the content to be signed for the specific `Scope`. This can be an encoded JSON object or any other data. It **MUST** be presented to the user in a human-readable format. |
+| `signer` | `bytes` | public key of the signer. This can the public related to an Algorand address or any other Ed25519 public key. |
+| `domain` | `string` | This is the domain requesting the signature. It can be a URL, a DID, or any other identifier. It **MUST** be presented to the user to inform them about the context of the signature. |
+| `requestId` | `string` | It is used to identify the request. It **MUST** be unique for each request. |


How can uniqueness be enforced? Would a wallet have to keep track of past requestIds? That sounds impractical

It's not in reality, but tracking uuids for instance is pretty straightforward.

k13n · 2024-10-03T12:21:00Z

ARCs/arc-0060.md

+| `signer` | `bytes` | public key of the signer. This can the public related to an Algorand address or any other Ed25519 public key. |
+| `domain` | `string` | This is the domain requesting the signature. It can be a URL, a DID, or any other identifier. It **MUST** be presented to the user to inform them about the context of the signature. |
+| `requestId` | `string` | It is used to identify the request. It **MUST** be unique for each request. |
+| `authenticatedData` | `bytes` | It **MUST** include, at least, the `sha256` hash of the `domain` requesting a signture. The wallet **MUST** do an integrity check on the first 32 bytes of `authenticatedData` to match the hash. It **COULD** also include signature counters, network flags or any other unique data to prevent replay attacks or to trick user to sign unrelated data to the scope. The wallet **SHOULD** validate every field in `authenticatedData` before signing. Each `Scope` **MUST** specify if `authenticatedData` should be appended to the hash of the `data` before signing. |


The spec states that wallets SHOULD validate every field in authenticatedData. Given that authenticationData is basically a binary blob, how should a wallet know what to validate? Who defines the binary serialization format of authenticationData? Every individual scope?

Yes; can be scope specific.

The most important are the first 32 bytes that must be the SHA256(domain); also calculated by the wallet; ensures that the domain you are "talking" to is the same one you expect to be "connected" to and sending you data to sign.

All the remaining bytes, are context specific and depending on the scope validations could vary

k13n · 2024-10-03T12:25:38Z

ARCs/arc-0060.md

+
+Summarized signing process for `AUTH` scope:
+```plaintext
+EdDSA(SHA256(data) + SHA256(authenticatedData))


In previous iterations of ARC60 the requirement was stated that it must be possible to sign exactly the input data (e.g., a 32 byte hash). Here the input data is hashed before it is signed, which means it's not possible to sign exactly the input data. Is that requirement no longer necessary? Because that'd be great and would simplify things a lot compared to the past.

One concern that I have is that the resulting hash might still by chance (or by design from a bad actor) contain a Program prefix, which makes the hash a valid logic signature. In the worst case, a logicsig could be crafted that takes control of the user's account.

D13 explained that a future version of this ARC will explicitly prevent Program prefixes, which is great.

Another option is to add a fixed prefix like so: EdDSA('arc60' + SHA256(data) + SHA256(authenticatedData)). Since we already modify the user's input before signing, I don't see a problem with adding a prefix.

"prefix" are a really bad practice in my opinion; prevents any subject to validate signature crafted in algorand wallets / dapps and generically verify them without conforming to our own custom way of doing things.

We can add a check to prevent "Program"; sure. But the chances of you finding a hash with valid 7 bytes (Program) + the remainder of the program are extremely low.

Still, i can add a check to reject "Program"

k13n · 2024-10-03T12:31:40Z

ARCs/arc-0060.md

+| --- | --- | --- |
+| `data` | `string` | string representing the content to be signed for the specific `Scope`. This can be an encoded JSON object or any other data. It **MUST** be presented to the user in a human-readable format. |
+| `signer` | `bytes` | public key of the signer. This can the public related to an Algorand address or any other Ed25519 public key. |
+| `domain` | `string` | This is the domain requesting the signature. It can be a URL, a DID, or any other identifier. It **MUST** be presented to the user to inform them about the context of the signature. |


Must the domain also be matched against WalletConnect, for example? This means, if a user is connected to dapp example.com through her wallet and the dapp asks the wallet to sign a payload, does the wallet have to check that example.com is the domain in StdSignData?

k13n · 2024-10-03T17:40:00Z

ARCs/arc-0060.md

+    const authenticationData: Uint8Array = new Uint8Array(createHash('sha256').update(caip122Request.domain).digest())
+
+    const signData: StdSigData = {
+        data: Buffer.from(JSON.stringify(caip122Request)).toString('base64'),


Is JSON.stringify deterministic? Since JSON objects are unordered, we might have to resort to something like canonical JSON to derive a deterministic byte-array from JSON data suitable for signing.

Great point. Yes, it should be deterministic JSON

Updated @k13n

Signed-off-by: ehanoc <[email protected]>

emg110 · 2024-10-22T13:31:34Z

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.

doc: New ARC60 arb data signing AUTH, random, fido2, caip122

c204990

Signed-off-by: ehanoc <[email protected]>

ehanoc requested a review from SudoWeezy September 27, 2024 10:27

ehanoc self-assigned this Sep 27, 2024

github-actions bot added c-new s-draft t-interface labels Sep 27, 2024

ehanoc and others added 2 commits September 27, 2024 11:37

doc header fix

39e8e8f

Signed-off-by: ehanoc <[email protected]>

Fix linting

e42b6dc

ehanoc changed the title ~~doc: New ARC60 arb data signing AUTH, random, fido2, caip122~~ ARC60 (new) - arb data signing AUTH, random, fido2, caip122 Sep 27, 2024

ehanoc added 3 commits September 27, 2024 16:02

fix formula signature

0680788

Signed-off-by: ehanoc <[email protected]>

Merge branch 'newArc60' of github.com:ehanoc/ARCs into arc60Plus

f4dbe9d

doc cleanup

e4d5eed

Signed-off-by: ehanoc <[email protected]>

ehanoc closed this Sep 29, 2024

ehanoc reopened this Sep 29, 2024

k13n reviewed Oct 3, 2024

View reviewed changes

SudoWeezy mentioned this pull request Oct 7, 2024

ARC-60 Algorand Wallet Structured Data Signing API #284

Closed

Serialize into canonical RFC8785 JSON instead fo stringify

1bfcfde

Signed-off-by: ehanoc <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ehanoc commented Sep 27, 2024 •

edited

Loading

k13n left a comment

k13n Oct 3, 2024

ehanoc Oct 11, 2024

k13n Oct 3, 2024

ehanoc Oct 11, 2024

k13n Oct 3, 2024

ehanoc Oct 11, 2024

k13n Oct 3, 2024

ehanoc Oct 11, 2024

k13n Oct 3, 2024

ehanoc Oct 11, 2024 •

edited

Loading

ehanoc Oct 17, 2024

emg110 commented Oct 22, 2024

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

Are you sure you want to change the base?

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

Conversation

ehanoc commented Sep 27, 2024 • edited Loading

NEW ARC60 Proposal

k13n left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ehanoc Oct 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emg110 commented Oct 22, 2024

ehanoc commented Sep 27, 2024 •

edited

Loading

ehanoc Oct 11, 2024 •

edited

Loading