1.1. 约定和 术语

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、 "MAY" 和 "OPTIONAL" 应按照 BCP 14 [RFC2119] [RFC8174] 中的说明来解释，但前提是它们以全大写形式出现，如此处所示。¶

本规范使用由 "OAuth 2.0 授权 框架" [RFC6749] 定义的术语："access token"、"refresh token"、 "authorization server" (AS)、"resource server" (RS)、"authorization endpoint"、 "authorization request"、"authorization response"、"token endpoint"、 "grant type"、"access token request"、"access token response" 和 "client"。¶

2.1. 授权详情 类型

AS 控制 type 参数值的解释，以及 type 参数允许的对象字段。但是， type 参数的值通常也会被文档化，并预期供 开发者使用。RECOMMENDED API 设计者选择 易于无歧义复制的 type 值。例如，某些字形对于相同的视觉字符有 多个 Unicode 码位，开发者可能会输入与 AS 所定义字符不同的字符。减少潜在 混淆的可能方法包括将值限制为 ASCII [RFC0020] 字符、提供机器可读的数据 类型值列表，或指示开发者直接从 文档复制并粘贴。¶

如果某个应用或 API 预期部署在不同服务器之间， 例如开放标准中的情况，则 RECOMMENDED API 设计者 使用其控制下的抗冲突命名空间，例如 API 设计者 控制的 URI。¶

下面的示例展示了实现如何利用命名空间 https://scheme.example.org/ 来确保类型值抗冲突。¶

{
   "type": "https://scheme.example.org/files",
   "locations": [
      "https://example.com/files"
   ],
   "permissions": [
      {
         "path": "/myfiles/A",
         "access": [
            "read"
         ]
      },
      {
         "path": "/myfiles/A/X",
         "access": [
            "read",
            "write"
         ]
      }
   ]
}

2.2. 通用数据字段

本规范定义了一组通用数据字段，这些字段设计为可在 不同类型的 API 中使用。本规范不要求 API 定义使用这些 通用字段，而是将其作为可重用的通用组件 提供给 API 设计者使用。所有字段的允许值由 受保护的 API 决定，具体由特定的 "type" 值定义。¶

locations:

表示资源或 RS 位置的字符串数组。这些字符串通常是标识 RS 位置的 URI。该字段可以允许客户端指定特定 RS，如 第 12 节所述。¶

actions:

表示要在资源上执行的 动作种类的字符串数组。¶

datatypes:

表示从资源请求的 数据种类的字符串数组。¶

identifier:

指示 API 中可用的特定 资源的字符串标识符。¶

privileges:

表示在资源上请求的权限类型 或权限级别的字符串数组。¶

当不同通用数据字段组合使用时， 客户端请求的权限是所有值的乘积。 该对象表示请求对象内列出的所有 actions 值 在对象内列出的所有 locations 值处，用于对象内列出的所有 datatypes 值。在下面的示例中，客户端请求对 customer_information API 中属于客户的 contacts 和 photos 同时拥有 read 和 write 访问权限。 如果该请求被授予，客户端 会认为它能够使用 API 所定义的任何权限组合， 例如对照片的读取访问权限以及对 联系人的写入访问权限。¶

[
   {
      "type": "customer_information",
      "locations": [
         "https://example.com/customers"
      ],
      "actions": [
         "read",
         "write"
      ],
      "datatypes": [
         "contacts",
         "photos"
      ]
   }
]

如果客户端希望对其访问有更精细的控制，它可以发送 多个对象。在此示例中， 客户端请求对同一 API 端点中的 contacts 进行 read 访问，并 对 photos 进行 write 访问。 如果该请求被授予，客户端将无法写入联系人。¶

[
   {
      "type": "customer_information",
      "locations": [
         "https://example.com/customers"
      ],
      "actions": [
         "read"
      ],
      "datatypes": [
         "contacts"
      ]
   },
   {
      "type": "customer_information",
      "locations": [
         "https://example.com/customers"
      ],
      "actions": [
         "write"
      ],
      "datatypes": [
         "photos"
      ]
   }
]

