📅 Original date posted:2014-03-07 📝 Original ...

2023-06-07T15:14:51Z

In reply to nevent1q…pmwv
_________________________

📅 Original date posted:2014-03-07
📝 Original message:2014-03-07 11:23 GMT+01:00 Andreas Schildbach <andreas at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140307/c8eeac9b/attachment.html>;

📅 Original date posted:2014-03-07 📝 Original ...

2023-06-07T15:14:50Z

In reply to nevent1q…xd7q
_________________________

📅 Original date posted:2014-03-07
📝 Original message:2014-03-06 12:26 GMT+01:00 Andreas Schildbach <andreas at schildbach.de>:

> In current phone implementations, the screen must be on already for NFC
> to be active. Also it must be unlocked, although I certainly hope future
> OSes will allow payment apps on the lock screen, just like they allow
> music players.

Just a small input to this point:
On Android 4.4 the new host card emulation (HCE) feature (aka: the phone
emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like a
Smartcard would do) only works when the display is on, but even when the
screen is locked (can be changed with "android:requireDeviceUnlock" in
Manifest). See here for detailled specification:
http://developer.android.com/guide/topics/connectivity/nfc/hce.html

Using the HCE API on Android 4.4 also has the beauty that any app that
registers itself for HCE and sets its category to CATEGORY_PAYMENT in the
Manifest automatically shows up in Adroid's system settings under "Tap &
Pay" (where a user would expect payment applications).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140307/a4a84190/attachment.html>;

Nostr notes by

📅 Original date posted:2014-03-07 📝 Original ...

📅 Original date posted:2014-03-07 📝 Original ...