Web Commerce 1.0

Unofficial Draft 31 January 2012

Editor:
Manu Sporny, Digital Bazaar, Inc.

Abstract

The purpose of PaySwarm is to build payment into the core architecture of the Web. This document details the electronic commerce portion of this architecture; enabling the decentralized listing of assets for sale and the transaction of those assets resulting in a digitally verifiable receipt between the buyer and the vendor.

Status of This Document

This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.

Table of Contents

1. Introduction

Add introductory text about the need for a simple electronic commerce standard for the Web.

2. The Conceptual Model

There are three primary participants in a PaySwarm transaction; the buyer, the vendor, and the authority.

2.1 Participants

2.1.1 Vendors

A vendor is the entity providing an asset for sale. Typically, the vendor is the legal owner of the asset that is being listed for sale. Ownership of an asset can manifest in a variety of different forms. Copyright ownership, physical ownership, and sub-leased property or services are just a few of the types of ownership that apply to vendors.

2.2 Commerce Model

2.2.1 Transactions

A transaction is the exchange of value from one or more source accounts into one or more destination accounts.

2.2.2 Assets

An asset describes a particular item that is provided as a part of a commercial transaction. It is usually an item that can be accessed or acquired on the basis of a sale or rental under the terms of a particular license. Examples of assets include web pages, crowd-funded loans or grants, music files, video streams, use of virtual machines by the hour, 3D printer files for on-demand manufacturing, radio spectrum and many other items that are capable of being transacted.

2.2.3 Licenses

A license is a legal description of a licensee's rights to a particular asset. Licenses are usually included as a part of a contract to express what a buyer may do with the asset that has been purchased.

2.2.4 Listings

A listing describes the combination of an asset that is for sale under a specific license and a set of payment terms that must be fulfilled in order to access the asset. Listings are often published on websites that sell assets via PaySwarm as a way to express wares for sale in a decentralized manner.

2.2.5 Contracts

A contract is the result of a commercial transaction in PaySwarm and contains information such as the listing, the asset that was purchased, the parties involved in the transaction, the license outlining the rights to the asset, and payment information associated with the transaction.

3. Base Technologies

PaySwarm builds on a number of successful Internet and Web technologies. These technologies are introduced in this section.

3.1 Representational State Transfer

REpresentational State Transfer [REST] is the architectural style that underpins the World Wide Web. It consists of a set of constraints to ensure that servers, gateways, proxies and clients may interact in a way that is predictable. Systems that are designed with this architecture in mind are called RESTful systems. PaySwarm is designed to be RESTful by ensuring that the constraints of REST are applied to all transactions performed via PaySwarm systems.

3.2 JavaScript Object Notation for Linking Data

JavaScript Object Notation for Linking Data [JSON-LD] is a lightweight Linked Data format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. If you are already familiar with JSON, writing JSON-LD is very easy. There is a smooth migration path from the JSON you use today, to the JSON-LD you will use in the future. These properties make JSON-LD an ideal Linked Data interchange language for JavaScript environments, Web services, and JSON document-based databases.

3.3 The Advanced Encryption Standard

The Advanced Encryption Standard (AES) [FIPS-197] is a world standard adopted by the United States Government and used to secure a vast majority of the commercial transactions over the Internet via OpenSSL. Since much of the data exchanged over PaySwarm participants is sensitive, it is important that a strong cryptography suite is utilized to digitally sign and transfer the messages.

3.4 HTML+RDFa

Web sites are largely implemented on top of the HyperText Markup Language (HTML). This format is known to be fairly easy to author and publish on the Web. In addition to being easy to publish, it is also important that data published via HTML can be easily read by machines without placing an undue burden on Web authors. Publishing structured data in a decentralized manner also requires a language that is capable of being both expressive and deterministic. The Resource Description Framework in attributes [RDFA-CORE] extends HTML [HTML-RDFA] to allow structured data to be expressed via HTML, but in a way that is easy for Web developers to author.

4. The Purchase Process

The simplest purchase process includes four distinct steps; publishing an asset, publishing a license, publishing a listing and performing the purchase. Typically, the vendor publishes the asset description and the listing. Anyone may publish a license that is used in a listing. The purchase is performed via a authority.

