Push authorization - URL schema and semantics

Push authorization (PA) URL schema and semantics.

Distribution of this documentation other than via the Decozo website decozo.org is not allowed, see https://drafts.decozo.org/docs/licentie (in Dutch) for more information.

Introduction

As described in US patent US10599830B2, Push Authorization (PA) introduces a mechanism for providing access to patient records decentrally, without the need to use (trusted, external) centralized components to mediate access to those records. There is also no need for centralized components that store information for locating patient records (localization services or indices).

Instead, the owner generates a "reference", a URL that refers to a specific patient record. This reference or push authorization URL (PA-URL) is "pushed" (actively sent) to the receiving party, who can use it to access the specified resource directly from the source. Regular healthcare processes such as referrals or prescription flows can be used for sending references to a party that may require access. A push authorization URL encodes some information in the pathname that is relevant for the recipient of the reference, such as the document Type, so the receiver knows what information can be retrieved using the URL.

A PA-URL contains a token (a UUID) that ensures it is unique, and describes its (security) properties. Every reference points to a specific patient record at a specific source. A reference is usable by only one specific healthcare professional or healthcare provider - it is bound to this healthcare provider or professional. Reference binding can take place at the time of generating the reference (pre-binding) or at the time when it is used first (late binding), but it can only take place once. Constraints on who can be bound to a late-bound reference exists (see specification below). Because references are cryptographically unique and can be bound to specific users, the model provides for a a very secure mechanism for passing authorizations.

Note: this document uses the terms references, authorizations, (PA-)URs and capabilties interchangeably; in the context of this document, these terms are synonyms.

To ensure that patient information can be made accessible to healthcare providers or professionals that are involved with treating a patient in all realistic healthcare scenario's, the system provides a mechanism for delegate access to resources without requiring the original holder of a patient's information to send PA-URLs to all parties involved with treatment individually. This mechanism, called Onward Authorization or 'doorautorisatie', allows for any party that is bound to an authorization - this can also be the patient - to request a new, typically late-bound reference from the source and send it it to a new healthcare professional. This enables a patient-centric network of access to different source records to be constructed dynamically, using any point in the network (or "chain of authorizations") as a point to extend the network from.

The push authorization framework replaces traditional, centralized "pull-based" authorizations with a "push-based" paradigm. In a pull system, a broker (a central switching point or other centralized access control component) manages access based on the role of the requesting party (Role-Based Access Control, RBAC), which creates a significant attack surface and privacy risks. In contrast, push authorization is designed so that authorizations can be sent to a recipient via any mechanism, after which the recipient can directly access the information it is authorized to see (if it is [allowed to be] bound). No centralized components are neeeded, avoiding the need to trust components that may in fact be vulnerable to compromize.

A reference's security properties ensure that access is only granted to explicitly authorized entities, according to an authorization policy under control of the source system. Policies are defined such that they match (and model) healthcare processees, such as prescription or referral flows.

A policy is associated with every reference that defines what (types of) parties may request an authorization and who may bind to such an authorization. Here, typically, roles (in healthcare, codes for specializations that match the Dutch registration of medical professionals, BIG) or organization types are used as attributes to describe who may authorize whom to access particular information. In that sense, push authorization can also be viewed as implementing an role-based access control (RBAC) or attribute-based access control (ABAC) system with more precise control over who precisely may access particular data - mitigating the scale-related risks of general RBAC policies described above. Either way, RBAC and push authorization policies are evaluated in the policy implemented at the source.

The resulting approach is both highly secure and highly flexible, and fully auditable. All authorizations and sub-authorizations and data access are tracked at the source.

The URL schema for push authorization URLs described in this document and in the patent provides a uniform format for references, allowing them to be passed between various healthcare providers while ensuring interoperability by providing a standardized way of interpreting and using PA-URLs.

The patent is owned by Decozo Foundation and will form the basis for an open standard that describes the security properties of PA-URLs and how the properties of specific PA-URLs are to be encoded in the URL (the PA-URL schema). This document is the first draft of such a description.

Technical Specification: URL Schema for Push Authorizations

The system employs a uniform URL schema for references (encoded as URLs) to ensure interoperability across systems and healthcare networks. The structure of the URL schema is defined as follows:

