DOIP数字对象接口协议规范（中文版）

致谢

DONA 基金会要感谢以下各位在准备本DOIP 规范方面所做的许多贡献和深刻见解：

罗伯特·卡恩（Robert E.Kahn），克里斯托弗·布兰奇（Christophe Blanchi），劳伦斯·兰诺姆（Laurence Lannom），帕特里斯·A·里昂（Patrice A.Lyons）。

版权许可协议

DONA 基金会2018

（1）本许可协议（协议）位于DONA 基金会，瑞士注册的非营利实体与访问、下载或实施此数字对象接口协议规范版本2.0（以下称为DOIP）的个人或组织（用户）之间。DONA 根据协议中的条款和条件向用户免费提供DOIP（v2）。

（2）DOIP（v2）基于ITU-T X.1255 标准建议书，该建议书在ITU 互联网站点上公开可用。尽管在数字对象体系结构本身或DOIP（v2）中没有DONA 主张的专利主张，但DOIP 中引用的外部规范中可能存在第三方权益，并且未在此协议中向用户授予此类第三方外部规范的许可。

（3）DONA 特此授予用户非专有的、已缴足的、不可撤销的全球性许可，以向公众复制、实施和进一步传播DOIP（v2），但前提是DONA基金会的版权声明和本协议均保留在DOIP 中（v2），包括对其进行的任何实现。

（4）用户在此确认DONA 正在按“现状”向公众提供DOIP（v2），并且DONA 不做任何明示或暗示的陈述或保证。举例来说（但不限于此），DONA 对任何特定目的不作任何表示或担保，或否认使用DOIP（V2）不会侵犯任何第三方权利。

（5）如果严重违反本协议的条款和条件，则该协议将自动终止。公认的对DOIP（v2）的编写有贡献的人员的名字或DONA 标记均不得以商标形式用于认可或促销用户或任何第三方的产品或服务。

（6）该协议应根据瑞士法律解释和执行。

数字对象接口协议规范版本2.0

1　导言

本文档是数字对象接口协议（DOIP）的规范，该协议是数字对象体系结构（DO 体系结构或DOA）的核心协议。DO 体系结构是互联网体系结构的逻辑扩展，它解决了更广泛地支持信息管理的需求，而不仅仅是将数字形式的信息从互联网的一个位置传递到另一个位置。它是非专有的体系结构，可免费公开获得。它是对移动程序和分组无线系统安全性的早期工作的产物。DOIP 旨在实现跨异构信息系统的互操作性。

2　数字对象体系架构

DO 引入了数字对象的概念，该概念构成了体系结构的基础。DO 是一个位序列或一组位序列，其中合并了对象或对象的一部分或一方具有权利或利益或具有价值的其他信息，每个序列的结构都可以由一个或多个计算工具解释。每个DO 都必须具有以下基本要素：相关的唯一持久标识符，称为数字对象标识符（非正式地称为Handle）。

DO 的概念基本上类似于ITU-T X.1255 建议书中定义的“数字实体”概念，该概念主要基于数字对象体系结构。该建议中的“实体”定义为可以单独和唯一标识的任何事物。它还将“数字实体”（DE）描述为一个实体，该实体表示或转换为与机器无关的数据结构，该数据结构由一个或多个不同信息系统解析的元素组成。在本说明中术语数字对象和数字实体可互换使用。X.1255 中提供了对DO、DO 数据模型、DO 接口协议和联合注册表的详细描述。

DO 体系结构指定了两个核心协议和三个基本组件。如下面简要描述的，这三个组件是标识符/解析系统，存储库系统和注册表系统。实际上，存储库和注册表组件是模块化的，可以根据需要进行组合。

第一种协议，即IRP，在较早的版本中也称为“处理系统协议”，用于创建、更新、删除和解析数字对象标识符。根据IRP 中的规定，每个标识符都与一个标识符记录相关联，该记录包含客户可以解析的相关“状态信息”；并且所有标识符的格式均为前缀/后缀，默认情况下，前缀可以首先解析为要使用的特定标识符/解析服务，并且后缀可以是任何位序列。一个组织可以通过为其分配一个前缀来为其自己的标识符集运行一个解析系统，并且可以通过将其视为后缀并在其分配的前缀之前将任何现有的标识符转换为数字对象标识符。在三个RFC 中描述了基于较早版本协议的系统实现。很快提供指定标识符/解析协议的文档。

