01

“验证”和“鉴权”

是个啥

这是一种和个人信息的“查询/共享/对外提供”很像但又不同的个人信息处理活动。

先举俩栗子：

·       二要素认证

这是社交APP一定要满足的合规要求，大家一定有对应的生活体验。

《互联网用户账号信息管理规定》第9条规定：“互联网信息服务提供者为互联网用户提供信息发布、即时通讯等服务的，应当对申请注册相关账号信息的用户进行基于移动电话号码、身份证件号码或者统一社会信用代码等方式的真实身份信息认证……”

就是因为这个要求的存在，我们注册每一个社交APP的时候，都需要提交实名信息。APP在收集了用户提交的“姓名+手机号”的二要素信息，或者“姓名+手机号+身份证号+银行卡号”的四要素信息后，就需要和第三方数据源（例如电信运营商/商业银行）核验，用户提交的信息是不是真实准确。

完成核验后，APP可以得到的反馈是“信息准确/不准确”，但无论是否准确，核验服务提供方都不会进一步提供额外的个人信息给APP运营主体。

·       人脸身份验证

《人脸识别技术应用安全管理办法》第11条规定：“应用人脸识别技术验证个人身份、辨识特定个人的，鼓励优先使用国家人口基础信息库、国家网络身份认证公共服务等渠道实施，减少人脸信息收集、存储，保护人脸信息安全。”

这也是我们生活中十分常见的场景，比如线上办理各种政务，或者在银行办理大额转账，往往都需要进行“人脸验证”环节，这个时候APP能做到的，至多是通过你的手机摄像头采集你的人脸照片和人脸信息（也就是加工提取出你的人脸特征值）。

但是再接下去，APP就需要把你的人脸特征值和某个特定的数据库中记载的特征值进行比对，才能知道正在操作APP的你到底“是不是你本人”。

在这个过程中，个人信息的处理逻辑和上面的例子高度相似。APP可以得到的验证反馈是“人脸信息正确/不正确”，但无论是否正确，核验服务提供方都不会进一步提供额外的个人信息/人脸信息给APP运营主体。

上面两个例子，就是最常见的“个人信息验证”和“个人信息鉴权”。它像极了“个人信息的查询”，但是显而易见地，两者又确实有区别。

02

验证个人信息

是个啥样的个人信息处理活动

它是一个这样的个人信息处理过程：

简单总结一下，它包含如下三个步骤：

·    传输：APP运营主体作为验证服务的需求方需要首先将“待验证”的个人信息数据样本（也就是APP运营主体自己向用户收集到的四要素、人脸特征值等）传输给验证服务的提供方，以供其执行所需的核对。此时，由需求方传输至核对方的信息字段就是一组个人信息形态的数据（例如：姓名+手机号+身份证号+银行卡号）；

·    验证：验证服务的提供方需要将接收到的“待核对数据样本”与其所已经掌握的数据样本进行核对，判断“待核对数据样本”与其自有数据样本是否“一致”。

·    回传：验证服务的提供方需要将“核对结果”回传至服务需求方。此时，核对方回传至需求方的数据形态仅仅是一个核对结果，并不具备个人信息的外观。例如：“一致/不一致”、“正确/不正确”、“0/1”。

做了这个拆解之后，我们就能显著地看到它和所谓的“个人信息查询”最大的区别，在这个个人信息处理活动里服务需求方从服务提供方那里并没有查询到任何额外的个人信息。

服务需求方获得的仅仅是一个“核验结果”。即使核验的结果是“不对/不一致/不正确”，服务提供方也并没有告诉服务需求方正确的信息到底是什么。

03

这到底是

什么个人信息处理关系？

这是什么个人信息处理关系？

对这个问题的回答至关重要，因为答案将直接决定和影响着对应的合规策略——到底“需要”还是“不需要”取得个人信息主体的同意/单独同意。我们知道，在APP合规设计的实务工作中，增加任何一个“同意/单独同意”，都会对用户的产品体验、用户存留率和最终的营业额/利润产生直接的影响。因此，如果能合理地解释并省去一个“同意”，必定价值巨大。

我们先来复习一下：

 

这就是《个保法》中，对于“个人信息处理活动”的主要界定：

·    全生命周期维度：从全生命周期的维度，《个保法》第4条规定：“个人信息的处理包括个人信息的收集、存储、使用、加工、传输、提供、公开、删除等”；

·    主体维度：从参与个人信息处理活动的主体数量和关系的角度，除了基础的单一主体进行处理外，《个保法》第20条、第21条分别界定了“共同处理”、“委托处理”两种特殊的个人信息处理状态。

而对于“个人信息验证和鉴权的处理关系”的讨论和界定，本质上就是围绕个保法下的三个核心概念展开，也就是“委托处理”、“对外提供”和“共同处理”。

