Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia August 2026
Zehavi Expires 10 February 2027 [Page]
Workgroup:
Web Authorization Protocol
Internet-Draft:
draft-zehavi-oauth-rar-metadata-06
Published:
Intended Status:
Standards Track
Expires:
Author:
Y. Zehavi
Raiffeisen Bank International

OAuth 2.0 RAR Metadata and Error Remediation

Abstract

OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types.

In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details.

This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out-of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://yaron-zehavi.github.io/oauth-rich-authorization-requests-metadata/draft-zehavi-oauth-rar-metadata.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/.

Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.

Source for this draft and an issue tracker can be found at https://github.com/yaron-zehavi/oauth-rich-authorization-requests-metadata.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 10 February 2027.

▲

Table of Contents

1. Introduction

OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] allows OAuth clients to request detailed and structured authorization, enabling advanced authorization models across domains such as banking and healthcare.

However, RAR [RFC9396] does not specify how clients discover metadata describing valid authorization details objects. Such metadata and documentation are obtained out-of-band.

This document defines:

Providing clients with actionable authorization details objects enables:

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Protocol Overview

Client remediates using actionable authorization details objects provided by resource server:

                                                +--------------------+
             +----------+ (B) API Request       |                    |
             |          |---------------------->|      Resource      |
(A) User +---|          |                       |       Server       |
   Starts|   |          |<----------------------|                    |
   Flow  +-->|  Client  | (C) 401 Unauthorized     +--------------------+
             |          |     WWW-Authenticate: Bearer
             |          |     error="insufficient_authorization",
             |          |     error_description=[human readable message],
             |          |     authorization_remediation=[required
             |          |     authorization_details]
             |          |        :
             |          |        :              +--------------------+
             |          |        :              |   Authorization    |
             |          | (D) Authorization     |      Server        |
             |          |     Request + RAR     |+------------------+|
             |          |---------------------->||                  ||
             |          |                       ||  Authorization   ||
             |          |<----------------------||    Endpoint      ||
             |          | (E) Authorization Code||                  ||
             |          |        :              |+------------------+|
             |          |        :              |                    |
             |          | (F) Token Request     |+------------------+|
             |          |---------------------->||                  ||
             |          |                       || Token Endpoint   ||
             |          |<----------------------||                  ||
             |          | (G) Access Token      |+------------------+|
             |          |        :              +--------------------+
             |          |        :
             |          |        :
             |          | (H) Retry API Call    +--------------------+
             |          |     with Token        |                    |
             |          |---------------------->|      Resource      |
             |          |                       |       Server       |
             |          |<----------------------|                    |
             |          | (I) 200 OK + Resource +--------------------+
             |          |
             +----------+

Figure: Client remediates using actionable authorization details objects provided by resource server

4. Remediation of failures due to insufficient authorization

This document defines:

Notes:

Example HTTP response from a direct debit resource:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_authorization",
error_description="Additional authorization is required",
authorization_remediation=eyJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJkaX...

The decoded authorization_remediation contents in this example are:

{
    "authorization_details": [{
            "type": "direct_debit_mandate",
            "DebtorAccount": {
                "SchemeName": "UK.OBIE.SortCodeAccountNumber",
                "Identification": "08080021325698",
                "Name": "JohnDoe"
            },
            "CreditorAgent": {
                "SchemeName": "UK.OBIE.BICFI",
                "Identification": "NWBKGB22"
            },
            "CreditorAccount": {
                "SchemeName": "UK.OBIE.SortCodeAccountNumber",
                "Identification": "08080021325698",
                "Name": "ACMECorp"
            },
            "MandateStatus": "Active",
            "CreationDateTime": "2026-06-01T09:00:00+00:00"
        }
    ],
    "authorization_reference": "Yb7q3AC5d"
}

Example HTTP response from a payment initiation resource:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_authorization",
error_description="Additional authorization is required",
authorization_remediation=eyJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJkaX...