第二种协议，即DOIP，定义为更广泛地由数字对象服务使用，其中存储库和注册表系统是特定实例。数字对象服务旨在实现本文档中指定的DOIP 及其基本必需的功能。该协议的早期版本，基于R.E.Kahn 和R.Wilensky 最初描述的存储库访问协议，于2009年公开发布。

标识/解析系统

标识/解析系统是组成数字对象体系结构的三个组件之一。该系统支持多种数字对象服务，包括：

（1）向构造为数字对象的数字形式的信息分配唯一标识符，而不考虑此类信息的位置或用于提供此类信息的技术；

（2）将标识符快速解析为关于相应数字对象的当前状态信息，如其位置、访问和使用策略、时间戳和/或公共密钥；包含状态信息的标识符记录的管理。

存储库系统

储存库系统是一种数字对象服务，它提供必要的功能来管理数字对象，包括基于标识符的使用以及集成的安全性提供对此类对象的访问。通过在访问协议中使用标识符，存储库系统从客户端抽象出了存储技术的详细信息，从而启用了一种用于保存和访问数字对象的长效机制。使用以下所述的DOIP 可以访问该系统。

注册系统

注册表系统是一种专用的存储库系统，旨在存储有关数字对象的元数据，而不是数字信息本身，并且当用作独立组件时，通常存储由一个或多个存储库系统管理的数字对象的元数据。也可以使用DOIP 启用对此系统的访问。

3　数字对象接口协议

数字对象接口协议（DOIP）版本2.0 为客户端指定了一种与数字对象（DO）进行交互的标准方式。假定此类DO 由DO 服务管理，在本文档中我们通常将其称为DOIP 服务，并且协议实现是这些服务的一部分。在这种情况下，DOIP 服务本身被视为数字对象。就其本质而言，协议旨在使运行该协议的一个或多个其他实体之间能够进行交互，因此通常可以支持网络环境中特定形式的进程间交互。

DOIP 利用IRP 将标识符与协议的不同元素相关联。标识符的最大大小将随时间变化，但是，最初，在DOIP 中指定的标识符的最大大小为4 096位。DOIP 支持使用PKI8 保证安全性以验证数字对象，包括用于服务/客户端身份验证以及通过签名确保完整性。固有的PKI 支持还将帮助客户和服务利用加密。协议假设使用标识符来指定批准的访问控制列表和PKI 质询响应测试的DO 的访问控制。定义了客户端可以在服务上调用的基本操作；该协议从本质上支持增加操作。

DOIP 可以通过任何安全通信协议建立隧道，而DOIP 本身可以用于确定此类协议的选择。最低要求是网络通信应支持TLS9。除了传输安全性，协议还利用了其他几个规范：一种是实现序列化的方法，可以为此使用JSON10。除非另有说明，否则本文档的其余部分假定使用JSON 进行序列化。如上所述，第二个是将PKI 用于DO 的加密和解密，包括其他系统资源的身份验证；此功能虽然依赖于协议外部的技术，但可以使用数字对象标识符。其他外部规范包括Unicode11（特别是UTF-8 编码）、TCP、MIME、X509、JWS16 和JWK。

每个DO 必须指定其类型。为此定义了核心类型。类型是可扩展的，以允许创建新类型。类型的一项重要功能是使DOIP 服务能够识别允许的操作。类型是分配的标识符，因此，每种类型都与可以使用IRP 访问的标识符记录相关联。类型记录的语义和其他结构细节未在DOIP 中指定。假定具有领域专业知识的组或组织将负责在其域中创建类型并指定类型记录的语义和序列化。

接下来定义各种与DOIP 相关的构造和交互。

4　数字对象的序列化

在数字对象服务和客户端之间通信的数字对象（DO）必须符合约定的序列化形式。包含DOIP 软件的客户端软件可能是另一个DOIP 服务的一部分。DO 的最低要求序列化在附录A 中指定。在较高级别，DO 由标识符、类型、可选和开放式属性以及可选元素组成。DO 的标识符必须是唯一的，并且可以按照IRP 中的说明进行解析。

客户端通过建立与每个DO 各自的DO 服务的DOIP 连接来与任何DO进行交互。为此，客户将需要获取该DO Service 的信息以建立与其的网络连接。此信息称为DO 服务信息。具体的服务信息中编码的值在本文档的类型部分中描述为0.TYPE/DOIPServiceInfo 类型。

客户应使用IRP 解析DO 标识符。结果信息应包含与0.TYPE/DOIP ServiceInfo 类型关联的服务信息，或接收到另一个标识符的重定向。如果客户端收到重定向，它将使用IRP 和任何其他重定向将新标识符解析为服务信息记录。

客户可以缓存任何服务信息，以加快将来与DOIP 服务的交互。标识符记录的详细信息在本规范附录D 中有关核心类型的讨论中说明。

充当代理的DOIP 服务可以允许在其他DOIP 服务管理的DO 上调用操作。代理服务在管理标识的DO 的服务上调用客户端指定的操作，并将结果返回给客户端。代理服务还可以缓存响应，以快速响应将来的此类请求。

下节指定客户端如何与DOIP 服务进行通信，以便在此类服务管理的DO 上调用操作。

5　操作

DOIP 操作分为基本操作和扩展操作两种。每个DOIP 服务都必须正确解释基本操作，并且必须先验将这些基本操作内置到这些服务中。扩展操作可以由DOIP 服务选择，只要它们在检索、验证和执行此类操作时强制实施足够的安全性即可。

所有DOIP 操作（无论是基本操作还是扩展操作）都必须具有IRP 中指定的唯一可解析标识符。

5.1　基本操作

如果客户端正确通信，则每个DOIP 服务都必须正确解释以下基本操作：问候、创建、访问、更新、删除、搜索和listOperations。服务可能会拒绝或允许客户端执行此类操作，具体取决于服务的内部策略，包括那些与访问控制有关的内部策略。有关基本操作的详细信息，请参见附录B。

5.2　扩展操作

DOIP 服务可能支持基本操作以外的操作；并且此类操作的标识符应按照IRP 中的规定解析。这些操作不是基本DOIP 规范的一部分，但是它们的执行方式与基本操作没有什么不同。

如果需要，可以将扩展的特定于操作的功能内置到服务实现中。或者，DOIP 服务可以提供运行时环境，以检索、验证和执行在与扩展操作有关的特殊DO 中管理的代码。无论哪种情况，都应按附录C 所述将操作详细信息作为DO 进行管理。将操作表示为DO 的目的是传播有关如何调用扩展操作的信息。

DOIP 服务可以开发扩展DO 操作用以添加访问数字对象信息，利用不同的安全机制，例如加密等手段基于角色访问控制或证书链以保障操作过程的安全性。

6　类型

类型表示为唯一标识符，这些标识符可解析为IRP 中指定的“类型记录”，并用于对客户端与DOIP 服务进行交互时可能遇到的DO 进行分类。特别是，由DOIP 服务返回的DO 必须包括整个DO 的类型。该类型通知DOIP 服务可以针对DO 调用哪些操作。DOIP 的核心类型在附录D 中说明。

类型可以通过DOIP 服务实现从“核心类型”扩展。除了指定父类型之外，没有为核心类型的扩展规定任何特定的结构。但是，其实现可能包括已添加的结构。

类型之间的这种链接使了解少数类型的客户端能够处理归类为更精细类型的DO，反之亦然。所有扩展类型必须指示对其进行扩展的类型的引用。特别地，使用其标识符记录的扩展类型应在句柄值中指示父类型：具体地说，应在与（标识符值）类型“0.TYPE/Type”相对应的数据字段中指定父类型。

