Exactly — the MEP distinction is important. With SGP.22 MEP, the virtual-eUICC separation means the profiles can coexist without the AID namespace being treated as one flat profile namespace, despite sharing the physical chip/UART. The ISD-R ↔ ISD-P case is different, and the ARA-M collision is the interesting edge case: those applications can end up in the same effective AID namespace despite belonging to different security-domain branches. That makes it a platform/GlobalPlatform application-selection issue rather than JavaCard Shareable-interface firewalling. So I’d separate the cases as: **SD-to-SD within one profile → Shareable governed by JavaCard context/AID policy.** **ISD-P-to-ISD-P under MEP → virtual-eUICC isolation.** **ISD-R/SSD ↔ ISD-P → AID collision can still occur.**

Exactly — the MEP distinction is important. With SGP.22 MEP, the virtual-eUICC separation means the profiles can coexist without the AID namespace being treated as one flat profile namespace, despite sharing the physical chip/UART. The ISD-R ↔ ISD-P case is different, and the ARA-M collision is the interesting edge case: those applications can end up in the same effective AID namespace despite belonging to different security-domain branches. That makes it a platform/GlobalPlatform application-selection issue rather than JavaCard Shareable-interface firewalling. So I’d separate the cases as: **SD-to-SD within one profile → Shareable governed by JavaCard context/AID policy.** **ISD-P-to-ISD-P under MEP → virtual-eUICC isolation.** **ISD-R/SSD ↔ ISD-P → AID collision can still occur.**

@fkamanzi thansk for your insight and explanation in the topic. It reflects also my understanding, but is much more clear than I would have been able to put it. One comment: In SGP.22 v3.x with MEP (multiple enabled profile) I expect there is also no AID clash as there are basically separate eUICCs virtualized on the same phyiscal chip. While they do share the same physical UART, there were some extensions at the TPDU T=0 transport level to separate the different virtual eUICCs at the lowest transport level from each other. Another comment: The AID clash does however happen if applications are installed in the ISD-R (or any other SSD below the ISD-R) and the the ISD-P. This is what we’re seeing with the ISD-R installed ARA-M applet clashing with any ARA-M present in the ISD-P (see section in sysmoEUICC1 user manual about this topic). I brought this up with leaders of at least one GSMA eSIM working group, but it seems it is nothing they want to investigate / follow-up

@fkamanzi thansk for your insight and explanation in the topic. It reflects also my understanding, but is much more clear than I would have been able to put it. One comment: In SGP.22 v3.x with MEP (multiple enabled profile) I expect there is also no AID clash as there are basically separate eUICCs virtualized on the same phyiscal chip. While they do share the same physical UART, there were some extensions at the TPDU T=0 transport level to separate the different virtual eUICCs at the lowest transport level from each other. Another comment: The AID clash does however happen if applications are installed in the ISD-R (or any other SSD below the ISD-R) and the the ISD-P. This is what we’re seeing with the ISD-R installed ARA-M applet clashing with any ARA-M present in the ISD-P (see section in sysmoEUICC1 user manual about this topic). I brought this up with leaders of at least one GSMA eSIM working group, but it seems it is nothing they want to investigate / follow-up

These are two separate lifecycle questions, and the SAIP model keeps them apart. On selectability: applet instantiation and selectability are not the same state. When the ProfileInstaller works through the SAIP, ApplicationInstance PEs create and register the applet instances, and the processData field carries install-time personalization that the applet consumes through its install/personalization hook — the applet is instantiated and receiving data, but that is not the same as being SELECTable over the radio/APDU interface. Selectability is gated by the applet’s lifecycle state and the profile’s own state. During installation the profile is in Disabled state, so nothing in it is reachable from the ME; the applet being “alive” enough to consume processData at install time does not make it externally selectable then. So no, processData does not imply the applet is selectable while the profile installs — it means the installer is driving the applet’s personalization, in-card, before the profile is ever enabled. On AID clash: the isolation boundary is what prevents it. Each profile lives in its own ISD-P, and per the GSMA rule an ISD-P has no visibility of any other ISD-P, so AID uniqueness only has to hold within the one profile being installed, not across profiles. Two different profiles can legitimately carry the same applet AID, and that is fine precisely because JCRE/GP resolution is scoped inside the ISD-P — a SELECT by AID is resolved within the active profile’s context, never across the boundary. Within a single SAIP, the installer is building one profile’s namespace, so the only clash you could create is duplicate AIDs inside that same profile, which is an authoring error the installer will reject, not a cross-profile collision. The one caveat worth stating: this holds because only one profile is Enabled/selectable at a time on a consumer eUICC (and even under MEP the profiles stay isolated). If you are reasoning about SGP.32 (M2M/IoT), the same ISD-P isolation applies, so the cross-profile AID-clash concern does not arise there either. If you have a concrete SAIP where two ApplicationInstance PEs in the same profile share an AID, that is the only real clash, and that is a profile-authoring fix, not a platform behaviour.

