[Spec] Auth Multi Account

[flypaper0]

Description

To support multi-account feature SDK should not store Account object. Account will be passed with respond method.

This makes problematic to generate finalised SIWE message for clients. I suggest to open SIWEMessageFormatter interface to allow this:

protocol SIWEMessageFormatting {
    func formatMessage(from payload: PayloadParams, address: String) -> String?
}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
walletconnect-docs	✅ Ready (Inspect)	Visit Preview	Dec 6, 2022 at 8:35AM (UTC)

[jakubuid]

What is the Account made of?

[flypaper0]

Account removed from sdk initializer and moved here. We can call it iss. Account object is a wrapper around CAIP-10 string

[jakubuid]

I suggest not changing the name and sticking to the iss. In general, not all sdks introduced the Account so from the spec perspective it's more readable having iss

[jakubuid]

Description

To support multi-account feature SDK should not store Account object. Account will be passed with respond method.

This makes problematic to generate finalised SIWE message for clients. I suggest to open SIWEMessageFormatter interface to allow this:

protocol SIWEMessageFormatting {
    func formatMessage(from payload: PayloadParams, address: String) -> String?
}

• What about adding formatMessage(from payload: PayloadParams, address: String) -> String? to the AuthSDK?
• Why the return type is nullable?

[flypaper0]

Description

To support multi-account feature SDK should not store Account object. Account will be passed with respond method.
This makes problematic to generate finalised SIWE message for clients. I suggest to open SIWEMessageFormatter interface to allow this:

protocol SIWEMessageFormatting {
    func formatMessage(from payload: PayloadParams, address: String) -> String?
}

• What about adding formatMessage(from payload: PayloadParams, address: String) -> String? to the AuthSDK?
• Why the return type is nullable?

If payload chainId is invalid string we returns nil

[bkrem]

What about adding formatMessage(from payload: PayloadParams, address: String) -> String? to the AuthSDK?

@jakobuid @flypaper0 this would be an internal util though wouldn't it, not part of the public API? Is there a case where this needs to be called from the top-level by an implementing dev?

EDIT: ah hold on I see now, so it gets bubbled up to top level via on("auth_request", ...), formatted with whatever account by the responder and then the responder adds that account to respond.

So yeah on board with Jakob's proposal to just make this part of the public API then rather than an appendix util.

[jakubuid]

What about adding formatMessage(from payload: PayloadParams, address: String) -> String? to the AuthSDK?

@jakobuid @flypaper0 this would be an internal util though wouldn't it, not part of the public API? Is there a case where this needs to be called from the top-level by an implementing dev?

EDIT: ah hold on I see now, so it gets bubbled up to top level via on("auth_request", ...), formatted with whatever account by the responder and then the responder adds that account to respond.

So yeah on board with Jakob's proposal to just make this part of the public API then rather than an appendix util.

Yup, because we have access to the iss/address only when it's passed by a dev, so when on("auth_request") is triggered, a dev calls formatMessage with payloadParams and address. It returns a SIWE that is displayed on the device. Then by pressing respond they pass the same iss/address and we send the signature.

[jakubuid]

@flypaper0 let's add formatMessage method to AuthSDK