Attention is currently required from: fixeria, neels, pespin.

laforge has posted comments on this change by neels. ( https://gerrit.osmocom.org/c/pysim/+/42829?usp=email )

Change subject: saip.PES.rebuild_mandatory_services(): set 5G get-identity, profile-a-x25519, profile-b-p256 ......................................................................

Patch Set 4:

(1 comment)

File pySim/esim/saip/__init__.py:

https://gerrit.osmocom.org/c/pysim/+/42829/comment/ae007c8e_acacf88f?usp=ema... : PS4, Line 1737: So, when SUCI-CalcInfo for USIM in DF.SAIP contains both key types, : # then no profile-A or B services need to be requested explicitly.

i see, so far i had a viewpoint of wide compatibility, sort of like voice codec choices: […]

The MNO has zero visibility of the eUICC capability. How would he have that? I think that's the key aspect here. The MNO only knows what they put into the profile.

Think of it from a classic USIM issuing situation: IF the operator deploys a USIM with keys for profile-a and profile-b, they would only do that if they know (based on a-priori knowledge of the USIM data sheet) that both are supported. They would also likely test that, at least if they have proper testing coverage.

in terms of eUICCs, the MNO has no idea whihc chip with what OS and whcih capabilities ends up being soldered into device X of vendor Z. The MNO also usually is not the SM-DP+ operator, but the SM-DP+ is only operated by a sub-contracted SaaS eSIM provider.

There is no standard interface by which the MNO would know about the individual capabilities of each eUICC. There is no standard database in which a MNO would track such capabilities. And last, but not least, I'm not aware of any 3GPP standardizd interface or feature influencing whatever 5GC elements that make the key selection.