While it is possible to express assets, licenses, and listings on the Web in many different machine-readable formats, to ensure that implementations do not become more complicated than necessary, all assets, licenses and listing must be expressed in HTML+RDFa [HTML-RDFA] format. The example markup that is expressed in many of the following sections below will use [JSON-LD] for the sake of brevity. In many cases, the information expressed via JSON-LD is expected to be express via RDFa on a Web page. There is a clear mapping from RDFa to JSON-LD, so the data expressed in the sections below can be losslessly expressed via RDFa on an HTML Web page.

4.1 Publishing an Asset

An asset describes a particular item that is provided as a part of a commercial transaction. It is usually an item that can be accessed or acquired on the basis of a sale or rental under the terms of a particular license. Examples of assets include web pages, music files, video streams, virtual machines intended to be paid for by the CPU-hour, 3D printer files for on-demand manufacturing, radio spectrum and crowd-funded loans and grants.

The following example describes a web page asset with the title "PaySwarm in Practice". The article was created by "Digital Bazaar, Inc." and the information in the asset is valid from November 28th, 2010 to November 28th, 2011. The asset is digitally signed by the organization providing it and thus can be cached, stored and then presented to someone else in a manner that is verifiable by the receiving party.

{
   "@context": "http://purl.org/payswarm/v1",
   "@id": "http://example.org/articles/1#asset",
   "@type": ["ps:Asset", "ps:WebPage"],
   "dc:title": "PaySwarm in Practice",
   "dc:description": "This article covers how to use PaySwarm on your Website.",
   "dc:creator": 
   {
      "@type": "foaf:Organization",
      "foaf:name": "Digital Bazaar, Inc.",
   }
   "ps:contentUrl": "http://example.org/articles/1",
   "ps:validFrom": "2010-11-28T00:00:00Z",
   "ps:validUntil": "2011-11-28T00:00:00Z"
   "sec:signature": 
   {
       "@type": "sec:JsonLdSignature",
       "dc:created": "2010-11-28T00:00:00Z",
       "sec:signer": "https://payswarm.example.com/i/digital-bazaar#key-5",
       "sec:signatureValue": "OWM3YzI4OGQzNGVkMzV...IyZTk2MzQzNmExMgo="
   }
}
        

In order to publish this asset on a Web page, a vendor must mark the data up in RDFa and place it into an HTML file. For example, assume that the following file is served from the http://example.org/articles/1-purchase IRI:

<html>
 <head>
   <title>Buy: PaySwarm in Practice</title>
 </head>
 <body prefix="dc: http://purl.org/dc/terms/ 
               foaf: http://xmlns.com/foaf/0.1/ 
               ps: http://purl.org/payswarm#
               sec: http://purl.org/security#
               xsd: http://www.w3.org/2001/XMLSchema#">

   <article about="http://example.org/articles/1#asset" typeof="ps:Asset ps:WebPage">
     <h1 property="dc:title">PaySwarm in Practice</h1>
     by
     <h2 property="dc:creator" typeof="foaf:Organization">
       <span property="foaf:name">Digital Bazaar, Inc.</span>
     </h2>

     <p property="dc:description">This article covers how to use PaySwarm on your Website.</p>
     <a property="ps:contentUrl" href="http://example.org/articles/1">permalink</a>
     
     <input type="button" onclick="doPurchase();">Purchase Access to the Article</input>
     
     <input type="button" onclick="toggleDetails();">Details</input>
     <div class="article-details hidden-by-default">
       This asset publication is valid from
       <span property="ps:validFrom" content="2010-11-28T00:00:00Z" datatype="xsd:dateTime">today</span>
       until a 
       <span property="ps:validTo" content="2011-11-28T00:00:00Z" datatype="xsd:dateTime">year from today</span>.
       <div property="sec:signature" typeof="sec:JsonLdSignature">
         Signed on 
         <span property="dc:created" content="2010-11-28T00:00:00Z" datatype="xsd:dateTime">November 28th 2010</span>
         by
         <a property="sec:signer" href="https://payswarm.example.com/i/digital-bazaar#key-5">Digital Bazaar</a>:
         <span property="sec:signatureValue">OWM3YzI4OGQzNGVkMzV...IyZTk2MzQzNmExMgo=</span>
       </div>
      </div>
   </article>
 </body>
</html>
        

It may not initially be clear why an asset would need to be digitally signed. There are two major reasons that assets must be digitally signed in order to take part in a secure financial system. The first is to ensure, from a legal standpoint, that the person or organization claiming ownership over the asset is clear. The second is to ensure that forgery cannot occur on any of the asset information claimed by the owner of the asset. For example, if the asset were listed on an non-secure HTTP-based Web site, the information could be easily modified in transit.