API MAY 定义其自己的扩展，但受 相应授权对象的 type 约束。 预计 API 设计者将结合使用本规范定义的 通用数据字段以及 API 自身特定的 字段。下面的非规范性 示例展示了作为两个不同虚构 API type 值的一部分， 同时使用通用字段和 API 特定字段。第一个 访问请求包含此处指定的 actions、locations 和 datatypes 字段，以及 API 特定的 geolocation 字段，表示访问在给定坐标拍摄的照片。 第二个访问请求包含此处指定的 actions 和 identifier 字段，以及 API 特定的 currency 字段。¶

[
   {
      "type":"photo-api",
      "actions":[
         "read",
         "write"
      ],
      "locations":[
         "https://server.example.net/",
         "https://resource.local/other"
      ],
      "datatypes":[
         "metadata",
         "images"
      ],
      "geolocation":[
         {
            "lat":-32.364,
            "lng":153.207
         },
         {
            "lat":-35.364,
            "lng":158.207
         }
      ]
   },
   {
      "type":"financial-transaction",
      "actions":[
         "withdraw"
      ],
      "identifier":"account-14-32-32-3",
      "currency":"USD"
   }
]

如果该请求被批准，生成的访问令牌的访问权限将 是两个 API 各自请求的访问类型的并集，与上文相同。¶

3.1. 与 "scope" 参数的关系

authorization_details 和 scope 可以在 同一个授权请求中用于携带独立的授权要求。¶

本规范支持 authorization_details 和 scope 的组合使用， 部分原因是允许现有基于 OAuth 的应用逐步迁移到 专门使用 authorization_details。RECOMMENDED 某个给定 API 仅使用一种要求 指定形式。¶

AS MUST 将这两组要求 彼此结合起来处理，用于给定授权请求。AS 如何 合并这些参数的细节特定于受保护的 API，超出本 规范的范围。¶

在收集用户同意时，AS MUST 呈现 授权请求所表示的合并后的要求集合。¶

如果资源所有者授予客户端所请求的访问权限，AS 将 向客户端颁发与相应 authorization_details（以及 scope 值，如适用）关联的令牌。¶

3.2. 与 "resource" 参数的关系

如 [RFC8707] 中定义的 resource 授权请求参数， 可用于进一步 确定所请求 scope 可应用到哪些资源。resource 参数不会影响 AS 处理 authorization_details 授权请求参数的方式。¶

6.1. 比较 授权详情

OAuth 协议中的许多操作允许 AS 和 RS 基于请求 是否比先前的现有请求要求“更多”或“更少”来做出安全 决策。例如，在刷新令牌时，客户端可以 请求一个权限“少于”资源所有者此前已授权权限的新访问令牌。 所请求的访问令牌将传达减少后的权限，但资源所有者 先前的授权不会因此类请求而改变。 由于 authorization_details 中字段的语义 对给定 API 或 API 集合而言是实现特定的，因此没有 标准化机制可用于比较两个任意授权详情请求。 AS 在大多数情况下不应依赖简单的对象比较，因为请求中某些 字段的交集可能会对授予的访问权限产生副作用， 具体取决于 API 的设计和部署方式。这与某些 API 使用 scope 值时的效果类似。¶

在将新请求与现有请求比较时，AS 可以使用与 最初授予请求时相同的处理技术，来确定资源 所有者是否需要授权该请求。此比较的细节取决于 授权请求的 type 定义，超出本规范的范围， 但可以应用通用模式。¶

这将通过贯穿全文的示例来说明。第 3 节 中的示例授权 请求如果由用户批准，则会导致颁发一个与以下权限关联的授权码：¶

• 列出账户，¶
• 访问一个或多个账户的余额，¶
• 访问一个或多个账户的交易，以及¶
• 发起、检查状态并取消支付。¶

客户端现在可以请求 AS 颁发一个仅分配 访问账户列表权限的访问令牌，如下所示：¶

[
   {
      "type": "account_information",
      "actions": [
         "list_accounts"
      ],
      "locations": [
         "https://example.com/accounts"
      ]
   }
]

该示例 API 设计为 account_information 类型所使用的每个字段都包含累加权限， actions 和 locations 数组内的每个值 都指定不同的访问元素。为了在此 实例中进行比较，AS 将执行以下步骤：¶

• 验证前一步颁发的授权码 包含类型为 account_information 的授权详情对象，¶
• 验证已批准的动作列表是否包含 list_accounts，并且¶
• 验证 locations 值是否仅包含 先前已批准的位置。¶

如果所有检查成功，AS 将使用减少后的访问集合 颁发所请求的访问令牌。¶

请注意，此比较与该特定 API 类型定义相关。 不同的 API 类型定义可能有不同的处理规则。例如，某个 actions 值可能包含与另一个 actions 值关联的权限。例如，如果客户端最初请求具有 write 访问权限的令牌，则这意味着对该 API 同时具有读取和写入访问权限：¶

[
    {
        "type": "example_api",
        "actions": [
            "write"
        ]
    }
]

之后，同一客户端为 read 访问发起刷新请求：¶

[
    {
        "type": "example_api",
        "actions": [
            "read"
        ]
    }
]

AS 将比较 type 值和 actions 值，以确定 read 访问已 被此前授予客户端的 write 访问覆盖。¶

同一个 API 可以设计一个 privileges 的可能值 admin，在此示例中用于 表示生成的令牌被允许对资源执行任何功能。 如果该 客户端随后被授予对此 API 的此类 admin 权限， authorization_details 将如下所示：¶

[
    {
        "type": "example_api",
        "privileges": [
            "admin"
        ]
    }
]

AS 将比较 type 值，并发现 privileges 值涵盖了 此前授予客户端的 read 或 write 访问的任何方面。 请注意，其他 API 定义可以使用 privileges，使得各值并不相互涵盖。¶

下一个示例展示了客户端如何使用通用数据元素 locations（参见 第 2.2 节）来请求颁发限制到特定 RS 的访问令牌。在我们的 贯穿示例中，客户端可以请求将已批准授权中 payment_initiation 类型的所有权限应用于位于 https://example.com/payments 的 RS，如下所示：¶

[
   {
      "type": "payment_initiation",
      "locations": [
         "https://example.com/payments"
      ]
   }
]

7.1. 令牌响应中的增强授权 详情

附加到访问令牌的授权详情 MAY 与客户端请求的内容不同。除了用户 授权少于客户端请求的内容之外，在某些用例中，AS 会增强 授权详情对象中的数据。是否允许增强以及 其工作方式的具体细节必然属于相应授权详情类型定义的一部分。¶

举一个例子，客户端可能请求访问账户信息，但将 其能够访问哪些具体账户的决定留给用户。在 授权过程期间，用户会选择他们 希望允许客户端访问的账户子集。作为传达所选账户的一种设计选项， AS 可以将此信息添加到相应的授权详情对象中。¶

在该示例中，请求的 authorization_details 参数 可能如下所示。在此示例中，空数组充当占位符，表示 AS 进行增强时将添加数据的位置。此示例仅用于说明，并不 旨在建议以这种方式设计任何授权详情类型的具体细节。¶

"authorization_details": [
   {
      "type": "account_information",
      "access": {
         "accounts": [],
         "balances": [],
         "transactions": []
      },
      "recurringIndicator":true
   }
]

随后，AS 将扩展授权详情对象并添加 相应的账户标识符。¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",
   "authorization_details":[
      {
         "type":"account_information",
         "access":{
            "accounts":[
               {
                  "iban":"DE2310010010123456789"
               },
               {
                  "maskedPan":"123456xxxxxx1234"
               }
            ],
            "balances":[
               {
                  "iban":"DE2310010010123456789"
               }
            ],
            "transactions":[
               {
                  "iban":"DE2310010010123456789"
               },
               {
                  "maskedPan":"123456xxxxxx1234"
               }
            ]
         },
         "recurringIndicator":true
      }
   ]
}

再举一个例子，客户端请求访问一份医疗记录，但 在请求时不知道记录编号。在此示例中，客户端指定它 想要的访问类型，但未指定该访问的位置或标识符。¶

{
"authorization_details": [
   {
      "type": "medical_record",
      "sens": [ "HIV", "ETH", "MART" ],
      "actions": [ "read" ],
      "datatypes": [ "Patient", "Observation", "Appointment" ]
   }
]}

