A Uniform Resource Name (URN) Namespace for Transaction Identifiers

Transaction identifiers are used throughout modern commerce to memorialize particular economic events. This document describes a Uniform Resource Name (URN) namespace that contains transaction identifiers.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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 document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 BSD License.

1. Introduction

In modern commerce, parties typically record unique transaction identifiers (TIDs) to memorialize economic transactions. The goal of this namespace is to provide a uniform syntax for embedding such identifiers in Uniform Resource Identifiers (URIs), specifically Uniform Resource Names (URNs).

A transaction identifier is any identifier for an economic transaction where goods or services are exchanged. Examples of such transactions include orders for books and transfers of money for any purpose, including gift transfers.

A transaction identifier is issued by someone who oversees the transaction. Banks, credit card issuers, merchants, governments, and individuals are all capable of issuing transaction identifiers. Transaction identifiers are guaranteed to be unique to the extent that the transaction overseer guarantees them to be unique. For example, PayPal generates a unique TransactionID for every payment in PayPal's system. Although a TID must represent some sort of exchange (or anticipation or memorialization of exchange) of goods or services, this specification does not further limit what a TID represents. A TID can represent an order, invoice, or actual monetary transfer. A TID can represent a failed transaction, such as a credit card authorization request that was subsequently declined. A TID can even represent a group of transactions, such as "an order for books from five booksellers" where the booksellers were paid separately and three of the five books were returned for refunds. Simply put, a TID is a key to an entry in a ledger for the transfer of goods and services.

Using this syntax, any protocol that uses URIs can unambiguously refer to a particular transaction. For example, an authorization protocol in which access to a resource (like a digital download of a book or movie) is requested can name the payment transaction associated with the access. The authorization server can then look up the transaction in a database, see that the transaction was completed successfully, and grant access to the resource.

1.1. Requirements Language

2. TID Syntax

The Namespace Specific String (NSS) portion of the identifiers has the following ABNF specification:

The org-nid identifies the entity responsible for issuing transaction IDs. This entity is called the "transaction provider" in this specification. Considerations for what an appropriate org-nid is, and how one gets assigned, are discussed below.

The tss is the Transaction Specific String. In most cases, the TSS is simply a character string that contains the same characters of the transaction identifier that the transaction provider itself provided.

2.1. Integral TIDs

If a transaction ID is integral, the Transaction Specific String SHOULD be represented in the TID URN as the ASCII decimal encoding of the number in base-10 in the fewest possible characters. Whether a transaction ID is integral depends entirely on the transaction provider. Note that a transaction provider might issue transaction identifiers that look like integral numbers, but are really characters, not integers. For example, a provider that issues transaction identifiers '123456' and '123410' may or may not be treating the characters as numbers. If the provider issued a transaction identifier '099999', that identifier is a clue that the identifiers should all be treated as characters, not numbers. Treating the identifier as an integer enables localization processing, because a user agent that shows the TID URN to the user can translate an integral TSS into displayable characters that are appropriate to the user's language. This transformation would not be safe or accurate if the TSS is not demonstrably an integer.

2.2. Typed TIDs

Some organizations issue multiple identifiers for different purposes. As common examples, a merchant may provide an "order number", an "invoice number", and a "receipt number", all for the same transaction or series of related transactions. In these cases, it may be necessary to distinguish these different types if identifiers would collide with one another.

The type production is the type of transaction identifier, as defined by the entity responsible for issuing Transaction IDs.

Because ":" delimits the type from the Transaction Specific String, ":" has a reserved purpose in this scheme. If a TSS includes the colon ":" as part of the transaction identifier, it MUST be percent-encoded. Similarly, ":" MUST be percent-encoded if used in type or org-nid. This restriction is consistent with RFC 3986 and RFC 2141.

typed-tss MUST NOT be used when the simpler tss-only form can be used. For example, if "NewEgg" draws from the same ID generator when generating Order Numbers and Invoice Numbers, the numbers are unique and there is no possibility of collision between the two types. These numbers are not "order numbers" and "invoice numbers"--they are simply "document numbers". Therefore, the transaction identifier for such a store would not include the "order" or "invoice" types.

Similarly, the type may be built in to the transaction identifier. An Apple, Inc. order number can be a Web Order Number such as "W12345678", or a Sales Order Number, such as "7123456789". Web Order Numbers are completely disjoint from Sales Order Numbers: a Web Order Number starts with "W" and has 8 digits; a Sales Order Number has 10 digits. Because these two are completely disjoint, the TID URN for these two transaction IDs would not use the typed-tss form.