The example above demonstrates how the information expressed as [JSON-LD] earlier in this section can be expressed as HTML+RDFa [HTML-RDFA]. The rest of this specification will not express information using both mechanisms, but will use [JSON-LD] markup for the sake of brevity even if the information being expressed is meant to be expressed in RDFa.

4.2 Publishing a License

A license is a legal description of a licensee's rights to a particular asset. Licenses are usually included as a part of a contract to express what a buyer may do with an asset that has been purchased. A license can include a number of rights bestowed upon the licensesee as well as further limitations on those rights. For example, how an asset may be re-broadcast, how often a digital asset may be physically reproduced, what an asset may specifically not be used for, and liability limitations when using the asset are but a few of the rights and obligations expressible via a license.

The following example describes a very simple license for personal use.

{
   "@context": "http://purl.org/payswarm/v1",
   "@id": "http://payswarm.example.com/licenses/personal-use",
   "@type": "ps:License",
   "dc:format": "text/html",
   "ps:licenseTemplate": "This personal use license allows you to save the 
      purchased asset onto any device that you own for your personal enjoyment
      and make up to <span property=\"ex:physicalCopies\" /> printed
      copies of the work for personal use."
   "ps:licenseTerms": 
   {
      "ex:physicalCopies": 5
   }
}
        

Licenses do not need to be created for each site on the Web. In many cases, common licenses can be placed on a website and re-used by a large number of sites that sell assets under similar license terms.

4.3 Publishing a Listing

A listing describes the combination of an asset that is for sale under a specific license and a set of payment terms that must be fulfilled in order to access the asset. Listings are often published on websites that sell assets via PaySwarm as a way to express things that are for sale, in a decentralized manner.

The following example describes an asset for sale for $0.05 USD under a license that covers acceptable use of blog posts. The offer is valid from March 2nd 2011 to March 3rd 2011. The only restriction on additional payees is that the authority (the organization processing the payment) may only take a maximum of 10% of the final sale price to cover their fees.

{
   "@context": "http://purl.org/payswarm/v1",
   "@id": "http://example.com/articles/1#listing",
   "@type": ["gr:Offering", "ps:Listing"],
   "com:payee": 
   [
      {
         "@id": "http://example.com/articles/1#listing-payee",
         "@type": "com:Payee",
         "com:currency": "USD",
         "com:destination": "https://payswarm.example.com/i/bob/accounts/primary",
         "com:rate": "0.05",
         "com:rateType": "com:FlatAmount",
         "rdfs:comment": "Payment for PaySwarm in Practice by Digital Bazaar."
      }
   ],
   "com:payeeRule": 
   [
      {
         "@type": "com:PayeeRule",
         "com:destinationOwnerType": "ps:Authority",
         "com:maximumRate": "10",
         "com:rateType": "com:InclusivePercentage"
      }
   ],
   "ps:asset": "http://example.com/articles/1#asset",
   "ps:assetHash": "14618b56ff597a2fed560db9aa0610fe442106a4",
   "ps:license": "http://payswarm.example.com/licenses/blogging",
   "ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
   "sec:signature": 
   {
      "@type": "ps:JsonLdSignature",
      "dc:created": "2011-03-02T00:00:00Z",
      "dc:creator": "https://payswarm.example.com/i/bob/keys/4",
      "sec:signatureValue": "KXtwA5kXZBJzj1rkPMJmGDROjM+fpi2cJIB+Xqf10="
   },
   "ps:validFrom": "2011-03-02T00:00:00+0000",
   "ps:validUntil": "2011-03-03T00:00:00+0000"
}
        

4.4 Performing a Purchase

A normal purchase, as opposed to an automatic purchase, is typically performed via a Web browser-based user agent when the participant has never performed a purchase with the vendor's website. The process consists of re-directing the Web browser to the buyer's PaySwarm Authority for the purposes of authorizing payment to the vendor for a particular listing. If a payment authorization is not approved, the user agent is re-directed back to the vendor's website with an error. If the payment authorization is approved, the user agent is re-directed bakc to the vendor's website with a short-form contract, which is used as a proof-of-purchase for the vendor's listing.

4.4.1 Purchase Terms

There are a number of terms that are used during the course of the purchase process.