·     委托处理：《个保法》第21条规定“个人信息处理者委托处理个人信息的，应当与受托人约定委托处理的目的、期限、处理方式、个人信息的种类、保护措施以及双方的权利和义务等，并对受托人的个人信息处理活动进行监督。受托人应当按照约定处理个人信息，不得超出约定的处理目的、处理方式等处理个人信息；委托合同不生效、无效、被撤销或者终止的，受托人应当将个人信息返还个人信息处理者或者予以删除，不得保留。未经个人信息处理者同意，受托人不得转委托他人处理个人信息。”

·     对外提供：《个保法》第23条规定“个人信息处理者向其他个人信息处理者提供其处理的个人信息的，应当向个人告知接收方的名称或者姓名、联系方式、处理目的、处理方式和个人信息的种类，并取得个人的单独同意。接收方应当在上述处理目的、处理方式和个人信息的种类等范围内处理个人信息。接收方变更原先的处理目的、处理方式的，应当依照本法规定重新取得个人同意。”

·     共同处理：《个保法》第20条规定“两个以上的个人信息处理者共同决定个人信息的处理目的和处理方式的，应当约定各自的权利和义务。但是，该约定不影响个人向其中任何一个个人信息处理者要求行使本法规定的权利。个人信息处理者共同处理个人信息，侵害个人信息权益造成损害的，应当依法承担连带责任。”

那么简单总结一下区分三者的意义：委托处理不用取得同意，而对外提供和共同处理需要取得个人信息主体的同意。

那么个人信息的“验证”和“鉴权”到底是什么数据处理关系，直接说答案：

是委托处理。

特别是对于服务需求方来说，完全是委托处理，所以不用个人信息主体的同意。

04

为什么是委托处理

为什么验证和鉴权是委托处理？ 

回答这个问题，也就是在回答究竟应该如何区分委托处理、对外提供和共同处理。我们先来做个看上去挺全的总结：

基本上大家讨论这三个概念的异同的时候，很容易检索和整理出上面的这个图，然后得出一个略显可爱的结论：三者之间在方方面面有很多的不同。

是这样吗？当然不是！

当我们在进行概念区分的时候，需要认知到有些区别要素在决定着概念的异同，而有些要素仅仅是对于不同概念的特征描述。

那么区分委托处理、对外提供和共同处理的核心要素到底是什么？其实答案非常的简单且单一，就是“个人信息处理者”的数量，只要把握住这一个要件特征，我们就能准确地区分这三个概念。

我们再来回看一下三者的概念：

·     委托处理：《个保法》第21条“个人信息处理者委托处理个人信息的，应当……”

·     对外提供：《个保法》第23条规定“个人信息处理者向其他个人信息处理者提供其处理的个人信息的，应当……”

·     共同处理：《个保法》第20条规定“两个以上的个人信息处理者共同决定个人信息的处理目的和处理方式的，应当……”

看，标准就是清楚地写在《个保法》里的，针对一个“跨主体的数据传输动作”，首先不会仅仅因为存在“跨主体数据传输”的技术事实，就天然地构成“需要单独同意”的“对外提供”。

相反，传输方和接收方的角色才是重点：

·     一个个人信息处理者：如果两者中只有一个个人信息处理者，那么就是“委托处理”，典型的例子包括“客服坐席外包”、“律师处理案件信息”等等；

·     两个独立的个人信息处理者：如果传输方和接收方互为独立的个人信息处理者，那么就是“对外提供”，典型的例子是一些类型的客户转介和导流；

·     共同作为个人信息处理者：如果传输方和接收方共同作为个人信息处理者，那么就是“共同处理”，典型的例子是一些联名活动、联合研发。

而在个人信息的验证和鉴权过程中，恰恰是因为“只存在一个”个人信息处理者——也就是收集待验证字段的服务需求方——我们才说这是一个委托处理活动。

那么问题来了，为啥只有一个个人信息处理者？

05

啥是个人信息处理者

这是理解中国体系《个保法》规则的任督二脉。

直接看定义：《个保法》第73条规定，所谓个人信息处理者，就是指在个人信息处理活动中自主决定处理目的、处理方式的组织、个人。

我们提取一下关键字，中国《个保法》体系下的“个人信息处理者”，就是“自主决定处理目的、处理方式”的主体。

任何参与个人信息处理的主体，如果它“自主决定处理目的、处理方式”，那么它就是“个人信息处理者”；如果它是根据其他主体确定的“处理目的、处理方式”处理个人信息，那么它就不是个人信息处理者。从这个视角来观察，由于《个保法》没有区分个人信息的“控制者”和“处理者”，因此从概念对等的角度来说，我国《个保法》下的“个人信息处理者”，是和GDPR下的个人信息控制者（controller）更为近似的概念。

