[SEP-45] Web Authentication for Contract Accounts

[philipliu]

This is the discussion thread for SEP-45: Stellar Web Authentication for Contract Accounts.

[leighmcculloch]

The home_domain_address value matches the Home Domain Address

SEP-45 refers to the server account as the home domain address. Are they the same thing, or behave differently?

The inconsistent naming suggests there's something different.

(Reviewing https://github.com/stellar/stellar-protocol/blob/a7c4dfcbe55ffa1e6d6c825403c5922c83c06a4b/ecosystem/sep-0045.md)

[leighmcculloch]

Why does the args map not include the client domain? It's not included in the list earlier in the document, although it is later in the document in the table. If it's not included, it could mean an authorisation could be used for a different client domain that used the same key. That sounds pretty low risk, but a shared key may be used by an operator running multiple client domains.

(Reviewing https://github.com/stellar/stellar-protocol/blob/a7c4dfcbe55ffa1e6d6c825403c5922c83c06a4b/ecosystem/sep-0045.md)

[leighmcculloch]

(Optional) The Server verifies that the nonce argument is the same across all authorization entries and is unique

The server can optionally include a nonce in the web_auth_verify function arguments. The nonce is a random string generated by the Server and included in the challenge transaction. The nonce is verified when the Client submits signed challenge to the Server. The nonce is used to prevent replay attacks.

Why is the nonce optional? Preventing replay attacks is important, and there should be someway to prevent that. The doc discusses the ledger expiration on the authorisation as one way to limit when replay can occur, but I think it could go into greater detail on the topic of replay discussing how both mechanisms are available and have different levels of effectiveness and preventing replay.

I think there's also value in always including the nonce, in the same way that SEP-10 always includes the random number in the manage data. It keeps the data consistent on the client side so that a client doesn't assume through it's first integration that the field doesn't exist, then at a later point discovers it does through a second integration.

(Reviewing https://github.com/stellar/stellar-protocol/blob/a7c4dfcbe55ffa1e6d6c825403c5922c83c06a4b/ecosystem/sep-0045.md)

[leighmcculloch]

Does this process work where there need to be additional authorisation entries for additional addresses that sign for the contract? I'm not sure this is specifically documented here, but those authorisation entries would probably need to not follow the format and would need to be allowed to be arbitrary, but included in the simulation.

@kalepail at some point was working on a contract that when you asked it to authorise, it requests authorisation of additional addresses, and would fit into this scenario.

(Reviewing https://github.com/stellar/stellar-protocol/blob/a7c4dfcbe55ffa1e6d6c825403c5922c83c06a4b/ecosystem/sep-0045.md)

[leighmcculloch]

If the Server supports client domain verification, the contract can optionally require a signature from the client_domain_address. All other arguments are ignored by the contract.

This paragraph is a little ambiguous. For the address, and home domain, the statement is that require_auth will be called. However for the client domain it says that a signature will be required. If this is intended to mean the same thing that the require_auth function be called, can we change it to say that?

(Reviewing https://github.com/stellar/stellar-protocol/blob/a7c4dfcbe55ffa1e6d6c825403c5922c83c06a4b/ecosystem/sep-0045.md)