<transport>://<domainname[:port]>/mdlink-v0.1/<token>/
<Type=..>[:Filter]/<Format>/<Subtype=..>/[indir-refType=..]/<recordID=..>
/<PIN=[y|n|binding-PIN]>/[bind-expiry=]/[expiry=]/[allow-renew=[y|n]]/
<permissions=R|W|C>/[WType=..]/[WFormat=..]/[WSubtype]/..

The above example contains a realistic but non-limitative set of properties that can be encoded in the PA-URL. Properties between angular brackets '< >' are mandatory, properties between square brackets optional. If a property is omitted, it defaults to 'n' ("no") unless stated otherwise.

The source (issuer of the URL) determines the URL content and ordering of the fields. Order matters. A recipient may not change the (ordering of fields in the) pathname of a URL. If any character in the path is modified, the PA-URL loses validity. In that sense, while the PA-URL remains unbound, it acts as a 'real' token or a capability. After being bound, it acts as an identity-based capability [ref Gong].

1. Core Routing and Protocol Fields

<transport>: This field specifies the data transport protocol. It is typically set to "https://" to ensure encrypted communication over (m)TLS.
<domainname[:port]>: This field defines the network location (domain name and optional TCP port) where the source system is reachable.

2. Version identification and token (unique identification of the URL)

/mdlink-v0.1/<token> is the primary, unique identification of the push authorization URL. mdlink-v0.1 defines the (version of the) push authorization request protocol, currently v0.1. <token> is a randomly generated UUID without dashes.

3. Data and Content Specification Fields

Content dat can be sent or retrieved is described using Type, Subtype, Format strings.

A record is a document or data set that consists of a set of one or more data items related to a given patient, represented in a specific Format.

<Type> This field indicates the functional type of the message or record, such as a "NHG-PS" or "AMO" (pharmacy record). A special Type is INDIR-REF for indirect reference, essentially a directory that contains other references.

The Type strings are defined externally. Example: "NHG-PS" stands for a professional summary (PS) as specified by the Dutch scientific GP organization NHG.

<Format> This field specifies the technical data format of the record, such as HL7v3, MEDEUR, HL7-CDA, or HL7-FHIR-STU4.
<Subtype> This field provides granular content identification (semantics), e.g., information about how the content of the Dataset was established, or what location of the body the data is about. It may also contain clarification of the content of a Dataset, for example an indication of the body part that an radiological scan was made of. Example: "Subtype=Bodypart:LowerAbdomen" (definitions and codesets TBD). Subtype may be included multiple times (see NEN7519 Lokalisatie).

Different forms of interaction may be allowed via a push authorization URL:

