StoreMetadataRequest ::= [37] SEQUENCE { -- Tag 'BF25'
	iccid Iccid,
	serviceProviderName [17] UTF8String (SIZE(0..32)), -- Tag '91'
	profileName [18] UTF8String (SIZE(0..64)), -- Tag '92' (corresponds to 'Short Description' defined in SGP.21 [2])
	iconType [19] IconType OPTIONAL, -- Tag '93' (JPG or PNG)
	icon [20] OCTET STRING (SIZE(0..1024)) OPTIONAL, -- Tag '94'(Data of the icon. Size 64 x 64 pixel. This field SHALL only be present if iconType is present)
	profileClass [21] ProfileClass DEFAULT operational, -- Tag '95'
	notificationConfigurationInfo [22] SEQUENCE OF NotificationConfigurationInformation OPTIONAL,
	profileOwner [23] OperatorId OPTIONAL, -- Tag 'B7'
	profilePolicyRules [25] PprIds OPTIONAL, -- Tag '99'
	serviceSpecificDataStoredInEuicc [34] VendorSpecificExtension OPTIONAL, -- Tag 'BF22'
	serviceSpecificDataNotStoredInEuicc [35] VendorSpecificExtension OPTIONAL -- Tag 'BF23'

}
OperatorId ::= SEQUENCE {
	mccMnc OCTET STRING (SIZE(3)), -- MCC and MNC coded as defined in 3GPP TS 24.008 [32]
	gid1 OCTET STRING OPTIONAL, -- referring to content of EF GID1 (file identifier '6F3E') as defined in 3GPP TS 31.102 [54]
	gid2 OCTET STRING OPTIONAL -- referring to content of EF GID2 (file identifier '6F3F') as defined in 3GPP TS 31.102 [54]
}
RulesAuthorisationTable ::= SEQUENCE OF ProfilePolicyAuthorisationRule
ProfilePolicyAuthorisationRule ::= SEQUENCE {
	pprIds PprIds,
	allowedOperators SEQUENCE OF OperatorId,
	pprFlags BIT STRING {consentRequired(0)}
}

PprIds ::= BIT STRING {-- Definition of Profile Policy Rules identifiers
	pprUpdateControl(0), -- defines how to update PPRs via ES6
	ppr1(1), -- Indicator for PPR1 'Disabling of this Profile is not allowed'
	ppr2(2) -- Indicator for PPR2 'Deletion of this Profile is not allowed'
}

校验的核心逻辑是：用 GetRatResponse 中的授权规则表（RAT），去匹配 StoreMetadataRequest 中 Profile 携带的策略规则（PPR）和 Profile 所有者（Profile Owner），判断该 Profile 是否被允许安装，以及是否需要用户额外同意。

SGP.22 规范中 LPA（本地 Profile 助手）的验证流程明确指出：如果 Profile 元数据中包含 PPR，LPA 必须根据 RAT 检查这些 PPR 是否被允许。eUICC 上的 Profile Policy Enabler 在安装时也会执行类似的验证。

各字段的作用与生效时机

生效顺序： pprIds → allowedOperators → pprFlags，逐层筛选。

详细校验步骤

步骤 0：前置判断——profilePolicyRules 是否存在

• 如果 profilePolicyRules 不存在：说明该 Profile 不携带任何策略规则，无需进行 PPR 授权校验，直接允许安装（仍可进行常规的 Profile 元数据校验，如 ICCID 匹配等）。
• 如果 profilePolicyRules 存在：进入步骤 1。

步骤 1：遍历 RAT，匹配 pprIds

对于 StoreMetadataRequest 中 profilePolicyRules 里的每一个 PPR（记为 targetPpr）：

在 GetRatResponse.rat（即 RulesAuthorisationTable）中查找所有满足以下条件的 ProfilePolicyAuthorisationRule：

• 该规则的 pprIds 包含 targetPpr，或者
• 该规则的 pprIds 为通配（无显式 PPR 限制，表示适用于所有 PPR）。

如果找不到任何匹配的 RAT 条目，则该 PPR 不被允许，安装应被拒绝。

