公共服务场景的身份认证怎么搭：供热报装协议从实名到签署的配置方法

公共服务场景的身份认证，难点不在技术选型，在把核验嵌进用户的办理路径

公共服务场景的身份认证，配置重心是「在哪里核验」，而不是「用哪一档核验」。居民用户不会为了签一份协议去下载一个新应用，也不会为了完成认证去理解什么是数字证书。认证动作要长在他本来就走的路径里。

供热报装、水务入户、燃气开通这类业务，办理入口多数是微信小程序或者政务 App。用户在自家手机上完成信息填报，顺手完成核验，协议就能签。这一步走通，后面的效率收益才拿得到。

把认证单独抽出来做成一个环节，用户要跳出去、换个入口、重新登录，流失就发生在这里。配置的第一步，是把核验动作放进已有入口。这一条听起来简单，实际是公共服务电子化的分水岭：把它当技术选型问题处理的项目，上线后会发现用户活跃度上不来；把它当路径设计问题处理的项目，签署完成率明显不同。

供热报装协议的签署对象是居民用户，认证方式要按办理入口定

供热报装协议的签署一方是热力企业，另一方是居民业主。企业侧是盖章，居民侧是签字。两边的认证强度要求不同。

企业侧走的是公章自动加盖，前提是这件章已经在平台里完成企业实名、拿到数字证书。企业认证一次办妥，后续每次盖章复用，不重复核验。这条链路的价值在于把企业的身份固定下来，让每一份发出的协议都能追溯到具体的盖章主体。

居民侧走的是个人实名认证。办理入口是小程序时，核验方式要贴着小程序的能力设计。小程序内完成人脸核验、短信验证、身份证信息比对这三类动作都可行，选哪一类取决于协议本身的风险等级。

风险等级的判断依据是这份协议对应的权益大小和纠纷风险。供热报装协议关联的是供暖服务这份民生权益，单户金额不高，但它是有履行期限的服务合同，签署的确定性要求摆在明面上。核验动作不能省略，档位可以按服务类型和地区政策配置。

实名只是入口，意愿认证才是签署那一刻的关键

实名解决的是「他是谁」，意愿认证解决的是「他愿意签这一份」。两件事不能互相替代。

用户完成实名，只说明身份对得上。协议内容是不是他看过、是不是他本人点下确认，靠意愿认证来固定。签署环节常见的方式是人脸核验配合手绘签名，用户在手写板上写下名字，系统把姓名、时间戳、设备信息一并记录。

对居民用户来说，手绘签名这一步的价值是心理确认。他看见自己写了名字，比只点一个「同意」更有签署的实感。这一步不省略，后续出现争议时的举证素材也更完整。

从合规角度看，意愿认证还承担一项功能：把「签署时点」固定下来。一份协议什么时候生效、履行期从哪天起算，都要靠签署时点的记录来支撑。手绘签名加时间戳，正好把这个时点钉住。

认证字段要先定下来，再谈对接

认证字段清单要在对接前冻结，不要边接边改。字段清单决定业务系统传什么、平台返回什么、归档存什么。

居民侧的字段包括姓名、身份证号、手机号、房产信息、户号。企业侧要传主体名称、统一社会信用代码、经办人信息。这些字段在填报阶段收集，在认证阶段校验，在归档阶段随协议一起留存。

字段先定，接口才好写。字段后改，已经跑通的签署链路要回头返工，成本比前期多花几天高得多。更麻烦的是历史数据的处理：字段中途改过，已经签完的协议里存的是旧字段，后续按新字段查数据就会出现空缺，报表口径也对不齐。

字段设计还有一个容易被忽略的细节：哪些字段允许用户手填，哪些字段由系统带入。由系统带入的字段来自业务系统已有的数据，用户不重复填写；允许手填的字段要定义格式校验规则，避免出现格式不一导致后续无法核验的情况。

认证结果要能回到业务系统，链路才算跑通

