SEP-45: Stellar Web Authentication for Contract Accounts

[philipliu]

This adds the initial draft for SEP-0045, which is a proposal for a new API to allow for web authentication for contract accounts. It is based on SEP-10 which is the web authentication API for classic accounts but with modifications to support Soroban's authentication model.

This is based on a previous PR authored by @leighmcculloch.

[github-actions]

This pull request is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

[marcelosalloum]

Should SEP-45 eventually fully replace SEP-10? if so, I believe we should replace occurrences of C-address account(s) with just Account and define what it means at the top of the document. A definition that includes C-address, G-address, and mux accounts would make it flexible from the starting point, WDYT?

[philipliu]

Should SEP-45 eventually fully replace SEP-10? if so, I believe we should replace occurrences of C-address account(s) with just Account and define what it means at the top of the document. A definition that includes C-address, G-address, and mux accounts would make it flexible from the starting point, WDYT?

I think we should initially support C-addresses only. As the ecosystem begins to adopt the protocol, we may uncover issues. By starting with C-addresses only, it will be easier to support G-addresses later, rather than removing support if there are issues.

That being said, I think a definition section is helpful. I will add it.

[JakeUrban]

Aside from my other comments, I didn't see a good place to raise this one in particular so I'm making it here.

The SorobanAuthorizationEntry XDR struct contains a SorobanCredentials struct within it, but we're not using that field in the authorization entries we pass between the client and server. Why is that?

Couldn't we do something like this instead?

• The response to the GET request is a list of authorization entires where:
  • the first one is the entry for the client account, which doesn't have a signature present in its SorobanCredentials struct
  • the second one is the entry for the server account, which has a signature present in its SorobanCredentials struct
  • the third one is optional, depending on whether the client domain account is being verified, and if present, does not have a signature present in its SorobanCredentials struct

In the POST request, the auth entires can include the signatures from the client in their credentials struct.

This way, we're only passing auth entry XDRs back and forth, rather than entires + signatures + credentials.

[philipliu]

the second one is the entry for the server account, which has a signature present in its SorobanCredentials struct

There wouldn't be an authorization entry for the server because the require_auth calls are only on the client address and an optional client domain address, right?

In the POST request, the auth entires can include the signatures from the client in their credentials struct.

This way, we're only passing auth entry XDRs back and forth, rather than entires + signatures + credentials.

Are you suggesting that we include the server signatures in each of the SorboanCredentials arrays?

[JakeUrban]

There wouldn't be an authorization entry for the server because the require_auth calls are only on the client address and an optional client domain address, right?

That depends on the implementation of the server's contract. We could require implementations to require authorization from the client and server (and optionally the client domain's address). The server could simulate the transaction to generate the auth entries, send it to the client, then simulate the entries sent back by the client in enforcing mode to validate the signatures.

Are you suggesting that we include the server signatures in each of the SorboanCredentials arrays?

I'm suggesting we use the credentials struct with the auth entries structs so the API looks like this:

GET <WEB_AUTH_ENDPOINT_SEP0045> Response

{
  "authorization_entries": [
"AAAAAQAAAAHw6CVqzY+dCq3myVJBo1kb3nEGE7oO6obmJeUNvYQ0uiUmvl6zrExtAAAAAAAAAAEAAAAAAAAAAahbWC88MmIccL/85Jd6Myxjq5sHF+2dnq1+2H8osKvEAAAAD3dlYl9hdXRoX3ZlcmlmeQAAAAAHAAAAEgAAAAHw6CVqzY+dCq3myVJBo1kb3nEGE7oO6obmJeUNvYQ0ugAAAA4AAAADMTIzAAAAAA4AAAAObG9jYWxob3N0OjgwODAAAAAAAA4AAAAObG9jYWxob3N0OjgwODAAAAAAAAEAAAABAAAADgAAAAozMDc4NjE1NjE1AAAAAAAA",
"AAAAAQAAAAHw6CVqzY+dCq3myVJBo1kb3nEGE7oO6obmJeUNvYQ0uiUmvl6zrExtAAAAAAAAAAEAAAAAAAAAAahbWC88MmIccL/85Jd6Myxjq5sHF+2dnq1+2H8osKvEAAAAD3dlYl9hdXRoX3ZlcmlmeQAAAAAHAAAAEgAAAAHw6CVqzY+dCq3myVJBo1kb3nEGE7oO6obmJeUNvYQ0ugAAAA4AAAADMTIzAAAAAA4AAAAObG9jYWxob3N0OjgwODAAAAAAAA4AAAAObG9jYWxob3N0OjgwODAAAAAAAAEAAAABAAAADgAAAAozMDc4NjE1NjE1AAAAAAAA"
  ]
}

Where the first entry contains a SorobanCredentials struct with a missing signature field from the client, and the second entry contains a credentials struct with a signature from the server present. That way, the request to the POST <WEB_AUTH_ENDPOINT_SEP0045> would have an identical format, but the first entry would be updated to include the client's signature.

[philipliu]

Implemented your suggestion, @JakeUrban 👍

[leighmcculloch]

👏🏻 Few comments in line.