那么啥是“个人信息的处理目的、处理方式”？

很遗憾，针对这个问题，我们国家的《个保法》并没有给出进一步的定义规则。虽然在概念设计上我国《个保法》借鉴了欧盟GDPR的立法思路，即参照了“determines the purposes and means of the processing of personal data”的表述，但并没有进一步解释和界定，什么是“目的（purpose）”、什么是“方式（means）”。

那么怎么办？

既然是参照和继受了域外法的概念，我们就去域外法下寻找可以参考的标准。幸运的是，在GDPR的术语体系下，确实有更详细的界定规则。

作为欧盟根据《通用数据保护条例》（GDPR）成立的独立监管机构欧洲数据保护委员会（European Data Protection Board，EDPB）在2021年曾正式出台过针对这一问题的解释文件Guidelines 07/2020 on the concepts of controller and processor in the GDPR(Version 2.1)。在这份指引中，对于何为“目的（purpose）”、何为“方式（means）”提供了十分合理且清晰的界定标准。

·    目的（purpose）：所谓目的，指的是数据处理的根本原因，也就是“why”，为什么要处理信息；它相对“方式”是一个更容易理解的概念；

·     方式（means）：所谓方式，指的是实现处理目的的具体手段，也就是“how”。而这个“how”相比于“why”，会难界定很多，毕竟一个数据处理活动中，涉及到太多的“how”，比如具体处理哪些信息、怎样处理信息、用什么软件处理、由哪位员工处理等等，都可以是“how”的一部分。

针对这个最最令人挠头的疑难问题，Guidelines 07/2020中作为非常有帮助的一个界定，即判断“controller”(对应我国法下的“个人信息处理者”)认定的方式（means），应当仅限于核心目的/必要目的（Essential Means），谁决定核心目的/必要目的（Essential Means），谁才是“controller”(对应我国法下的“个人信息处理者”)。

而所谓的核心目的/必要目的（Essential Means），指的是“被处理的数据类型（如姓名、地址、健康信息）”、“处理持续时间（如数据保留期限）”、“数据主体类别（如员工、客户）”等。并不包括“具体技术工具（如选择云存储服务商）”、“安全措施细节（如防火墙配置）”、“内部操作流程（如备份频率）”等等。

有了这些理论知识的武装，我们再回来判断中国法下的个人信息处理者是谁思路就能清晰很多。

哪个主体在自主决定着个人信息的处理目的（why，基于什么缘由处理个人信息）和处理方式（how，针对哪些个人信息开展什么角度的处理），哪个主体就是个人信息处理者。

06

验证/鉴权

不用个人信息主体同意

回到我们的主题上来。

在“个人信息的验证和鉴权”活动中，个人信息的处理目的和方式是什么，是由谁来决定的？

·     目的（purpose）：为啥（why）要处理，这是APP运营主体要确定APP的具体服务对象，同时满足法定的实名制合规要求。这个目的（why），是完全由APP运营主体（也就是核验服务的需求方自主决定的）自主决定的，核验服务的提供方只是单纯地（收钱）干活，完全没有自主决定；

·     方式（means）：怎么（how）去处理，是“核验”信息，核验一组信息的真实性/一致性，而不是查询对应主体的其他额外信息，不是去联名搞营销活动，这也是由APP运营主体（也就是核验服务的需求方自主决定的）自主决定的。

而至于服务提供方使用什么数据库去核验，以什么样的标准去核验，这些由于不是核心目的/必要目的（Essential Means），即使由服务提供方决定，也并不影响我们的判断。

所以我们终于有了结论：

在“个人信息的验证和鉴权”活动中，只有一个个人信息处理者，就是核验服务需求方，也就是APP运营主体。

所以，“个人信息的验证和鉴权”是委托处理，它不需要取得个人信息主体的同意。

07

结语：一点小佐证

其实这个问题从2021年《个保法》实施以来，已经经历了近4年的激烈讨论。学界和实务界的观点也有过摇摆。

在2021年的《信息技术安全 个人信息告知同意指南(报批稿)》(2021.12.26)中就曾经规定：“对用户进行告知并在得到用户明示同意后，个人信息处理者才能将个人信息交给相关身份认证机构进行认证，涉及传输敏感个人信息的，需取得用户的单独同意……”

但幸运地是，经过了多年的讨论和辨析，学界和实务界对于这个问题的判断和理解终于趋于一致，于是在《信息技术安全 个人信息告知同意指南》的正式版本中，便没有再提及上面的要求。

好了，那么今天就闲聊这么多。很有趣吧对不对？

其实这个话题还有个延伸的问题点：服务提供方核验数据时，用到了自有的数据库，那么这个动用自有数据库的动作，是啥“个人信息处理关系”？

这个就留给读者们一起思考思考吧（doge）~