📄 rfc2801.txt
字号:
o the Status component is used to indicate to the Payment Handler that an earlier exchange (e.g., an Offer Exchange) has successfully completed and by the Payment Handler to indicate the completion status of the Payment Exchange. o The Organisation Components are generated by the Merchant. They contain details of the Merchant and Payment Handler Roles: - the Merchant role is required so that the Payment Handler can identify which Merchant initiated the payment. Typically, the result of the Payment Handler accepting (or making) a payment on behalf of the Merchant will be a credit or debit transaction to the Merchant's account held by the Payment Handler. These transactions are outside the scope of this version of IOTP - the Payment Handler role is required so that the Payment Handler can check that it is the correct Payment Handler to be used for the payment o The Payment Component contains details of how much to pay, the currency and the payment direction o The "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity. Note that the Brand List and Brand Selection Components are not signed until the payment information is created (step 4 in the diagram) o the Trading Role Data component contains from other roles (e.g., a Merchant) that needs to be forwarded to the Payment Handler o The Payment Scheme Component contains messages from the payment protocol used in the Trade. For example they could be SET messages, Mondex messages, GeldKarte Messages or one of the other payment methods supported by IOTP. The content of the PaymentBurdett Informational [Page 23] RFC 2801 IOTP/1.0 April 2000 Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols. o The Payment Receipt Component contains a record of the payment. The content depends upon the payment protocol used. o The "Payment Receipt" Signature Component provides proof of payment by digitally signing both the Payment Receipt Component and the Offer Response Signature. The signature on the offer digitally signs the Order, Organisation and Delivery Components contained in the Offer. This signature effectively binds the payment to the offer. The example of a Payment Exchange above is the most general case. Simpler cases are also possible. For example, if the amount paid is not dependent on the payment brand and protocol selected then the payment information generated by step 3 can be sent to the Consumer at the same time as the Brand List Component generated by step 1. These and other variations are described in the Baseline Purchase IOTP Transaction (see section 9.1.8).2.2.3 Delivery Exchange The goal of the Delivery Exchange is to cause purchased goods to be delivered to the consumer either online or via physical delivery. A second goal is to provide a "delivery note" to the consumer, providing details about the delivery, such as shipping tracking number. The result of the delivery may also be signed so that it can be used for customer care in the case of problems with physical delivery. The message flow is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* CONSUMER DELIVERY | HANDLER | Merchant |STEP | | | 1. Consumer decides to trade and sends information about what to deliver and who is to take delivery, to the Merchant e.g., using HTML. C --> M Information on what is being delivered (outside scope of IOTP) 2. Merchant checks the information provided by the Consumer, adds information about how the delivery will occur, information about the Organisations involved in the delivery and optionally sings it and sends it to the ConsumerBurdett Informational [Page 24] RFC 2801 IOTP/1.0 April 2000 C <-- M Components: Delivery; Organisations (Delivery Handler, Deliver To); Order, Optional Offer Response Signature 3. Consumer checks delivery information is OK, obtains authorisation for the delivery, for example by making a payment, and sends the delivery information to the Delivery Handler C --------> D DELIVERY REQUEST. Components: Status; Delivery, Organisations: (Merchant, Delivery Handler, DelivTo); Order, Trading Role Data (optional); Optional Offer Response Signature, Optional Payment Receipt Signature (from Payment Exchange) 4. Delivery Handler checks information and authorisation. Starts or schedules delivery and creates and then sends a delivery not tot the Consumer which can optionally be signed. C <-------- D DELIVERY RESPONSE. Components: Status; Delivery Note, Trading Role Data (optional); Optional Delivery Response Signature 5. Consumer checks delivery note is OK and accepts or waits for delivery as described in the the Delivery Note. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 4 Delivery ExchangeA Delivery Exchange uses the following Trading Components that arepassed between the Consumer, the Merchant and the Delivery Handler: o the Status component is used to indicate to the Delivery Handler that an earlier exchange (e.g., an Offer Exchange or Payment Exchange) has successfully completed and by the Delivery Handler to indicate the completion status of the Delivery Exchange. o The Organisation Component(s) contain details of the Deliver To, Delivery Handler and Merchant Roles: - the Deliver To role indicates where the goods or services are to be delivered toBurdett Informational [Page 25] RFC 2801 IOTP/1.0 April 2000 - the Delivery Handler role is required so that the Delivery Handler can check that she is the correct Delivery Handler to do the delivery - the Merchant role is required so that the Delivery Handler can identify which Merchant initiated the delivery o The Order Component, contains information about the goods or services to be delivered o The Delivery Component contains information about how delivery will occur, for example by post or using e-mail. o The "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity. o The "Payment Receipt" Signature Component provides proof of payment by digitally signing the Payment Receipt Component and the Offer Signature. This is used by the Delivery Handler to check that delivery is authorised o The Delivery Note Component contains customer care information related to a physical delivery, or alternatively the actual "electronic goods". The Consumer's software does not interpret information about a physical delivery but should have the ability to display the information, both at the time of the delivery and later if the Consumer selects the Trade to which this delivery relates from a transaction list o The "Delivery Response" Signature Component, if present, provides proof of the results of the Delivery by digitally signing the Delivery Note and any Offer Response or Payment Response signatures that the Delivery Handler received.2.2.4 Authentication Exchange The goal of the Authentication Exchange is to allow one Organisation, for example a financial institution, to be able to check that another Organisation, for example a consumer, is who they appear to be. An Authentication Exchange involves: o an Authenticator - the Organisation which is requesting the authentication, and o an Authenticatee - the Organisation being authenticated.Burdett Informational [Page 26] RFC 2801 IOTP/1.0 April 2000 This is illustrated in the diagram below. +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Organisation 1 (Authenticatee) | Organisation 2 | (Authenticator)STEP | | 1. First Organisation, e.g., a Consumer, takes an action (for example by pressing a button on an HTML page) which requires that the Organisation is authenticated 1 --> 2 Need for Authentication (outside scope of IOTP) 2. The second Organisation generates an Authentication Request - including challenge data, and a list of the algorithms that may be used for the authentication - and/or a request for the Organisation information then sends it to the first Organisation 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, Trading Role Information Request 3. The first Organisation optionally checks any signature associated with the Authentication Request then uses the specified authentication algorithm to generate an Authentication Response which is sent back to the second Organisation together with details of any Organisation information requested 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, Organisation(s) 4. The Authentication Response is checked against the challenge data to check that the first Organisation is who they appear to be and the result recorded in a Status Component which is then sent back to the first Organisation. 1 <-- 2 AUTHENTICATION STATUS. Component: Status 5. The first Organisation then optionally checks the results indicated by the Status and any associated signature and takes the appropriate action or stops. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 5 Authentication ExchangeBurdett Informational [Page 27] RFC 2801 IOTP/1.0 April 2000 An Authentication Exchange uses the following Trading Components that are passed between the two Organisations: o the Authentication Request Component that requests an Authentication and indicates the authentication algorithm and optional challenge data to be used. o A Trading Role Information Request Component that requests information about an Organisation, for example a ship to address. o The Authentication Response Component which contains the challenge response generated by the recipient of the Authentication Request Component. o Organisation Components that contain the result of the Trading Role Information Request o the Status Component which contains the results of the second party's verification of the Authentication Response.2.3 Scope of Baseline IOTP This specification describes the IOTP Transactions which make up Baseline IOTP. As described in the preface, IOTP will evolve over time. This section defines the initial conformance criteria for implementations that claim to "support IOTP." The main determinant on the scope of an IOTP implementation is the roles which the solution is designed to support. The roles within IOTP are described in more detail in section 2.1 Trading Roles. To summarise the roles are: Merchant, Consumer, Payment Handler, Delivery Handler and Customer Care Provider. Payment Handlers who can be of three types: o those who accept a payment as part of a purchase or make a payment as part of a refund, o those who accept value as part of a deposit transaction, or o those that issue value a withdrawal transaction The following table d⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -