Notice Record Schema

Towards semantic interoperability of privacy control vocabularies.

OPN Notice Record for Receipts

OPN-Receipt v0.59

Description

This is the OPN receipt schema wiki, the OPN Network provides notice receipts for privacy, safety, surveillance and security. The notice record to receipt specification is intended to be an all purpose digital transparency record, usable for low to high assurance notice receipts.

The receipt specification is provided here with a semantic format to enable future forward applications, and is designed to be extended by the Kantara Consent Receipt Specification, and industry receipt specification for privacy best practices in Identity Management, as well as the W3C Data Privacy and Control vocabulary(DPV) for GDPR compliance, the COEL (Classification of Everyday Living) specification for an attribute level consent storage solution, and finally an example of the Consent Receipt is included in the upcoming ISO 29184 specification due in 2020.

The standardised notice records can be used for many types of applications and is explained here to specify the OPN Network notary services

Notice Record Schema

Effective digital transparency largely depends on the provision of a notice, to communicate contextual information. This historically has been a static document such as a privacy policy rather than a contextually useful notice or sign personalised for people by context.

Open Notice (OPN) as a network based solution is designed to address critical challenges that can be addressed using computational semantics to signal contextual changes to privacy, security, and smart city policy. Demonstrating contextual integrity.

OPN uses a semantic schema based on, and connecting to, international standards. This enables organisations to broadcast signals based on standards and generate notice receipts using these standards for service users so people can autonomously track changes in the state of notice or a privacy policy.

The objective of the OPN Network is to lessen the burden of understanding privacy for users saving time and resources with a notice receipt. OPN is scheduled to have an initial public release in June 2019.

USAGE

The notice receipt can be used for any type of policy, notice, or even a physical sign. It can be used for health and safety for a product recall or notice, a security example would for notice of data breach notices, and for privacy a receipt is used to dramatically improve digital transparency.

The receipt itself is technically a contextual notice that is specific to a context as defined in the notice and notice policy. A notice policy can be a legal policy as defined directly in legislation that requires notification. A notice receipt can therefore demonstrate notice compliance and act as a notice and if written in JSON-LD extended as a semantic notice that links to meta data that can be aggregated, profiled and used for other purposes.

INTEROPERABILTY

This specification uses terminology and definitions from open standards and Fair Information Practice (FIP) best practices, to maintain consistency with common terms used in regulations. The definitions where possible are based on ISO 29100 terms and definitions so as to be broadly applicable to all notice requirements for privacy and security. As a result, it is also consistent with the Kantara Consent Receipt v1.1, COEL V.1 (Classification for Everyday Living), W3C Data Privacy Control Vocabulary.

FIELD DESCRIPTIONS & SCHEMA

The following sub-sections define the fields for a Notice Receipt including the corresponding JSON and JSON-LD field names and types. This specification uses “named object” data types to describe the principal concepts within the Notice Receipt and allows for extension by implementers.

For conformance, a Notice Receipt MUST include the fields defined as REQUIRED below. When using JSON, the Receipt MUST also be valid per the JSON-schema provided. When using JSON-LD, the Receipt MUST also be valid per the schema ontology provided. Note that when using external IRIs in JSON-LD, a human-readable description should be provided wherever appropriate. Additional fields MAY be added as long as they don’t conflict with the conformance requirements.

Field NameField LabelFormatDescription Required/Optional
Schema VersionversionstringThe version of specification used to which the receipt conforms. To refer to this version of the specification, the string “v1” or the IRI “https://w3id.org/OPN/v1” should be used.Required
OPN Privacy Profile URIprofilestringLink to the controller’s profile in the OPN registry. Required
Type of Notice ReceiptNotice Receiptstring Label Notice Receipt Required
Receipt IDidstringA unique number for each Notice Receipt. SHOULD use UUID-4 [RFC 4122].Required
TimestamptimestampintegerDate and time of when the notice was generated and provided. The JSON value MUST be expressed as the number of seconds since 1970-01-01 00:00:00 GMT (Unix epoch).Required
Signing KeykeystringThe Controller’s profile public key. Used to sign notice icons, receipts and policies for higher assurance.Optional
LanguagelanguagestringLanguage in which the consent was obtained. MUST use ISO 639-1:2002 [ISO 639] if this field is used. Default is ‘EN’.Optional
Controller IdentitycontrollerIDstringThe identity (legal name) of the controller.Required
Legal JurisdictionjurisdictionstringThe jurisdiction(s) applicable to this noticeRequired
Controller ContactcontrollerContactstringContact name of the Controller. Contact could be a telephone number or an email address or a twitter handle.Required
Link to NoticenoticestringLink to the notice the receipt is for Optional
Link to PolicypolicystringLink to the policies relevant to this notice e.g. privacy policy active at the time notice was providedRequired
ContextcontextstringMethod of notice  presentation, sign, website pop-up etcOptional
Justification for NoticejustificationstringAuthority of notice providerOptional





