eUICC Profile Reference
An eUICC is a SIM that is soldered into a device. A mobile network operator cannot exchange it. The operator loads a profile onto it instead.
A profile holds the file system, the keys, and the applications of one subscription. A profile package is the file that carries a profile from the operator to the eUICC.
The Trusted Connectivity Alliance defines the format of that file in eUICC Profile Package: Interoperable Format, which the industry calls SAIP. These pages describe version 3.4.1.
Why the pages exist
Section titled “Why the pages exist”An ASN.1 module gives the structure of a profile package. The module states which elements exist, what type each element has, and how large each value can be.
The module cannot state the rest. “A package holds exactly one header, and the header comes first” is a sentence in the specification and not in the schema. Those sentences are the rules on these pages.
A profile package that satisfies the schema can still fail on an eUICC. It can put the PIN codes in the wrong context, or address an RFM instance that no security domain owns. The rules catch that class of error.
Who the pages are for
Section titled “Who the pages are for”If you write a profile package, read these pages. If you read a package that failed a check, read them too.
Each rule cites the clause of the specification that it comes from. A disagreement about a rule is therefore a disagreement about a clause.
The specification itself is not reproduced here. The Trusted Connectivity Alliance publishes it at trustedconnectivityalliance.org.
How to read these pages
Section titled “How to read these pages”Each element has a page. The page gives the type of the element, its size limit, its position in the tree, and the fields in it. The rules that constrain the element follow.
Each type has a page. The page gives the definition from the module, the fields of the type, and the elements that use it.
Each rule has a page. The page gives the requirement, the clause it comes from, the elements it applies to, and a counter-example.
The search box finds all three. Press Ctrl or Cmd and K.
What is here
Section titled “What is here”- Rules
- 112 in 19 files
- Errors
- 109
- Warnings
- 3
- Elements
- 576
- Elements with a rule
- 46
- Types
- 99
Rules on the package as a whole
Section titled “Rules on the package as a whole”14 rules judge the order and the count of the profile elements. They belong to no single element.
| Rule | Requirement | Clause | |
|---|---|---|---|
| SAIP-CARD-01 | PE-MF may be provided at most once in a profile package. | 8.1 | error |
| SAIP-CARD-02 | PE-IoT may be provided at most once in a profile package. | 8.1 | error |
| SAIP-CARD-03 | PE-PUKCodes may be provided at most once in a profile package. | 8.1 | error |
| SAIP-CARD-04 | PE-CD may be provided at most once in a profile package. | 8.3.4.2 | error |
| SAIP-CARD-05 | PE-TELECOM may be provided at most once in a profile package. | 8.3.4.3 | error |
| SAIP-CARD-06 | PE-OPT-IoT may be provided at most once in a profile package. | 8.3.4.8.2 | error |
| SAIP-CARD-07 | The MF shall be created either by PE-MF or by PE-GenericFileManagement, not by both. | 11.2.4 | error |
| SAIP-END-01 | A profile package shall contain exactly one PE-End. | 8.10 | error |
| SAIP-END-02 | The PE-End shall be the last ProfileElement. | 8.10 | error |
| SAIP-HDR-01 | A profile package shall contain exactly one Profile Header. | 8.2.1 | error |
| SAIP-HDR-02 | The Profile Header shall be the first ProfileElement. | 8.2.1 | error |
| SAIP-IOT-01 | A Full Profile Package, whose header carries no iotOptions, shall contain neither PE-IoT nor PE-OPT-IoT. | 7.4 | error |
| SAIP-IOT-02 | An IoT Minimal Profile Package, whose header carries iotOptions, shall define its file system using at least one PE-IoT. | 7.5 | error |
| SAIP-IOT-03 | An IoT Minimal Profile Package shall not contain a PE-MF. | 7.5 | error |
Rules with more than one subject
Section titled “Rules with more than one subject”The context of these 3 rules names no single element. They appear here, and not on an element page. A rule that is absent from the documentation is invisible. A rule in the wrong place gets corrected.
| Rule | Requirement | Clause | |
|---|---|---|---|
| SAIP-AKA-05 | ssimParameters shall be provided only in the context of an SSIM. | 8.4.2 | error |
| SAIP-FCP-15 | A BER-TLV file shall carry its TLVs in fillFileContent alone, so fillFileOffset shall not be used. | 8.3.2 | error |
| SAIP-PEID-02 | Every ProfileElement other than the Profile Header shall carry an identification. | 7.1 | error |
Names that are not elements
Section titled “Names that are not elements”These 3 names are in the schema tree, and a profile author writes none of them. asn1c uses the name of a type where a member has no name of its own.
OBJECT_IDENTIFIER OCTET_STRING SEQUENCE