A Uniform Resource Name (URN) Namespace for Transaction Identifiers

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.

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

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.

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.

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.

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.

The most difficult part of this scheme is the question of how to consistent with URN Syntax and URN Namespace Definition Mechanisms. On the one hand, it is desirable to use short and recognizable names for common transaction providers, such as "paypal", "visa", and "deutschebank", and to be able to generate such names from obvious properties. On the other hand, URNs are supposed to be unique and persistent for a very significant confidence interval. This document provides one main proposal and two alternatives, inviting the Internet community to provide comment and feedback.

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 the resulting string contains extended Unicode characters, use those characters directly; IDNA ToAscii conversion MUST NOT be performed. If the TID URN is encoded as an IRI, then the extended Unicode characters can be encoded directly (e.g., using UTF-8). If the TID URN is encoded as an URI, then the extended Unicode characters can be encoded using UTF-8 encoding followed by percent-encoding, as discussed in . 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.

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

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. Using the DNS in an URN may be a surprising proposal, especially when Section B.1 of RFC 3406 calls it a "poor" choice. However, the primary DNS name of the entity is quite sensible in this case given the nature of transaction identifiers. 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. The uniqueness of all URNs relies on the promise of every registration authority to maintain that uniqueness. At the end of the day, URNs are unique merely "because the registration authority says so". Nothing in the ISBN namespace or SWIFT namespace actually prevents the authority from reusing identifiers: ISO or SWIFT can change their standards if they feel like it. This scheme is no different, although it may make this reliance on registration authorities' promises a bit more obvious. Every transaction provider has an interest in keeping their transaction identifiers unique, because to do otherwise would cause bookkeeping havoc. Similarly, every transaction provider has an interest in keeping their domain names, at least as long as they are in business. 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.

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 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:

In this case, "@" serves as a general delimiter to distinguish between the entity name and the date. The date is not optional; it MUST be included. The format of the date is TBD, but the proposal in is reasonable, as is the ISO 8601 date format down to the day. DNS names are assumed to be valid for at least 24 hours, so there is no need for finer granularity. 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: Do nothing. Adjust the org-name-nid to an earlier date, where the earlier date value comes from a known TID URN that is equivalent. (Effectively, replace the TID URN with the earlier equivalent TID URN.) 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.

This document requests the assignment of formal URN namespace ID "tid". (TBD)

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.