当用户与 AS 交互时，他们选择哪些医疗记录 由其负责提供给客户端。此信息会随访问 令牌一起返回。¶

{
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA",
   "authorization_details":[
    {
      "type": "medical_record",
      "sens": [ "HIV", "ETH", "MART" ],
      "actions": [ "read" ],
      "datatypes": [ "Patient", "Observation", "Appointment" ],
      "identifier": "patient-541235",
      "locations": [ "https://records.example.com/" ]
     }
  ]
}

9.1. 基于 JWT 的访问 令牌

如果访问令牌是 JWT [RFC7519]，则 RECOMMENDED AS 将针对特定受众过滤后的授权详情对象添加为顶层 声明。¶

AS 通常还会向 JWT 添加 RS 处理请求所需的其他 声明，例如用户 ID、角色和交易特定数据。特定 RS 需要哪些声明由该 RS 与 AS 之间的特定策略定义。¶

下面展示了上述支付发起 示例的一个示例 JWT 内容：¶

{
   "iss": "https://as.example.com",
   "sub": "24400320",
   "aud": "a7AfcPcsl2",
   "exp": 1311281970,
   "acr": "psd2_sca",
   "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
   "authorization_details": [
      {
         "type": "https://scheme.example.com/payment_initiation",
         "actions": [
            "initiate",
            "status",
            "cancel"
         ],
         "locations": [
            "https://example.com/payments"
         ],
         "instructedAmount": {
            "currency": "EUR",
            "amount": "123.50"
         },
         "creditorName": "Merchant A",
         "creditorAccount": {
            "iban": "DE02100100109307118603"
         },
         "remittanceInformationUnstructured": "Ref Number Merchant"
      }
   ],
   "debtorAccount": {
      "iban": "DE40100100103307118608",
      "user_role": "owner"
   }
}

在这种情况下，AS 向基于 JWT 的 访问令牌添加了以下示例声明：¶

sub:

指示客户端正在为其 请求支付发起的用户。¶

txn:

用于在提供者 example.com 的各服务之间跟踪交易的交易 ID¶

debtorAccount:

包含债务人账户的 API 特定字段。 在该示例中，此账户并未在 authorization_details 中传递，而是由用户在授权 过程中选择的。user_role 字段传达用户相对于该 特定账户所具有的角色。在这种情况下，他们是所有者。此数据用于 支付 API（RS）处的访问控制。¶

9.2. 令牌自省

令牌自省 [RFC7662] 提供了一种手段，使 RS 能够查询 AS 以 确定有关访问令牌的信息。如果 AS 在其响应中包含该令牌的授权详情信息， 则该信息 MUST 以 authorization_details 作为自省响应 JSON 对象的顶层成员来传达。authorization_details 成员 MUST 包含 第 2 节 中定义的相同结构， 可能会针对发起自省请求的 RS 进行过滤和扩展。¶

下面是支付发起 示例的一个自省响应示例：¶

{
   "active": true,
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "exp": 1311281970,
   "acr": "psd2_sca",
   "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
   "authorization_details": [
      {
         "type": "https://scheme.example.com/payment_initiation",
         "actions": [
            "initiate",
            "status",
            "cancel"
         ],
         "locations": [
            "https://example.com/payments"
         ],
         "instructedAmount": {
            "currency": "EUR",
            "amount": "123.50"
         },
         "creditorName": "Merchant123",
         "creditorAccount": {
            "iban": "DE02100100109307118603"
         },
         "remittanceInformationUnstructured": "Ref Number Merchant"
      }
   ],
   "debtorAccount": {
      "iban": "DE40100100103307118608",
      "user_role": "owner"
   }
}

11.1. 在特定部署中使用授权 详情

在特定部署中使用授权详情将需要 以下步骤：¶

• 定义授权详情类型。¶
• 在 OAuth 服务器 元数据中发布授权详情类型。¶
• 确定授权详情如何在 用户同意提示中显示给用户。¶
• 如有需要，在用户 同意过程中增强授权详情（例如添加选定账户或设置过期时间）。¶
• 如有需要，确定授权详情如何 反映在访问令牌内容或自省响应中。¶
• 确定 RS 如何处理授权详情 或从授权详情派生的令牌数据。¶
• 如有需要，授权客户端使用某些授权 详情类型。¶