The decoded authorization_remediation contents in this example are:

{
    "authorization_details": [{
           "type": "payment_initiation",
           "instructed_amount": {
              "currency": "EUR",
              "amount": "100.00"
           },
           "creditor_account": {
              "iban": "DE02120300000000202051"
           }
       }
   ]
}

5. Authorization Details Types Metadata Endpoint

The following authorization server metadata [RFC8414] parameter is introduced to indicate the server's support for Authorization Details Types Metadata:

"authorization_details_types_metadata_endpoint":

OPTIONAL. The URL of the Authorization Details Types Metadata endpoint.

The Authorization Details Types Metadata endpoint is called with HTTP GET and responds with Content-Type application/json and a JSON object whose members are authorization details type identifiers.

Each member value is an object describing a single authorization details type.

{
  "type": {
    "version": "...",
    "description": "...",
    "documentation_uri": "...",
    "schema": { },
    "schema_uri": "...",
    "examples": [ ]
  }
}

Attribute definition:

"version":

OPTIONAL. String identifying the version of the authorization details type definition. The value is informational and does not imply semantic version negotiation.

"description":

OPTIONAL. String containing a description of the authorization details type. Clients MUST NOT rely on this value for authorization or validation decisions.

"documentation_uri":

OPTIONAL. URI referencing external documentation describing the authorization details type.

"schema":

The schema attribute contains a JSON Schema document [JSON.Schema] that describes a single authorization details object. The schema MUST validate exactly one authorization details object and MUST restrict the type attribute to the corresponding authorization details type identifier. This attribute is REQUIRED unless schema_uri is specified. If present, schema_uri MUST NOT be included.

"schema_uri":

The schema_uri attribute is an absolute URI, as defined by RFC 3986 [RFC3986], referencing a JSON Schema document describing a single authorization details object. The referenced schema MUST satisfy the same requirements as the schema attribute. This attribute is REQUIRED unless schema is specified. If this attribute is present, schema MUST NOT be present.

"examples":

OPTIONAL. An array of example authorization details objects. Examples are non-normative.

See Examples Appendix A.1 for non-normative response example.

6. RAR objects in JWT access tokens

Pursuant with RAR [RFC9396] section 9, authorization servers MUST provide approved RAR objects to resource servers for enforcement. The authorization server MAY add the authorization_details attribute to access tokens in JSON Web Token (JWT) format or to token introspection responses.

There may however be cases, where due to various considerations such as token size or information privacy, including approved RAR objects in JWT access tokens would be advised against.

It is RECOMMENDED that when an authorization server issues JWT access tokens, it should consider the size, sensitivity, and privacy implications of including the authorization_details attribute. Where appropriate, the authorization server SHOULD omit this attribute from JWT tokens and instead provide the approved RAR objects to resource servers via the token introspection endpoint. This endpoint SHOULD use appropriate client authentication methods to prevent unauthorized access, in case of token leakage.

7. Processing Rules

7.1. Client Processing Rules

General:

Client MAY attempt calling resource server, either on first attempt or as a remediation step, using any valid tokens which were obtained following a remediation challenge from same resource server origin, which included an authorization_reference, as such tokens are not limited for single-use.

Existing tokens whose authority is inclusive may permit resource calls requiring lower authority, despite their authorization_reference value differs from value obtained in other remediation challenges. For example, a recurring direct debit token permitting up to 100$ can authorize a 80$ debit, although the remediation challenges returned when attempting 80$ or 100$ debits with insufficient authority, will differ in their authorization_details and authorization_reference values.

Therefore attempting a 80$ debit with an existing token permitting 100$ debits may succeed.

Handling an HTTP 401 failure response:

When a client receives an HTTP 401 response with WWW-Authenticate error code insufficient_authorization and an authorization_remediation parameter, it SHOULD process it as follows.

7.1.1. Step 1 - Parse the remediation response

