change EIP to ERC, remove non-relative link (#8)

EIPS/eip-5573.md

@@ -13,11 +13,11 @@ requires: 4361
 
 ## Abstract
 
-[EIP-4361](./eip-4361.md), or Sign-In with Ethereum (SIWE), describes how Ethereum accounts authenticate with off-chain services. This proposal, known as ReCaps, describes a mechanism on top of SIWE to give informed consent to authorize a Relying Party to exercise certain scoped capabilities. How a Relying Party authenticates against the target resource is out of scope for this specification and depends on the implementation of the target resource.
+[ERC-4361](./eip-4361.md), or Sign-In with Ethereum (SIWE), describes how Ethereum accounts authenticate with off-chain services. This proposal, known as ReCaps, describes a mechanism on top of SIWE to give informed consent to authorize a Relying Party to exercise certain scoped capabilities. How a Relying Party authenticates against the target resource is out of scope for this specification and depends on the implementation of the target resource.
 
 ## Motivation
 
-SIWE ReCaps unlock integration of protocols and/or APIs for developers by reducing user friction, onchain state and increasing security by introducing informed consent and deterministic capability objects on top of Sign-In With Ethereum (EIP-4361).
+SIWE ReCaps unlock integration of protocols and/or APIs for developers by reducing user friction, onchain state and increasing security by introducing informed consent and deterministic capability objects on top of Sign-In With Ethereum (ERC-4361).
 
 While SIWE focuses on authenticating the Ethereum account against the service (relying party or SIWE client) initiating the SIWE flow, there is no canonical way for the authenticated Ethereum account to authorize a relying party to interact with a third-party service (resource service) on behalf of the Ethereum account. A relying party may want to interact with another service on behalf of the Ethereum account, for example a service that provides data storage for the Ethereum account. This specification introduces a mechanism that allows the service (or more generally a Relying Party) to combine authentication and authorization of such while preserving security and optimizing UX.
 
@@ -53,7 +53,7 @@ This specification defines the following:
 
 ### ReCap SIWE Extension
 
-A ReCap is an EIP-4361 message following a specific format that allows an Ethereum account to delegate a set of ReCap Capabilities to a Relying Party through informed consent. ReCap Capabilities MUST be represented by the final entry in the `Resources` array of the SIWE message that MUST deterministically translate the ReCap Capability in human-readable form to the `statement` field in the SIWE message using the ReCap Translation Algorithm.
+A ReCap is an ERC-4361 message following a specific format that allows an Ethereum account to delegate a set of ReCap Capabilities to a Relying Party through informed consent. ReCap Capabilities MUST be represented by the final entry in the `Resources` array of the SIWE message that MUST deterministically translate the ReCap Capability in human-readable form to the `statement` field in the SIWE message using the ReCap Translation Algorithm.
 
 The following SIWE message fields are used to further define (or limit) the scope of all ReCap Capabilities:
 
@@ -85,7 +85,7 @@ A ReCap Capability is identified by their ReCap URI that resolves to a ReCap Det
 
 ##### ReCap URI Scheme
 
-A ReCap URI starts with `urn:recap:` followed by `:` and the unpadded base64url-encoded payload of the ReCap Details Object (as according to RFC4648[^fn1]). If present, a Recap URI MUST occupy the final entry of the SIWE resource list.
+A ReCap URI starts with `urn:recap:` followed by `:` and the unpadded base64url-encoded payload of the ReCap Details Object. Note, the term base64url is defined in RFC4648 - Base 64 Encoding with URL and Filename Safe Alphabet. If present, a Recap URI MUST occupy the final entry of the SIWE resource list.
 
 The following is a non-normative example of a ReCap Capability:
 
@@ -245,7 +245,7 @@ After applying the ReCap Translation Algorithm on a given SIWE message that MAY
 
 ```text
 recap-transformed-statement = statement recap-preamble 1*(" " recap-statement-entry ".")
-   ; see EIP-4361 for definition of input-statement
+   ; see ERC-4361 for definition of input-statement
 recap-preamble = "I further authorize the stated URI to perform the following actions on my behalf:"
 recap-statement-entry = "(" number ") " action-namespace ": " 
                           action-name *("," action-name) "for"
@@ -264,7 +264,7 @@ The following algorithm or an algorithm that produces the same output MUST be pe
 Inputs:
 
 - Let `recap-uri` be a ReCap URI, which represents the ReCap Capabilities that are to be encoded in the SIWE message, and which contains a ReCap Details Object which conforms to the ReCap Details Object Schema.
-- [Optional] Let `statement` be the statement field of the input SIWE message conforming to EIP-4361.
+- [Optional] Let `statement` be the statement field of the input SIWE message conforming to ERC-4361.
 Algorithm:
 - Let `recap-transformed-statement` be an empty string value.
 - If `statement` is present, do the following:
@@ -292,10 +292,10 @@ The following algorithm or an algorithm that produces the same output MUST be pe
 
 Inputs:
 
-- Let `recap-siwe` be the input SIWE message conforming to EIP-4361 and this EIP.
-- Let `siwe-signature` be the output of signing `recap-siwe`, as defined in EIP-4361.
+- Let `recap-siwe` be the input SIWE message conforming to ERC-4361 and this EIP.
+- Let `siwe-signature` be the output of signing `recap-siwe`, as defined in ERC-4361.
 Algorithm:
-- Perform EIP-4361 signature verification with `recap-siwe` and `siwe-signature` as inputs.
+- Perform ERC-4361 signature verification with `recap-siwe` and `siwe-signature` as inputs.
 - Let `uri` be the uri field of `recap-siwe`.
 - Let `recap-uri` be a recap URI taken from the last entry of the resources field of `recap-siwe`.
 - Let `recap-transformed-statement` be the result of performing the above `ReCap Translation Algorithm` with `uri` and `recap-uri` as input.
@@ -328,5 +328,3 @@ Resource service implementer's should not consider ReCaps as bearer tokens but i
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).
-
-[^fn1]: [RFC4648 - Base 64 Encoding with URL and Filename Safe Alphabet](https://www.rfc-editor.org/rfc/rfc4648#section-5)