注意：SGP.22 规定，如果 RAT 中没有针对某个 PPR 的条目，则该 PPR 是被禁止的。

步骤 2：匹配 allowedOperators

对于步骤 1 中找到的每一条候选 RAT 条目，检查 StoreMetadataRequest.profileOwner 是否在 allowedOperators 中：

• allowedOperators 是一个 SEQUENCE OF OperatorId，可能包含：
  • MCC/MNC 形式的 Operator 标识
  • GID1/GID2 形式的 Group Identifier
  • 通配符 *（表示允许任意 Operator）

匹配规则：

• 如果 allowedOperators 中包含 *，则任意 profileOwner 都匹配成功。
• 否则，需要 profileOwner 的 MCC/MNC、GID1 或 GID2 与 allowedOperators 中的某一项精确匹配。

如果所有候选 RAT 条目的 allowedOperators 都不匹配 profileOwner，则该 PPR 不被允许，安装应被拒绝。

步骤 3：检查 pprFlags —— 是否需要用户同意

对于步骤 2 中匹配成功的 RAT 条目，检查其 pprFlags：

• 如果 pprFlags 中 consentRequired 位被置位（即 pprFlags 包含 consentRequired），则表示：该 Profile Owner 虽然被允许设置此 PPR，但需要用户额外的强确认（Strong Confirmation）才能安装。
• 如果 consentRequired 未置位，则不需要额外用户同意。

When set to ‘true’, it indicates that for all Profile Owners allowed by the ‘Allowed Operators’ field the LPA SHALL get the End User Consent for the related PPR to install the Profile.
When set to ‘false’, it indicates that this End User Consent is not mandatory.
当设置为“true”时，表示对于“允许的操作员”字段所允许的所有配置文件所有者，LPA（位置平台应用程序）应获取相关PPR（产品/服务请求）的最终用户同意，以便安装配置文件。
当设置为“false”时，表示此最终用户同意并非强制性的。

多个 RAT 条目匹配同一 PPR 时的优先级规则：
SGP.22 规定：当一个 Profile Owner 在多条 PPAR 中都被允许时（显式列出或通配匹配），应使用第一条匹配到的 PPAR 的 End User Consent required 值。

When a Profile Owner is allowed in several PPARs (explicitly listed or matching a wild card), the ‘End User Consent required’ field value of the first of these PPARs SHALL be used.

步骤 4：综合决策

对所有 PPR 完成上述校验后：

profilePolicyRules 不存在时，还需要校验 profileOwner 吗？

不需要。

理由如下：

1. 校验的触发条件是 profilePolicyRules 的存在。SGP.22 明确规定：”If the ProfileMetadata contains PPR(s), the LPAd SHALL check if the PPR(s) is/are allowed based on the Rules Authorisation Table”。如果 Profile 元数据中不包含任何 PPR，则不触发基于 RAT 的 PPR 授权校验。
2. profileOwner 在 PPR 校验流程中的唯一作用，是作为”请求设置 PPR 的 Operator 身份”去与 RAT 中的 allowedOperators 做匹配。如果根本没有 PPR 需要设置，这个匹配步骤就没有执行的必要。
3. 其他独立的校验（如 profileOwner 的 MCC/MNC 与 Profile 内部 EF IMSI 的一致性校验）与 RAT 授权校验是不同的机制，即使 profilePolicyRules 不存在，这类一致性校验可能仍然需要执行，但它不属于”根据 GetRatResponse 校验是否允许安装”的范畴。

SGP.22 v1.2 Profile Download and Installation 章节明确指出

If the ProfileMetadata contains PPR(s), the LPAd SHALL check if the PPR(s) is/are allowed based on the Rules Authorisation Table defined in section 2.9.2.3. If one or more PPR(s) are not allowed, the LPAd SHALL continue the Sub-procedure “Profile Download and installation – Download rejection” hereunder with reason code ‘PPR not allowed’. If any PPR is subject to additional End User consent according to the RAT, LPAd SHOULD ask for Strong Confirmation by showing relevant information concerning the PPR(s). This information SHOULD include the consequences of the Profile Policy Rule to the End User. This message SHALL be formulated in a descriptive and non-discriminatory manner (e.g. for “Non-Delete” Profile Policy Rule: “The profile that you are about to install can be deleted only under the terms you have agreed with your service provider. Enter your PIN to approve installation”). If the Profile Metadata does not contain any Profile Policy Rule(s) subject to additional End User consent, the LPAd SHALL ask for Simple Confirmation (e.g., simple ‘Yes’ or ‘No’ or ‘Not Now’) on the Profile download.