The client decodes the base64url-encoded authorization_remediation JSON object and extracts:

  • authorization_details (RECOMMENDED): the actionable RAR objects.

  • authorization_reference (OPTIONAL): an opaque string for token-bag lookup.

7.1.2. Step 2 - Attempt token reuse via authorization_reference (if present)

  1. If the authorization_remediation contains an authorization_reference attribute, the client SHOULD search its in-session tokens for a token previously associated with that reference value and the same resource server origin.

  2. Matching is a simple string comparison — the client MUST NOT attempt to compute, parse, or derive meaning from the reference value.

  3. If a matching, non-expired token is found, the client MAY retry the failing request with that token. If the retry also fails with insufficient_authorization, the client MUST NOT retry again with the same token for the same reference and SHOULD proceed to Step 3.

  4. If no matching token is found, the client proceeds to Step 3.

7.1.3. Step 3 - Obtain a new token via OAuth + RAR

The client proceeds to this step if: (a) no authorization_reference was present, (b) no matching token in client's possession was found, (c) a matched token was rejected by the resource server (Step 2, item 4), or (d) the client elects to skip an existing token lookup and use authorization_details directly.

  1. The client uses the authorization_details from the authorization_remediation response in a new OAuth authorization request per [RFC9396]. The client MAY use any grant type or extension that supports RAR (such as PAR [RFC9126], JAR [RFC9101], etc).

  2. Upon successful token issuance, if the triggering resource server response included an authorization_reference, the client SHOULD persist the newly obtained token associated with that reference value and the resource server origin in its in-session token storage. This token-to-reference association enables future lookups in Step 2 when the same authorization_reference is encountered again.

  3. The client retries the failing request with the newly obtained token.

7.1.4. Step 4 - Handle continued failure

If after obtaining a new token and retrying, the resource server still returns insufficient_authorization:

  • If the new response contains a different authorization_reference, the client MAY attempt remediation again (subject to implementation-defined retry limits).

  • If the new response contains the same authorization_reference, the client MUST NOT loop — it SHOULD treat the failure as non-remediable and report an error to the user or calling application.

7.1.5. Additional guidance

  • Clients MAY ignore authorization_reference entirely if they do not implement token caching or reuse. In that case, each insufficient_authorization response triggers a fresh authorization request using the provided authorization_details.

  • If the client's current authorization server does not support the required authorization details types (as indicated by its metadata), the client MAY use Protected Resource Metadata [RFC9728] to discover alternative authorization servers for the resource.

  • The token storage MUST be scoped per end-user session. Concurrent users operating through the same client instance MUST maintain separate token storage instances.

7.2. Resource Server Processing Rules

When a resource server receives a request with an OAuth token:

7.2.1. Step 1 - Validate the access token

Verify token validity following [RFC6750] or [RFC9068] if JWT profiled. If the token is invalid for reasons other than insufficient authorization details, return the appropriate existing error code (e.g., invalid_token).

7.2.2. Step 2 - Verify authorization details (if present)

Determine whether the token carries sufficient authorization details for the requested operation. Authorization details MAY be obtained from the JWT access token payload or via token introspection [RFC7662].

7.2.3. Step 3 - If authorization details are missing or insufficient

The resource server responds with an error per the bearer token error framework [RFC6750] Section 3. The specific error code depends on the nature of the failure: - If the token is valid but lacks sufficient scope, the resource server returns insufficient_scope per [RFC6750] Section 3.1. - If the token is valid but lacks sufficient authentication context (e.g., ACR/AMR level), the resource server returns insufficient_user_authentication per [RFC9470]. - If the token is valid but lacks sufficient authorization details, the RS returns insufficient_authorization per Section 4 of this document, with an authorization_remediation parameter as defined in Section 4.1. The authorization_remediation parameter carries the actionable authorization_details and optional authorization_reference as specified in Section 4. The resource server constructs these per the rules defined below.

7.3. Limitations and Considerations for authorization_reference