listing hash
An identifier created by processing a listing expressed as JSON-LD through the JSON-LD Universal Graph Normalization Algorithm (UGNA2011) and then generating a SHA-1 hash of the result.
purchase callback
An IRI that will be on the receiving end of an HTTP POST from the authority with the result of a purchase request.
reference identifier
A string value that must be greater than one character and less than 256 characters used by the vendor to track purchases. These identifiers can be used to ensure that asset that can be purchased multiple times, like game tokens, can be tracked by the vendor. These identifiers also allow the vendor to protect against unintended double-purchasing due to network failures.
receipt
The resulting value of a purchase request, typically sent from the authority to the publishing agent. The object typically contains a short-form contract as well as other information that may be pertinent to the transaction.

4.4.2 The Purchase Algorithm

The normative algorithm for performing a purchase is expressed below.

  1. The publishing agent initiates a purchase request for a specific listing by re-directing the user agent to the contracts service endpoint:
    1. Generate the purchase request IRI by concatenating the contracts service and the following IRI parameters:
      listing
      The URL-encoded listing IRI.
      listing-hash
      A SHA-1 hash of the listing after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
      callback
      A de-referenceable IRI that must be able to process an HTTP POST request from the authority with the result of a purchase request.
      reference
      An optional, internal reference identifier used by the publishing agent to keep track of the purchase.
      nonce
      An optional cryptographic value that will be used in the encrypted response to the vendor. The response nonce is utilized to prevent replay attacks on the vendor.
    2. Perform an HTTP 303 redirect via the user agent to the purchase request IRI.
  2. The authority processes the purchase request ending in either an error message or a short-form contract:
    1. If the purchase was denied or failed for any reason, the authority performs an HTTP POST via the user agent back to the callback IRI supplied by the vendor during the initiation of the purchase request.
    2. If the purchase was successful, then a receipt is generated and transmitted to the vendor:
      1. To generate the receipt in JSON-LD format, the following pieces of information must be expressed:
        @context
        A single value containing the string http://purl.org/payswarm/v1 or a list containing that context IRI as the first member, where subsequent context declarations must not override any values in the first member.
        @type
        The value ps:Receipt.
        ps:preference
        An array of preferences that are requested by either the authority or the participant. All valid options are listed below:
        ps:preAuthorization - The participant has pre-authorized future purchases for the vendor and thus the Automatic Purchasing Algorithm may be used for future purchases. If this preference setting is mentioned, the publishing agent should store the participant's information, including the authority IRI, for use in future automatic transactions.
        ps:contract
        The contract used in the receipt is a summary of the digital contract that was finalized via the authority. It includes the minimum amount of information necessary for the publishing agent to correctly identify the listing that was transacted:
        @type
        The value ps:Contract.
        ps:asset
        An IRI to the asset that was purchased.
        ps:assetHash
        The SHA-1 hash of the asset information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
        com:reference
        The reference identifier, if one was suppied via the purchase request.
        ps:license
        An IRI to the license describing the rights associated with the asset that was purchased.
        ps:licenseHash
        The SHA-1 hash of the license information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
        ps:listing
        An IRI to the listing that was purchased.
        ps:listingHash
        The SHA-1 hash of the listing information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
        ps:assetAcquirer
        An IRI to the identity that acquired the asset.
      2. The authority initiates an HTTP POST via the user agent back to the callback IRI supplied by the publishing agent during the initiation of the purchase request. The POST data is digitally signed according to the Request Signature Algorithm, using the public key of the authority.
    3. The publishing agent acts upon the callback by granting access to the asset if the purchase was successful, or providing a page detailing why the purchase failed. The publishing agent should note any preferences in the receipt and utilize those preferences when processing future purchases from the participant.

4.5 Performing Automatic Purchases

An automatic purchase is one where a vendor has been previously authorized by a participant to perform purchases with the buyer's pre-authorized consent. This is typically used when the vendor is trusted, or when the participant has set a spending limit with the vendor and does not want to be bothered unless that spending limit is reached. Automatic purchases are designed to get out of the way of the participant and make the transactional flow as friction-free as possible.

4.5.1 Purchase Terms

There are a number of terms that are used during the course of the purchase process.

purchase request
A message consisting of a listing IRI, a listing hash, a participant identity IRI, and an optional reference identifier. The message is typically sent by a publishing agent to a participant's authority for processing.

4.5.2 The Automatic Purchase Algorithm

