minor editorial (#3)

xrpl/caip122.md

@@ -21,20 +21,22 @@ This specification provides the signing algorithm to use, the `type` of the sign
 
 ### Signing Algorithm
 
-XRPL uses the ECDSA [secp256k1][secp256k1] or  EdDSA [Ed25519][Ed25519] signing algorithm for signing and verifying messages depending on the type of the keypair that is being used. A [secp256k1][secp256k1] keypair will be using the [secp256k1][secp256k1] algorithm and a [Ed25519][Ed25519] keypair will be using the [Ed25519][Ed25519] algorithm.
+XRPL uses the ECDSA [secp256k1][] or  EdDSA [Ed25519][] signing algorithm for signing and verifying messages depending on the type of the keypair that is being used. A [secp256k1][] keypair will be using the [secp256k1][] algorithm and a [Ed25519][] keypair will be using the [Ed25519][] algorithm.
 
-Prior to the message being signed using [secp256k1][secp256k1], it needs to be hashed using the SHA-512/2 algorithm. Correspondingly it needs to be converted to bytes prior to signing it using the [Ed25519][Ed25519] algorithm.
+Prior to the message being signed using [secp256k1][], it needs to be hashed using the 512bit digest of the SHA-2 algorithm, commonly referred to as [SHA-512][] and specified in [RFC4634][]. 
+Correspondingly, a message needs to be serialized to bytes prior to signing it with the [Ed25519][] algorithm.
 
 ### Signature Type
 
 We propose using the signature type `xrpl:secp256k1` and `xrpl:ed25519` to refer to the chain and algorithm used uniquely.
 
 ### Signature Creation
 
-The abstract data model must be converted into a string representation in an unambigious format, and then the string converted to the proper format mentioned in [signing algorithm](#signing-algorithm) to be signed over with the proper algorithm.
-Depending on the method used for signatures, this conversion may or may not happen automatically. For example, if using [ripple-keypairs][ripple-keypairs] you need to convert it to a byte representation before signing using [Ed25519][Ed25519] and for [secp256k1][secp256k1] the library will handle hashing and signing.
+The abstract data model must be canonicalized to a string representation in an unambigious format, and then the string serialized to the proper binary format mentioned [above](#signing-algorithm) to be signed over with the proper algorithm. 
+Depending on the method or libraries used for signatures, this conversion may or may not happen automatically. 
+For example, if using [ripple-keypairs][], you will need to convert the key to a byte representation before signing using [Ed25519][] and for [secp256k1][] the library will handle hashing and signing internally.
 
-We propose the following string format, inspired by [EIP-4361][EIP-4361].
+We propose the following string format, inspired by the ABNF in [EIP-4361][].
 
 ```
 ${domain} wants you to sign in with your XRPL account:
@@ -75,15 +77,17 @@ Resources:
 - https://example.com/my-web2-claim.json
 ```
 
-The preceeding example would be hashed to `4beb3f7d5c8bf8deab467de033628274a9053f688f82e0f023cddcb0564cfc9a` prior to being signed using the [secp256k1][secp256k1] algorithm.
+The preceeding example would be hashed to `4beb3f7d5c8bf8deab467de033628274a9053f688f82e0f023cddcb0564cfc9a` prior to being signed using the [secp256k1][] algorithm.
 
-The conversion to bytes prior to signing with [Ed25519][Ed25519] would be:
+The serialization of this string prior to signing with [Ed25519][Ed25519] would produce:
 ```
 736572766963652e6f72672077616e747320796f7520746f207369676e20696e207769746820796f7572205852504c206163636f756e743a0a72344654766e6168625566686531574b32454b354a7a34634e766446765438447a740a0a49206163636570742074686520536572766963654f7267205465726d73206f6620536572766963653a2068747470733a2f2f736572766963652e6f72672f746f730a0a5552493a2068747470733a2f2f736572766963652e6f72672f6c6f67696e0a56657273696f6e3a20310a436861696e2049443a20300a4e6f6e63653a2033323839313735370a4973737565642041743a20323032312d30392d33305431363a32353a32342e3030305a0a5265736f75726365733a0a2d20697066733a2f2f516d653773733341525667787636725871565069696b4d4a3875324e4c676d67737a673133705972444b456f69750a2d2068747470733a2f2f6578616d706c652e636f6d2f6d792d776562322d636c61696d2e6a736f6e
 ```
 ### Signature Verification
 
-Signature verification behaves similarly. We can use standard [secp256k1][secp256k1]/[Ed25519][Ed25519] signature verification. We convert the input message to a bytes representation of the string format, then verify the signature over that using the public key. These verification methods are also available in the [ripple-keypairs][ripple-keypairs] library.
+Signature verification behaves similarly. We can use standard [secp256k1][] or[Ed25519][] signature verification. 
+We convert the input message to a bytes representation of the string format, then verify the signature over that using the public key. 
+Both of these verification methods are available in the [ripple-keypairs][] library.
 
 ## References
 
@@ -94,6 +98,8 @@ Signature verification behaves similarly. We can use standard [secp256k1][secp25
 [ed25519]: https://ed25519.cr.yp.to/
 [secp256k1]: https://en.bitcoin.it/wiki/Secp256k1
 [ripple-keypairs]: https://www.npmjs.com/package/ripple-keypairs
+[SHA-512]: https://csrc.nist.gov/projects/hash-functions
+[RFC4634]: https://datatracker.ietf.org/doc/html/rfc4634
 
 - [EIP-4361][]: Sign-In with Ethereum
 - [CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md): Account ID Specification
@@ -102,3 +108,5 @@ Signature verification behaves similarly. We can use standard [secp256k1][secp25
 - [Ed25519](https://ed25519.cr.yp.to/): Ed25519: high-speed high-security signatures
 - [secp256k1](https://en.bitcoin.it/wiki/Secp256k1): secp256k1 algorithm.
 - [ripple-keypairs](https://www.npmjs.com/package/ripple-keypairs): Ripple keypairs
+- [SHA-512]: NIST.gov overview of SHA-2 family of algorithms
+- [RFC4634]: IETF RFC including the SHA-512 implementation