表单要求填写姓名、地址、国籍、联系方式、收入或家庭资料。这样的表单，你以前已经填过某种版本。有些服务还要求上传证明文件，再由工作人员或后台系统核对文件内容与所填信息是否一致。
这时，页面上出现了一个按钮：
获取 Myinfo 数据
在用户眼中，这很像自动填表。
这么理解不算错，但还不够完整。自动填表省的是打字；Myinfo 所做的远不止这些：
Myinfo 在取得同意后，传递经核实的声明。
因此，Myinfo 与 Singpass QR 登录同属一套信任基础设施。
QR 登录回答的是：“我怎样证明自己是谁？”
Myinfo 回答的是：“我怎样授权这项服务使用关于我的特定可信信息？”
这类常见的个人资料页面让用户很容易形成一个直观印象：个人信息分属若干易于理解的类别。Myinfo 真正发挥作用的地方在于，用户同意后，服务可以从中调取特定的经核实声明。
身份验证并不会自动带来个人信息 链接到标题
身份验证告诉服务方当前用户是谁。但对许多业务来说，光知道这一点还不够。
银行可能需要身份和居住信息；保险业务可能需要人口统计资料和联系方式；政府申请则可能涉及家庭、就业或福利数据。如果 Singpass 只确认“这名用户已经登录”，用户仍得填写其余字段、上传文件，再等待核验。
更深一层的问题是，各家机构都在重复同一套核验工作。缺少可信的数据共享层，每个依赖方都不得不充当一个小型身份核验系统：收集文件、留存副本、逐项检查、纠正错误，并承担相应的数据风险。
Myinfo 之所以存在，是因为经核实的个人数据也应当纳入共享基础设施。
用户实际看到的是什么 链接到标题
不妨把它直观地看成一张包含两类字段的表单。
用户点击“获取 Myinfo 数据”后，一部分字段会从获准使用的数据源调取，并应显示为调取的数据；其余字段仍由用户自行填写。
| 表单字段 | 获取 Myinfo 数据后有什么变化 | 为什么重要 |
|---|---|---|
| 法定姓名、出生日期、国籍、登记地址 | 从获准使用的政府或参与机构数据源调取，并按原样显示 | 服务方可以将这些信息视为经核实的声明，而不是用户刚刚输入的一段文字 |
| CPF 缴交记录、估税通知书、家庭或车辆记录 | 只有依赖方获准申请且用户明确同意，才会调取 | 敏感信息按范围和用途流转，而不是一次性交出整份个人资料 |
| 电子邮箱、偏好的联系时间、配送说明、营销偏好 | 仍由用户填写或修改 | 并非每个字段都需要政府背书；有些信息只是个人偏好 |
| 数据源中缺失或已经过时的信息 | 用户可能需要联系源头机构更新，或改走不使用 Myinfo 的流程 | 表单不应悄悄将来自权威数据源的信息变成可随意修改的普通文字 |
所以，改变的不只是“填表更快了”。同一张表里既有经核实的声明，也有用户自行提供的信息，还体现了服务方可以接收哪些数据的政策决定。
共享的是声明，不是整份个人资料 链接到标题
更恰当的共享单位不是“个人资料”，而是“声明”。
一项声明，就是关于某个人的一项具体事实：
name
registered_address
nationality
mobile_number
notice_of_assessment
cpf_contribution_history
family_record
vehicle_record
并非每项服务都需要全部声明。简单的注册流程也许只需要姓名和联系方式；金融产品可能需要收入相关数据；车辆服务则可能需要驾驶或车辆记录。
这正是 scopes 的重要之处。Scopes 不只是 API 配置，也划定了政策边界：依赖方可以申请什么，用户可以批准什么，平台最终可以返回什么。
真正该问的，不是：
这项服务可以使用哪些数据？
而是：
为了这个具体目的，这项服务确实需要哪些数据？
只有将必要性与具体用途绑定，才能防止 Myinfo 沦为一条不受约束的数据通道。
同意是一条记录，不是一个复选框 链接到标题
同意既要让用户看得见，也要在后台落到实处。
用户应当清楚知道：谁在申请数据、申请哪些字段，以及为什么需要这些数据。后台也不能只留下一句笼统的“用户点击了同意”，而应记录结构更清晰的信息：
consent_grant {
user_id
client_id
purpose
approved_scopes
status
created_at
expires_at
}
具体的数据结构可以不同，但平台日后必须能够回答：
这名用户是否曾在这个时间点
允许这个依赖方为所说明的目的
访问这些声明？
这就是便利的自动填表与可问责的数据共享之间的区别。
数据来源的权威性会改变整个流程 链接到标题
如果用户在表单中输入一个地址，服务方收到的只是用户填写的文字。内容或许正确，但可信度有多高，仍要由服务方自行判断。
如果服务方通过 Myinfo 收到一项获准调取的声明，信任模式就不同了。这些数据可能仍需检查是否为最新数据，也要结合具体政策来理解；但它们不再是任意填写的文本，而可能来自参与其中的权威数据源或经过验证的缓存。
业务流程也会随之改变。只要用户同意，且服务方获准申请相关信息，就能直接取得所需声明，不必再让用户上传文件，也无须人工逐项核对。
这样可以减少重复输入和文件上传，避免信息前后不一，也能减少敏感文件的重复留存。不过，服务方同时也要承担更严格的责任：只申请真正需要的数据，只将其用于获准的目的；如果交易没有完成，也不应继续保留这些数据。
为什么必须按原样显示调取的数据 链接到标题
Myinfo 有一项原则，看似只是界面细节：从数据源调取的信息应在表单中按原样显示。
但这不只是界面问题。
如果来自权威数据源的信息在提交前可以随意修改，服务方就无法明确区分哪些内容有权威来源，哪些是用户自行提供的。更合理的做法是：
- 清楚显示源自政府的数据
- 防止权威字段在后续流程中被悄悄改动
- 允许用户继续编辑自行提供的字段
- 提交前让用户看清本次调取了哪些数据
这样既保留了数据的验证价值，也让整个流程更便于审计。
整体流程 链接到标题
简化来看，Myinfo 式流程需要分别作出两个判断：
- 用户是否已经通过身份验证？
- 在用户同意的前提下，这个依赖方是否有权访问这些声明？
流程大致如下：
用户开始填写表单
-> 依赖方申请 scopes
-> 用户查看所申请的声明
-> 记录或检查 consent grant
-> Profile / UserInfo API 验证 token 和 grant
-> 从权威数据源或缓存中获取已批准的声明
-> 只返回已批准的声明
-> 记录使用情况，以便审计并保障用户知情
身份验证与数据共享应当始终分开处理。一项服务可以知道你是谁，却不会因此自动获得调取你所有信息的权利。
便利背后的取舍 链接到标题
Myinfo 的价值在于减少流程阻力、提高数据质量。它能加快表单填写、降低错误率，也能免去反复核验文件的工作。
主要风险则是过度收集。一旦数据共享变得太容易，依赖方就可能申请超出实际需要的信息，用户可能不看内容便直接批准，敏感数据也可能继续流向下游。
因此，正确的设计绝不是“更快地共享一切”，而应遵循以下原则：
- 采用强身份验证
- 尽量缩小申请范围
- 清楚展示所申请的声明
- 取得明确同意
- 只返回已获批准的声明
- 保留数据来源的权威性
- 审计对敏感数据的访问
- 要求依赖方承担责任
用一句话概括：
Myinfo 不是换了个好听说法的自动填表。
它是一条经用户同意后开放的通道，用于在居民、政府与依赖方之间
传递经核实的事实。
因此，理解 Myinfo 时，不能只看到便利，更要将它视为信任基础设施。