These are two separate lifecycle questions, and the SAIP model keeps them apart. On selectability: applet instantiation and selectability are not the same state. When the ProfileInstaller works through the SAIP, ApplicationInstance PEs create and register the applet instances, and the processData field carries install-time personalization that the applet consumes through its install/personalization hook — the applet is instantiated and receiving data, but that is not the same as being SELECTable over the radio/APDU interface. Selectability is gated by the applet’s lifecycle state and the profile’s own state. During installation the profile is in Disabled state, so nothing in it is reachable from the ME; the applet being “alive” enough to consume processData at install time does not make it externally selectable then. So no, processData does not imply the applet is selectable while the profile installs — it means the installer is driving the applet’s personalization, in-card, before the profile is ever enabled. On AID clash: the isolation boundary is what prevents it. Each profile lives in its own ISD-P, and per the GSMA rule an ISD-P has no visibility of any other ISD-P, so AID uniqueness only has to hold within the one profile being installed, not across profiles. Two different profiles can legitimately carry the same applet AID, and that is fine precisely because JCRE/GP resolution is scoped inside the ISD-P — a SELECT by AID is resolved within the active profile’s context, never across the boundary. Within a single SAIP, the installer is building one profile’s namespace, so the only clash you could create is duplicate AIDs inside that same profile, which is an authoring error the installer will reject, not a cross-profile collision. The one caveat worth stating: this holds because only one profile is Enabled/selectable at a time on a consumer eUICC (and even under MEP the profiles stay isolated). If you are reasoning about SGP.32 (M2M/IoT), the same ISD-P isolation applies, so the cross-profile AID-clash concern does not arise there either. If you have a concrete SAIP where two ApplicationInstance PEs in the same profile share an AID, that is the only real clash, and that is a profile-authoring fix, not a platform behaviour.

These new SGP.32 SAIP scripts have processData fields in the ApplicationInstance PE. That means the profile’s applets must be “alive” to handle processData() hooks while the profile is getting installed. Does this mean the applets are selectable? Cant it cause AIDs to clash?

These new SGP.32 SAIP scripts have processData fields in the ApplicationInstance PE. That means the profile’s applets must be “alive” to handle processData() hooks while the profile is getting installed. Does this mean the applets are selectable? Cant it cause AIDs to clash?

YouTube video by ThothTrust ThothTrust

MEP doesn’t change it — it changes concurrency, not isolation. Yes, with MEP more than one profile can be Enabled at once, but each sits on its own eSIM port with its own baseband, and the isolation rule is unchanged in the very same v3.x spec that defines MEP: an ISD-P hosts a unique profile, and no component outside the ISD-P has visibility of or access to any profile component (only the ISD-R, and only to metadata). So both profiles being enabled simultaneously still does not let an applet in one ISD-P obtain a Shareable SIO from an applet in another. Cross-ISD-P getAppletShareableInterfaceObject fails regardless of enable state. The broker/hub applet doesn’t rescue it, for two reasons: * There’s nowhere neutral to put it. The only components outside the profiles are the ISD-R / ECASD / EUM domains, which are reserved for the RSP/OS functions — you can’t load a third-party broker applet there on a consumer eUICC. There is no user-loadable security domain that both profiles can reach. * Even if there were, the isolation rule cuts both ways: a profile applet reaching out to an external broker, or a broker reaching into a profile, is exactly what “no access to any profile component from outside the ISD-P” forbids. The broker would see none of the profiles’ applets and vice versa. So a broker only works when the broker and all its clients live in the same ISD-P (same profile), across SDs — which is the plain-JavaCard case that already works. On duplicate AIDs — real property, but moot here. AID namespaces are per-ISD-P, so the same client AID legitimately existing in two profiles is fine precisely because firewall/JCRE resolution is scoped inside the profile context. The server’s getShareableInterfaceObject(clientAID, param) only ever sees callers from its own profile, so there’s no cross-profile collision to resolve. Within one profile, AIDs are unique and Shareable resolves normally. Net: cross-profile Shareable is unavailable by design, MEP included. And your “if someone writes such a thing” instinct is right — the standards body is writing exactly that: GSMA SAM.01 (Secured Applications for Mobile) introduces a SAM-SD that lives outside the profiles specifically to let SIM applets be accessed independently of any profile. It needs a brand-new domain type precisely because today’s model blocks what you’re describing. If cross-profile data sharing is your real goal, SAM.01 / SAM-SD is the path to watch, not JavaCard Shareable.