The automatic purchase algorithm is outlined below:

  1. The publishing agent prepares a purchase request by constructing a JSON-LD message. The following pieces of information must be expressed:
    @context
    A single value containing the string http://purl.org/payswarm/v1 or a list containing that context IRI as the first member, where subsequent context declarations must not override any values in the first member.
    @type
    The value ps:PurchaseRequest.
    ps:listing
    An IRI to the listing that was purchased.
    ps:listingHash
    The SHA-1 hash of the listing information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
    ps:assetAcquirer
    An IRI to the identity that acquired the asset.
    com:reference
    The reference identifier, if one was suppied via the purchase request.
  2. The purchase request is digitally signed by the publishing agent according to the Request Signature Algorithm using the private key associated with the listing in the purchase request. The purchase request is sent to the authority of the participant via an HTTPS connection. The HTTPS protocol must be used for transmission of the request and retrieval of the response to prevent replay attacks.
  3. The authority checks to ensure that the publishing agent is authorized to perform an automatic purchase on behalf of the provided participant identity IRI and responds to the publishing agent:
    1. If the transaction fails, the exception details are placed into a JSON-LD message and sent to the publishing agent.
      Determine how PaySwarm will handle response exceptions.
    2. If the transaction is successful, a receipt is generated for the publishing agent. The following fields must be placed into the response:
      @context
      A single value containing the string http://purl.org/payswarm/v1 or a list containing that context IRI as the first member, where subsequent context declarations must not override any values in the first member.
      @type
      The value ps:Receipt.
      ps:contract
      The contract used in the receipt is a summary of the digital contract that was finalized via the authority. It includes the minimum amount of information necessary for the publishing agent to correctly identify the listing that was transacted:
      @type
      The value ps:Contract.
      ps:asset
      An IRI to the asset that was purchased.
      ps:assetHash
      The SHA-1 hash of the asset information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
      com:reference
      The reference identifier, if one was suppied via the purchase request.
      ps:license
      An IRI to the license describing the rights associated with the asset that was purchased.
      ps:licenseHash
      The SHA-1 hash of the license information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
      ps:listing
      An IRI to the listing that was purchased.
      ps:listingHash
      The SHA-1 hash of the listing information after being normalized using the JSON-LD Universal Graph Normalization Algorithm (UGNA2011).
      ps:assetAcquirer
      An IRI to the identity that acquired the asset.
    3. The receipt is encrypted according to the Response Encryption Algorithm, using the public key associated with the private key that digitally signed the listing. The encrypted receipt is sent to the publishing agent.
  4. The publishing agent receives the response, which will either be an exception or a receipt, and responds accordingly to the user agent.

4.6 The Contract

A contract is the result of a commercial transaction in PaySwarm and contains information such as the listing, the asset that was purchased, the parties involved in the transaction, the license outlining the rights to the asset, and payment information associated with the transaction.

The following example describes a purchase that occurred on March 2nd 2011 for a Web-based article called "PaySwarm in Practice". The article was authored and listed for sale by Bob Smith and a personal use license was acquired by Jane, who may now peruse the article.

