{"type":"rich","version":"1.0","author_name":"npub18fpvcsep7mwe4zfg4nsaquey5q7u6r5c8y3928258grwarxmtuusay739f","author_url":"https://nostr.ae/npub18fpvcsep7mwe4zfg4nsaquey5q7u6r5c8y3928258grwarxmtuusay739f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-07\n📝 Original message:2014-03-07 11:23 GMT+01:00 Andreas Schildbach \u003candreas at schildbach.de\u003e:\n\n\n\u003e Good news: HCE offers the required dispatch ability -- they call it AID\n\u003e (Application ID).\n\u003e\n\nYes, that's also something adopted from the existing Smartcard world.\nExisting smartcards can contain different payment applications (for example\nin Germany the \"Maestro\" and the \"Geldkarte\" application on the same card).\nSo the terminal can actively request one specific application within the\nSmartcard.\n\nBut as Mike correctly said, we have no pre-existing infrastructure to\nsupport. So decisions should only be based on what makes sense for the\nfuture.\n\n\nBad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.\n\u003e\n\nI'm not sure about this. I've built several HCE test apps and tested them\nwith readers (and other phones used as reader) but I did not notice any\ndifference to using CATEGORY_OTHER (besides that the apps using\nCATEGORY_PAYMENT appear in KitKat's new shiny \"Tap \u0026 Pay\" menu).\n\n\nHCE seems to cover only the payer side. I wonder if there is also an API\n\u003e for \"reader emulation\" which we would need for apps to support the payee\n\u003e side.\n\u003e\n\nYou are free to implement whatever protocol you want. On the reader side\nyou simply do a IseDep \"connect()\" and send your commands with\n\"transceive()\" (\nhttps://developer.android.com/reference/android/nfc/tech/IsoDep.html#transceive(byte[])).\nAfter sending the initial ISO 7816-4 \"SELECT APPLICATION\" command (see here\nfor some ISO 7816-4 doc:\nhttp://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11)\nwhich triggers Android HCE routing mechanism to route all following PDUs to\nyour HCE app, you are free to send whatever you want.\n\nAnything you send with \"transceve()\" on the sender side, will be received\nwithin your HCE application in the \"processCommandApdu\" method:\nhttps://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#processCommandApdu(byte[],\nandroid.os.Bundle)\n\nThe only limitation is that you have a strict request/response model. The\nreader terminal (or the reading phone) sends a request, the HCE phone sends\na response.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140307/c8eeac9b/attachment.html\u003e"}