类型本身可以作为DO 进行管理，以提供客户端可以用来处理这些DO 的其他信息。本规范未规定此类附加信息的性质和结构，并将其留给具体实现。

7　通信协议

7.1　通信安全

DOIP 网络通信应通过DO 服务信息中指定的安全传输协议连接（例如TLS）进行，或者使用各方可能同意的其他通信/安全协议进行。通过网络执行的基本操作应在默认的安全传输协议上进行，而扩展操作可以在默认协议或参与者同意的其他安全协议或其他DO 可能要求的其他安全协议上进行。在使用TLS 的情况下，在TLS 握手期间，服务器必须出示TLS要求的证书。该证书必须包含DOIP 服务的标识符以及DOIP 服务的公钥。客户应通过使用IRP 解析标识符来检查公钥是否与预期的公钥相对应。TLS 连接本身会验证服务器是否具有相应的私钥。

客户端可以以相同的方式提供证书以对DOIP 服务进行身份验证，但是，当匿名提出请求或使用扩展操作时，则不需要这样做。特别是，对于扩展操作，客户端可以使用支持替代身份验证方法的其他机制进行身份验证。在这种情况下，应使用可选属性“验证”。特别是，每当提供客户端证书时，客户端证书中的标识符必须与DOIP 请求中所述的ClientId 匹配。尽管不一定会满足所有匿名请求，但ClientId 应该留空以匿名发送请求。

TLS 证书基于X.509 规范，该规范定义了许多术语，包括以下两个项目符号中带下划线的术语。DOIP 服务证书以及客户证书的解释如下（使用X.509 规范中定义的术语）：

（1）标识符在主题字段中，作为属性UID 的第一个条目（如果存在），否则作为属性CN 的第一个条目。

（2）公钥是主题公钥。

对于谁可以颁发证书没有任何限制。如果需要，可以对证书进行自签名。客户和DOIP 服务应通过解析证书中的标识符以检索公共密钥并使密钥与证书中所述的密钥匹配来验证证书。对于服务器证书，该标识符将被解释为DOIP 服务标识符，并且必须与客户端打算联系的DOIP 服务标识符匹配；如果使用客户端证书，则该标识符将被解释为客户端标识符，并且必须与DOIP 请求中所述的ClientId 匹配。

客户和DOIP 服务可以使用其他附加标准（经共同商定）来验证另一方：例如，证书中显示的标识符的前缀可以用于指示证书颁发者。

7.2　请求/响应交互

一旦建立了TLS 连接（或约定的其他连接），并且客户端验证了服务公共密钥，客户端就可以通过单个连接顺序发送多个DOIP 请求，反之亦然。DOIP 服务应响应每个此类请求，并且此类响应应包括其对应的requestId。

DOIP 请求或响应由此处定义的多个段组成。各段分别如下：

（1）JSON 段，其中包含JSON 数据交换格式的UTF-8 编码文本，通常跨多行，并以换行符终止。

（2）一个字节段，其中包含任意字节。字节段必须以单行文本开头，并以符号字符（“@”）开头，并可选地后跟以换行符结尾的空格；该行之后是分块编码的字节，由零个或多个分块组成。每个分块都有：

① 以UTF-8 编码的正十进制数开头的一行文本（不包括定界符的块的大小），可以选择后面跟空格，并以换行符结尾；

② 由大小指示的字节数，可选后跟空白或后跟换行符；或者空段，指示请求或响应的结束。

在每个段的末尾，必须是一行UTF-8 编码的文本，该文本以井号（“＃”）开头，可以选择后面跟空格，并以换行符终止。JSON 段由换行符后的第一个哈希符号终止。字节段由出现的第一个哈希符号而不是块大小终止。空段会终止请求或响应。

可以通过读取一系列段来解析DOIP 请求或响应。如果段以字符“@”开头，则为字节段；如果段以字符“＃”开头，则为空段，表示结束；否则，该段是默认段（最初是JSON 段）或各方之间应同意的其他段。DOIP请求或响应必须以JSON 段开头。