Implementers should be aware of the following limitations:

7.3.1. Token reuse is opportunistic, not guaranteed

A matching authorization_reference with client's existing tokens does NOT guarantee the token will be accepted by the resource server. The token may have been issued under conditions that no longer apply:

  • The resource owner may have revoked consent since the token was issued.

  • Contextual risk may have changed (e.g., geolocation, device posture), causing the resource server to require stronger authorization ceremonies.

  • The authorization server may have issued the token with a subset of the requested authorization details (per [RFC9396] Section 7).

Clients MUST handle the case where a reused token is rejected despite matching the authorization_reference (see Section 7.1, Step 2, item 4).

7.3.2. authorization_reference does not replace authorization_details

The authorization_reference is an optimization for token selection. It is NOT a substitute for authorization_details:

  • authorization_details is RECOMMENDED in every authorization_remediation response providing actionable RAR objects and is what the client uses when initiating a new authorization request.

  • authorization_reference is RECOMMENDED and enables the client to avoid unnecessary authorization flows when it already possesses a suitable token.

Clients that do not implement token caching MAY safely ignore authorization_reference with no loss of interoperability.

7.3.3. Loop prevention

If the resource server consistently returns the same authorization_reference and rejects tokens obtained via the associated authorization_details, the client may enter an infinite loop. To prevent this:

  • Clients MUST implement a maximum retry count (RECOMMENDED: 1 retry with a cached token, then 1 fresh authorization attempt, then fail).

  • If a freshly obtained token (from a new authorization flow using the resource server provided authorization_details) is immediately rejected by the same resource server with the same authorization_reference, the client MUST stop and report the error.

7.3.4. No cross-resource-server portability

The authorization_reference value is scoped to the producing resource server. It MUST NOT be used for token selection when interacting with a different resource server, even if the two servers enforce similar authorization details types.

7.3.5. Analogy to scope-based token selection

The authorization_reference mechanism is analogous to how clients select tokens based on OAuth scopes in traditional deployments. Just as a client maintains a mapping of {scope → token} and selects the appropriate token for each resource server call, this mechanism extends that pattern to RAR:

Table 1
Traditional (scope-based) RAR + authorization_reference
Resource server returns insufficient_scope with required scope value Resource server returns insufficient_authorization with authorization_remediation
Client checks if it has a token with matching scope Client checks if it has a token with matching authorization_reference
Simple string comparison on scope values Simple string comparison on reference values
If not found, request new token with required scope If not found, request new token with provided authorization_details

The key advantage: clients do not need to understand, parse, or compare complex JSON authorization_details objects — the resource server has already reduced the comparison to an opaque string.

8. Security Considerations

8.1. Confidentiality of resource server provided authorization_details

Resource servers when providing actionable authorization_details SHOULD NOT include sensitive data in those objects. This is consistent with RAR [RFC9396] authorization_details OAuth request parameter, representing request semantics.

Confidentiality-preserving authorization_details types SHOULD NOT include sensitive data. Instead, the end-user SHOULD provide such information when interacting with the authorization server.

Alternatively, authorization_details MAY refer to specific end-user resources using opaque reference handles (e.g., "account_1a" instead of using explicit IBAN).

9. IANA Considerations

9.1. OAuth 2.0 WWW-Authenticate Error Code Registry

Table 2
Error Code Error Usage Location Change Controller Specification Document
insufficient_authorization Resource access error response IETF RFC XXXX, Section X

9.2. OAuth Authorization Server Metadata Registry

This specification registers the following authorization server metadata parameter in the OAuth Authorization Server Metadata registry:

Table 3
Metadata Name Metadata Description Change Controller Specification Document
authorization_details_types_metadata_endpoint URL of the Authorization Details Types Metadata endpoint IETF RFC XXXX, Section X

10. Normative References

