payid-uri.txt

Network Working Group                                        D. Fuelling
Internet-Draft                                                    Ripple
Intended status: Standards Track                           July 17, 2020
Expires: January 18, 2021


                         The 'payid' URI Scheme
                      draft-fuelling-payid-uri-01

Abstract

   This specification defines the 'payid' Uniform Resource Identifier
   (URI) scheme as a way to identify a payment account at a service
   provider.

Feedback

   This specification is a draft proposal, and is part of the PayID
   Protocol [1] initiative.  Feedback related to this document should be
   sent in the form of a Github issue at: https://github.com/payid-
   org/rfcs/issues.

Status of This Memo

   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 18, 2021.

Copyright Notice

   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



Fuelling                Expires January 18, 2021                [Page 1]

Internet-Draft           The 'payid' URI Scheme                July 2020


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Concerns . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Internationalization Concerns . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Various Uniform Resource Identifier (URI) schemes can be used to
   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,
   these identifiers are insufficient because they are typically
   recognized as supporting functionality unique to those schemes.  For
   example, the 'mailto' scheme [RFC6068] 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 concerns such as phishing
   attacks.

   Deploying payment protocols on top of identifiers that are commonly
   employed for other use-cases would likely be a mis-use of those
   identifiers, and could also cause confusion for end-users, among
   other problems.

   Instead, the 'payid' scheme defines an identifier that is intended to
   identify accounts for payment use-cases only.





Fuelling                Expires January 18, 2021                [Page 2]

Internet-Draft           The 'payid' URI Scheme                July 2020


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  Definition

   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, and is designed for payment account identification rather
   than interaction, as discussed in section 1.2.2 of [RFC3986].

   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
   normalization (as specified in sections 6.2.2.1 and 6.2.2.2 of
   [RFC3986]) 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
   "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' 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' URI into its two component parts.

4.  Examples

   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' scheme via the following construction:

    'payid:apollo$wallet.example.com'

   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



Fuelling                Expires January 18, 2021                [Page 3]

Internet-Draft           The 'payid' URI Scheme                July 2020


   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 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 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 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 "payid:alice$bank.example$wallet.example".

   The following example URIs illustrate several variations of PayIDs
   and their common syntax components:

        payid:alice$example.net

        payid:john.doe$example.net

        payid:jane-doe$example.net

5.  Security Concerns

   The 'payid' URI scheme defined in this document does not directly
   enable interaction with a user's payment account and therefore does
   not present 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 allowed by a service provider.

   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, 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.




Fuelling                Expires January 18, 2021                [Page 4]

Internet-Draft           The 'payid' URI Scheme                July 2020


   Due to the use of percent-encoding in 'payid' URIs, implementers
   SHOULD disallow percent-encoded characters or sequences that would
   result in "space", "null", "control", or other characters that are
   otherwise forbidden.

6.  Internationalization Concerns

   As specified in [RFC3986], the 'payid' URI scheme allows any
   character from the Unicode repertoire [UNICODE] encoded as UTF-8
   [RFC3629] and then percent-encoded into valid ASCII [RFC0020].
   Before applying any percent-encoding, an application MUST ensure the
   following about the string that is used as input to the URI-
   construction process:

   o  The 'acctpart' consists only of Unicode code points that conform
      to the PRECIS IdentifierClass specified in [RFC8264].

   o  The 'host' consists only of Unicode code points that conform to
      the rules specified in [RFC5892].

   o  Internationalized domain name (IDN) labels are encoded as A-labels
      [RFC5890].

7.  IANA Considerations

   In accordance with [RFC7595], this section provides the information
   needed to register the 'payid' URI scheme.

   *URI Scheme Name*: payid

   *Status*: permanent

   *URI Scheme Syntax*: The 'payid' URI syntax is defined here in
   Augmented Backus-Naur Form (ABNF) per [RFC5234], borrowing the 'host'
   and 'path' rules from [RFC3986]:

     payidURI   = "payid" ":" acctpart "$" host
     acctpart   = path

   Note that additional rules limit the characters that can be percent-
   encoded in a 'payid' URI.  See "Encoding Considerations" below for
   more details.

   *URI Scheme Semantics*: The 'payid' URI scheme identifies payment
   accounts hosted at payment service providers.  It is used only for
   identification, not interaction.

   *Encoding Considerations*: See Section 6 of this document.



Fuelling                Expires January 18, 2021                [Page 5]

Internet-Draft           The 'payid' URI Scheme                July 2020


   *Applications/Protocols That Use This URI Scheme Name*: The following
   protocols utilize this URI scheme:

     - [PAYID-DISCOVERY][],
     - [PAYID-PROTOCOL][],
     - [VERIFIABLE-PAYID][].

   *Interoperability Considerations*: n/a.

   *Security Considerations*: See Section 6 of this document.

   *Contact*: rfcs@payid.org

   *Author/Change Controller*: TBD.

   *References*: None.

8.  Acknowledgements

   This document was adapted from and heavily influenced by [RFC7565],
   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.

   In addition, the author would like to acknowledge everyone who
   provided feedback and use-cases for this derivative specification.

9.  References

9.1.  Normative References

   [PAYID-DISCOVERY]
              Fuelling, D., "The PayID Discovery Protocol", n.d.,
              <https://tbd.example.com/>.

   [PAYID-PROTOCOL]
              Malhotra, A. and D. Schwartz, "PayID Protocol", n.d.,
              <https://tbd.example.com/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.




Fuelling                Expires January 18, 2021                [Page 6]

Internet-Draft           The 'payid' URI Scheme                July 2020


   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <https://www.rfc-editor.org/info/rfc5892>.

   [RFC8264]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
              Preparation, Enforcement, and Comparison of
              Internationalized Strings in Application Protocols",
              RFC 8264, DOI 10.17487/RFC8264, October 2017,
              <https://www.rfc-editor.org/info/rfc8264>.

   [UNICODE]  Consortium, T. U., "The Unicode Standard", n.d.,
              <http://www.unicode.org/versions/latest/>.

   [VERIFIABLE-PAYID]
              Malhotra, A. and D. Schwartz, "Verifiable PayID Protocol",
              n.d., <https://tbd.example.com/>.

9.2.  Informative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <https://www.rfc-editor.org/info/rfc5988>.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/info/rfc6068>.





Fuelling                Expires January 18, 2021                [Page 7]

Internet-Draft           The 'payid' URI Scheme                July 2020


   [RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
              "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
              2013, <https://www.rfc-editor.org/info/rfc7033>.

   [RFC7565]  Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,
              DOI 10.17487/RFC7565, May 2015,
              <https://www.rfc-editor.org/info/rfc7565>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/info/rfc7595>.

9.3.  URIs

   [1] https://payid.org/

Author's Address

   David Fuelling
   Ripple
   315 Montgomery Street
   San Francisco, CA  94104
   US



























Fuelling                Expires January 18, 2021                [Page 8]