7.2.1　请求

有效的DOIP 请求将作为具有以下属性的JSON 段生成：

（1）requestId：客户端提供的请求的标识符；在给定的DOIP 会话中必须是唯一的，以便客户端可以区分DOIP 服务响应。requestId 必须是不超过4 096 位的字符串。

（2）clientId：客户端的标识符。

（3）targetId：要在其上调用操作的DO 的标识符；DOIP 服务本身可以成为目标。

（4）operationId：要执行的操作的标识符。

（5）属性：JSON 属性的可选数组；规定的操作。

（6）身份验证：客户端用于身份验证的可选JSON 对象。

（7）输入：由操作处理的任意信息。如果不存在，则该操作的输入是该段之后的所有段。如果存在，则输入是与“input”属性相对应的JSON对象，并且请求中不得再有其他非空段。

附录B 为上述基本属性定义了各种基本操作的特定值。

7.2.2　响应

有效的DOIP 响应将作为具有以下属性的JSON 段生成：

（1）requestId：这是响应的请求的标识符。DOIP 服务必须在其响应中包含客户端提供的requestId。

（2）status：指示请求状态的标识符。必须来自下面“状态代码”小节中列出的代码。

（3）属性：JSON 属性的可选数组；规定的操作。

（4）输出：根据操作返回给客户端的任意信息。如果不存在，则该操作的输出是该响应对象之后的所有段。如果存在，则输出是与output 属性相对应的JSON 对象，并且请求中不得再有其他非空段。

附录B 为上述基本属性定义了各种基本操作的特定值。

术语JSON 对象和JSON 属性符合JSON 规范。术语JSON 段是在上面的Exchange 子小节中定义的。

7.3　状态码

状态代码应具有IRP 中规定的可解析的关联唯一标识符。以下基本状态代码适用。实现可能会使用其他状态代码，并在属性中提供其他状态代码，但是必须在任何DOIP 响应的状态属性中提供基本代码。

（1）0.DOIP/Status.001：操作已成功处理。

（2）0.DOIP/Status.101：请求在某种程度上无效。

（3）0.DOIP/Status.102：客户端未成功进行身份验证。

（4）0.DOIP/Status.103：客户端已成功通过身份验证，但未经授权可以调用该操作。

（5）0.DOIP/Status.104：服务不知道该数字对象是否存在。

（6）0.DOIP/Status.105：客户端试图创建一个新的数字对象，其标识符已被现有数字对象使用。

（7）0.DOIP/Status.200：服务拒绝执行扩展操作。

（8）0.DOIP/Status.500：发生上述以外的错误。

8　身份标识

如上所述，DOIP 定义了四种形式的标识符：一种用于操作，一种用于类型，一种用于状态信息以及一种用于DO。实现可以根据需要定义自己的标识符集，只要它们可以按照IRP 中的说明进行解析即可。就是说，每当在不需要标识符的外部解析的特定环境中使用DOIP 时，由于预期的客户已经意识到标识符记录中的信息，或者由于标识符记录中此类信息的暴露带来了安全风险或其他问题，则此类标识符可能无法通过IRP 解析。但是，应该注意的是：当在互联网上提供DOIP 服务时，可以预期此类标识符应解析为包含本文档中指定的最少信息的记录。

基本集使用的约定是将前缀0.DOIP 用于操作以及状态信息，将前缀0.TYPE 用于类型。在此版本的协议中，标识符具有语义。在随后的版本中，意图是这样的标识符也将具有非语义表示。

附录A：DO 序列化

通过DOIP 通信的任何DO 必须使用DOIP 序列进行序列化。接下来定义的各个字段的序列化顺序并不重要。下文所述的第一段是数字对象的JSON 序列化，元素中的数据部分除外。数据部分跟随第一段，每个数据部分序列化为两个段：JSON 序列化中的一个段，表示一个对象，该对象具有表示元素ID 的属性“id”，其后是一个字节段，该字节段由元素中的数据组成。最终的JSON 段包含签名，如附录中所述对于类型0.TYPE/DOIPServiceInfo 和0.TYPE/DOIPOperation 的DO，签名段是必需的，否则是可选的。(www.xing528.com)