11.2. 最小实现 支持

支持本规范的通用 AS 实现应提供 以下基本功能：¶

• 支持在 OAuth 服务器元数据中公告受支持的授权 详情类型¶
• 根据本规范接受授权请求中的 authorization_details 参数¶
• 支持将已同意的授权详情作为 授权的一部分进行存储¶
• 实现用于将授权 详情添加到访问令牌和令牌自省响应的默认行为，以便使其可供 RS 使用（类似于 scope 值）。这应适用于任何授权类型，尤其是 authorization_code 和 refresh_token。¶

不同授权详情类型之间，授权详情的处理和呈现将有显著差异。 因此，实现应支持对相应行为进行 自定义。特别是，实现应允许 部署：¶

• 确定授权详情的呈现；¶
• 在用户 同意过程中修改请求的授权详情，例如添加字段；以及¶
• 合并请求的和预先存在的授权 详情。¶

支持此类自定义的一种方法是提供一种机制， 允许注册扩展模块，每个模块负责呈现 相应的用户同意，并负责为通过 结构化访问令牌或令牌自省响应向 RS 提供所需数据而进行的任何转换。¶

11.3. 机器可读类型模式的使用

实现可以允许部署使用机器可读模式 语言来定义授权详情类型，以便根据此类模式创建和验证 授权详情对象。例如，如果某个授权详情 type 使用 JSON Schema [JSON.Schema] 来定义，则该 JSON Schema 标识符可用作 相应授权详情对象中的 type 值。¶

不过请注意，type 值是 AS 以及必要时客户端和 RS 所理解的标识符。 本规范不假设 type 值会指向 机器可读模式格式，也不假设系统中的任何一方（例如客户端、AS 或 RS） 会以任何特定方式解引用或处理 type 字段的内容。¶

11.4. 大型请求

包含作为请求参数或请求对象中的 authorization_details 的授权请求 URI 可能会变得很长。因此，实现者应 考虑使用 [RFC9101] 中定义的 request_uri 参数，并结合 [RFC9126] 中定义的推送请求对象 机制，以可靠且安全的方式传递 authorization_details。下面是此类 推送授权请求的示例，它通过受 HTTPS 保护的连接将授权请求数据直接发送给 AS：¶

  POST /as/par HTTP/1.1
  Host: as.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

  response_type=code&
  client_id=s6BhdRkqt3
  &state=af0ifjsldkj
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &code_challenge_method=S256
  &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U
  &authorization_details=%5B%7B%22type%22%3A%22account_information%22
  %2C%22actions%22%3A%5B%22list_accounts%22%2C%22read_balances%22%2C%
  22read_transactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fe
  xample.com%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment_initiat
  ion%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22canc
  el%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpaym
  ents%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22
  %2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchan
  t123%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE021001001093
  07118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%2
  0Number%20Merchant%22%7D%5D

14.1. OAuth 参数 注册

以下参数已注册到 由 [RFC6749] 建立的 "OAuth Parameters" 注册表 [IANA.OAuth.Parameters] 中。¶

名称：

authorization_details¶

参数使用位置：

授权请求、令牌请求、令牌 响应¶

变更控制方：

IETF¶

参考：

RFC 9396¶

14.2. JSON Web Token 声明 注册

以下值已注册到 由 [RFC7519] 建立的 IANA "JSON Web Token Claims" 注册表中。¶

声明名称：

authorization_details¶

声明描述：

声明 authorization_details 包含一个 JSON 对象数组，表示访问令牌的 权限。每个 JSON 对象包含用于指定 某种资源类型的授权要求的数据。¶

变更控制方：

IETF¶

参考：

RFC 9396 的 第 9.1 节¶

14.3. OAuth 令牌 自省响应注册

以下值已注册到由 [RFC7662] 建立的 IANA "OAuth Token Introspection Response" 注册表中。¶

名称：

authorization_details¶

描述：

成员 authorization_details 包含一个 JSON 对象数组，表示访问令牌的 权限。每个 JSON 对象包含用于指定 某种资源类型的授权要求的数据。¶

变更控制方：