Proposed Fields (new field first requeires testing)

Field Name LabelField NameFormatDescriptionRequired
Notice Disclosure disclosestringfield for disclosures for the notice, its context, information about it’s provenance, or  obligations and statements of risk for notice use from the the notice providerOptional

Version

REQUIRED: The version of specification used to which the receipt conforms. To refer to this version of the specification, the string “v1” or the IRI “https://w3id.org/OPN/v1” should be used.

Notice Timestamp

REQUIRED: Date and time of when the notice was generated and provided. The JSON value MUST be expressed as the number of seconds since 1970-01-01 00:00:00 GMT (Unix epoch). ISO 8601 Date and Time Format [ISO 8601] MUST be used for formatting.

Jurisdiction

REQUIRED: The jurisdiction(s) applicable to this interaction. This field MUST contain a non-empty string describing the jurisdiction(s).

Receipt ID

REQUIRED: A unique number for each Notice Receipt. SHOULD use UUID-4 [RFC 4122]. This field MUST contain a non-empty string.

Language

OPTIONAL: Language in which the consent was obtained. MUST use ISO 639-1:2002 [ISO 639] if this field is used. Default is ‘EN’.

Notice Context

REQUIRED: A description of the technical context by which a notice was provided, such as a physical sign, digital pop-up etc. The context includes the method of providing the notice. This field MUST contain a non-empty string.

Notice

REQUIRED:  A link to the notification the receipt is created from. If the notice is a policy (like the privacy policy) the link of this field can be a link directly to the policy.

Justification

OPTIONAL: Primary authority for the notice in the context it is authoritative. 

Secondary Justification

OPTIONAL: Justification for notice if different from policy or primary expected context. For example, a notice or local environment might operate independently for data processing, and reside a sub policy in a governing policy or code of practice.  

Controller 

REQUIRED: The entity or entities responsible for creating and/or providing the notice. Each entity is an object containing fields describing attributes such as identity, contact, policy of the controller.

Controller Identity 

REQUIRED: The identity (legal name) of the controller. This field is required for every controller defined in the notice receipt.

Controller Contact

REQUIRED: Contact name of the Controller. Contact could be a telephone number or an email address or a twitter handle. This field is required for every controller defined in the notice receipt.

Profile URL

REQUIRED: Link to the controller’s profile in the OPN registry. This field is required for every controller defined in the notice receipt.

Service URL

OPTIONAL: A URL for identifying Controller and contact. This field is optionally defined for every controller defined in the notice receipt.

Governing Policy

Optional: Link to the privacy policy relevant to the notice associated with the receipt. This field is required for every controller defined in the notice receipt.

Notice Disclosures

This is listing disclosures specific to notice and its context of use, to provide risk disclosures for the notice, its context, and it’s provenance.  

Validation Key

OPTIONAL: The Controller’s profile public key. Used to sign notice icons, receipts and policies for higher assurance. This field is optional for every controller defined in the notice receipt.

Schema Examples

JSON-LD