除非另有说明，否则所有字段均为必填字段。除数据部分外的所有值都必须以UTF-8 编码。

（1）id：DO 的标识符。

（2）类型：DO 类型。必须为0.TYPE/DO 或其扩展名。请参阅类型部分。

（3）属性（可选）：序列化为JSON（子）对象的一个或多个字段（键值对）。

（4）elements（可选）：在默认序列化中序列化为数组的一个或多个元素，每个元素包括：

① id：元素的标识符；在一个DO 中必须唯一。

② 长度（可选）：数据部分的长度。

③ type：应为本规范中定义的类型或MIME 类型。

④ 属性（可选）：使用默认值序列化为一个对象的一个或多个字段序列化，或作为JSON（子）对象。

⑤ 数据：如上所述，序列化为单独的段。

（5）签名（有条件的）：类型0.TYPE/DOIPServiceInfo 和0.TYPE/DOIP Operation 的数字对象为必需；否则为可选。该字段是默认序列化中的字符串数组；每个字符串均为JWS 格式，带有未编码的分离有效负载。每个JWS 的标头必须通过引用“子类”字段中的标识符来指定签名实体，可以解析该标识符以获得签名者的公共密钥。有效载荷的内容是序列化的数字对象，省略了签名并按附录E 中的描述规范化。

附录B：基本操作

下面列出了基本的DOIP 操作。描述了成功响应的输入和输出。除了不成功的“状态”之外，失败响应还可能具有带有属性“message”的JSON对象作为输出，并带有对错误的易于理解的描述。

（1）0.DOIP/Op.Hello：允许客户端获取有关DOIP 服务的信息的操作。

① 请求属性：无。

② 输入：空。

③ 响应属性：无。

④ 输出：DOIP 服务信息作为DO 的默认序列化。

（2）0.DOIP/Op.Create：在DOIP 服务中创建数字对象的操作。创建操作的目标是DOIP 服务本身。

① 请求属性：无。

② 输入：序列化的数字对象。对象使用默认序列化元素数据；除此之外，序列化是如上所述的多段DO 序列化。可以省略“id”，以要求DOIP服务自动选择ID。

③ 响应属性：无。

④ 输出：创建的对象的默认序列化，省略元素数据。值得注意的是，包括对象的标识符（即使由客户端选择）以及由DOIP 服务自动执行的对对象的任何更改。

（3）0.DOIP/Op.Retrieve：检索目标DO 表示的信息（的某些部分）的操作。

① 请求属性：

②“元素”：如果指定，则检索该元素的数据。

③“includeElementData”：如果存在，则返回DO 的序列化，包括所有元素数据。

④ 输入：无。

⑤ 响应属性：无。

⑥ 输出：默认输出是使用默认值对对象进行序列化，没有元素数据的序列化。如果指定了“element”，则输出是一个包含指定元素字节的单个字节段。如果指定了“includeElementData”，则输出为完整的序列化DO。

（4）0.DOIP/Op.Update：更新目标DO 信息（的某些部分）的操作。

① 请求属性：无。

② 输入：序列化的数字对象。对象使用默认序列化元素数据；除此之外，序列化是如上所述的多段DO 序列化。不需要更改的元素可以从输入中省略。

③ 响应属性：无。

④ 输出：创建的对象的默认序列化，省略元素数据。值得注意的是，包括由DOIP 服务自动执行的对对象的任何更改。

（5）0.DOIP/Op.Delete：从DOIP 服务的管理中删除目标DO 的操作。

① 请求属性：无。

② 输入：无。

③ 响应属性：无。

④ 输出：无。

（6）0.DOIP/Op.Search：通过搜索DOIP 服务管理的一组数字对象中包含的元数据来发现数字对象的操作。

① 请求属性：

②“查询”：要执行的搜索查询，以文本形式表示。

③“pageNum”：要返回的页码，从0 开始。

