Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

By prohibiting SELECT command EMV applications be limited #3

Closed
GoogleCodeExporter opened this issue May 3, 2015 · 2 comments
Closed

Comments

@GoogleCodeExporter
Copy link

Guys,

The new version don't allow me to perform a SELECT command.

But, in the EMV wolrd, SELECT command returns important information and I need 
them on my application.

I wont migrate to this new version due to this limitation. Can you handle this 
by at least providing the SELECT answer in the basicChannel?

Thanks.

Original issue reported on code.google.com by kdusilve...@gmail.com on 22 Jun 2011 at 3:32

@GoogleCodeExporter
Copy link
Author

Correcting gramma ;)

"By prohibiting SELECT command EMV applications will be limited:
Guys,

The new version doesn't allow me to perform a SELECT command.

But, in the EMV world, SELECT command returns important information and I need 
them on my application.

I won't migrate to this new version due to this limitation. Can you handle this 
by at least providing the SELECT answer in the basicChannel?

Thanks."

Original comment by kdusilve...@gmail.com on 22 Jun 2011 at 5:17

@GoogleCodeExporter
Copy link
Author

It's not desirable to support a SELECT command in the OpenMobileAPI spec as
- this might result with an 'SIM error' if the selected applet is changed on 
the basic channel for the UICC
- most basebands discard SELECT by name commands to omit an 'SIM error'
- (it might become challenging with Access Control when the applet selection is 
changed on a tranmit() )

-> Android applications should filter a SELECT command and translate to 
closeChannel and openChannel(new AID) to change the context

Receiving the SELECT response within an application (if possible) should be 
included in next OMAPI spec and correspondig SEEK release

Original comment by Daniel.A...@gi-de.com on 27 Sep 2011 at 8:52

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant