|
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.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2010.
Copyright (c) 2010 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 (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.
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.
Examples: urn:tid:paypal:0EA43237VW4885712 urn:tid:amazon:105-1112222-3444031 urn:tid:schwab:24791122231246900563725 urn:tid:newegg:55112123
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
The Namespace Specific String (NSS) portion of the identifiers has the following ABNF specification:
NSS = org-nid ":" 1*(tss / typed-tss)
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.
Examples: urn:tid:paypal:receipt:1111-2222-3333-4444 urn:tid:newegg:order:55915122 urn:tid:newegg:invoice:54121116 The ABNF: typed-tss = type ":" tss
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 (Moats, R., “URN Syntax,” May 1997.) [RFC2141] and URN Namespace Definition Mechanisms (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) [RFC3406]. 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 two alternatives and invites the Internet community to provide comment and feedback.
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 (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) [RFC3406] 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 (Hakala, J. and H. Walravens, “Using International Standard Book Numbers as Uniform Resource Names,” October 2001.) [RFC3187] or SWIFT namespace (Gustin, J. and A. Goyens, “A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging,” September 2003.) [RFC3615] 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 (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:
NSS = org-nid ":" tss / typed-tss org-nid = org-name-nid "@" org-date-nid
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 [I‑D.masinter‑dated‑uri] (Masinter, L., “The "tdb" URI scheme: denoting described resources,” July 2009.) is reasonable, as is the ISO 8601 date format (International Organization for Standardization, “Data elements and interchange formats - Information interchange - Representation of dates and times,” June 1988.) [ISO.8601.1988] 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:
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.
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.
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.
| [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). |
| [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). |
| [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/ |