{“@context”: {“opn”: “https://w3id.org/OPN#“,”schema”: “http://schema.org/“,”xsd”: “http://www.w3.org/2001/XMLSchema#“,”opn:profile”: { “@type”: “@id”},”opn:time”: { “@type”: “xsd:dateTime”},”opn:key”: { “@type”: “xsd:hexBinary”},”opn:controllerID”: { “@type”: “@id”},”opn:notice”: { “@type”: “@id”},”opn:policy”: { “@type”: “@id”},”opn:primaryJustificationReceipt”: { “@type”: “@id”}    },”@id”: “http://example.com/receipts/2“,”@type”: “opn:NoticeReceipt”,”opn:profile”: “http://example.com/profiles/X“,”opn:id”: “cc7b97a9-8999-412c-9f41-3cdc84a35f73″,”opn:time”: “2019-05-10T00:00:00″,”opn:key”: “6C46B7C2D42A76AB134F2D4EA4D4977B2F7FAB03B0707A768E99803B39EB227E”,”opn:language”: “EN”,”opn:controller”: {“@type”: “opn:Controller”,”opn:controllerID”: “http://example.com/org/X“,”opn:controllerContact”: { “@type”: “schema:ContactPoint”,”schema:telephone”: “(111) 1234 5678″        }    },”opn:notice”: “http://example.com/notices/A“,”opn:policy”: “http://example.com/org/X/privacy-policy-201905“,”opn:context”: { “schema:url”: “http://example.com/org/X/website“},”justification”: “consent”,”primaryJustification”: “legitimate-interest”,”primaryJustificationReceipt”: “http://example.com/receipts/1“}

Turtle

@base<https://w3id.org/OPN> .@prefix: <https://w3id.org/OPN#> .@prefixrdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefixrdfs: <http://www.w3.org/2000/01/rdf-schema#> .@prefixxsd: <http://www.w3.org/2001/XMLSchema#> .
:NoticeReceiptardfs:Class;rdfs:label”Notice Receipt”;rdfs:comment”The class of all notice receipts”.
:profileardfs:Property;rdfs:label”profile”;rdfs:description: “OPN privacy profile of the Controller”;rdfs:domain:Controller;rdfs:rangexsd:anyURI.
:idardfs:Property;rdfs:label”id”;rdfs:description: “Identifier for the notice receipt”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:timeardfs:Property;rdfs:label”time”;rdfs:description: “timestamp of the generation or provision of receipt”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:keyardfs:Property;rdfs:label”key”;rdfs:description: “verification key”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:languageardfs:Property;rdfs:label”language”;rdfs:description: “lang”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:Controllerardfs:Class;rdfs:label”Controller”;rdfs:description”A Controller (GDPR definition) or Provider”.
:controllerIDardfs:Property;rdfs:label”controller ID”;rdfs:description: “Identity of the Controller”;rdfs:domain:Controller;rdfs:rangerdfs:Resource.
:controllerContactardfs:Property;rdfs:label”controller contact”;rdfs:description: “Contact of the Controller”;rdfs:domain:Controller;rdfs:rangerdfs:Resource.
:controllerardfs:Property;rdfs:label”controller”;rdfs:description”Controller associated with notice”;rdfs:domain:NoticeReceipt;rdfs:range:Controller.
:noticeardfs:Property;rdfs:label”notice”;rdfs:description: “Link to the notice this receipt is about”;rdfs:domain:NoticeReceipt;rdfs:rangexsd:anyURI.
:policyardfs:Property;rdfs:label”policy”;rdfs:description: “Link to the policy associated with the notice”;rdfs:domain:NoticeReceipt;rdfs:rangexsd:anyURI.
:contextardfs:Property;rdfs:label”context”;rdfs:description: “Context of the notice e.g. website it was given at”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:justificationardfs:Property;rdfs:label”justification”;rdfs:description: “Justification of the notice e.g. legal basis or requirements”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:primaryJustificationardfs:Property;rdfs:label”primary justification”;rdfs:description: “Primary or main justification of the notice”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.
:primaryJustificationReceiptardfs:Property;rdfs:label”primary justification receipt”;rdfs:description: “Notice Receipt of agreement for primary justification”;rdfs:domain:NoticeReceipt;rdfs:rangerdfs:Resource.

OC-OpenSource

If you are interested, have some tech, want to run a project, get involved. Send and email to info@openconsent.org – or get involved directly with an on-going project, or working group.


All privacy systems and legislations require the provision of this information for the data processing of people. The greater the scope and the more invisible, the greater the privacy risk. This classification system is for how to understand in a practical manner what privacy is for any specific context.

OC: OpenSource is for Privacy Laws that enable open use.
Contextual Privacy Classification

  • No-Consent (no-transparency)
  • No-Consent (but notice)
  • Implied Consent (notice and choice)
  • Explicit Consent
  • Self-Soverign Consent – (user driven and controlled)

OpenConsent (Open Public Privacy)

Open Public Privacy: Active projects, repositories, open resources and community forums. [100% open]
(Home of the OpenConsent: Public Privacy Classification System for People)

Open Standards We Actively Support

Kantara Initiative CISWG, ISO 29184, OASIS, W3C :

Resources

Active Projects

OPN.OpenConsent.Com (openconsent.org is administered by OC and sponsored by [get in touch] )