补充说明

关于 pprFlags 的编码细节： pprFlags 是一个 BIT STRING，目前只定义了 consentRequired(0) 一个位。由于 BIT STRING 的编码特性，pprFlags { }（空）和 pprFlags { consentRequired } 是两种不同的编码状态：前者表示该位为 0（不需要用户同意），后者表示该位为 1（需要用户同意）。

关于 allowedOperators 的 OperatorId 类型： OperatorId 是一个 CHOICE 类型，可以包含 mccMnc、gid1、gid2 等形式。校验时需要根据 profileOwner 中实际携带的 Operator 标识类型，在 allowedOperators 列表中查找同类型的精确匹配项。

关于 eUICC 侧的校验： 上述流程主要描述的是 LPA 侧的校验逻辑。实际上，eUICC 上的 Profile Policy Enabler 在 Profile 安装时也会独立执行 PPR 验证。LPA 侧的校验是为了提前向用户展示信息并获取必要的确认，而 eUICC 侧的校验是最终的强制关卡。

核心约束规则

首先列出所有相关约束（各版本规范表述一致）：

对 profileOwner

ES8 接口 Function: StoreMetadata中有记录

The data object profileOwner is optional. It SHALL be present if the profilePolicyRules data object is present. In this instance the mccMnc field SHALL not specify any wildcard (‘E’) digits. The data object SHALL NOT be present if the Profile does not contain an EFIMSI.

数据对象profileOwner是可选的。如果profilePolicyRules数据对象存在，则该字段必须存在。在此情况下，mccMnc字段不得包含任何通配符（’E’）数字。如果配置文件不包含EFIMSI，则该数据对象不应存在

对 profilePolicyRules

ES8 接口 Function: StoreMetadata中有记录

The data object profilePolicyRules is optional. It SHALL not be present for a Profile that has no PPR set. Otherwise the profilePolicyRules SHALL identify all the PPRs set in the Profile. If the profilePolicyRules data object is not present, all PPR bits of the Profile SHALL be considered zero. The PrdIds type is defined in section 2.8.1.1. The data object SHALL NOT be present if the Profile does not contain an EFIMSI.

数据对象profilePolicyRules是可选的。对于未设置PPR的配置文件，不应出现此数据对象。否则，profilePolicyRules应标识配置文件中设置的所有PPR。如果profilePolicyRules数据对象未出现，则配置文件中的所有PPR位应视为零。PrdIds类型在第2.8.1.1节中定义。如果配置文件不包含EFIMSI，则不应出现此数据对象。

四种组合逐一分析

组合①：两者都不存在 允许

profileOwner          = absent
profilePolicyRules    = absent

• 规则 (F)：Profile 无 PPR → profilePolicyRules 不应存在
• 规则 (B)：后件（profilePolicyRules 存在）不成立 → profileOwner 不需要强制存在
• 规则 (C)/(I)：若 Profile 无 EF_{IMSI}，两者都不应存在，这里恰好都不存在

典型场景：Profile 没有设置 PPR（所有 PPR bit 为 0），且 Profile 不包含 EF_{IMSI}（或虽包含但 SM-DP+ 选择不提供 profileOwner）。

组合②：只存在 profileOwner

仅部分情况下允许，但无实际意义

profileOwner          = present
profilePolicyRules    = absent

• 规则 (F)：Profile 无 PPR → profilePolicyRules 不应存在 （此处满足）
• 规则 (B)：profilePolicyRules 不存在，不触发”SHALL be present”约束
• 规则 (C)：是否允许取决于 Profile 是否包含 EF_{IMSI}：
  • 包含 EF_{IMSI} → profileOwner 可存在 （规范未明确禁止）
  • 不包含 EF_{IMSI} → profileOwner SHALL NOT be present
