a gp secure channel is opened with an application (aid), which means that selecting another application (aid) will break the current channel.
you are opening a channel with the security domain (a0...03)
then you select your app
this breaks the previous channel
then you send an apdu, but the security level is zero, because no security channel was opened with the selected app.
this will definitely never work.
there are only two ways to do something like that:
1) open the secure channel with your app, not with the SD. To do that, you have to manage yourself the INS=50 and INS=82 instructions by forwarding the command to the security domain instance, via the GlobalPlatform API. There is a method for that, the name is processSecurity()
this function must be called each time your app receives an init update or ext authenticate apdu. It will manage the global platform security for you by calling the proper routines in the security domain that handles your app.
if authentication is successful, your SecureChannel instance will show an updated security level and you will be able to unwrap wrapped commands.
the process becomes
-select your app
-authenticate using init update and ext auth
-send wrapped apdus
this should works on most cards, I have tested and used it 2 years ago, so it's a "well established" behaviour.
Your 6D00 failure is strange, I did not know that you could disable that.
2) use the personnalization methods from GP
With this process
-select the security domain
-send INSTALL FOR PERSONALIZATION, passing the AID of the app you want to communicate with
-send STORE DATA commands, they can contain anything.
-these store data commands are handled by the processData() callback that belong to the Application interface (you must implement that, see Application )
-if you want to get data in response to a STORE DATA command, you have to use the Personnalization interface in GP 2.2 admendments. This is not possible with GP 2.1.1, because the Application.processData() method returns void.
Application should work on most cards, Personnalization requires recent (GP 2.2) cards. Moreover, the idea behind this process is intended for card personnalization, not for a deployed lifecycle.
I know you tested method 1. I find this non-working behaviour quite strange, but it's difficult to do the same thing on every card, that would be too easy
I only know one alternative: implement your own GP-compatible secure channel routines. I've also done that before to support R-MAC on a card that didn't support it.
Then, you "just" have to find a way to store GP keys in your application.