MEP doesn’t change it — it changes concurrency, not isolation. Yes, with MEP more than one profile can be Enabled at once, but each sits on its own eSIM port with its own baseband, and the isolation rule is unchanged in the very same v3.x spec that defines MEP: an ISD-P hosts a unique profile, and no component outside the ISD-P has visibility of or access to any profile component (only the ISD-R, and only to metadata). So both profiles being enabled simultaneously still does not let an applet in one ISD-P obtain a Shareable SIO from an applet in another. Cross-ISD-P getAppletShareableInterfaceObject fails regardless of enable state. The broker/hub applet doesn’t rescue it, for two reasons: * There’s nowhere neutral to put it. The only components outside the profiles are the ISD-R / ECASD / EUM domains, which are reserved for the RSP/OS functions — you can’t load a third-party broker applet there on a consumer eUICC. There is no user-loadable security domain that both profiles can reach. * Even if there were, the isolation rule cuts both ways: a profile applet reaching out to an external broker, or a broker reaching into a profile, is exactly what “no access to any profile component from outside the ISD-P” forbids. The broker would see none of the profiles’ applets and vice versa. So a broker only works when the broker and all its clients live in the same ISD-P (same profile), across SDs — which is the plain-JavaCard case that already works. On duplicate AIDs — real property, but moot here. AID namespaces are per-ISD-P, so the same client AID legitimately existing in two profiles is fine precisely because firewall/JCRE resolution is scoped inside the profile context. The server’s getShareableInterfaceObject(clientAID, param) only ever sees callers from its own profile, so there’s no cross-profile collision to resolve. Within one profile, AIDs are unique and Shareable resolves normally. Net: cross-profile Shareable is unavailable by design, MEP included. And your “if someone writes such a thing” instinct is right — the standards body is writing exactly that: GSMA SAM.01 (Secured Applications for Mobile) introduces a SAM-SD that lives outside the profiles specifically to let SIM applets be accessed independently of any profile. It needs a brand-new domain type precisely because today’s model blocks what you’re describing. If cross-profile data sharing is your real goal, SAM.01 / SAM-SD is the path to watch, not JavaCard Shareable.