• 规则 (D)：若存在，mccMnc 不能含通配符 ‘E’

结论：从纯语法约束看，当 Profile 有 EF_{IMSI} 且无 PPR 时，规范并没有明文禁止单独存在 profileOwner。但在实际设计中 不推荐、也没有实际用途，因为 ：

• profileOwner 的主要设计目的是配合 PPR 进行 RAT 校验（profileOwner SHALL be present if profilePolicyRules is present）
• 无 PPR 时 Profile 直接允许安装，profileOwner 不参与任何校验
• 规范中未定义”无 PPR 时单独存储 profileOwner”的合理场景

组合③：只存在 profilePolicyRules 不允许

profileOwner          = absent
profilePolicyRules    = present

• 规则 (B) ：profileOwner SHALL be present if profilePolicyRules is present → 但这里 profileOwner 不存在
• 规则 (F) ：profilePolicyRules 存在说明 Profile 至少有一个 PPR
• 规则 (I)：若 Profile 不含 EF_{IMSI} 则不应用存在 （双重重叠违规）

结论：明确违反规范。只要 profilePolicyRules 存在，profileOwner 就 必须 同时存在 。SM-DP+ SHALL NOT 生成这种组合。

组合④：两者都存在 标准情况，允许

profileOwner          = present
profilePolicyRules    = present

• 规则 (B) ：profileOwner 存在，满足”SHALL be present if profilePolicyRules is present”
• 规则 (F) ：profilePolicyRules 存在说明 Profile 有 PPR 设置
• 规则 (G) ：profilePolicyRules 标识 Profile 中所有的 PPR
• 规则 (C)/(I)：Profile 必须包含 EF_{IMSI}，否则两者都不应存在
• 规则 (D) ：mccMnc 中不能含通配符 ‘E’

典型场景：Profile 设置了 PPR（如 PPR1=禁止禁用 和/或 PPR2=禁止删除），需要标识 Profile Owner 用于 RAT 校验。这是规范中定义的 标准组合 。

最终结论矩阵

因为规范中 profilePolicyRules 和 profileOwner 之间存在单向强依赖关系——profilePolicyRules 存在则 profileOwner 必须存在（规则 B），而无 PPR 时 profilePolicyRules 又不允许存在（规则 F）——所以：

允许的只有 ①（皆无）和 ④（皆有）这两种组合；③（仅有 PPR）被明确禁止；②（仅有 Owner）在无 PPR 时有 EF_{IMSI} 时虽不被规范明文禁止，但无实际设计用途。

ProfilePolicyAuthorisationRule.pprIds和StoreMetadataRequest.profilePolicyRules比较判断

ProfilePolicyAuthorisationRule 中的 pprIds 和 StoreMetadataRequest 中的 profilePolicyRules 具有完全相同的 ASN.1 类型定义，都是 PprIds ::= BIT STRING { pprUpdateControl(0), ppr1(1), ppr2(2) }。因此它们的比较不是简单的“相等”或“不等”，而是按位进行的子集包含检查。

下面详细说明比较的语义、方法和注意事项。

1. BIT STRING 的语义：位即集合

PprIds 是一个 BIT STRING，其中每个位代表一个特定的 Profile Policy Rule（PPR）标识：

• 在 ProfilePolicyAuthorisationRule.pprIds 中：某位为 1 表示该授权规则允许对应的 PPR 被设置。
• 在 StoreMetadataRequest.profilePolicyRules 中：某位为 1 表示该 Profile 实际请求设置对应的 PPR。

因此，比较的本质是：检查 Profile 请求设置的每一个 PPR，是否都在 RAT 授权规则允许的范围内。

2. 比较逻辑：子集检查

对于一条具体的 ProfilePolicyAuthorisationRule，设其 pprIds 为 allowed，StoreMetadataRequest 中的 profilePolicyRules 为 requested。比较规则是：

requested 中所有置 1 的位，在 allowed 中必须也置 1。
即：requested 是 allowed 的子集。

用位运算表达为：

(requested & ~allowed) == 0

或者等价地：

(requested & allowed) == requested