[IANA.oauth-parameters]
"*** BROKEN REFERENCE ***".
[JSON.Schema]
Wright, Ed, A., Andrews, Ed, H., Hutton, Ed, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", , <https://json-schema.org/draft/2020-12/json-schema-core>.
[RFC2119]
"*** BROKEN REFERENCE ***".
[RFC3986]
"*** BROKEN REFERENCE ***".
[RFC6750]
"*** BROKEN REFERENCE ***".
[RFC7662]
"*** BROKEN REFERENCE ***".
[RFC8174]
"*** BROKEN REFERENCE ***".
[RFC8414]
"*** BROKEN REFERENCE ***".
[RFC9068]
"*** BROKEN REFERENCE ***".
[RFC9101]
"*** BROKEN REFERENCE ***".
[RFC9126]
"*** BROKEN REFERENCE ***".
[RFC9396]
"*** BROKEN REFERENCE ***".
[RFC9470]
"*** BROKEN REFERENCE ***".
[RFC9728]
"*** BROKEN REFERENCE ***".

Appendix A. Examples

This section provides non-normative examples of how this specification may be used to support specific use cases.

A.1. Authorization Server Metadata Examples

A.1.1. Example authorization_details_types_metadata_endpoint response with Payment Initiation 

HTTP/1.1 200 OK
Content-Type: application/json

{
    "payment_initiation": {
        "version": "1.0",
        "description": "Authorization to initiate a single payment from a payer account to a creditor account.",
        "documentation_uri": "https://example.com/docs/payment-initiation",
        "schema": {
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "title": "Payment Initiation Authorization Detail",
            "type": "object",
            "required": [
                "type",
                "instructed_amount",
                "creditor_account"
            ],
            "properties": {
                "type": {
                    "const": "payment_initiation",
                    "description": "Authorization details type identifier."
                },
                "actions": {
                    "type": "array",
                    "description": "Permitted actions for this authorization.",
                    "items": {
                        "type": "string",
                        "enum": ["initiate"]
                    },
                    "minItems": 1,
                    "uniqueItems": true
                },
                "instructed_amount": {
                    "type": "object",
                    "description": "Amount and currency of the payment to be initiated.",
                    "required": ["currency", "amount"],
                    "properties": {
                        "currency": {
                            "type": "string",
                            "description": "ISO 4217 currency code.",
                            "pattern": "^[A-Z]{3}$"
                        },
                        "amount": {
                            "type": "string",
                            "description": "Decimal monetary amount represented as a string.",
                            "pattern": "^[0-9]+(\\.[0-9]{1,2})?$"
                        }
                    }
                },
                "creditor_account": {
                    "type": "object",
                    "description": "Account to which the payment will be credited.",
                    "required": ["iban"],
                    "properties": {
                        "iban": {
                            "type": "string",
                            "description": "International Bank Account Number (IBAN).",
                            "pattern": "^[A-Z0-9]{15,34}$"
                        }
                    }
                },
                "remittance_information": {
                    "type": "string",
                    "description": "Unstructured remittance information for the payment.",
                    "maxLength": 140
                }
            }
        }
    }
}

A.1.2. Example authorization_details_types_metadata_endpoint response for the Norwegian Health Sector (HelseID) 

HTTP/1.1 200 OK
Content-Type: application/json