IETF¶

参考：

RFC 9396 的 第 9.2 节¶

14.4. OAuth 授权 服务器元数据注册

以下值已注册到由 [RFC8414] 建立的 [IANA.OAuth.Parameters] 的 IANA "OAuth Authorization Server Metadata" 注册表中。¶

元数据名称：

authorization_details_types_supported¶

元数据描述：

包含 AS 支持的授权 详情类型的 JSON 数组¶

变更控制方：

IETF¶

参考：

RFC 9396 的 第 10 节¶

14.5. OAuth 动态客户端 注册元数据注册

以下值已注册到由 [RFC7591] 建立的 [IANA.OAuth.Parameters] 的 IANA "OAuth Dynamic Client Registration Metadata" 注册表中。¶

客户端元数据名称：

authorization_details_types¶

客户端元数据描述：

指示客户端使用哪些授权详情类型。¶

变更控制方：

IETF¶

参考：

RFC 9396 的 第 10 节¶

14.6. OAuth 扩展错误 注册

以下值已注册到由 [RFC6749] 建立的 [IANA.OAuth.Parameters] 的 IANA "OAuth Extensions Error Registry" 中。¶

名称：

invalid_authorization_details¶

使用位置：

令牌端点、授权端点¶

协议扩展：

OAuth 2.0 富授权请求¶

变更控制方：

IETF¶

参考：

RFC 9396 的 第 5 节¶

A.1. OpenID Connect

OpenID Connect [OIDC] 指定了基于 JSON 的 claims 请求参数，可用于以细粒度 且保护隐私的方式指定客户端（作为 OpenID Connect Relying Party）希望接收的 声明，并将这些声明分配给某些传递机制，即 ID Token 或 userinfo 响应。¶

scope 值 openid 与附加 参数 claims 的组合，可以像任何非 OIDC scope 值一样，与 authorization_details 一起使用。¶

或者，也可以为 OpenID Connect 设置一种授权详情类型。本节给出了这种授权详情类型可能 是什么样子的示例，但定义此授权详情类型超出本规范的范围。¶

这些假设示例试图将授权过程中 OpenID Connect 部分特有的所有细节封装到授权 JSON 对象中。¶

顶层字段基于 [OIDC] 中给出的定义：¶

claim_sets:

预定义声明集的名称， 替代相应的 scope 值，例如 profile¶

max_age:

最大认证年龄¶

acr_values:

请求的认证上下文类 引用（ACR）值¶

claims:

如 [OIDC] 中定义的 claims JSON 结构¶

这是对若干声明集的简单请求。¶

[
   {
      "type": "openid",
      "locations": [
         "https://op.example.com/userinfo"
      ],
      "claim_sets": [
         "email",
         "profile"
      ]
   }
]

图 26 展示了一个更复杂的示例。¶

[
   {
      "type": "openid",
      "locations": [
         "https://op.example.com/userinfo"
      ],
      "max_age": 86400,
      "acr_values": "urn:mace:incommon:iap:silver",
      "claims": {
         "userinfo": {
            "given_name": {
               "essential": true
            },
            "nickname": null,
            "email": {
               "essential": true
            },
            "email_verified": {
               "essential": true
            },
            "picture": null,
            "http://example.com/claims/groups": null
         },
         "id_token": {
            "auth_time": {
               "essential": true
            }
         }
      }
   }
]

A.2. 远程电子 签名

以下示例基于 ETSI TS 119 432 [ETSI] 中提出的远程电子 签名概念，以及用于远程签名创建的 Cloud Signature Consortium (CSC) API [CSC]。¶

[
   {
      "type": "sign",
      "locations": [
         "https://signing.example.com/signdoc"
      ],
      "credentialID": "60916d31-932e-4820-ba82-1fcead1c9ea3",
      "documentDigests": [
         {
            "hash": "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
            "label": "Credit Contract"
         },
         {
            "hash": "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=",
            "label": "Contract Payment Protection Insurance"
         }
      ],
      "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1"
   }
]

顶层字段具有以下含义：¶

credentialID:

要用于 签名的证书标识符¶

documentDigests:

包含每个待签名文档 哈希（hash 字段）的数组。此外，对应的 label 字段向用户标识相应文档，例如用于用户同意。¶