如果结果为 true，表示该请求的 PPR 集合被这条 RAT 规则完全允许；如果为 false，则存在至少一个请求的 PPR 未被允许。

注意：allowed 中为 1 但 requested 中为 0 的位是允许的，这表示该授权规则还可以允许其他 PPR，但本次 Profile 没有请求它们。

3. 结合 allowedOperators 和 pprFlags 的完整校验

由于 RAT 中可能有多条 ProfilePolicyAuthorisationRule，且每条规则都有各自的 allowedOperators 和 pprFlags，实际校验时不能简单地对整个 pprIds 做一次子集检查，而需要针对 requested 中的每一个置 1 的位，分别查找匹配的 RAT 条目。

具体流程如下：

1. 遍历 requested 中每一个置 1 的 PPR 位（例如 ppr1、ppr2 等）。
2. 在 GetRatResponse.rat 中查找候选 RAT 条目，条件为：
   • 该条目的 pprIds 中对应位也为 1；
   • 并且该条目的 allowedOperators 与 StoreMetadataRequest.profileOwner 匹配（精确匹配或通配符 *）。
3. 如果某个 PPR 位找不到任何匹配的 RAT 条目，则该 PPR 不被允许，安装应被拒绝。
4. 如果找到匹配条目，再检查该条目的 pprFlags 中 consentRequired 是否置位，决定是否需要用户强确认。

换句话说，pprIds 的比较是逐位查找，而不是对整个 BIT STRING 做一次性相等比较。

4. 多个 RAT 条目时的处理

如果存在多条 RAT 条目，它们的 allowedOperators 都匹配 profileOwner，但 pprIds 不同，可以将这些条目的 pprIds 取并集，得到一个“总允许集合” allowedTotal。然后检查：

(requested & ~allowedTotal) == 0

但需要注意：pprFlags 中的 consentRequired 必须与具体授权该 PPR 的那条 RAT 条目关联。因此，更严谨的做法是逐位查找：对于每个请求的 PPR，找到第一条满足 allowedOperators 匹配且 pprIds 对应位为 1 的 RAT 条目，并使用该条目的 pprFlags 来判断是否需要用户同意。

SGP.22 规范规定：当一个 Profile Owner 在多条 PPAR 中都被允许时，应使用第一条匹配到的 PPAR 的 consentRequired 值。

5. 特殊情况：空 BIT STRING 或不存在

• profilePolicyRules 不存在：表示 requested 为空集（所有位为 0），不需要进行任何 PPR 授权校验，直接允许安装（仍可进行其他常规校验）。
• profilePolicyRules 存在但所有位为 0：同样视为没有请求任何 PPR，无需校验。
• pprIds 为空 BIT STRING（所有位为 0）：表示该 RAT 规则不允许任何 PPR。此时任何请求的 PPR 都无法与它匹配。
• pprIds 中包含 pprUpdateControl(0)：该位通常用于控制后续通过 ES6 更新 PPR 的权限，在安装时的 profilePolicyRules 中可能不会出现。但比较规则相同：如果请求中包含了 pprUpdateControl，则 RAT 中对应位也必须为 1。

6. 示例

假设：

• StoreMetadataRequest.profilePolicyRules 请求了 ppr1 和 ppr2：

  位: 2 1 0 值: 1 1 0 (二进制，ppr2=1, ppr1=1, pprUpdateControl=0)

• 某条 ProfilePolicyAuthorisationRule 的 pprIds 允许 ppr1 和 ppr2：

  位: 2 1 0 值: 1 1 0

  则 requested & ~allowed = 0，匹配成功。

• 如果 pprIds 只允许 ppr1：

  位: 2 1 0 值: 0 1 0

  则 requested & ~allowed = 0b110 & ~0b010 = 0b110 & 0b101 = 0b100 ≠ 0，表示 ppr2 未被允许，匹配失败。

7. 总结

因此，pprIds 和 profilePolicyRules 的比较是逐位授权检查：Profile 请求设置的每一个 PPR，都必须在 RAT 中找到对应位为 1 且 allowedOperators 匹配的授权规则，否则安装被拒绝。

• Next Post →