This requirement facilities TID URN comparison. A rule of thumb: if the issuing entity can find a record for the transaction with a single text search box, tss (not typed-tss) is sufficient to record the transaction identifier.

2.2.1. Unicode in TID

A TID URN can contain any Unicode character in accordance with IRI syntax. However, the TSS portion SHOULD be limited to URI characters, especially since transaction identifiers are usually combinations of numbers, letters, and occasional punctuation like "-". The type in typed-tss SHOULD be limited to the unreserved characters of an URI, and SHOULD be all-lowercase. If an internationalized domain name is used in reg-name / ireg-name, the domain name should remain in Unicode or UTF-8 percent-encoded form, and should not be processed with ToASCII according to IDNA. Resolution of a TID URN to actual data--which may require a DNS lookup--is a separate matter from what the transaction itself is named--which does not require a DNS lookup.

3. Transaction Provider Name (org-nid) Assignment

This document provides one main proposal and two alternatives, inviting the Internet community to provide comment and feedback.

3.1. Main Proposal: IANA PEN Registry

Under this proposal, an organization that needs to be identified under this scheme will have a IANA Private Enterprise Number (PEN) registered for it. The registry is first-come, first-served. Any entity with a need can register for itself or for another entity, but MUST check before registering for a redundant PEN. In this case, the NSS has the syntax:

Per the ABNF above, org-nid identifies the organization by its PEN. The org-nid MAY include an optional informative identifier, the org-name-nid, but MUST include the org-pen, which is the PEN assigned by IANA. The org-pen is a ASCII decimal-encoded digit using the fewest possible characters. For example, for a PEN of 3, "3" is acceptable; "0003" is not.

When comparing TID URNs, comparison of the org-nid is done strictly on the org-pen; org-name-nid is ignored during comparison.

Nevertheless, using the same org-name-nid between different implementations is strongly desirable, because that facilitates accurate results by non TID URN-aware comparators. Implementations and authors SHOULD use the following algorithm to determine the org-name-nid.

First, if the entity has a known website, determine the Unicode characters of the website's primary domain registration, excluding generic or country code TLD-like components. For example, for a site "www.example.com", omit "www" (because it is not a domain registration), and omit "com" (because it is a generic TLD). For a site "example.co.uk", omit "co" and "uk": "uk" is a cc TLD, and "co" is a generic TLD-like component. Use the resulting string as the org-name-nid.

If no domain name can be ascertained for the entity identified by the PEN, determine the current Organization name registred in the IANA PEN Registry. Remove all corporate designators such as ", Inc." and " GmbH". Take the resulting string and encode it directly, preserving case, as the org-name-nid.

Percent-encoding of reserved characters is REQUIRED when they would conflict with the reserved purposes of this specification (namely "@" as the PEN separator, and ":" as the separator between org-nid and tss / typed-tss), and STRONGLY RECOMMENDED otherwise. Many Organization names in the PEN Registry contain spaces, for example: spaces ought to be percent-encoded using "%20" since a space is not a canonically valid URI or IRI character.

If no org-name-nid can be determined using the above two methods, an implementation or author MAY omit the org-name-nid entirely, using org-pen alone, or MAY use an org-name-nid of his, her, or its choosing. If the implementation or author chooses an org-name-nid, however, the implementation or author SHOULD make reasonable attempts to confirm that the org-name-nid bears a reasonable resemblance to the entity identified by the org-pen.

3.2. Alternative 1: First-Come, First-Served IANA Registration

Under this proposal, IANA would set up a registry for transaction providers under this TID URN. The registry is first-come, first-served. Any entity with a need can register for that entity.

For each registration, IANA shall collect: a) the requested org-nid, b) the name of the entity, c) the contact information for a responsible person at the entity (or the person, if a natural person), and d) any initial type identifiers. IANA may collection an optional description from the entity of the TSS.

No two organizations can ever be assigned the same org-nid: IANA will check at the time of the request and will refuse registration if the org-nid has already been assigned. (TBD: what if an entity requests multiple org-nids?)

It is desirable, however, for entities other than the named entity to request an assignment. Specifically, an application developer may accept transactions from "visa" and from "smalltimepayments", but "smalltimepayments" is not yet assigned an org-nid. To serve this case, any entity with a need can register for another entity, but additional safeguards SHALL be used to prevent spurious or defamatory registrations.

When the requesting entity is not the registering entity, IANA shall also collect a statement from the requesting entity stating that the information in the application is true and correct to the best of the requestor's ability (TBD: and other requirements).

3.3. Alternative 2: DNS Registration

