This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on January 8, 2021.
+
This Internet-Draft will expire on February 7, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Interactive PayID Discovery is broken up into a series of steps, each of which is defined in more detail below. The following is a visual representation of the protocol flow:
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on January 8, 2021.
+
This Internet-Draft will expire on February 7, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -675,7 +675,7 @@
The response body for application/* + json is a JSON object with the following name/value pairs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on January 8, 2021.
+
This Internet-Draft will expire on February 7, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -506,9 +506,9 @@
The following example URIs illustrate several variations of PayIDs and their common syntax components:
diff --git a/dist/spec/payid-uri.txt b/dist/spec/payid-uri.txt
index 6fa0263..2427986 100644
--- a/dist/spec/payid-uri.txt
+++ b/dist/spec/payid-uri.txt
@@ -4,8 +4,8 @@
Network Working Group D. Fuelling
Internet-Draft Ripple
-Intended status: Standards Track July 07, 2020
-Expires: January 8, 2021
+Intended status: Standards Track August 06, 2020
+Expires: February 7, 2021
The 'payid' URI Scheme
@@ -39,7 +39,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on January 8, 2021.
+ This Internet-Draft will expire on February 7, 2021.
Copyright Notice
@@ -53,9 +53,9 @@ Copyright Notice
-Fuelling Expires January 8, 2021 [Page 1]
+Fuelling Expires February 7, 2021 [Page 1]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
carefully, as they describe your rights and restrictions with respect
@@ -109,9 +109,9 @@ Table of Contents
-Fuelling Expires January 8, 2021 [Page 2]
+Fuelling Expires February 7, 2021 [Page 2]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
2. Terminology
@@ -165,9 +165,9 @@ Internet-Draft The 'payid' URI Scheme July 2020
-Fuelling Expires January 8, 2021 [Page 3]
+Fuelling Expires February 7, 2021 [Page 3]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
address "alice@example.net" might register with a wallet website
@@ -221,9 +221,9 @@ Internet-Draft The 'payid' URI Scheme July 2020
-Fuelling Expires January 8, 2021 [Page 4]
+Fuelling Expires February 7, 2021 [Page 4]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
Due to the use of percent-encoding in 'payid' URIs, implementers
@@ -277,9 +277,9 @@ Internet-Draft The 'payid' URI Scheme July 2020
-Fuelling Expires January 8, 2021 [Page 5]
+Fuelling Expires February 7, 2021 [Page 5]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
*Applications/Protocols That Use This URI Scheme Name*: The following
@@ -333,9 +333,9 @@ Internet-Draft The 'payid' URI Scheme July 2020
-Fuelling Expires January 8, 2021 [Page 6]
+Fuelling Expires February 7, 2021 [Page 6]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
@@ -389,9 +389,9 @@ Internet-Draft The 'payid' URI Scheme July 2020
-Fuelling Expires January 8, 2021 [Page 7]
+Fuelling Expires February 7, 2021 [Page 7]
-Internet-Draft The 'payid' URI Scheme July 2020
+Internet-Draft The 'payid' URI Scheme August 2020
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
@@ -445,4 +445,4 @@ Author's Address
-Fuelling Expires January 8, 2021 [Page 8]
+Fuelling Expires February 7, 2021 [Page 8]
diff --git a/dist/spec/payid-uri.xml b/dist/spec/payid-uri.xml
index dd67db4..9f8b60a 100644
--- a/dist/spec/payid-uri.xml
+++ b/dist/spec/payid-uri.xml
@@ -1,6 +1,6 @@
-
+
@@ -41,7 +41,7 @@
-
+
security
@@ -50,7 +50,7 @@
-This specification defines the 'payid' Uniform Resource Identifier (URI)
+This specification defines the 'payid' Uniform Resource Identifier (URI)
scheme as a way to identify a payment account at a service provider.
@@ -61,9 +61,9 @@
-This specification is a draft proposal, and is part of the
- PayID Protocol initiative. Feedback related to this
- document should be sent in the form of a Github issue at:
+This specification is a draft proposal, and is part of the
+ PayID Protocol initiative. Feedback related to this
+ document should be sent in the form of a Github issue at:
https://github.com/payid-org/rfcs/issues.
@@ -77,14 +77,14 @@
Various Uniform Resource Identifier (URI) schemes can be used to
- identify a user account at a service provider. However, no standard
+ identify a user account at a service provider. However, no standard
identifier exists to identify a user's payment account at a service
provider.
-While popular URIs could be re-used as payment account identifiers,
+While popular URIs could be re-used as payment account identifiers,
these identifiers are insufficient because they are typically recognized
as supporting functionality unique to those schemes. For example, the
- 'mailto' scheme is broadly deployed for messaging. Re-using
+ 'mailto' scheme is broadly deployed for messaging. Re-using
this identifier for payments would likely cause confusion because one
desirable quality of a payment account identifier is that it expressly
does not support messaging, in order to avoid spam and/or other security
@@ -110,61 +110,61 @@
The syntax of the 'payid' URI scheme is defined in Section 7 of this
document.
-A 'payid' URI identifies a payment account hosted at a service provider,
+A 'payid' URI identifies a payment account hosted at a service provider,
and is designed for payment account identification rather than
interaction, as discussed in section 1.2.2 of .
-A 'payid' URI is constructed by taking a user's payment account identifier
- at a service provider and using that value as the 'acctpart'. The 'host'
+A 'payid' URI is constructed by taking a user's payment account identifier
+ at a service provider and using that value as the 'acctpart'. The 'host'
portion is then set to the DNS domain name of the service provider that
provides the 'payid'.
-To compare two 'payid' URIs, case normalization and percent-encoding
+To compare two 'payid' URIs, case normalization and percent-encoding
normalization (as specified in sections 6.2.2.1 and 6.2.2.2 of
) MUST be employed before performing any comparison.In addition, a 'payid' is case-insensitive and therefore should be
- normalized to lowercase. For example, the URI
- "PAYID:aLICE$www.EXAMPLE.com" is equivalent to
+ normalized to lowercase. For example, the URI
+ "PAYID:aLICE$www.EXAMPLE.com" is equivalent to
"payid:alice$www.example.com".Note that both the 'acctpart' and 'host' components of a 'payid' may
- contain one or more dollar-sign characters. However, because a 'host'
+ contain one or more dollar-sign characters. However, because a 'host'
SHOULD also be a valid DNS domain, that portion of a 'payid' will
generally not include a dollar-sign. Therefore, applications SHOULD
- always search for the last dollar-sign when attempting to parse a 'payid'
+ always search for the last dollar-sign when attempting to parse a 'payid'
URI into its two component parts.As an example, a user with an account name of "apollo" at a wallet
- service "wallet.example.com" can be identified by a URI using the 'payid'
+ service "wallet.example.com" can be identified by a URI using the 'payid'
scheme via the following construction:
-One possible PayID scenario is for an account to be registered with a
- payment service provider using an identifier that is associated with some
- other service provider. For example, a user with the email address
+One possible PayID scenario is for an account to be registered with a
+ payment service provider using an identifier that is associated with some
+ other service provider. For example, a user with the email address
"alice@example.net" might register with a wallet website whose domain
name is "wallet.example.com". In order to facilitate payments to/from
- Alice, the wallet service provider might offer Alice a PayID using Alice's
+ Alice, the wallet service provider might offer Alice a PayID using Alice's
email address (though using an email address as a PayID is not
recommended). In order to use Alice's email address as the 'acctpart' of
- the 'payid' URI, no percent-encoding is necessary because the 'acctpart'
- portion of a PayID allows for at-signs. Thus, the provisioned 'payid' URI
+ the 'payid' URI, no percent-encoding is necessary because the 'acctpart'
+ portion of a PayID allows for at-signs. Thus, the provisioned 'payid' URI
for Alice would be "payid:alice@example.net$shoppingsite.example".Another possible scenario is where a payment service provider (e.g., a
digital wallet) provides its users with PayIDs that are associated with
the PayIDs of another service provider. For example, a user with the
- PayID "alice$bank.example.net" might register with a wallet website whose
+ PayID "alice$bank.example.net" might register with a wallet website whose
domain name is "wallet.example.net". In order to use the bank's PayID
- as the acctpart of the wallet's 'payid' URI, no percent-encoding is
- necessary because the 'acctpart' portion of a PayID allows for
- dollar-signs. Therefore, the resulting 'payid' URI would be
+ as the acctpart of the wallet's 'payid' URI, no percent-encoding is
+ necessary because the 'acctpart' portion of a PayID allows for
+ dollar-signs. Therefore, the resulting 'payid' URI would be
"payid:alice$bank.example$wallet.example".The following example URIs illustrate several variations of PayIDs and
@@ -172,9 +172,9 @@
@@ -185,13 +185,13 @@
any direct security concerns.However, a 'payid' URI indicates existence of a payment account, so
- care should be taken to properly secure any payment account interactions
+ care should be taken to properly secure any payment account interactions
allowed by a service provider.
-In addition, service providers and users should consider whether an
+In addition, service providers and users should consider whether an
attacker might be able to derive or infer other identifiers correlating
- to the user of any particular PayID. For example, replacing the $
- character in a PayID with an @ sign SHOULD NOT yield a 'mailto' URI,
+ to the user of any particular PayID. For example, replacing the $
+ character in a PayID with an @ sign SHOULD NOT yield a 'mailto' URI,
when possible. In addition, care should be taken when the 'acctpart' of
a PayID corresponds to a user's email address (in part or in whole) as this
might allow an attacker to execute phishing attacks or send spam messages.
@@ -228,7 +228,7 @@ rules specified in .Status: permanentURI Scheme Syntax: The 'payid' URI syntax is defined here in Augmented
- Backus-Naur Form (ABNF) per , borrowing the 'host' and 'path'
+ Backus-Naur Form (ABNF) per , borrowing the 'host' and 'path'
rules from :.
percent-encoded in a 'payid' URI. See "Encoding Considerations" below for
more details.
-URI Scheme Semantics: The 'payid' URI scheme identifies payment
+URI Scheme Semantics: The 'payid' URI scheme identifies payment
accounts hosted at payment service providers. It is used only for
identification, not interaction.
@@ -250,7 +250,7 @@ rules specified in .
protocols utilize this URI scheme:
@@ -267,7 +267,7 @@ rules specified in .
-This document was adapted from and heavily influenced by ,
+This document was adapted from and heavily influenced by ,
modifying it (in some cases only slightly) for a payments use-case. The
author would like to acknowledge the contributions of everyone who worked
on that and related specifications.
@@ -354,91 +354,90 @@ rules specified in .
diff --git a/dist/spec/self-sov-verifiable-payid-protocol.html b/dist/spec/self-sov-verifiable-payid-protocol.html
index ed2cbc3..6611d78 100644
--- a/dist/spec/self-sov-verifiable-payid-protocol.html
+++ b/dist/spec/self-sov-verifiable-payid-protocol.html
@@ -402,14 +402,14 @@
-
+
-
-
-
+
+
+
@@ -431,8 +431,8 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on February 5, 2021.
+
This Internet-Draft will expire on February 7, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on January 8, 2021.
+
This Internet-Draft will expire on February 7, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.