hashAlgorithm:

用于计算 哈希值的算法¶

AS 应请求用户同意为该结构中列出的 文档创建签名。客户端使用作为该过程结果颁发的访问令牌 调用相应签名服务处的文档签名 API，以实际 创建签名。该访问令牌绑定到客户端、用户 ID 以及用户 已同意的哈希（和签名算法）。¶

A.3. 访问税务数据

此示例受到允许第三方访问公民 税务申报和收入报表的 API 启发，例如用于确定其信用状况。¶

[
    {
        "type": "tax_data",
        "locations": [
            "https://taxservice.govehub.no.example.com"
        ],
        "actions":"read_tax_declaration",
        "periods": ["2018"],
        "duration_of_access": 30,
        "tax_payer_id": "23674185438934"
    }
]

顶层字段具有以下含义：¶

periods:

客户端希望访问的期间¶

duration_of_access:

客户端打算访问数据的时长， 以天为单位¶

tax_payer_id:

纳税人的标识符（如果客户端知道）¶

A.4. 电子健康

这两个示例受到挪威电子健康系统中使用的 API 要求启发。¶

在此用例中，物理治疗师坐在自己的计算机前， 使用本地电子健康记录（EHR）系统。他们希望查看某个患者的电子 患者记录，并且还希望从另一个系统（可能在另一个机构或国家服务中） 获取患者的病历条目。对此类数据的访问由 API 提供。¶

在 API 处授权该请求所需的信息仅由 EHR 系统知道，并且必须提交给 API。¶

在第一个示例中，授权详情对象包含一个 组织的标识符。在这种情况下，API 需要知道给定组织是否具有 处理个人健康信息以访问敏感数据的合法依据。¶

"authorization_details": {
    "type": "patient_record",
    "requesting_entity": {
        "type": "Practitioner",
        "identifier": [
        {
            "system": "urn:oid:2.16.578.1.12.4.1.4.4",
            "value": "1234567"
        }],
        "practitioner_role": {
            "organization": {
                "identifier": {
                    "system": "urn:oid:2.16.578.1.12.4.1.2.101",
                    "type": "ENH",
                    "value": "[organizational number]"
                }
            }
        }
    }
}

在第二个示例中，API 需要更多信息来授权 请求。在这种情况下，授权详情对象包含有关 健康机构以及用户在请求时当前职业的附加信息。 这一额外详细级别可同时用于授权和数据最小化。¶

[
   {
      "type": "patient_record",
      "location": "https://fhir.example.com/patient",
      "actions": [
         "read"
      ],
      "patient_identifier": [
         {
            "system": "urn:oid:2.16.578.1.12.4.1.4.1",
            "value": "12345678901"
         }
      ],
      "reason_for_request": "Clinical treatment",
      "requesting_entity": {
         "type": "Practitioner",
         "identifier": [
            {
               "system": "urn:oid:2.16.578.1.12.4.1.4.4",
               "value": "1234567"
            }
         ],
         "practitioner_role": {
            "organization": {
               "identifier": [
                  {
                     "system": "urn:oid:2.16.578.1.12.4.1.2.101",
                     "type": "ENH",
                     "value": "<organizational number>"
                  }
               ],
               "type": {
                  "coding": [
                     {
                        "system":
                           "http://hl7.example.org/fhir/org-type",
                        "code": "dept",
                        "display": "Hospital Department"
                     }
                  ]
               },
               "name": "Akuttmottak"
            },
            "profession": {
               "coding": [
                  {
                     "system": "http://snomed.example.org/sct",
                     "code": "36682004",
                     "display": "Physical therapist"
                  }
               ]
            }
         }
      }
   }
]

字段描述：¶

patient_identifier:

由 OID 格式的系统标识符（命名空间）和 该命名空间内实际值组成的患者标识符。¶

reason_for_request:

用户希望访问某个 API 的原因。¶

requesting_entity:

通过 身份、角色和组织上下文来说明请求者。提供此数据是为了便利授权 以及用于审计目的。¶

在此用例中，AS 对请求者进行身份验证，该请求者不是 患者，并基于策略批准访问。¶