Under this proposal, the primary DNS name of the entity shall be used for the org-nid. Using the DNS name solves the problem of using short and recognizable names for common transaction providers. Furthermore, someone who wishes to design a TID URN resolution protocol will have a much easier time mapping the URN to a resource when the DNS name is embedded in the resource. Any problems with who-owns-what org-nid are explicitly subordinated to the DNS.

The primary use of a TID URN is to identify purchases in a uniform manner that can be resolved on the Internet. Therefore, virtually all of the entities that would have org-nids would have DNS names, and will keep the same name as long as they are conducting business. Second, although DNS names change hands, DNS names are centrally managed through the ICANN accreditation process and are unique to a registrant of record for any given point in time. In other words, no two entities can own the same DNS name at the same time. The registrant of record at any given time is an historical fact.

In practice, TID URNs will always be used in contexts where the time that the TID URN was produced is ascertainable. For example, the TID URN will appear in an e-mail invoice of a camera that the recipient purchased, or in a database record that indicates that a camera shipped out on a date because of a payment associated with <urn:tid:paypal.com:12345>. Furthermore, TID URNs in general have great utility to e-commerce, but a specific TID URN is only useful to parties in privity with the parties that executed the transaction. Only the person who bought the camera and the person who sells the camera really care about the TID URN. The transaction provider (when different from the seller) does not care because presumably the transaction provider can distinguish its own IDs from IDs of others. If the person who bought the camera later wants to sell the camera, he might provide the URN to public passers-by as evidence that he bought the camera, but anyone who actually relies on the URN to buy the used camera will be in privity with the seller.

A single TID URN also has limited utility over time, because nobody will care that a camera was purchased several years down the line (after taxes and other accounting are dealt with). This use period corresponds roughly to the lifetime of a domain name.

3.3.1. Alternative 2.1: DNS Registration + Time

At least two approaches may be considered for those who consider a raw domain name to be insufficiently vague. The first is to explicitly combine the TID URN with a time in a manner that is external to the TID URN, but is internal to the URI (i.e., not inferred from the context in which the TID URN appears). Larry Mainster's "tdb" URI scheme (Masinter, L., “The "tdb" URI scheme: denoting described resources,” July 2009.) [I‑D.masinter‑dated‑uri] presents such an option.

The second option is to explicitly include a time reference in a TID URN itself. In that case, the syntax would be agumented to:

The org-date-nid production specifies the DNS registration record on the last instant of that day in UTC (or IAT). It does not refer to the date of the transaction, and no information about the transaction should be gleaned from it. In any event, attempting to date the transaction would raise difficult and unnecessary semantic issues about what the time means, as a transaction can be ongoing (ordered but not shipped) or be a grouping of related transactions.

Including the time complicates the issue of equivalence in TID URNs. 2009, 200912, and 20091231 are equivalent. TID URNs that have different transaction specific strings are surely not equivalent. However, the URNs urn:tid:paypal.com@2008:12345 and urn:tid:paypal.com@2009:12345 may or may not be equivalent. For an in-depth equivalence check to be performed, the checker would have to obtain the DNS records for paypal.com at the end of 2008 and 2009. Perhaps this is an acceptable tradeoff if one must sacrifice being concise at the altar of "uniqueness": since a TID is only generated once, the org-date-nid has no particular reason to be updated after 2008 anyway.

Perhaps a better solution is to treat the date as the first instant of that day in UTC (or IAT), rather than the last instant, and to say that a receiver of a TID URN SHOULD transform a received TID URN in one of the following ways:

That leads to a somewhat more natural reading of the number, and arguably gives a more explicit hint about when the transaction identifier was created or recognized (which should lead to better matches without historical DNS lookups). In particular, TID URNs that are marked with later DNS records, but are equivalent to ones marked with earlier DNS records, will tend to converge to the earliest recorded date. That date is bounded by the date at which the transaction identifier came into existence, because there should never be a given TID URN that has a DNS record date less than the date, month, or year that the TID URN was created.

4. Specification Template

Namespace ID:

   "tid"

Registration Information:

   Version 1
   Date: 2001-08-01

Declaraed registrant of the namespace:

   TBD

Declaration of syntactic structures:

   The structure of the Namespace Specific String is provided
   above.

Relevant ancillary documentation:

   TBD

Identifier uniqueness considerations:

   The Transaction Specific String and optional type
   are assigned by transaction provider. The transaction provider
   gurantees uniqueness of these identifiers.
   The org-nid identifies the entity responsible for issuing
   transaction identifiers. The degree to which this org-nid is
   unique is discussed further in this document.

