-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathcore.html
1106 lines (1015 loc) · 57.3 KB
/
core.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>OpenTransact Core</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenTransact Core">
<meta name="keywords" content="Internet-Draft">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">OpenTransact</td><td class="header">P. Braendgaard</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">PicoMoney Inc</td></tr>
<tr><td class="header">Intended status: Informational</td><td class="header">N. Matake</td></tr>
<tr><td class="header">Expires: July 13, 2012</td><td class="header">Cerego Japan Inc</td></tr>
<tr><td class="header"> </td><td class="header">T. Brown</td></tr>
<tr><td class="header"> </td><td class="header"> </td></tr>
<tr><td class="header"> </td><td class="header">D. Nicol</td></tr>
<tr><td class="header"> </td><td class="header">TipJar</td></tr>
<tr><td class="header"> </td><td class="header">January 10, 2012</td></tr>
</table></td></tr></table>
<h1><br />OpenTransact Core<br />draft-pelle-opentransact-core-02</h1>
<h3>Abstract</h3>
<p>
This document specifies the OpenTransact standard for requesting and performing transfers of assets over the http protocol.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
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.”</p>
<p>
This Internet-Draft will expire on July 13, 2012.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
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 Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#status-of-document">1.</a>
Status of Document<br />
<a href="#introduction">2.</a>
Introduction<br />
<a href="#assets">2.1.</a>
Assets<br />
<a href="#asset-service">2.1.1.</a>
Asset Service<br />
<a href="#transaction-url">2.1.2.</a>
Transaction URL<br />
<a href="#example-of-asset-services">2.1.3.</a>
Example of Asset Services<br />
<a href="#derivative-assets">2.1.4.</a>
Derivative Assets<br />
<a href="#roles">2.2.</a>
Roles<br />
<a href="#transfer">2.3.</a>
Transfer<br />
<a href="#transfer-request">2.4.</a>
Transfer Request<br />
<a href="#transfer-authorization">2.5.</a>
Transfer Authorization<br />
<a href="#exchange-transaction">2.6.</a>
Exchange Transaction<br />
<a href="#exchanged-item-uri">2.6.1.</a>
Exchanged item URI<br />
<a href="#authorization">2.6.2.</a>
Authorization<br />
<a href="#vocabulary">2.7.</a>
Vocabulary<br />
<a href="#authentication">2.8.</a>
Authentication<br />
<a href="#parameter-encoding">2.9.</a>
Parameter encoding<br />
<a href="#extensions">2.10.</a>
Extensions<br />
<a href="#notational-conventions">2.11.</a>
Notational Conventions<br />
<a href="#transfer-request-1">3.</a>
Transfer Request<br />
<a href="#response">3.1.</a>
Response<br />
<a href="#errors">3.2.</a>
Errors<br />
<a href="#transfer-authorization-1">4.</a>
Transfer Authorization<br />
<a href="#validity-duration">4.1.</a>
Validity duration<br />
<a href="#validity-request-parameter">4.1.1.</a>
Validity Request Parameter<br />
<a href="#validity-request-error">4.1.2.</a>
Validity Request Error<br />
<a href="#response-1">4.2.</a>
Response<br />
<a href="#errors-1">4.3.</a>
Errors<br />
<a href="#transfer-1">5.</a>
Transfer<br />
<a href="#response-2">5.1.</a>
Response<br />
<a href="#receipt">6.</a>
Receipt<br />
<a href="#asset-meta-data">7.</a>
Asset Meta data<br />
<a href="#transaction-history">7.1.</a>
Transaction history<br />
<a href="#derivative-assets-1">7.2.</a>
Derivative assets<br />
<a href="#security-considerations">8.</a>
Security Considerations<br />
<a href="#rfc.references1">9.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="status-of-document"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Status of Document</h3>
<p>This document is in draft and reflects the current designs from the OpenTransact mailing list.
</p>
<a name="introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Introduction</h3>
<p>The goal is to develop a very simple low level standard for transferring an amount of an asset from one account to another.
</p>
<p>Most payment systems and existing standards use the messaging paradigm for historical reasons. OpenTransact specifically rejects the message paradigm and prefers the RESTful (REpresentational State Transfer) resource approach as used on the web with URL’s and HTTP at it’s core.
</p>
<p>We aim to create a new standard from scratch ignoring all legacy systems, while leaving it flexible enough to allow applications built on top of it to deal with legacy systems.
</p>
<p>The standard is designed to follow standard RESTful practices and be concise and human readable.
</p>
<a name="assets"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Assets</h3>
<p>Within OpenTransact we use the accounting definition of the word “Asset” to mean anything fungible about which one could make an accounting book entry.
</p>
<p>For example:
</p>
<p></p>
<ul class="text">
<li>money
</li>
<li>shares
</li>
<li>bonds
</li>
<li>mobile phone minutes
</li>
<li>hours of work
</li>
<li>property
</li>
<li>domain names
</li>
<li>tons of sand
</li>
<li>general admission tickets to an event
</li>
<li>et cetera
</li>
</ul>
<a name="asset-service"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.1"></a><h3>2.1.1.
Asset Service</h3>
<p>An Asset Service is a service maintained by an organization to manage accounts of one asset. For money and other financial assets the Asset Service would normally be run by a Financial Service Provider of some type. Other types of assets are offered by non-financial services. The regulatory definition of “financial” is of course out of the scope of this document.
</p>
<a name="transaction-url"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.2"></a><h3>2.1.2.
Transaction URL</h3>
<p>Each Asset Service has a unique transaction URL. An informal convention is developing, but is out of the cope of this document. Guidance concerning the form of these URLs with regard to specific details like currency, card type, size, color MAY become available in a future Best Current Practices document.
</p>
<p>The service available at the transaction URL MUST follow basic REST practices:
</p>
<p></p>
<ul class="text">
<li>A transaction URL such as https://paymentsarewe.example.com/prwpoints MUST NOT contain query or fragment part.
</li>
<li>Loading the URL into a normal web browser should present a human readable description of the asset.
</li>
<li>A POST to the URL is used for creating a transaction transferring value.
</li>
<li>A GET to the URL from a normal web browser with specific parameters becomes a payment request that the user can authorize.
</li>
<li>A GET to the URL in a machine readable form such as json returns meta data about the asset and optionally a list of transactions that the current user is allowed to see.
</li>
<li>Each transaction has a unique URL. This SHOULD be formed by appending a unique transaction identifier to the transaction URL, such as https://paymentsarewe.example.com/prwpoints/aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d.
</li>
</ul>
<a name="example-of-asset-services"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.3"></a><h3>2.1.3.
Example of Asset Services</h3>
<p>Lets say it’s an imaginary electronic currency asset provider eepay.example.net they only offer one asset type, their currency. So they would only have one transaction url:
</p>
<p></p>
<ul class="text">
<li>http://eepay.example.net/transactions
</li>
</ul>
<p>If the asset provider offered multiple currencies it should have a url for each currency as they are really separate asset types:
</p>
<p></p>
<ul class="text">
<li>http://eepay.example.net/transactions/usd
</li>
<li>http://eepay.example.net/transactions/euro
</li>
</ul>
<p>A bank offering OT as an alternative to ACH service could have a tranaction URL for each of the currencies in which it offers checking accounts. The details of interbank settlements are out of the scope of this document.
</p>
<p></p>
<ul class="text">
<li>http://coolbank.example.com/current
</li>
<li>http://coolbank.example.com/savings
</li>
<li>http://coolbank.example.com/bonds/mortgage
</li>
</ul>
<p>A mutual fund company would have a url for each of their funds.
</p>
<p></p>
<ul class="text">
<li>http://fidelify.example.com/funds/sp500
</li>
<li>http://fidelify.example.com/funds/emergingmarkets
</li>
</ul>
<p>With relaxation of current regulations on brokerage transactions all going through markets, a broker (rather, a stock market) could implement an OpenTransact API and have a different URL for each symbol.
</p>
<p></p>
<ul class="text">
<li>http://nyex.example.com/trade/AAPL
</li>
<li>http://nyex.example.com/trade/EBAY
</li>
</ul>
<p>This would ease the barrier to registered securities being used directly as money.
</p>
<p>If we let the URL do the describing, there are many different possibilities. This allows support for all manners of asset types.
</p>
<p>All the above examples are fungible assets. In general it is best practice that one item of value for one asset is fungible for one another.
</p>
<p>For unique items such as domain names, property titles and diamonds that are unique and infungible, we can still create asset urls for each item, but only accept transfer amounts of 1.
</p>
<p>All the above examples are fungible assets.
</p>
<p>For unique items such as domain names, property titles and diamonds that are unique and infungible, we may define a separate currency for the item representing partial ownership. The legal framework for defining the resulting partnerships and their governance is out of scope of this document.
</p>
<a name="derivative-assets"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.4"></a><h3>2.1.4.
Derivative Assets</h3>
<p>A Derivative asset is an asset that is based on the current asset but provides different semantics and business rules.
</p>
<p>Examples:
</p>
<p></p>
<ul class="text">
<li>Reserves/Escrows
</li>
<li>Subscription services providing recurring billing
</li>
<li>Exchanges providing exchange of asset with another asset
</li>
</ul>
<p>It is out of scope to define here exactly how these would work, but the OpenTransact community will build a list of recipes for how to implement these and may publish further drafts outlining specifics in the future.
</p>
<a name="roles"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Roles</h3>
<p>OpenTransact defines 4 roles:
</p>
<p></p>
<ul class="text">
<li>Asset provider
<ul class="text">
<li>The entity providing or issuing the asset
</li>
</ul>
</li>
<li>Transferer
<ul class="text">
<li>The entity transfering an amount of the asset
</li>
</ul>
</li>
<li>Transferee
<ul class="text">
<li>The entity receiving an amount of the asset
</li>
</ul>
</li>
<li>3rd party application
<ul class="text">
<li>An application performing a transfer on behalf of the Transferer
</li>
</ul>
</li>
</ul>
<a name="transfer"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Transfer</h3>
<p>We will use the term “Transfer” as it is more widely applicable than “Payment”.
</p>
<p>A Transfer is legally a transfer in ownership of some amount of the Asset from the Transferer to the Transferee.
</p>
<p>Eg. A Payment of $12 from Bob to Alice is a Transfer of $12 with Bob being the Transferer and Alice the Transferee.
</p>
<a name="transfer-request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4"></a><h3>2.4.
Transfer Request</h3>
<p>A Transfer request is when the Transferee requests a transfer of a given amount of an asset from the Transferer.
</p>
<p>Eg. Alice sends an invoice to Bob for $12. This is a Transfer Request from Alice to Bob where Alice is the Transferee and Bob the Transferer.
</p>
<p>A Transfer Request is simply a specially formatted payment link that takes Bob to Asset Service if followed. The Asset Service shall present the Transfer Request to Bob who can authorize or decline it.
</p>
<a name="transfer-authorization"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5"></a><h3>2.5.
Transfer Authorization</h3>
<p>A Transfer Authorization is when the Transferee or a third party application requests an authorization to transfer of a given amount of an asset from the Transferer.
</p>
<p>Eg. Bob wants to hire someone on an online job board to edit a document for $33. The Job Board creates a Transfer Authorization link. Bob follows this link to the Asset Service and authorizes the Job Board to transfer $33 from his account to some one else within a time period.
</p>
<p>A Transfer Request is simply a specially formatted payment link that takes Bob to Asset Service if followed. The Asset Service shall present the Transfer Request to Bob who can authorize or decline it. If Bob authorizes it the Asset Service issues an authorization code to the Job Board that they can use to exchange for an OAuth token.
</p>
<a name="exchange-transaction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.6"></a><h3>2.6.
Exchange Transaction</h3>
<p>A Transfer is often but not always part of an exchange of value between 2 types of assets. Eg.:
</p>
<p></p>
<ul class="text">
<li>10 consulting hours exchanged for 1100EUR
</li>
<li>10 USD exchanged for 8 EURO
</li>
<li>0.99 USD exchanged for an mp3 song
</li>
</ul>
<p>There are as many different exchange mechanisms for creating exchanges as there are exchange types.
</p>
<p></p>
<ul class="text">
<li>Invoicing system
</li>
<li>App Store
</li>
<li>Web shop
</li>
<li>Auction site
</li>
<li>Stock Exchange
</li>
</ul>
<p>It is outside the scope for OpenTransact to define every single type of exchange that is possible. OpenTransact provides a fundamental building block in building such systems. It integrates well with exchange systems that don’t yet understand OpenTransact.
</p>
<a name="exchanged-item-uri"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.6.1"></a><h3>2.6.1.
Exchanged item URI</h3>
<p>In an Exchange Transaction we can include a url to the exchanged item. This URI could either be a link to the exchanged item itself or the unique URI identifying the transaction itself.
</p>
<a name="authorization"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.6.2"></a><h3>2.6.2.
Authorization</h3>
<p>A useful building block for creating Exchange services is the Transfer Authorization flow.
</p>
<a name="vocabulary"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.7"></a><h3>2.7.
Vocabulary</h3>
<p>OpenTransact includes a standard list parameter names used in the GET and POST requests.
</p>
<p></p>
<ul class="text">
<li><em>asset</em> - Transaction URL
</li>
<li><em>from</em> - Transferer account identifier
</li>
<li><em>to</em> - Transferee account identifier
</li>
<li><em>amount</em> - Amount of asset
</li>
<li><em>note</em> - Textual description of transfer
</li>
<li><em>for</em> - Identifier of exchanged item. This SHOULD be a URI
</li>
<li><em>redirect_uri</em> - URI to redirect User Agent to
</li>
<li><em>callback_uri</em> - URI for performing callback after request
</li>
<li><em>client_id</em> - Identifier of 3rd party application
</li>
<li><em>expires_in</em> - Request that a token expires in given seconds
</li>
</ul>
<p>They are designed to be small and semantically correct. eg
</p>
<p></p>
<blockquote class="text">
<p>A transfer of 10 USD from Bob to Alice for consulting.
</p>
</blockquote>
<p>Would become the following:
</p>
<p></p>
<ul class="text">
<li>amount=10
</li>
<li>asset=http://pay.me/usd
</li>
</li>
</li>
<li>note=Consulting on XYZ project
</li>
<li>for=http://myinvoice.test/invoices/123123
</li>
</ul>
<a name="authentication"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.8"></a><h3>2.8.
Authentication</h3>
<p>OpenTransact does not define any new authentication mechanisms, but relies on the Asset Provider’s existing mechanisms for authenticating the Transferer and OAuth 2.0 <a class='info' href='#I-D.ietf-oauth-v2-bearer'>[I‑D.ietf‑oauth‑v2‑bearer]<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Protocol: Bearer Tokens,” December 2011.</span><span>)</span></a> for authenticating 3rd party applications on behalf of the Transferer.
</p>
<a name="parameter-encoding"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.9"></a><h3>2.9.
Parameter encoding</h3>
<p>Since OpenTransact is designed to be simple to implement, the basic parameter encoding is URL form encoding.
</p>
<p>Data responses should be in JSON format.
</p>
<p>OpenTransact includes a standard for name strings and value ranges for use with the JSON objects returned from a request made to a compliant OT transaction URL.
</p>
<a name="extensions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.10"></a><h3>2.10.
Extensions</h3>
<p>OpenTransact is designed to be extensible, either through proprietary extensions, conventions or futher standards.
</p>
<p>For example it may be useful to follow the lat/lon convention allowing geotagging of data.
</p>
<a name="notational-conventions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.11"></a><h3>2.11.
Notational Conventions</h3>
<p>The key words ‘MUST’, ‘MUST NOT’, ‘REQUIRED’, ‘SHALL’, ‘SHALL NOT’, ‘SHOULD’, ‘SHOULD NOT’, ‘RECOMMENDED’, ‘MAY’, and ‘OPTIONAL’ in this specification are to be interpreted as described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
</p>
<p>This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>.
</p>
<p>Certain security-related terms are to be understood in the sense defined in <a class='info' href='#RFC4949'>[RFC4949]<span> (</span><span class='info'>Shirey, R., “Internet Security Glossary, Version 2,” August 2007.</span><span>)</span></a>. These terms include, but are not limited to, ‘attack’, ‘authentication’, ‘authorization’, ‘certificate’, ‘confidentiality’, ‘credential’, ‘encryption’, ‘identity’, ‘sign’, ‘signature’, ‘trust’, ‘validate’, and ‘verify’.
</p>
<p>Unless otherwise noted, all the protocol parameter names and values are case sensitive.
</p>
<a name="transfer-request-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Transfer Request</h3>
<p>A Transfer Request consists of a GET to the Asset URL.
</p><br /><hr class="insert" />
<a name="get-usdtobillexamplecomamount10000notemilkredirecturihttpsiteexamplecomcallback-http11host-payme"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /[email protected]&amount=100.00&note=Milk&redirect_uri=http://site.example.com/callback HTTP/1.1
Host: pay.me
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1 </b></font><br /></td></tr></table><hr class="insert" />
<p>We use the following parameters from our common vocabulary. All fields are optional:
</p>
<p></p>
<ul class="text">
<li><em>to</em> Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.
</li>
<li><em>amount</em> Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.
</li>
<li><em>note</em> Textual description, which can include hash tags. Asset Service may truncate this. No default.
</li>
<li><em>from</em> Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.
</li>
<li><em>for</em> URI identifying the exchanged item.
</li>
<li><em>redirect_uri</em> URI for redirecting client to afterwards
</li>
<li><em>callback_uri</em> URI for performing a web callback
</li>
</ul>
<p>When a user follows this link, the Asset Service should present the user with a form authorizing the payment.
</p>
<p>Note: Client can include OpenID Connect parameters.
</p>
<a name="response"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Response</h3>
<p>The user is redirected back to the clients redirect uri with the following url encoded parameters:
</p>
<p></p>
<ul class="text">
<li><em>txn_url</em> A url identifying the transaction.
</li>
</ul>
<p>Asset provider can include an access_token in the query string of txn_url.
</p>
<a name="errors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Errors</h3>
<p>Error types use OAuth 2.0’s error codes. <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a>
</p>
<a name="transfer-authorization-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Transfer Authorization</h3>
<p>A Transfer Authorization consists of a GET to the Asset URL with a client_id.
</p><br /><hr class="insert" />
<a name="get-usdtobillexamplecomamount10000notemilkredirecturihttpsiteexamplecomcallbackclientid1234-http11host-payme"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /[email protected]&amount=100.00&note=Milk&redirect_uri=http://site.example.com/callback&client_id=1234 HTTP/1.1
Host: pay.me
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 2 </b></font><br /></td></tr></table><hr class="insert" />
<p>A Transfer Authorization is really a OAuth2 Authorization <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> with a few extra payment related parameters.
</p>
<p>We use the following parameters from our common vocabulary. All fields are optional:
</p>
<p></p>
<ul class="text">
<li><em>to</em> Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.
</li>
<li><em>amount</em> Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.
</li>
<li><em>note</em> Textual description, which can include hash tags. Asset Service may truncate this. No default.
</li>
<li><em>from</em> Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.
</li>
<li><em>for</em> URI identifying the exchanged item.
</li>
<li><em>validity</em> A <a class='info' href='#ISO.8601.1988'>[ISO.8601.1988]<span> (</span><span class='info'>International Organization for Standardization, “Data elements and interchange formats - Information interchange - Representation of dates and times,” June 1988.</span><span>)</span></a> <a href='http://en.wikipedia.org/wiki/ISO_8601#Durations'>duration</a> or <a href='http://en.wikipedia.org/wiki/ISO_8601#Time_intervals'>interval</a> (see below)
</li>
</ul>
<p>OAuth2 related parameters. See <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> section 5 for full details
</p>
<p></p>
<ul class="text">
<li><em>client_id</em> OAuth2 client id
</li>
<li><em>redirect_uri</em> URI for redirecting client to afterwards
</li>
<li><em>callback_uri</em> URI for performing a web callback
</li>
<li><em>response_type</em> token or code REQUIRED
</li>
</ul>
<p>When a user follows this link, the Asset Service should present the user with a form authorizing the payment.
</p>
<p>Note: Client can include OpenID Connect parameters.
</p>
<a name="validity-duration"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Validity duration</h3>
<p>A client can request a specific validity length of the oauth token.
</p>
<p>The asset provider will assign a default expiration of the token if client doesn’t specify a validity.
</p>
<p>A validity can be request which is either a fixed duration or a repeating interval.
</p>
<p>For a fixed interval the amount SHOULD be guaranteed and reserved for the client.
</p>
<p>For a repeating interval the amount SHOULD be guaranteed for the first interval only.
</p>
<a name="validity-request-parameter"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.1"></a><h3>4.1.1.
Validity Request Parameter</h3>
<p>The validity is requested using A ISO8601 <a href='http://en.wikipedia.org/wiki/ISO_8601#Durations'>duration</a>, <a href='http://en.wikipedia.org/wiki/ISO_8601#Time_intervals'>interval</a> or <a href='http://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals'>repeating interval</a>.
</p>
<p>A duration is written
</p><br /><hr class="insert" />
<a name="p30d-30-dayspt5m-5-minutesp1m14dt3h5m23s-1-month-14-days-3-hours-5-minutes-and-23-seconds"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
P30D # 30 days
PT5M # 5 minutes
P1M14DT3H5M23S # 1 month 14 days 3 hours 5 minutes and 23 seconds
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 3 </b></font><br /></td></tr></table><hr class="insert" />
<p>Intervals are either 2 ISO Dates or an ISO date and a duration separated by the ‘/’ character:
</p><br /><hr class="insert" />
<a name="t130000z2008-05-11t153000z-the-interval-between-2-datest130000zp1y2m10dt2h30m-the-interval-starting-at-a-date-and-finishing-after-a-durationp1y2m10dt2h30m2008-05-11t153000z-the-interval-starting-with-a-duration-and-finishing-at-a-given-datep1m-the-duration-starting-at-the-time-the-token-was-authorized"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
2007-03-01T13:00:00Z/2008-05-11T15:30:00Z # The interval between 2 dates
2007-03-01T13:00:00Z/P1Y2M10DT2H30M # The interval starting at a date and finishing after a duration
P1Y2M10DT2H30M/2008-05-11T15:30:00Z # The interval starting with a duration and finishing at a given date
P1M # The duration starting at the time the token was authorized.
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 4 </b></font><br /></td></tr></table><hr class="insert" />
<p>Repeating intervals by prefix one of the above intervals or durations with the letter ‘R’ and an optional number specifying the amount of times to repeat:
</p><br /><hr class="insert" />
<a name="rp1m-repeat-once-a-monthr12p1m-repeat-12-times-once-a-monthrp1m2008-05-11t153000z-repeat-monthly-until-a-given-date"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
RP1M # repeat once a month
R12P1M # repeat 12 times once a month
RP1M/2008-05-11T15:30:00Z # repeat monthly until a given date
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 5 </b></font><br /></td></tr></table><hr class="insert" />
<p>By supporting a single parameter with any of the above durations/intervals/repeated intervals we can support a lot of different kinds of applications:
</p>
<p></p>
<ul class="text">
<li>Recurring payments (subscriptions) using the Repeated Intervals
</li>
<li>Daily spending limits on tokens using Repeated intervals similar to what debit cards have to day. eg. $300/day
</li>
<li>Request validity of a token using a simple duration
</li>
</ul>
<a name="validity-request-error"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.2"></a><h3>4.1.2.
Validity Request Error</h3>
<p>If a specified interval is not supported by service or user refuses to authorize the interval an <a href='http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.2.1'>OAuth2.0 Authorization error response</a> MUST be returned through redirection with the following error:
</p>
<p>error=unsupported_interval
</p>
<a name="response-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Response</h3>
<p>Follows OAuth 2 response depending on response_type requested. <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a>
</p>
<a name="errors-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.
Errors</h3>
<p>Error types use OAuth 2.0’s error codes. <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a>
</p>
<a name="transfer-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Transfer</h3>
<p>A transfer consists of a HTTP POST to the asset url by a 3rd party application on behalf of the Transferer.
</p>
<p>The Application MUST have an OAuth 2.0 access token issued as defined in the <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.</span><span>)</span></a> section 7.
</p>
<p>The asset provider SHOULD support the <a class='info' href='#I-D.ietf-oauth-v2-bearer'>[I‑D.ietf‑oauth‑v2‑bearer]<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Protocol: Bearer Tokens,” December 2011.</span><span>)</span></a> Access Token type and can support other access token such as <a class='info' href='#I-D.ietf-oauth-v2-http-mac'>[I‑D.ietf‑oauth‑v2‑http‑mac]<span> (</span><span class='info'>Hammer-Lahav, E., Barth, A., and B. Adida, “HTTP Authentication: MAC Access Authentication,” May 2011.</span><span>)</span></a>.
</p>
<p>The Transfer MUST be created using HTTPS when using <a class='info' href='#I-D.ietf-oauth-v2-bearer'>[I‑D.ietf‑oauth‑v2‑bearer]<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Protocol: Bearer Tokens,” December 2011.</span><span>)</span></a> and other unsigned access tokens.
</p><br /><hr class="insert" />
<a name="post-usd-http11host-paymeauthorization-bearer-vf9dft4qmttobillexamplecomamount10000notemilk"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /usd HTTP/1.1
Host: pay.me
Authorization: Bearer vF9dft4qmT
[email protected]&amount=100.00&note=Milk
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 6 </b></font><br /></td></tr></table><hr class="insert" />
<p>We use the following parameters from our common vocabulary in 1.6. All fields are optional:
</p>
<p></p>
<ul class="text">
<li><em>to</em> Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.
</li>
<li><em>amount</em> Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.
</li>
<li><em>note</em> Textual description, which can include hash tags. Asset Service may truncate this. No default.
</li>
<li><em>from</em> Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.
</li>
<li><em>for</em> URI identifying the exchanged item.
</li>
</ul>
<a name="response-2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Response</h3>
<p>http 201 with Receipt json.
</p>
<a name="receipt"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Receipt</h3>
<p>The receipt is returned when creating a transaction as well as when accessing a transaction url. It can also be used for creating a transaction list by the asset provider.
</p>
<p>The receipt is a JSON object consisting of the following fields:
</p>
<p></p>
<ul class="text">
<li><em>txn_url</em>
</li>
<li><em>to</em>
</li>
<li><em>from</em>
</li>
<li><em>amount</em>
</li>
<li><em>note</em>
</li>
<li><em>for</em>
</li>
<li><em>asset_url</em>
</li>
<li><em>timestamp</em>
</li>
</ul>
<a name="asset-meta-data"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Asset Meta data</h3>
<p>A client can find out information about an asset by accessing the asset url directly with a http Accept header of application/json:
</p><br /><hr class="insert" />
<a name="get-usd-http11host-paymeaccept-applicationjson"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /usd HTTP/1.1
Host: pay.me
Accept: application/json
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 7 </b></font><br /></td></tr></table><hr class="insert" />
<p>This returns a json hash of meta information about the asset.
</p>
<p>The minimum required data would be:
</p>
<p></p>
<ul class="text">
<li>name - Short name of asset
</li>
</ul>
<p>The minimal asset meta data is:
</p><br /><hr class="insert" />
<a name="namepay-me"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{
"name":"Pay Me"
}
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 8 </b></font><br /></td></tr></table><hr class="insert" />
<p>Further OpenTransact specific parameters could be:
</p>
<p></p>
<ul class="text">
<li>default_amount - The default amount transfered if an amount is not specified in a transfer
</li>
<li>provider_uri - The provider of the asset’s home page
</li>
<li>description - Short description
</li>
<li>logo_uri - Image url for Assets logo
</li>
<li>unit - ISO currency unit of asset if monetary or other such as (minute, gram, point etc)
</li>
<li>derivatives - a list of derivative assets supported by this server (see below)
</li>
</ul>
<p>Example:
</p><br /><hr class="insert" />
<a name="namepay-medefaultamount10providerurihttppaysamplecomlogourihttppaysamplecomlogopngunitusdderivatives-reservehttppaysamplecomreservessubscriptionhttppaysamplecomsubscriptionsexchangehttppaysamplecomexchange"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{
"name":"Pay Me",
"default_amount":1.0,
"provider_uri":"http://pay.sample.com",
"logo_uri":"http://pay.sample.com/logo.png",
"unit":"USD",
"derivatives": [
{"reserve":"http:/pay.sample.com/reserves"},
{"subscription":"http:/pay.sample.com/subscriptions"},
{"exchange":"http:/pay.sample.com/exchange"}
]
}