{

    "helseid_authorization": {
        "version": "1.0",
        "description": "Allows the OAuth client to pass organization information to HelseID.",
        "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tekniske-mekanismer/organisasjonsnumre_enmd",
        "schema": {
            "$schema": "http://json-schema.org/draft-07/schema#",
            "title": "Organization numbers for a multi-tenant client",
            "type": "object",
            "properties": {
                "type": {
                    "type": "string",
                    "const": "helseid_autorization"
                },
                "practitioner_role": {
                    "type": "object",
                    "properties": {
                        "organization": {
                            "type": "object",
                            "properties": {
                                "identifier": {
                                    "type": "object",
                                    "properties": {
                                        "system": {
                                            "type": "string"
                                        },
                                        "type": {
                                            "type": "string"
                                        },
                                        "value": {
                                            "type": "string"
                                        }
                                    },
                                    "required": [
                                        "system",
                                        "type",
                                        "value"
                                    ]
                                }
                            },
                            "required": [
                                "identifier"
                            ]
                        }
                    },
                    "required": [
                        "organization"
                    ]
                }
            },
            "required": [
                "type",
                "practitioner_role"
            ]
        }
    },
    "helseid_trust_framework": {
        "version": "1.0",
        "description": "HelseID Trust Framework Information",
        "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tekniske-mekanismer/trust-framework",
        "schema": {
            "$schema": "http://json-schema.org/draft-07/schema#",
            "description": "Complete Trust Framework structure",
            "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tillitsrammeverk/profil_for_tillitsrammeverkmd",
            "type": "object",
            "properties": {
                "type": {
                    "type": "string",
                    "const": "nhn:tillitsrammeverk:parameters"
                },
                "practitioner": {
                    "type": "object",
                    "properties": {
                        "authorization": {
                            "type": "object",
                            "properties": {
                                "code": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "code",
                                "system"
                            ]
                        },
                        "legal_entity": {
                            "type": "object",
                            "properties": {
                                "id": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "id",
                                "system"
                            ]
                        },
                        "point_of_care": {
                            "type": "object",
                            "properties": {
                                "id": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "id",
                                "system"
                            ]
                        },
                        "department": {
                            "type": "object",
                            "properties": {
                                "id": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "id",
                                "system"
                            ]
                        }
                    },
                    "required": [
                        "authorization",
                        "legal_entity",
                        "point_of_care",
                        "department"
                    ]
                },
                "care_relationship": {
                    "type": "object",
                    "properties": {
                        "healthcare_service": {
                            "type": "object",
                            "properties": {
                                "code": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "code",
                                "system"
                            ]
                        },
                        "purpose_of_use": {
                            "type": "object",
                            "properties": {
                                "code": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "code",
                                "system"
                            ]
                        },
                        "purpose_of_use_details": {
                            "type": "object",
                            "properties": {
                                "code": {
                                    "type": "string"
                                },
                                "system": {
                                    "type": "string"
                                }
                            },
                            "required": [
                                "code",
                                "system"
                            ]
                        },
                        "decision_ref": {
                            "type": "object",
                            "properties": {
                                "id": {
                                    "type": "string"
                                },
                                "user_selected": {
                                    "type": "boolean"
                                }
                            },
                            "required": [
                                "id",
                                "user_selected"
                            ]
                        }
                    },
                    "required": [
                        "healthcare_service",
                        "purpose_of_use",
                        "purpose_of_use_details",
                        "decision_ref"
                    ]
                },
                "patients": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "point_of_care": {
                                "type": "object",
                                "properties": {
                                    "id": {
                                        "type": "string"
                                    },
                                    "system": {
                                        "type": "string"
                                    }
                                },
                                "required": [
                                    "id",
                                    "system"
                                ]
                            },
                            "department": {
                                "type": "object",
                                "properties": {
                                    "id": {
                                        "type": "string"
                                    },
                                    "system": {
                                        "type": "string"
                                    }
                                },
                                "required": [
                                    "id",
                                    "system"
                                ]
                            }
                        },
                        "required": [
                            "point_of_care",
                            "department"
                        ]
                    }
                }
            },
            "required": [
                "type",
                "practitioner",
                "care_relationship",
                "patients"
            ]
        }
    }
}

Appendix B. Document History

-06

-05

-04

-03

-02

-01

-00

Acknowledgments

The authors would like to thank the following individuals who contributed ideas, feedback, and wording that helped shape the final specification: Rune Grimstad, Justin Richer, Jeff Lombardo, Judith Kahrer, Pieter Kasselman.

Author's Address

Yaron Zehavi
Raiffeisen Bank International