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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <johannes@zweng.at>) id 1WLtSt-0005GA-Sn
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 12:01:24 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of zweng.at
designates 80.67.31.94 as permitted sender)
client-ip=80.67.31.94; envelope-from=johannes@zweng.at;
helo=smtprelay05.ispgateway.de;
Received: from smtprelay05.ispgateway.de ([80.67.31.94])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WLtSr-0003bx-Rr
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 12:01:23 +0000
Received: from [209.85.216.54] (helo=mail-qa0-f54.google.com)
by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-SHA:128)
(Exim 4.68) (envelope-from <johannes@zweng.at>) id 1WLtSk-0000Dq-GS
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 13:01:14 +0100
Received: by mail-qa0-f54.google.com with SMTP id w8so3936152qac.27
for <bitcoin-development@lists.sourceforge.net>;
Fri, 07 Mar 2014 04:01:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc:content-type;
bh=+0KsfHsFsr8VC/JlkWjYB1bnzNNS7JB/MBP1H8yEjKg=;
b=Hb/31Q31joAc2s43ATZmNPJ90X7CWOmJtosDPlC5TaS1SgeX5MjsiY+Eqg8IyoezVz
+kWwncZc2m2/1fUpanLmH6mYVQbZx0Nwmu4q82Q9XDx8LiR1/0WnFHUW5InUoZjIkV8W
U+10e41GLpBG0ZjgB86TpepH1otVWom4oWATntx28/9oZkTjmMHHI3UZI27Z8TLkTRFO
SYnsiPD4tm2rqzeJDSCVk5GglGk2Bbope6u7Ij/6LNGyDGMDyM09LOw0FDSZJXj1K4ui
nvUieYhVIC6ffIUGsqq/DJ8njQweH2XhVi0KdPKD84cd7buKmOygoftm8WTIMVS+qUKQ
d3ww==
X-Received: by 10.140.108.2 with SMTP id i2mr10763228qgf.80.1394193673681;
Fri, 07 Mar 2014 04:01:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.66.97 with HTTP; Fri, 7 Mar 2014 04:00:33 -0800 (PST)
In-Reply-To: <lfc6mi$qth$1@ger.gmane.org>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
<lf9m0e$q7t$1@ger.gmane.org>
<CAJoe_wFeyFvxbd2nSD2yztJ_qjRQ=AKZj8pBOXs-ChKKbaZeuQ@mail.gmail.com>
<lfc6mi$qth$1@ger.gmane.org>
From: Johannes Zweng <johannes@zweng.at>
Date: Fri, 7 Mar 2014 13:00:33 +0100
Message-ID: <CAJoe_wGgLDh_pk6fntsKrYjXczZv-X5PLth7Y2B2s=oPuFz6AQ@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a113ab74aab02ad04f4030284
X-Df-Sender: am9oYW5uZXNAendlbmcuYXQ=
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.67.31.94 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WLtSr-0003bx-Rr
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Instant / contactless payments
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: johannes@zweng.at
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 07 Mar 2014 12:01:24 -0000
--001a113ab74aab02ad04f4030284
Content-Type: text/plain; charset=ISO-8859-1
2014-03-07 11:23 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:
> Good news: HCE offers the required dispatch ability -- they call it AID
> (Application ID).
>
Yes, that's also something adopted from the existing Smartcard world.
Existing smartcards can contain different payment applications (for example
in Germany the "Maestro" and the "Geldkarte" application on the same card).
So the terminal can actively request one specific application within the
Smartcard.
But as Mike correctly said, we have no pre-existing infrastructure to
support. So decisions should only be based on what makes sense for the
future.
Bad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.
>
I'm not sure about this. I've built several HCE test apps and tested them
with readers (and other phones used as reader) but I did not notice any
difference to using CATEGORY_OTHER (besides that the apps using
CATEGORY_PAYMENT appear in KitKat's new shiny "Tap & Pay" menu).
HCE seems to cover only the payer side. I wonder if there is also an API
> for "reader emulation" which we would need for apps to support the payee
> side.
>
You are free to implement whatever protocol you want. On the reader side
you simply do a IseDep "connect()" and send your commands with
"transceive()" (
https://developer.android.com/reference/android/nfc/tech/IsoDep.html#transceive(byte[])).
After sending the initial ISO 7816-4 "SELECT APPLICATION" command (see here
for some ISO 7816-4 doc:
http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11)
which triggers Android HCE routing mechanism to route all following PDUs to
your HCE app, you are free to send whatever you want.
Anything you send with "transceve()" on the sender side, will be received
within your HCE application in the "processCommandApdu" method:
https://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#processCommandApdu(byte[],
android.os.Bundle)
The only limitation is that you have a strict request/response model. The
reader terminal (or the reading phone) sends a request, the HCE phone sends
a response.
--001a113ab74aab02ad04f4030284
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div dir=3D"ltr"><div><br>=
</div></div></div><div class=3D"gmail_quote">2014-03-07 11:23 GMT+01:00 And=
reas Schildbach <span dir=3D"ltr"><<a href=3D"mailto:andreas@schildbach.=
de" target=3D"_blank">andreas@schildbach.de</a>></span>:<div>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">
Good news: HCE offers the required dispatch ability -- they call it AID<br>
(Application ID).<br></blockquote><div><br></div><div>Yes, that's also =
something adopted from the existing Smartcard world. Existing smartcards ca=
n contain different payment applications (for example in Germany the "=
Maestro" and the "Geldkarte" application on the same card). =
So the terminal can actively request one specific application within the Sm=
artcard.</div>
<div><br></div><div>But as Mike correctly said, we have no pre-existing inf=
rastructure to support. So decisions should only be based on what makes sen=
se for the future.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Bad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.<=
br></blockquote><div><br></div><div>I'm not sure about this. I've b=
uilt several HCE test apps and tested them with readers (and other phones u=
sed as reader) but I did not notice any difference to using CATEGORY_OTHER =
(besides that the apps using CATEGORY_PAYMENT appear in KitKat's new sh=
iny "Tap & Pay" menu).</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">
HCE seems to cover only the payer side. I wonder if there is also an API<br=
>
for "reader emulation" which we would need for apps to support th=
e payee<br>
side.<br></blockquote><div><br></div><div>You are free to implement whateve=
r protocol you want. On the reader side you simply do a IseDep "connec=
t()" and send your commands with "transceive()" (<a href=3D"=
https://developer.android.com/reference/android/nfc/tech/IsoDep.html#transc=
eive(byte[])">https://developer.android.com/reference/android/nfc/tech/IsoD=
ep.html#transceive(byte[])</a>). After sending the initial ISO 7816-4 "=
;SELECT APPLICATION" command (see here for some ISO 7816-4 doc: <a hre=
f=3D"http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basi=
c_interindustry_commands.aspx#chap6_11">http://www.cardwerk.com/smartcards/=
smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11</=
a>) which triggers Android HCE routing mechanism to route all following PDU=
s to your HCE app, you are free to send whatever you want.</div>
<div><br></div><div>Anything you send with "transceve()" on the s=
ender side, will be received within your HCE application in the "proce=
ssCommandApdu" method:</div><div><a href=3D"https://developer.android.=
com/reference/android/nfc/cardemulation/HostApduService.html#processCommand=
Apdu(byte[]">https://developer.android.com/reference/android/nfc/cardemulat=
ion/HostApduService.html#processCommandApdu(byte[]</a>, android.os.Bundle)<=
br>
</div><div><br></div><div>The only limitation is that you have a strict req=
uest/response model. The reader terminal (or the reading phone) sends a req=
uest, the HCE phone sends a response.</div><div><br></div><div><br></div>
</div></div></div>
--001a113ab74aab02ad04f4030284--
|