④“pageSize”：要返回的页面大小；如果缺失或为负，则所有结果均回来；如果为零，则不返回任何结果，但仍返回“大小”。

⑤“sortFields”：排序规范的逗号分隔列表，每个规范都是一个字段名称（可选）后跟ASC 或DESC。

⑥“type”：要么是“id”，仅返回对象id；要么是“full”，以返回完整的对象数据（忽略元素数据）。默认为“完整”。

⑦ 输入：无。

⑧ 响应属性：无。

⑨ 输出：基于具有顶级属性的默认序列化的对象。

⑩“大小”：所有页面上的结果数。

⑪“结果”：结果列表，每个结果都是字符串（对象ID）或对象的默认序列化，省略元素数据。

（7）0.DOIP/Op.ListOperations：一种操作，用于请求可以在目标DO上调用的操作列表。

① 请求属性：无。

② 输入：无。

③ 响应属性：无。

④ 输出：基于默认序列化的字符串的序列化列表，每个字符串是目标DO 支持的操作ID。

以下标识符指定对于DOIP 操作有用和/或必需的参数：

（1）0.DOIP/请求：此标识符将用于描述扩展操作的DOIP 请求的细节。

（2）0.DOIP/响应：该标识符将用于描述扩展操作的DOIP 响应的细节。

（3）0.DOIP/OperationReference：此标识符应用于指定一个DOIP 操作与另一个DOIP 操作相似。

（4）0.DOIP/传输：此标识符可用于指定DO 服务使用的DOIP 传输协议；它解析为扩展的DOIP 类型。如果未指定传输，则假定为TCP/IP。例如，如果DOIP 使用TLS，则也可以在此字段中指定它。

（5）O.DOIP/编码：此标识符可用于提供DOIP 服务用来指定DOIP使用的编码的信息。它解析为扩展的DOIP 类型。

（6）0.DOIP/AccessControl：此标识符可用于提供指定访问控制操作的信息。

附录C：扩展操作的数字对象

扩展操作DO 的最小结构如下：

（1）id：扩展操作的标识符。

（2）类型：必须为0。TYPE/DOIPOperation。

（3）属性：包含以下属性的值的数组。

（4）serviceId：管理此DO 的服务的标识符。

① 0.DOIP/Request：一个或多个键值对，用于描述期望值规范的“请求”部分6.2.1 中列出的每个属性的最大值。一个密钥必须是“可读的”，以表明DOIP 请求的描述对人类有用。可以另外使用简单自动化的其他形式的描述。

② 0.DOIP/响应：一个或多个用于描述期望值的键值对规范的响应部分6.2.2 中列出的每个属性的最大值。由于上述原因，一把钥匙必须是“可读的”。

③ 0.DOIP/OperationReference：一个可选字段，用于引用其他操作标识符以建立操作实现的相似性。

（5）签名：如附录A 所述。

附录D：核心类型

在这种情况下，类型旨在用于DOIP 服务和相关的客户端，以了解适合针对DO 调用的操作。具体来说，每个DO 都指定其类型，并且该类型应告知DOIP 服务要执行的操作。客户应从DOIP 服务中了解那些适用的操作。其中某些类型旨在提供给所有DOIP 服务，而其他类型则可能不可用。特别是，加密数字信息的一部分类型显然不会被DOIP 服务普遍使用。

类型与IRP 中指定的可解析的唯一标识符关联。与任何类型关联的标识符记录至少将指定其父类型。特别地，类型在其标识符记录中使用一个值指示其值，该值的数据字段与0.TYPE/Type 相关联，应为其父代的类型。

在此定义DOIP 操作所需的核心类型。0.TYPE/Type 是类型的根。所有其他核心类型均从0.TYPE/Type 扩展。DOIP 实现可能创建的类型应从0.TYPE/Type 或此处定义的扩展名扩展。

核心类型及其内在关系（表示为层次结构）定义如下：

（1）0.TYPE/Type：类型的根。

① 0.TYPE/DO：DO 必须使用的类型。DOIP 服务使用的基础类型并可用该类型扩展到DO 其他类型。