MEP doesn’t change it — it changes concurrency, not isolation. Yes, with MEP more than one profile can be Enabled at once, but each sits on its own eSIM port with its own baseband, and the isolation rule is unchanged in the very same v3.x spec that defines MEP: an ISD-P hosts a unique profile, and no component outside the ISD-P has visibility of or access to any profile component (only the ISD-R, and only to metadata). So both profiles being enabled simultaneously still does not let an applet in one ISD-P obtain a Shareable SIO from an applet in another. Cross-ISD-P getAppletShareableInterfaceObject fails regardless of enable state. The broker/hub applet doesn’t rescue it, for two reasons: * There’s nowhere neutral to put it. The only components outside the profiles are the ISD-R / ECASD / EUM domains, which are reserved for the RSP/OS functions — you can’t load a third-party broker applet there on a consumer eUICC. There is no user-loadable security domain that both profiles can reach. * Even if there were, the isolation rule cuts both ways: a profile applet reaching out to an external broker, or a broker reaching into a profile, is exactly what “no access to any profile component from outside the ISD-P” forbids. The broker would see none of the profiles’ applets and vice versa. So a broker only works when the broker and all its clients live in the same ISD-P (same profile), across SDs — which is the plain-JavaCard case that already works. On duplicate AIDs — real property, but moot here. AID namespaces are per-ISD-P, so the same client AID legitimately existing in two profiles is fine precisely because firewall/JCRE resolution is scoped inside the profile context. The server’s getShareableInterfaceObject(clientAID, param) only ever sees callers from its own profile, so there’s no cross-profile collision to resolve. Within one profile, AIDs are unique and Shareable resolves normally. Net: cross-profile Shareable is unavailable by design, MEP included. And your “if someone writes such a thing” instinct is right — the standards body is writing exactly that: GSMA SAM.01 (Secured Applications for Mobile) introduces a SAM-SD that lives outside the profiles specifically to let SIM applets be accessed independently of any profile. It needs a brand-new domain type precisely because today’s model blocks what you’re describing. If cross-profile data sharing is your real goal, SAM.01 / SAM-SD is the path to watch, not JavaCard Shareable.

MEP doesn’t change it — it changes concurrency, not isolation. Yes, with MEP more than one profile can be Enabled at once, but each sits on its own eSIM port with its own baseband, and the isolation rule is unchanged in the very same v3.x spec that defines MEP: an ISD-P hosts a unique profile, and no component outside the ISD-P has visibility of or access to any profile component (only the ISD-R, and only to metadata). So both profiles being enabled simultaneously still does not let an applet in one ISD-P obtain a Shareable SIO from an applet in another. Cross-ISD-P getAppletShareableInterfaceObject fails regardless of enable state. The broker/hub applet doesn’t rescue it, for two reasons: * There’s nowhere neutral to put it. The only components outside the profiles are the ISD-R / ECASD / EUM domains, which are reserved for the RSP/OS functions — you can’t load a third-party broker applet there on a consumer eUICC. There is no user-loadable security domain that both profiles can reach. * Even if there were, the isolation rule cuts both ways: a profile applet reaching out to an external broker, or a broker reaching into a profile, is exactly what “no access to any profile component from outside the ISD-P” forbids. The broker would see none of the profiles’ applets and vice versa. So a broker only works when the broker and all its clients live in the same ISD-P (same profile), across SDs — which is the plain-JavaCard case that already works. On duplicate AIDs — real property, but moot here. AID namespaces are per-ISD-P, so the same client AID legitimately existing in two profiles is fine precisely because firewall/JCRE resolution is scoped inside the profile context. The server’s getShareableInterfaceObject(clientAID, param) only ever sees callers from its own profile, so there’s no cross-profile collision to resolve. Within one profile, AIDs are unique and Shareable resolves normally. Net: cross-profile Shareable is unavailable by design, MEP included. And your “if someone writes such a thing” instinct is right — the standards body is writing exactly that: GSMA SAM.01 (Secured Applications for Mobile) introduces a SAM-SD that lives outside the profiles specifically to let SIM applets be accessed independently of any profile. It needs a brand-new domain type precisely because today’s model blocks what you’re describing. If cross-profile data sharing is your real goal, SAM.01 / SAM-SD is the path to watch, not JavaCard Shareable.

Thank you, that is a great answer. I’m assuming the card will also block Sharable across ISD-P-to-ISD-P boundaries even when both profiles are enabled at the same time because of MEP? I guess you could have a “broker/hub” applet running in the independent security domain, implementing Sharable, with applets from both enabled profiles connecting to it and sharing data (if someone writes such a thing – I don’t know how client AIDs work here cause they could be duplicated).

Thank you, that is a great answer. I’m assuming the card will also block Sharable across ISD-P-to-ISD-P boundaries even when both profiles are enabled at the same time because of MEP? I guess you could have a “broker/hub” applet running in the independent security domain, implementing Sharable, with applets from both enabled profiles connecting to it and sharing data (if someone writes such a thing – I don’t know how client AIDs work here cause they could be duplicated).