{
   "@context": "http://purl.org/payswarm/v1",
   "@id": "http://payswarm.example.com/contracts/28394729347",
   "@type": ["ps:Transaction", "ps:Contract"],
   "com:amount": "0.05",
   "com:currency": "USD",
   "dc:created": "2011-03-02T03:00:53Z",
   "com:payee": 
   [
      {
         "@type": "com:Payee",
         "com:currency": "USD",
         "com:destination": "https://payswarm.example.com/i/authority/accounts/main",
         "com:payeePosition": 0,
         "com:rate": "10.00",
         "com:rateContext": "com:TaxExempt",
         "com:rateType": "com:InclusivePercentage",
         "rdfs:comment": "authority Transaction Processing"
      }
   ],
   "com:transfer": 
   [
      {
         "@type": "com:Transfer",
         "com:amount": "0.045",
         "com:currency": "USD",
         "com:destination": "https://payswarm.example.com/i/bob/accounts/primary",
         "com:forTransaction": "http://payswarm.example.com/contracts/28394729347",
         "com:source": "https://payswarm.example.com/i/jane/accounts/primary",
         "rdfs:comment": "Payment for PaySwarm in Practice by Bob Smith."
      },
      {
         "@type": "com:Transfer",
         "com:amount": "0.005",
         "com:currency": "USD",
         "com:destination": "https://payswarm.example.com/i/authority/accounts/main",
         "com:forTransaction": "http://payswarm.example.com/contracts/28394729347",
         "com:source": "https://payswarm.example.com/i/jane/accounts/primary",
         "rdfs:comment": "authority Transaction Processing"
      }
   ],
   "dc:created": "2011-03-02T03:00:53Z",
   "ps:asset": 
   {
      "@id": "http://example.com/articles/1#asset",
      "@type": ["ps:Asset", "ps:WebPage"],
      "dc:creator": 
      {
         "foaf:name": "Bob Smith"
      },
      "dc:title": "PaySwarm in Practice",
      "ps:assetProvider": "https://payswarm.example.com/i/bob",
      "ps:authority": "https://payswarm.example.com/client-config",
      "ps:contentUrl": "http://example.com/articles/1",
      "sec:signature": 
      {
         "@type": "ps:JsonLdSignature",
         "dc:created": "2011-03-02T00:00:00Z",
         "dc:creator": "https://payswarm.example.com/i/bob/keys/4",
         "sec:signatureValue": "XuLEGuq+ne56Qsc5Nic8I="
      }
   },
   "ps:assetAcquirer": "https://payswarm.example.com/i/jane",
   "ps:assetProviderIdentity": 
   {
      "ps:identityHash": "df913752be56fe0d37dcedc2d7f44708373d2a68"
   },
   "ps:license": 
   {
      "@id": "http://payswarm.example.com/licenses/blogging",
      "@type": "ps:License",
      "dc:format": "text/html",
      "ps:licenseTemplate": "Personal Use License ..."
   },
   "ps:listing": 
   {
      "@id": "http://example.com/articles/1#listing",
      "@type": ["gr:Offering", "ps:Listing"],
      "com:payee": 
      [
         {
            "@id": "http://example.com/articles/1#listing-payee",
            "@type": "com:Payee",
            "com:currency": "USD",
            "com:destination": "https://payswarm.example.com/i/bob/accounts/primary",
            "com:rate": "0.05",
            "com:rateType": "com:FlatAmount",
            "rdfs:comment": "Payment for PaySwarm in Practice by Digital Bazaar."
         }
      ],
      "com:payeeRule": 
      [
         {
            "@type": "com:PayeeRule",
            "com:destinationOwnerType": "ps:Authority",
            "com:maximumRate": "10",
            "com:rateType": "com:InclusivePercentage"
         }
      ],
      "ps:asset": "http://example.com/articles/1#asset",
      "ps:assetHash": "14618b56ff597a2fed560db9aa0610fe442106a4",
      "ps:license": "http://payswarm.example.com/licenses/blogging",
      "ps:licenseHash": "0d8866836917f8ef58af44accb6efab9a10610ad",
      "sec:signature": 
      {
         "@type": "ps:JsonLdSignature",
         "dc:created": "2011-03-02T00:00:00Z",
         "dc:creator": "https://payswarm.example.com/i/bob/keys/4",
         "sec:signatureValue": "KXtwA5kXZBJzj1rkPMJmGDROjM+fpi2cJIB+Xqf10="
      },
      "ps:validFrom": "2011-03-02T00:00:00+0000",
      "ps:validUntil": "2011-03-03T00:00:00+0000"
   },
   "ps:listingHash": "1acbd23c3a7d8827270a959a2760f7c4ded98022",
   "sec:signature": 
   {
      "@type": "ps:JsonLdSignature",
      "dc:created": "2011-03-02T03:00:53Z",
      "dc:creator": "https://payswarm.example.com/i/authority/keys/1",
      "sec:signatureValue": "ZnGaAs0QCIfEAvCsj2TxRTs8ekQrbbQUXvTLWcQ0kQ=="
   }
}
        

4.7 Verifying a Purchase

A. References

A.1 Normative references

[FIPS-197]
Information Technology Laboratory. Specification for the ADVANCED ENCRYPTION STANDARD (AES) November 26th, 2001. Department of Commerce, National Institute of Standards and Technology. URL: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[HTML-RDFA]
Manu Sporny; et al. HTML+RDFa 04 March 2010. W3C Working Draft. URL: http://www.w3.org/TR/rdfa-in-html/
[JSON-LD]
Manu Sporny; Gregg Kellogg; Dave Longley; et al. JSON-LD latest. W3C Community Group Working Draft. URL: http://json-ld.org/spec/latest/
[RDFA-CORE]
Shane McCarron; et al. RDFa Core 1.1: Syntax and processing rules for embedding RDF through attributes. 31 March 2011. W3C Working Draft. URL: http://www.w3.org/TR/2011/WD-rdfa-core-20110331

A.2 Informative references

[REST]
Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures 2000. University of California, Irvine. URL: http://www.ics.uci.edu/~fielding/pubs/dissertation/