② 0.TYPE/DOIPServiceInfo：用于传输DO 服务的类型信息。

③ 0.TYPE/DOIPOperation：用于指定DO 的类型表示扩展操作。

除了指定父项外，类型还可以规定要在标识符记录中表示的其他特征。以下说明指出了此类规定适用于核心类型的任何地方。

（2）0.TYPE/DO：这是一个通用的DO 类型。与此类型相对应的DO应当在其标识符记录中包含一个值， 该值的数据字段与“0.TYPE/DOIPServiceInfo”相关联的应该是管理所讨论的DO 的DOIP 服务的服务标识符，或者是针对该DO 的实际服务信息。自己服务的DO，如下所述。

（3）0.TYPE/DOIPServiceInfo：这是扩展的DO 类型。与此类型相对应的DO应符合上述0.TYPE/DO规定，并在其句柄记录中包含一个句柄值，该句柄值与“0.TYPE/DOIPServiceInfo”相关联的数据字段为服务信息记录，即一个符合附录A 中指定的序列化的DO，包含以下属性：

① serviceName（可选）：DOIP 服务的名称。

② serviceDescription（可选）：服务的描述。

③ ipAddress（必填）：服务的IP 地址。

④ 端口（必填）：IP 地址上的监听端口。

⑤ 协议（必填）：默认值为“TCP”。

⑥ protocolVersion（必需）：支持的DOIP 协议的最高版本。

⑦ publicKey（必填）：默认情况下，以JWK 格式表示的公钥。

⑧ 任意数量的其他字段（可选）。

该DO 中包含的签名应使用DOIP 服务的privateKey 进行签名。

注意，如果在与DOIP 服务相对应的DO 上调用了DOIP 服务在检索操作期间返回的DO，则它应符合上述规范。

（4）0.TYPE/DOIPOperation：这是扩展的DO 类型，适用于提供可以由DOIP 服务提供的运行时环境执行的代码的扩展操作。与此类型相对应的DO 应符合附录C。

附录E：DO 签名

如附录A 所述，序列化DO 包括JSON 段和字节段（如果适用）。序列化的DO 可能还包含另一个JSON 段，并带有（其余）DO 的签名。本附录描述了如何生成该签名段以及如何验证签名。

签名段应为具有“bytesAlg”和“signatures”属性的JSON 对象。“bytesAlg”部分描述了如何生成有效载荷以产生签名。特别是，“bytesAlg”属性描述了如何在要签名的有效负载中规范化DO 的“字节段”。“bytesAlg”属性本身是一个包含属性“hashAlg”的JSON 对象。“hashAlg”属性可以采用以下两个值之一：

（1）“none”，表示字节段按原样包含在已签名的有效载荷中。

（2）“SHA-256”，意味着每个字节段都用其SHA-256 摘要的字节替换，如果省略了“bytesAlg”属性，则假定值为“none”。

JWS 签名的有效载荷是按照附录A 序列化的DO 的所有段的文字序列，不包括签名段，其字节段根据上面定义的“bytesAlg”的值进行处理。

如RFC 7515 中所述，“签名”属性应具有JWS 的一个或多个值。紧凑序列化或JSON 序列化均可用于生成JWS。如果要为同一个有效负载生成多个签名，可能存在多个签名者，那么应该优先使用JSON 序列化。每个JWS 的标头必须通过引用“儿童”字段中的标识符来指定签名实体，可以解析该标识符以获得签名者的公共密钥。

为了检查签名，应该使用与已解析的公钥相对应的私钥来确认JWS已被正确签名。然后，必须检查序列化DO 与签名有效负载中序列化DO的等效性。特别是，可以更改顺序，可以是任何JSON 段中的JSON 属性，也可以是第一个JSON 段中的元素JSON 数组，也可以是数据元素的整体顺序。因此，应检查每个JSON 细分与相应JSON 细分中的身份、签名的有效载荷。同样，在根据“bytesAlg”对每个字节段进行转换后，应确认每个字节段与签名有效载荷中的相应字节段相对应。