Thank you, that is a great answer. I’m assuming the card will also block Sharable across ISD-P-to-ISD-P boundaries even when both profiles are enabled at the same time because of MEP? I guess you could have a “broker/hub” applet running in the independent security domain, implementing Sharable, with applets from both enabled profiles connecting to it and sharing data (if someone writes such a thing – I don’t know how client AIDs work here cause they could be duplicated).

Two different boundaries are being conflated. The JavaCard firewall keys on the applet context (the package group context), not on the GlobalPlatform security domain — so the SD an applet sits in does not by itself block Shareable. Your OC1230 case works in plain JavaCard/GP: the server applet exposes an SIO, a client in a different SD calls JCSystem.getAppletShareableInterfaceObject(serverAID, param), and the server’s getShareableInterfaceObject() decides whether to return it (it can check the client’s AID and refuse). SD-to-SD sharing is gated by that AID check, not by the SD boundary. ISD-P-to-ISD-P is the case that actually differs. On an eUICC the ISD-P/profile boundary is a hard isolation boundary — GSMA mandates profile isolation (SGP.22 consumer, SGP.02 M2M) and the eUICC OS enforces that an applet in one ISD-P cannot obtain a Shareable SIO from an applet in another ISD-P. On a consumer eUICC only one profile is enabled at a time as well, so the target applet in another profile isn’t even running to answer. That block comes from platform profile isolation, not from the firewall or the SD concept. Net: within one profile, SD-to-SD Shareable is allowed and gated by the server applet’s AID check; across ISD-Ps it’s blocked by eUICC profile isolation, and moot anyway since only one profile is enabled.

Two different boundaries are being conflated. The JavaCard firewall keys on the applet context (the package group context), not on the GlobalPlatform security domain — so the SD an applet sits in does not by itself block Shareable. Your OC1230 case works in plain JavaCard/GP: the server applet exposes an SIO, a client in a different SD calls JCSystem.getAppletShareableInterfaceObject(serverAID, param), and the server’s getShareableInterfaceObject() decides whether to return it (it can check the client’s AID and refuse). SD-to-SD sharing is gated by that AID check, not by the SD boundary. ISD-P-to-ISD-P is the case that actually differs. On an eUICC the ISD-P/profile boundary is a hard isolation boundary — GSMA mandates profile isolation (SGP.22 consumer, SGP.02 M2M) and the eUICC OS enforces that an applet in one ISD-P cannot obtain a Shareable SIO from an applet in another ISD-P. On a consumer eUICC only one profile is enabled at a time as well, so the target applet in another profile isn’t even running to answer. That block comes from platform profile isolation, not from the firewall or the SD concept. Net: within one profile, SD-to-SD Shareable is allowed and gated by the server applet’s AID check; across ISD-Ps it’s blocked by eUICC profile isolation, and moot anyway since only one profile is enabled.

Two different boundaries are being conflated. The JavaCard firewall keys on the applet context (the package group context), not on the GlobalPlatform security domain — so the SD an applet sits in does not by itself block Shareable. Your OC1230 case works in plain JavaCard/GP: the server applet exposes an SIO, a client in a different SD calls JCSystem.getAppletShareableInterfaceObject(serverAID, param), and the server’s getShareableInterfaceObject() decides whether to return it (it can check the client’s AID and refuse). SD-to-SD sharing is gated by that AID check, not by the SD boundary. ISD-P-to-ISD-P is the case that actually differs. On an eUICC the ISD-P/profile boundary is a hard isolation boundary — GSMA mandates profile isolation (SGP.22 consumer, SGP.02 M2M) and the eUICC OS enforces that an applet in one ISD-P cannot obtain a Shareable SIO from an applet in another ISD-P. On a consumer eUICC only one profile is enabled at a time as well, so the target applet in another profile isn’t even running to answer. That block comes from platform profile isolation, not from the firewall or the SD concept. Net: within one profile, SD-to-SD Shareable is allowed and gated by the server applet’s AID check; across ISD-Ps it’s blocked by eUICC profile isolation, and moot anyway since only one profile is enabled.

Can a Javacard applet in one ISDP implement `Sharable` for client applets in a different security domain? Like a “non SIM related” client applet loaded in another security domain (OC1230), or an applet in one ISDP being a Sharable client of a applet in another ISDP. Or do EUICCs just block Sharable somehow across security domains??