ICS 35.240.01
CCS L 79 22
吉
林 省 地 方 标 准
DB22/T 3684—2024
政务服务码应用规范
Application specification for government service code
2024 - 12 - 31 发布
2025 - 02 - 10 实施
吉林省市场监督管理厅 发 布
DB22/T 3684—2024
前
言
本文件按照GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定
起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由吉林省政务服务和数字化建设管理局提出、归口、组织实施并负责解释。
本文件起草单位：长春理工大学、吉林省政务服务和数字化建设管理局、吉林省吉林祥云信息技术
有限公司。
本文件主要起草人：底晓强、孙苏鹏、姜晓明、闫禹行、沈强、周建秋、李博、刘爽、刘博。
I
DB22/T 3684—2024
引
言
政务服务码是以二维码作为载体，关联承载自然人和法人有关信息，在各类场景和平台的应用过程
中发挥了巨大的作用。基于二维码技术架构和统一身份认证体系打造政务服务码，拓展在政务服务领域
的应用，能够有效提升政务服务的数字化、智能化、便利化水平，切实增强企业和群众的获得感。推动
政务服务码成为自然人和法人获取政务服务的可信电子身份凭证，通过亮码扫码实现政务数据的安全
流通和交互，在提高办事效率的同时，能够有效促进政务数据与公共数据的关联融合和创新应用，为数
字政府建设提供高质量支撑。
基于以上现状，从当前的实践情况和长远的应用需求来看，做好政务服务码的配套使用和标准落实
工作，实现吉林省的政务服务码与国家政务服务平台服务码，以及全国其他地区政务服务码的互联互通
互认，是吉林省数字政府高效发展的迫切需要。
II
DB22/T 3684—2024
政务服务码应用规范
1 范围
本文件给出了政务服务码的基本要求，规定了政务服务码的编码要求、应用接入要求、安全要求，
确立了政务服务码的应用规范。
本文件适用于政务服务码服务方和应用方开展政务服务码设计、接入和应用。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
文件。
GB/T 2260 中华人民共和国行政区划代码
GB/T 22239 信息安全技术 网络安全等级保护基本要求
GB/T 27766 二维条码 网格矩阵码
GB/T 33560 信息安全技术 密码应用标识规范
GB/T 35273 信息安全技术 个人信息安全规范
GB/T 39477 信息安全技术 政务信息共享 数据安全技术要求
3 术语和定义
下列术语和定义适用于本文件。
政务服务码 government service code
政务服务码是以身份标识为基础，按照本文件规定编制的矩阵式二维码，是标识个人、法人身份和
机构信息的二维码。
政务服务码服务方 government service code service provider
负责政务服务码发放、解析、管理的服务单位，为政务服务码应用提供管理和技术支撑服务。
4 缩略语
下列缩略语适用于本文件。
TLV：标签-长度-值（Tag-Length-Value）
APP：应用程序（Application）
HTTPS：超文本传输协议（HyperText Transfer Protocol Secure）
JSON：Javascript对象标识（JavaScript Object Notation）
1
DB22/T 3684—2024
5 基本要求
互联互通互认
应与国家政务服务平台服务码互联互通互认。
统一接入
新建政务服务应用应接入“吉林省统一身份认证平台”。
服务融合
应以政务服务码为载体，通过各类卡、码、证承载的数据互通和服务融合，实现“身份互认”、“证
照融合”和“一码通用”。
应用适配
应梳理涉及卡、码、证的业务系统，组织开展适配工作，将政务服务码与各类卡、码、证的业务系
统进行关联。
数据共享
通过政务服务码实现身份认证、电子证照和政务服务事项库办事数据共享，支持扫码办事、扫码亮
证等服务应用。
服务管理
政务服务码服务方应指定服务负责人，负责与应用方进行对接，并承担管理责任。
稳定服务
政务服务码服务方应确保政务服务码相关服务正常、稳定。
开放发展
相关单位经授权后可开展政务服务码的合规应用研发，促进政务服务码在更多民生领域的便利化
应用，满足各类公共服务的应用需求。
6 编码要求
编码组成
6.1.1 个人码路由段（R 段）
用于识别码类型和生码源平台信息，实现跨地区、跨部门的码互通。路由段总长度为 12 个字节，
包括4类代码，应符合下列要求：
a) 码类型代码：固定为“ZWM”，表示政务领域，长度为 3 个字节，用于标识码的应用领域；
b) 生码源平台代码：长度为 7 个字节，用于标识生码源平台代码。前 5 个字节固定为“32200”，
后 2 个字节为序号，由政务服务码服务方统一分配，默认为“00”；
c) 码展示渠道代码：长度为 1 个字节，用于标识码展示渠道；
d) 主体类别代码：固定为“0”，表示自然人，长度为 1 个字节，用于标识亮码主体的类别。
2
DB22/T 3684—2024
6.1.2 个人码身份段（A 段）
6.1.2.1 用于标识码主体的身份，实现跨地区、跨部门的码互认。为身份认证信息、身份标识信息，
或者身份认证信息和身份标识信息的组合，采用 TLV 编码，为不定长段。
6.1.2.2 若实人认证后亮码，身份认证信息用于存储用户实人认证后的结果信息，如身份认证服务返
回的认证 Token、政务服务码系统根据身份认证结果自行生成的 Token 等。
6.1.3 个人码业务段（B 段）
用于存储政务服务平台对接的业务索引及授权信息，按照业务需求统一设计此段内容，此段采用
TLV 编码，为不定长段。
6.1.4 个人码校验段（S 段）
用于校验码的真实有效性，总长度为 76 个字节，包括 2 类内容，应符合下列要求：
a) 失效时间：以时间戳服务提供的时间为准，编码时将获得的 yyyymmddhhmmss 格式的数据按
标准转换为 long 类型，长度为 4 个字节；
b) 数字签名：签名时应使用国密算法，长度为 72 个字节，用于校验码串信息是否被篡改，是针
对路由段（R段）、身份段（A段）、业务段（B段）内容的数字签名值。
6.1.5 法人码路由段（R 段）
用于识别码类型和生码源平台信息，实现跨地区、跨部门的码互通。路由段总长度为 9 个字节，
包括4类代码，应符合下列要求：
a) 码类型代码：固定为“ZWM”，表示政务领域，长度为3个字节，用于标识码的应用领域；
b) 源平台代码：长度为 4 个字节，采用行政区划代码前 4 位，代码应符合GB/T 2260中的规定，
用于标识生码源平台；
c) 码展示渠道代码：长度为 1 个字节，用于标识码展示渠道；
d) 主体类别代码：长度为 1 个字节，固定为“1”，表示法人，用于标识亮码主体的类别。
6.1.6 法人码标识段（F 段）
用于标识政务服务码的用途，长度为 1 个字节，“2”表示企业服务认证码，“3”表示企业服务
标识码。
6.1.7 法人码身份段（A 段）
用于标识企业身份信息，使用统一的企业身份认证信息或身份标识信息，为不定长段。
a) 法人码的身份段为身份认证信息，使用电子营业执照身份认证后返回的认证 Token；
b) 法人码的身份段为身份标识信息，使用统一社会信用代码。
6.1.8 法人码签名段（S 段）
用于存储法人码身份段（A段）内容的数字签名值，签名时应符合GB/T 33560 中的规范。
展现形式
政务服务码编码展现形式应为二维码图像，符号结构应符合GB/T 27766 中的规定。应支持根据屏
幕大小自适应将政务服务码最优显示，分辨率不小于 200 DPI（每英寸长度内的像素点数）。
解析要求
3
DB22/T 3684—2024
6.3.1 日志记录
应完整表述个人信息主体对其个人信息、授权有效期、被授权主体及授权情况。
6.3.2 解码方式
获得用户授权后，应通过调用解码接口，获取用户授权的个人信息和个人标签信息。
6.3.3 数据交互方式
通过 HTTPS 发送请求，使用 JSON 进行数据交互。
6.3.4 离线可用
在网络阻塞、服务器离线等情况下可离线使用。
7 应用接入
接入要求
7.1.1 网络环境
政务服务码服务方应描述网络 IP、域名、平台部署位置等信息。
7.1.2 接口信息
政务服务码服务方应给出接口调用方案。
7.1.3 数据环境
政务服务码服务方应给出数据同步方案和元数据。
7.1.4 安全要求
政务服务码服务方应给出安全方案。
7.1.5 调试要求
政务服务码应用方代码调试时按照政务服务码服务方的要求使用测试环境，测试通过后，正式接入
政务服务码。
7.1.6 认证要求
政务服务码应用方的业务系统应接入“吉林省统一身份认证平台”，实现统一认证和统一登出功能。
接入流程
政务服务码应用方应按照以下步骤接入：
a) 政务服务码应用方向行业主管部门提出接入申请，对应用场景、服务目录和所需信息进行备案
登记；
b) 行业主管部门对申请进行审核，指定服务负责人，对审核通过的政务服务码应用方申请进行管
理和需求对接；
4
DB22/T 3684—2024
c) 政务服务码服务方对政务服务码应用方提供的可行性分析、需求分析及界面设计方案进行审
核，确定业务应用上线方式；
d) 政务服务码应用方根据政务服务码服务方提供的方案接入“吉林省统一身份认证平台”；
e) 根据政务服务码服务方提供的接口调用信息、网络地址、域名、平台部署信息、数据同步方案、
安全方案，政务服务码应用方在测试环境中进行测试，测试通过后接入。
8 应用范围
服务对象
应为已经获得政务服务码的自然人或法人。
应用场景
政务服务码应用场景可参见附录 A。
9 安全要求
个人信息安全要求
个人信息保护应符合GB/T 35273 的要求。
网络安全要求
应符合GB/T 22239和政务服务码服务方规定的网络安全要求。
数据安全要求
应符合GB/T 39477和政务服务码服务方规定的数据安全要求。
5
DB22/T 3684—2024
附 A A A
录
（资料性）
政务服务码应用场景
A.1 总体说明
政务服务码采用亮码与扫码结合方式开展场景化应用，通过“吉事办”统一亮码、集成政务服务码
扫码接口的各类服务应用和设施设备进行扫码。自然人和法人以自愿为前提，通过出示和扫描政务服务
码享受各类政务服务、公共服务和其他机构提供的各类便民服务。法人在政务服务码应用中，可根据实
际情况选择关联法人代表或者授权代表人公民身份证信息，作为场景化应用中的身份标识。政务服务码
与国务院部门垂直管理业务系统进行对接时，采用全国一体化政务服务平台规定的接口进行个人信息
匹配。
A.2 应用场景
政务服务码的应用场景包括但不限于以下场景：
——政务服务：通过出示政务服务码，实现在各级各类线下办事场所进行预约办事、现场办事、
缴费等场景化应用。通过扫描业务平台展示政务服务码，实现身份核验、信息核查、使用授权、
信息调取和信息流转等场景化应用；
——出行服务：通过出示政务服务码，实现公交、地铁和博物馆等公共设施及场所的刷码出行及
消费。同时，为特定群体提供限时通行的个性化服务
；
——医疗服务：通过出示政务服务码，实现在医疗机构或定点药店的预约挂号、医保结算、就医
购药、金融支付等场景化应用；
——教育服务：通过出示政务服务码，实现学校的通行凭证、就餐消费、出席签到等场景化应
用。同时为师生、社会群体提供基于授权的个人简历、学籍学位、电子成绩单和荣誉奖励等信息
的可信查验服务；
——电子证照：通过出示政务服务码，实现自然人和法人相关电子证照的授权使用、查验流转、
互信互认等场景化应用；
——信用服务：通过出示政务服务码，实现信用办事等场景化应用；
——数据服务：通过出示政务服务码，实现自然人和法人关联数据授权使用等场景化应用。
6