Identifier persistence considerations:

   A TID records an historical fact, namely, that the
   transaction provider generated a unique TID
   for an actual or contemplated transaction.
   Resolution of the TID to a particular repesentation
   of that resource, however, is a separate matter
   left to the transaction provider.
   For example, a TID representing a credit card reference
   number may resolve to a credit card statement from the
   issuing bank with the transaction details highlighted.
   The transaction provider might keep this information
   downloadable for some number of years (say, five years),
   and then take it offline. The TID remains valid as
   an identifier of the historical fact; it also remains
   valid as an instruction to an archivist to dig up
   the transaction from paper storage in a vast warehouse.
   However, the TID will no longer resolve to an online resource.

Process of identifiers assignment:

   The transaction provider generates transaction identifiers
   for actual or contemplated economic transactions.
   Names of transaction providers are discussed further below.

Process for identifier resolution:

   Resolution is controlled by the named transaction providers.
   Identifying the services that the transaction providers provide
   is TBD (or outside the scope of this specification).

Rules for Lexical Equivalence:

   No special consideration.

Conformance with URN Syntax:

   No special consideration.

Validation mechanism:

   No special consideration.

Scope:

   Global.

5. IANA Considerations

6. Security Considerations

The existence and resolution of a TID URN can disclose private facts when stored in context. For example, a protocol that includes the TID URN urn:tid:bookstore.com:12345 may imply that the client user shops at bookstore.com; when the URN is urn:tid:adultbookstore.com:12345, one might infer that the client user purchased adult products at bookstore.com. (Note that if the client user purchased adult products at adult.bookstore.com, the top-level DNS record is bookstore.com, not adult.bookstore.com. This example only works when bookstore.com maintains separate DNS records for its branches.) Other than this aspect, TID URNs do not present significant security risks because they only name past transactions (or transactions already underway). TID URNs do not embed authorization information. Resolving a TID URN only looks up the transaction; it is not intended to cause a new transaction to occur, or to change the transaction in any way.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2141]	Moats, R., “URN Syntax,” RFC 2141, May 1997 (TXT, HTML, XML).
[RFC3406]	Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” BCP 66, RFC 3406, October 2002 (TXT).
[RFC3986]	Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).

[I-D.masinter-dated-uri]	Masinter, L., “The "tdb" URI scheme: denoting described resources,” draft-masinter-dated-uri-06 (work in progress), July 2009 (TXT, PDF).
[ISO.8601.1988]	International Organization for Standardization, “Data elements and interchange formats - Information interchange - Representation of dates and times,” ISO Standard 8601, June 1988.
[RFC3187]	Hakala, J. and H. Walravens, “Using International Standard Book Numbers as Uniform Resource Names,” RFC 3187, October 2001 (TXT).
[RFC3490]	Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).
[RFC3615]	Gustin, J. and A. Goyens, “A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging,” RFC 3615, September 2003 (TXT).

	Sean Leonard
	Penango, Inc.
	1215 K Street
	17th Floor
	Sacramento, CA 95814
	USA
Email:	dev+ietf@seantek.com
URI:	http://www.penango.com/

A Uniform Resource Name (URN) Namespace for Transaction Identifiers
draft-seantek-tid-urn-01

Abstract

Status of this Memo

Copyright Notice

1. Introduction

1.1. Requirements Language

2. TID Syntax

2.1. Integral TIDs

2.2. Typed TIDs

2.2.1. Unicode in TID

3. Transaction Provider Name (org-nid) Assignment

3.1. Main Proposal: IANA PEN Registry

3.2. Alternative 1: First-Come, First-Served IANA Registration

3.3. Alternative 2: DNS Registration

3.3.1. Alternative 2.1: DNS Registration + Time

4. Specification Template

5. IANA Considerations

6. Security Considerations

7. References

7.1. Normative References

7.2. Informative References

Author's Address

A Uniform Resource Name (URN) Namespace for Transaction Identifiersdraft-seantek-tid-urn-01

Abstract

Status of this Memo

Copyright Notice

1. Introduction

1.1. Requirements Language

2. TID Syntax

2.1. Integral TIDs

2.2. Typed TIDs

2.2.1. Unicode in TID

3. Transaction Provider Name (org-nid) Assignment

3.1. Main Proposal: IANA PEN Registry

3.2. Alternative 1: First-Come, First-Served IANA Registration

3.3. Alternative 2: DNS Registration

3.3.1. Alternative 2.1: DNS Registration + Time

4. Specification Template

5. IANA Considerations

6. Security Considerations

7. References

7.1. Normative References

7.2. Informative References

Author's Address

A Uniform Resource Name (URN) Namespace for Transaction Identifiers
draft-seantek-tid-urn-01