diff --git a/api/json-rpc.mdx b/api/json-rpc.mdx
index d2004ce3..d78265a8 100644
--- a/api/json-rpc.mdx
+++ b/api/json-rpc.mdx
@@ -12,6 +12,14 @@ To interact with soroban-rpc from inside a JavaScript application, use the [Java
When XDR is passed as a parameter or returned, it is always a string encoded using standard base64.
+:::info
+
+Please note that parameter structure must contain named parameters as a by-name
+object, and not as positional arguments as a by-position array. Positional
+arguments as a by-position array will be deprecated in future RPC releases.
+
+:::
+
## Open-RPC Specification
Soroban-RPC provides an [OpenRPC] specification document that can be used to mock, build, and/or validate both server and client software implementations. This document is used to generate all of our [methods] documentation pages. You can view the full [specification document here]. Additionally, you can experiment with this specificaiton document in the [OpenRPC Playground].
diff --git a/api/pagination.mdx b/api/pagination.mdx
index 4a9e0cfa..3ac52f5a 100644
--- a/api/pagination.mdx
+++ b/api/pagination.mdx
@@ -16,7 +16,7 @@ For example, calling a method with pagination parameter set:
```json
{
"jsonrpc": "2.0",
- "Id": "1",
+ "id": "1",
"method": "exampleMethod",
"params": ["other", "arguments", { "cursor": "1234-1", "limit": 100 }]
}
diff --git a/docs/notes.mdx b/docs/notes.mdx
index 53df8fa5..1cdc9fc3 100644
--- a/docs/notes.mdx
+++ b/docs/notes.mdx
@@ -21,6 +21,30 @@ description: Notes and recordings from the Soroban protocol & developers meeting
2. Stellar + Soroban documentation survey
1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962)
+## 2024-02-01
+
+
+
+[Discord agenda thread](https://discord.com/channels/897514728459468821/1201979721211203614)
+
+1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality.
+1. Note that the proposal is not for a new signer type but a host function.
+1. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload.
+1. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets.
+1. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network.
+1. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban.
+1. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates.
+1. It is also costly to bundle decoding with verification in guest.
+1. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well.
+1. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256.
+1. Brief discussion around proposed process for adding of a host function by a non-core dev.
+
## 2024-01-26