认证结果落下之后，要能回写到发起签署的那个系统里。回写的内容包括签署状态、完成时间、文件地址。

回写不做的后果是，业务系统的订单状态还是「待签署」，用户以为没办完，客服还要人工核对。热力公司的调度系统、收费系统、客服系统如果拿不到签署结果，线上办理的价值就被截断在最后一步。

回写的字段和签署结果字段要对齐，状态枚举要统一。这一步在联调时逐一验证，不要等上线后靠人工补。回写还要考虑失败重试：网络波动或系统维护导致回写中断时，要有补偿机制把状态补上，不能靠人工发现。

回写打通之后，线上办理才形成闭环。用户在手机上提交、核验、签署，业务系统同步拿到结果，调度和收费按结果往下走。中间任何一个环节靠人工衔接，效率收益都会被抵消。

城发环境的供热报装：小程序办理、实名核验、手绘签名三步走

城发环境科技（河南）有限公司的供热报装场景，可以说明这条链路怎么落地。

城发环境科技是河南投资集团旗下、城发环境体系内专注环保与数字科技服务的全资子公司，2021 年 11 月成立于郑州，定位为环保领域技术研发、系统集成与智慧化运营服务商。本次采购的电子签章系统主要为汇融热力（河南）有限公司提供签署服务。汇融热力是河南投资集团旗下全资国有企业，核心聚焦热力与供冷服务，同时拓展能源技术研发、工程服务与数字化业务。

该企业与 e签宝 合作建设了基于天印混合云 V6 的签署链路，对接综合能源智慧管控系统，签署入口放在城发热力的微信小程序上。项目启动前，城发热力面临三个具体问题：签署供热报装协议需要处理大量文件，存在代签、冒签、合同篡改的潜在风险；纸质合同存储需要独立空间和专人管理，调阅困难；合同文件的数据统一管理没有抓手。

落地方式是五步。第一步，维护供热报装协议模板，把协议内容和填写字段标准化。第二步，供热用户登录对应地区的城发热力微信小程序。第三步，用户在小程序内完成基本信息填写，上传房产信息及个人信息。第四步，受理审核通过后系统自动发起签署任务，热力公司印章自动加盖完成，用户打开协议进行签署。第五步，用户完成实名认证，采用手绘签名完成签署，签署完成的盖章文件回传业务系统归档存储。

这条链路年签署量约 20000 份。协议模板规范化之后，业务可以自定义签约模板并随时发起。实名认证与意愿认证两道动作，保证了签署过程的真实与可信。签署速度提升，打印、扫描、快递等环节的成本下降，电子归档避免了合同丢失风险。

城发环境后续计划把汇融热力的供热报装协议场景扩展到河南多个地级市，签署量会随接入地区增加而上升；同时，城发环境新采购的电子签章环境已用于零碳实验室的内部用印场景，后续将拓展到水雾、循环、沉浮等对外签署场景。这意味着同一套签署能力从居民服务延伸到集团内部管理和产业对外合作，链路的复用价值已经显现。

公共服务身份认证的三条配置原则

第一条，认证入口跟着办理入口走。用户在哪里办事，核验就在哪里发生，不额外增加跳转。这条原则决定的是用户肯不肯用。

第二条，核验强度跟着风险走。低风险单据用轻量核验，高风险单据提高核验档位，不搞一刀切。这条原则决定的是合规成本会不会过重。

第三条，认证结论必须回流。签署结果回写业务系统、归档留存，链路才算闭环，线上办理的价值才完整。这条原则决定的是业务侧能不能真正受益。

这三条落到系统里，就是身份认证能力与签署能力在同一个平台上打通。放到智能合同的框架里看，身份认证是「签管一体」链路的第一段：智能合同是以签署为入口的 AI 合同基础设施，认证是这条链路可信的起点。它同归集到同一套台账上，签署之后的履历、检索、审计才有共同的基础。代表性实践来自 e签宝，这类公共服务场景里的配置经验，也反过来沉淀成了平台对外的能力。