permissions=[R|W|C]`: This field specifies the permissible actions a bound party may be perform on the record.
- "R": Read/Readable.
- "W": Write/Writable.
- "C": Copy permission

[TODO: "L": Logging access; "A": Append-only (only used for indirect indices)].

R allows for the operation GET to obtain the document with type Type and format Format. (Note: more document types may be observed using content negotiation, see below).
W allows for a document to be sent back ("push-back") to the source using a PUT operation; Wtype and Wforward define allowed data types for sending information to the source (Also here, additional types may be available through content negotiation, see below).
C allows for a POST operation to copy a PA-URL, in the sense of requesting a new unique PA-URL that points to the same source record as the original (modulo policy).
Format strings may have a :filter string appended, that indicates what (optional) filter is applied by the source system to the (default) dataset that would normally be expected for a given Type. For example, an NHG-PS may be filtered to present fewer journal entries and episodes of care that are marked as significant only, compared to the standard NHG PS. This filter creates a "Minimal" PS, making the resulting string Type=NHG-PS:Minimal
recordID: This field is an opaque, source-assigned number that uniquely identifies the source record. It may contain a patient-specific identifier but this is not recommended for obvious reasons. It may also be a random number. Copied URLs deriving from a given URL may inherit the parent's recordID (in general, copied URLs will inherit properties from the parent's PA-URL).
LDSType=INDIR-REF: indicates if the PA-URL refers to a directory, i.e., a lokalisation structure. An indirect reference refers to a directory that contains a set of references to other records, facilitating the transfer of complex dossiers consisten of records contained at different sources.
indir-refType=... indicates the representation of the indirect references, for example a simple HTTP directory listing (default) or a representation corresponding to the NEN 7517 localization structure. TBD: content-negotiation is probably a better approach here.
WType and WFormat are similar to Type and Format but then for the record / message sent to the source instead of the record retrieved from it. The allowed write type and write format may be dependent on the type of recipient. When there are multiple possible document types depending on context or the party bound to the PA-URL, content negotiation may be provided.

Context negotiation (CNG)

For Type or Format fields in a URL, a property *CNG" may be specified instead of a specific Type or Format. CNG indicates that HTTP content-negotiation is to be used to select one of a set of source-defined content types or formats for retrieving or sending information to the source. For WType and WFormat, this is the default.

3. Binding types

There are two default types of binding: pre-binding and late binding.

For the recipent of a PA-URL, the binding type is not so relevant -- it is either bound or not. We describe some binding-related properties here only because it is relevant to the inner working of the system and the policies associated with PA-URLs.

One example is that a PA-URL policy may describe the type (or role, e.g., medical specialization) of a healthcare professional that may bind to the PA-URL.

Note that normally, PA-URLs may only be bound to a person, or more precise: to an authenticated identy or key of a healthcare professional.

There is one type of binding that is different from above: in a limited set of cases, a PA-URL may be SYSTEM-BOUND, so bound to the key of a system. This special type of binding allows for components of organizations to use a URL not to access data directly, but instead to allow this component request copies of the PA-URL from the source that may be bound to and used by people (healtcare professionals) within the organization that this component is part of. Such a URL is called a copy-only URL.

4. Security and Binding Properties

<PIN=[y|n|binding-PIN>: This field specifies whether a PIN is required to bind to a URL.
- "y" requires the PIN for every access.
- "n" indicates no PIN is required.
- "binding-PIN" specifies that the PIN is required only during initial access to establish a permanent binding to the client. This is the most common use of a PIN. An authhorization code is also effectively a binding PIN.
bind-expiry: This field specifies the deadline by which a late-bound reference must be claimed. If the binding does not occur within this timeframe, the reference is invalidated to prevent misuse after the deadline for binding.
expiry=: expiry is the outer date or "time-to-live", formatted in 'UTC:yyyymmdd:hh:mm' format, within which the PA-URL can be used. Once assigned, an expiry cannot be changed. Renewal is sometimes possible; this invalidates the original PA-URL and issues a new PA-URL with identical properties (including binding) as the original. Renewal must be done before the original PA-URL is expired.
**allow-renew=y|n" indicates whether renewal is allowed. If 'y', renewal may still be refused; a policy specifies who may renew when and for how long.

5. Other policy and permission Fields

allow_copy=[y|n]: This field sets the policy for delegation. Note: this property is superfluous as permissions can also contain "C". When set to "y", the current authorized holder is permitted to request that the source system generate a new, unique copy of the reference for another party.

Note: copying requires a POST call with a datastructure that contains additional parameters governing the copying proces, e.g., whether prebinding is needed (if so, to what key or identity) or whether a binding-PIN must be returned, possibly an authorization code. TBD.

Security Implications of the Schema

The fields within the URL schema correspond to the security properties associated with the URL, including binding parameters, doctypes, etc. These are the parameters that collectively define the security properties that guard access to the source record referred to by the push authorization URL.

Mandatory Binding: Through the <bind> and <PIN> fields, the system enforces cryptographic binding. This ensures that authorization is not merely possessed (as with a password) but is tied to the identity and private key of the authorized recipient.
Traceable Delegation: The <allow_copy> and <token> fields enable the source system to track the chain of authorization. Each "copy" is a unique URL generated by the source, allowing the record owner to audit exactly how a reference was passed from one provider to another.
Self-Contained Policy: The inclusion of expiry, permissions, and datatype within the URL makes the authorization self-describing. Client systems parse these fields to determine their permitted actions before even contacting the source system.
Defense in Depth: By adding PA-URLs that act as tokens to the role-based access control mechanism based on health professional PKI-based identification commonly used in healthcare, push authorization reduces the attack surface for patient information and ensures that even if one layer is compromised, other protective mechanisms remain in place.

Push authorization (PA) URL schema and semantics.​

Push authorization (PA) URL schema and semantics.