GL1: A Verifiable Digital Licensing Protocol for Gambling Regulation

A. Abstract

This paper introduces GL1 (Gambling Licence version 1), an open protocol for machine-readable, cryptographically verifiable digital gambling licences. GL1 enables gambling regulators to issue digitally signed licence credentials that can be independently verified by any party — consumers, Internet Service Providers, payment processors, search engines, app stores, and other gambling regulators — without requiring trust in the operator or real-time access to the issuing authority.

GL1 defines three complementary verification mechanisms built entirely on existing open standards:

• A .well-known URI (RFC 8615) hosting a signed JSON licence document
• A DNS TXT record carrying a compact signed licence assertion
• A RESTful verification API

Together, these mechanisms provide defence-in-depth verification that is resistant to forgery, instantly revocable, and designed for adoption by any gambling regulatory authority worldwide.

The protocol addresses a fundamental gap in global gambling regulation: the absence of a standardised, machine-readable mechanism for distinguishing licensed from unlicensed operators. This gap undermines enforcement, enables illegal operators to reach consumers unchallenged, and makes it difficult for payment processors and ISPs to comply with their obligations.

GL1 is published as an open specification. GRAI intends to submit it for standardisation through the IETF and to register the gambling-licence well-known URI suffix with IANA.

1. The Problem

1.1 The Scale of Illegal Online Gambling

Online gambling is a global industry generating over €90 billion annually in gross gaming revenue. Alongside the regulated market, a substantial illegal market operates across jurisdictions, targeting consumers without the oversight, consumer protections, or tax contributions required by law.

Illegal gambling operators:

• Harm consumers — no responsible gambling protections, no self-exclusion, no complaint resolution, no fund segregation
• Evade taxation — depriving jurisdictions of gambling levy revenue
• Enable crime — money laundering, fraud, match fixing, and organised crime
• Undermine regulation — licensed operators face unfair competition from unregulated counterparts

1.2 The Verification Gap

Despite decades of gambling regulation, there is no standardised, machine-readable protocol for verifying whether an online gambling operator holds a valid licence from a recognised regulatory authority.

Today, licence verification requires:

1. A human visiting the regulator's website
2. Manually searching a registry (if one exists)
3. Interpreting the result (licence types, conditions, jurisdictional scope)
4. Repeating this process for every regulator that may have issued a licence

This process is:

• Not scalable — cannot be performed for thousands of gambling domains
• Not automatable — requires human interpretation of unstructured web pages
• Not standardised — every regulator presents information differently
• Not cryptographic — licence badges on operator websites can be trivially faked
• Not real-time — registries may not reflect recent suspensions or revocations

1.3 Who Needs Automated Verification?

1.4 The Opportunity

The technical building blocks for solving this problem already exist. Email authentication solved an analogous problem — proving sender legitimacy — using DNS records (SPF, DKIM, DMARC). Certificate transparency solved the problem of verifiable issuance for TLS certificates. Web PKI provides a global trust framework for cryptographic identity.

GL1 applies these proven patterns to gambling licence verification, creating a protocol that is:

• Machine-readable — automated verification at scale
• Cryptographically verifiable — cannot be forged
• Decentralised — any authority can issue; any party can verify
• Instantly revocable — suspension and revocation reflected in real-time
• Built on open standards — no proprietary dependencies

2. Current State of Licence Verification

2.1 Regulator Registries

Most gambling regulators maintain some form of public registry:

2.2 Operator Self-Assertion

Licensed operators typically display licence badges or seals on their websites. These are:

• Self-asserted — the operator places the badge; no cryptographic proof
• Trivially forgeable — an unlicensed operator can copy and display any badge
• Static — badges do not reflect real-time licence status
• Non-standard — every regulator's badge looks different; no consistent verification UX

2.3 Analogous Solved Problems

GL1 draws directly from these proven approaches.

3. Design Principles

GL1 is designed around seven core principles:

3.1 Open Standards Only

GL1 uses exclusively open, royalty-free standards. No proprietary protocols, formats, or algorithms. Every component is defined by an existing RFC or open specification. GL1 itself is published as an open specification and will be submitted for IETF standardisation.

3.2 Authority-Issued, Operator-Hosted

Licence credentials are generated and signed by the regulatory authority, not the operator. The operator hosts the signed credential but cannot modify it. This ensures that the authority retains control over licence assertions while distributing verification load.

3.3 Offline-First Verification

The primary verification mechanisms (.well-known file and DNS record) do not require real-time connectivity to the issuing authority. A verifier can validate the cryptographic signature against the authority's published public key without contacting the authority's servers. The verification API provides optional real-time confirmation.

3.4 Defence in Depth

Three independent mechanisms provide layered verification:

• HTTP layer: .well-known URI with signed JSON
• DNS layer: TXT record with signed assertion
• API layer: Real-time verification endpoint

Each mechanism can function independently. Together, they provide redundancy and resistance to evasion.

3.5 Instant Revocability

When a licence is suspended or revoked, the change must propagate to all verification channels within a bounded time:

• Verification API: Immediate
• .well-known file: Within 4 hours (operator update) or via API fallback
• DNS record: Within 1 hour (TTL-bounded)

3.6 Multi-Authority by Design

GL1 is not a single-authority protocol. Any gambling regulatory authority can operate as a GL1 issuer using its own signing keys and verification infrastructure. The protocol includes a discovery mechanism that allows verifiers to resolve the issuing authority for any licence credential and obtain the correct public key for verification.

3.7 Minimal Operator Burden

Operators are required to:

1. Host a static file at a well-known URI (trivial for any web server)
2. Publish a DNS TXT record (trivial for any DNS configuration)
3. Update both when the authority issues new credentials (automatable)

No specialised software, hardware, or expertise is required.

4. Protocol Overview

4.1 Participants

4.2 Credential Lifecycle

1. LICENCE ISSUED
   Authority issues gambling licence to operator
                    |
                    v
2. CREDENTIAL GENERATED
   Authority generates signed GL1 credential
   (JSON document + DNS record content)
                    |
                    v
3. CREDENTIAL DISTRIBUTED
   Authority transmits credential to operator
   via secure channel (API, portal, email)
                    |
                    v
4. CREDENTIAL HOSTED
   Operator publishes:
   - JSON file at /.well-known/gambling-licence
   - DNS TXT record at _gambling-licence.{domain}
                    |
                    v
5. CREDENTIAL VERIFIED
   Verifier checks one or more mechanisms:
   - Fetch .well-known file --> verify signature
   - Resolve DNS TXT record --> verify signature
   - Call verification API --> get authoritative status
                    |
                    v
6. CREDENTIAL UPDATED (on change)
   Authority issues updated credential when:
   - Licence renewed
   - Conditions changed
   - Licence suspended or revoked
   Operator updates hosted credential within SLA

4.3 Trust Model

                 +------------------+
                 |   GL1 Trust      |
                 |   Directory      |
                 | (gl1.gamblinglicence.org)  |
                 +--------+---------+
                          |  Lists known authorities
                          |  and their public keys
                 +--------+--------+
                 |        |        |
           +-----+--+ +--+---+ +--+------+
           |  GRAI  | | UKGC | |  MGA    |   ... other authorities
           |(issuer)| |(issuer)| |(issuer)|
           +---+----+ +--+---+ +---+-----+
               |         |         |
               |  Signs credentials for their licensees
               |         |         |
          +----+---+ +---+--+ +---+--+
          |Operator| |Op. B | |Op. C |
          |   A    | |      | |      |
          +----+---+ +------+ +------+
               |
               |  Hosts credential at .well-known + DNS
               |
          +----+---+
          |Verifier|  (ISP, payment processor, consumer, etc.)
          +--------+
               Fetches credential --> resolves authority -->
               obtains authority public key --> verifies signature

5. Mechanism 1: Well-Known URI

5.1 Endpoint

Licensed operators MUST serve a GL1 licence credential at:

https://{operator-domain}/.well-known/gambling-licence

This follows the Well-Known URIs framework defined in RFC 8615.

5.2 Document Format

The document is a JSON object with three top-level members:

5.3 Licence Object

JSON
{
  "gl1": "1.0",
  "licence": {
    "id": "GRL-2026-001234",
    "type": "remote_gambling",
    "activities": ["sports_betting", "casino", "poker"],
    "operator": {
      "name": "Example Gambling Ltd",
      "trading_as": "ExampleBet",
      "registration": "IE-123456",
      "country": "IE"
    },
    "authority": {
      "id": "GRAI",
      "name": "Gambling Regulatory Authority of Ireland",
      "country": "IE",
      "uri": "https://www.grai.ie",
      "verify": "https://verify.grai.ie/api/v1"
    },
    "scope": {
      "territories": ["IE"],
      "domains": ["examplebet.ie", "examplebet.com"],
      "apps": [
        {"platform": "ios", "id": "com.examplebet.app"},
        {"platform": "android", "id": "com.examplebet.app"}
      ]
    },
    "validity": {
      "issued": "2026-04-01",
      "expires": "2027-03-31"
    },
    "status": "active",
    "conditions": [],
    "updated": "2026-04-01T00:00:00Z"
  },
  "signature": {
    "alg": "ES384",
    "kid": "grai-licence-signing-2026-01",
    "x5u": "https://pki.grai.ie/certs/licence-signing-2026.pem",
    "value": "<base64url-encoded signature>"
  }
}

5.4 Field Definitions

licence.id — The unique licence identifier assigned by the authority. Format is authority-defined. MUST be globally unique when combined with authority.id.

licence.type — The licence type. Recommended values: remote_gambling, retail_gambling, betting, casino, lottery, bingo, poker, gaming_machine, software_supplier, testing_laboratory. Authorities MAY define additional types.

licence.activities — Array of permitted gambling activities. Allows granular verification of whether a specific activity is licensed.

licence.authority.id — Short identifier for the issuing authority. MUST match the authority's entry in the GL1 Trust Directory (see Section 10).

licence.authority.verify — Base URI for the authority's GL1 verification API. Enables verifiers to perform real-time checks.

licence.scope.territories — ISO 3166-1 alpha-2 country codes where the licence is valid.

licence.scope.domains — All domains authorised to operate under this licence. The .well-known file MUST be served from each listed domain.

licence.status — Current licence status. MUST be one of: active, suspended, revoked, expired, surrendered.

5.5 Serving Requirements

6. Mechanism 2: DNS TXT Record

6.1 Record Location

Operators MUST publish a DNS TXT record at:

_gambling-licence.{operator-domain}.  IN  TXT  "<GL1 record>"

6.2 Record Format

The GL1 DNS record follows a tag-value format inspired by SPF (RFC 7208) and DMARC (RFC 7489):

v=GL1; a=GRAI; id=GRL-2026-001234; t=remote_gambling; s=active; e=2027-03-31; u=https://verify.grai.ie/api/v1/licence/GRL-2026-001234; sig=<base64url>

6.3 Field Definitions

6.4 Signature Input

The signature is computed over the concatenation of the non-signature fields in the order they appear in the record, separated by semicolons:

v=GL1;a=GRAI;id=GRL-2026-001234;t=remote_gambling;s=active;e=2027-03-31;u=https://verify.grai.ie/api/v1/licence/GRL-2026-001234

6.5 DNS Configuration Requirements

6.6 Advantages of DNS-Layer Verification

• Pre-connection verification — ISPs can check licence status before establishing any connection to the operator's servers
• Bulk scanning — DNS records can be queried at scale for thousands of domains efficiently
• Infrastructure integration — ISPs already operate DNS resolvers; GL1 records integrate with existing DNS infrastructure
• Response Policy Zone (RPZ) integration — Unlicensed domains (those without valid GL1 records) can be automatically added to RPZ blocking lists

7. Mechanism 3: Verification API

7.1 Purpose

The verification API is the authoritative, real-time source of licence status. While the .well-known file and DNS record provide offline-verifiable credentials, the API provides:

• Guaranteed current status (no caching delay)
• Richer information (enforcement history, conditions)
• Bulk verification for high-volume verifiers
• Blacklist/blocklist feeds

7.2 Endpoints

Each issuing authority operates its own API at the base URI specified in authority.verify.

Licence verification:

GET  {authority.verify}/licence/{licence-id}

Domain lookup:

GET  {authority.verify}/domain/{domain-name}

Bulk verification:

POST {authority.verify}/verify/bulk
Content-Type: application/json

{"domains": ["domain1.com", "domain2.com", ...]}

Blacklist:

GET  {authority.verify}/blacklist
GET  {authority.verify}/blacklist?since={ISO-date}

Authority metadata (discovery):

GET  {authority.verify}/.well-known/gl1-authority

Returns the authority's public keys, supported algorithms, contact information, and federation membership.

7.3 Response Format

JSON
{
  "gl1": "1.0",
  "licence": {
    "id": "GRL-2026-001234",
    "status": "active",
    "type": "remote_gambling",
    "operator": {
      "name": "Example Gambling Ltd",
      "trading_as": "ExampleBet"
    },
    "validity": {
      "issued": "2026-04-01",
      "expires": "2027-03-31"
    },
    "domains": ["examplebet.ie", "examplebet.com"],
    "enforcement_actions": [],
    "last_updated": "2026-04-01T00:00:00Z"
  },
  "authority": {
    "id": "GRAI",
    "name": "Gambling Regulatory Authority of Ireland"
  }
}

7.4 Authentication Tiers

7.5 Data Feeds

For high-volume consumers, authorities SHOULD provide bulk data feeds:

8. Cryptographic Framework

8.1 Signature Algorithm

GL1 uses ECDSA with the P-384 curve (ES384), as defined in:

• FIPS 186-4 (Digital Signature Standard)
• RFC 6979 (Deterministic ECDSA)
• RFC 7518 (JSON Web Algorithms — ES384 identifier)

8.2 Signature Computation — Well-Known Document

1. Extract the licence object from the GL1 document
2. Canonicalise the JSON using JCS (RFC 8785 — JSON Canonicalization Scheme)
3. Compute the SHA-384 hash of the canonical bytes
4. Sign the hash using the authority's private key (ECDSA P-384)
5. Encode the signature as base64url (RFC 4648 Section 5)
6. Place in signature.value

8.3 Signature Computation — DNS Record

1. Concatenate the non-signature fields in record order, semicolon-separated
2. UTF-8 encode the concatenated string
3. Compute SHA-384 hash
4. Sign with ECDSA P-384
5. Encode as base64url
6. Place in sig field

8.4 Key Management

8.5 Verification Procedure

1. Obtain GL1 credential (from .well-known, DNS, or API)
2. Extract authority identifier (authority.id or 'a' tag)
3. Resolve authority's public keys:
   a. Check local cache
   b. Fetch from GL1 Trust Directory (gl1.gamblinglicence.org)
   c. Or fetch from authority's .well-known/gl1-authority
4. Select the correct key using 'kid' identifier
5. Reconstruct the signed content:
   - For .well-known: JCS-canonicalised licence object
   - For DNS: concatenated non-sig fields
6. Verify ECDSA-P384 signature
7. Check licence status is "active"
8. Check expiry date is in the future
9. Optionally: call verification API for real-time confirmation

8.6 Post-Quantum Cryptographic Agility

GL1's initial algorithm (ECDSA P-384) is vulnerable to quantum computing attacks. Shor's algorithm, executed on a sufficiently capable quantum computer, breaks all elliptic curve cryptography. GL1 is designed as a long-lived international standard and must prepare for the post-quantum era.

NIST Post-Quantum Signature Standards (Finalized August 2024)

Impact on GL1 Mechanisms

Algorithm Agility (Built Into GL1 v1.0)

GL1 is designed with algorithm agility from day one:

• signature.alg — identifies the algorithm. Verifiers MUST read this field, MUST NOT assume ES384.
• kid — allows multiple active keys with different algorithms during transition.
• Discovery endpoint — /.well-known/gl1-authority publishes all current keys with their algorithms.
• No hardcoding — all GL1 software must support algorithm negotiation.

Hybrid Signatures (Transition Period)

During transition, GL1 supports dual signatures — classical + post-quantum simultaneously:

Verification rule: valid if either signature verifies (backwards compatibility), but fully verified only if both verify. If either algorithm is broken, the other provides protection.

DNS Mechanism — Post-Quantum Adaptation

When PQC signatures exceed DNS TXT limits, the record adapts with new fields:

This preserves DNS utility for quick status checks and bulk scanning while delegating full PQC verification to the API layer.

Migration Timeline

9. Revocation Model

9.1 Revocation Channels

When a licence is suspended or revoked, the change propagates through all three mechanisms:

9.2 Failsafe Behaviour

If the .well-known file or DNS record shows "status": "active" but the credential is stale (close to or past the updated timestamp + SLA), verifiers SHOULD fall back to the verification API for confirmation.

If the API is unreachable, verifiers SHOULD treat credentials with valid signatures and unexpired dates as provisionally valid, but flag for re-verification.

9.3 Operator Non-Compliance

If an operator fails to update their hosted credential after a suspension or revocation:

1. The verification API returns the true status (suspended/revoked)
2. The authority publishes the operator on its blacklist feed
3. The authority notifies ISPs and payment processors via data feeds
4. The stale .well-known file will eventually expire (based on validity.expires)
5. The authority may take further enforcement action for non-compliance with hosting requirements

9.4 Short-Lived Credentials (Optional)

Authorities MAY issue short-lived credentials (e.g., 24-hour validity) that require frequent renewal. This reduces the revocation window but increases operational burden. Recommended for high-risk operators or during enforcement proceedings.

10. Multi-Authority Federation

10.1 GL1 Trust Directory

A critical component of GL1 is the Trust Directory — a registry of recognised gambling regulatory authorities and their public keys. This enables verifiers to resolve the authority for any credential and obtain the correct verification key.

Location: https://gl1.gamblinglicence.org (proposed)

Governance: Operated by an independent body or consortium of founding authorities.

Content:

JSON
{
  "gl1": "1.0",
  "directory_version": "2026-04-01",
  "authorities": [
    {
      "id": "GRAI",
      "name": "Gambling Regulatory Authority of Ireland",
      "country": "IE",
      "uri": "https://www.grai.ie",
      "verify": "https://verify.grai.ie/api/v1",
      "keys_uri": "https://verify.grai.ie/.well-known/gl1-authority",
      "status": "active",
      "joined": "2026-04-01"
    },
    {
      "id": "UKGC",
      "name": "UK Gambling Commission",
      "country": "GB",
      "verify": "https://verify.gamblingcommission.gov.uk/api/v1",
      "keys_uri": "https://verify.gamblingcommission.gov.uk/.well-known/gl1-authority",
      "status": "active",
      "joined": "2026-09-01"
    }
  ]
}

10.2 Authority Onboarding

To join the GL1 federation, an authority must:

1. Be a recognised governmental gambling regulatory body
2. Generate signing keys in an HSM
3. Publish public keys at /.well-known/gl1-authority
4. Operate a verification API conforming to GL1 specification
5. Submit application to Trust Directory governance body
6. Undergo peer review by existing federation members
7. Be added to the Trust Directory

10.3 Cross-Border Verification

When a verifier encounters a credential from an unfamiliar authority:

1. Extract authority.id from the credential
2. Look up the authority in the GL1 Trust Directory
3. Fetch the authority's public keys
4. Verify the credential signature
5. The verifier now has cryptographic proof that the authority issued this licence

This enables a payment processor in Ireland to verify a Malta Gaming Authority licence, or a UK ISP to verify a GRAI licence — without any prior relationship with the issuing authority.

10.4 Mutual Recognition

11. Deployment Model

11.1 Phase 1: Single Authority (National)

A single authority (e.g., GRAI) deploys GL1 for its licensees:

• Authority generates and signs credentials
• Licensed operators host credentials
• Authority operates verification API
• ISPs and payment processors in the jurisdiction integrate with the API

11.2 Phase 2: Regional Federation (European)

Multiple European authorities adopt GL1:

• Each authority operates independently with its own keys
• GL1 Trust Directory established with founding members
• Cross-border verification enabled
• GREF coordinates harmonisation of licence types and activities

11.3 Phase 3: Global Federation

IAGR coordinates global adoption:

• Trust Directory expanded to global authorities
• Standardised licence type taxonomy agreed
• IETF standardisation completed
• Major payment processors and ISPs implement GL1 verification globally

12. Security Analysis

12.1 Threat Model

12.2 Security Properties

13. Privacy Considerations

13.1 Data Minimisation

GL1 credentials contain only information that is already publicly associated with a gambling licence:

• Operator name and registration number (public company record)
• Licence number and type (published on regulator's registry)
• Authorised domains (publicly known)
• Licence validity dates (published)

No personal data about consumers, employees, or beneficial owners is included in GL1 credentials.

13.2 Verification Privacy

The .well-known and DNS mechanisms provide verifier-private verification: the verifier fetches the credential from the operator's infrastructure or public DNS, not from the authority. The authority does not learn who is verifying which licence.

The verification API does reveal verification activity to the authority. Authorities SHOULD:

• Not log individual consumer verification requests
• Aggregate API usage statistics without identifying individual verifiers
• Provide privacy-preserving bulk data feeds as an alternative to per-query API calls

13.3 GDPR Compliance

GL1 credentials contain no personal data as defined by GDPR Article 4(1). The operator and company information in credentials is corporate data already in the public domain. No GDPR data subject rights apply to GL1 credential contents.

14. Economic Analysis

14.1 Cost to Implement

14.2 Value Delivered

15. Comparison with Existing Approaches

15.1 Why Not Blockchain?

Blockchain-based approaches have been proposed for various credential verification use cases. GL1 does not use blockchain because:

• Unnecessary complexity — GL1's trust model (authority signs, verifier checks) does not require distributed consensus
• Performance — DNS and HTTPS are orders of magnitude faster than blockchain queries
• Integration — DNS and HTTPS are universal infrastructure; blockchain requires specialised clients
• Governance — Gambling licence issuance is inherently centralised (authority-issued); blockchain decentralisation adds no value
• Existing infrastructure — GL1 works with infrastructure every operator and ISP already has

16. Standardisation Pathway

16.1 Immediate Actions

1. Publish this white paper for public comment
2. Publish the GL1 specification as an open document under Creative Commons Attribution 4.0 (CC BY 4.0)
3. Implement reference deployment (GRAI as first issuer)
4. Gather operational experience over 12 months

16.2 IETF Internet-Draft

1. Submit Internet-Draft: "The GL1 Gambling Licence Verification Protocol"
2. Register gambling-licence as a well-known URI suffix with IANA (per RFC 8615 Section 3.1)
3. Progress through IETF review (likely Applications and Real-Time Area — ART)
4. Target: Proposed Standard RFC

16.3 European Harmonisation

1. Present to GREF for European regulatory forum discussion
2. Propose as CEN/CENELEC technical specification for EU gambling regulation
3. Integrate with EU Digital Identity framework (eIDAS 2.0) where applicable

16.4 International Adoption

1. Present to IAGR annual conference
2. Establish GL1 Trust Directory governance with founding authorities
3. Coordinate with IMGL on legal framework implications

17. Call to Action

GL1 is a practical, implementable solution to a real and growing problem. We invite:

Gambling regulators worldwide

• Review the GL1 specification and provide feedback
• Consider pilot implementation for your jurisdiction
• Join the discussion on standardisation through IAGR and GREF

Licensed gambling operators

• Review the operator hosting requirements and assess implementation effort
• Participate in pilot programmes
• Provide feedback on operational feasibility

ISPs and payment processors

• Review the verification API specification
• Assess integration with existing compliance infrastructure
• Participate in pilot programmes

Standards bodies (IETF, CEN/CENELEC)

• Consider GL1 for standardisation
• Provide guidance on well-known URI registration
• Review the protocol for alignment with existing standards

Researchers and the public

• Review the security analysis and identify gaps
• Propose improvements to the protocol
• Contribute to the open specification

References

1. RFC 8615 — Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. May 2019.
2. RFC 8785 — JSON Canonicalization Scheme (JCS). A. Rundgren, B. Jordan, S. Erdtman. June 2020.
3. RFC 7208 — Sender Policy Framework (SPF). S. Kitterman. April 2014.
4. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). M. Kucherawy, E. Zwicky. March 2015.
5. RFC 6960 — Online Certificate Status Protocol (OCSP). S. Santesson et al. June 2013.
6. RFC 5280 — Internet X.509 PKI Certificate and CRL Profile. D. Cooper et al. May 2008.
7. RFC 4648 — The Base16, Base32, and Base64 Data Encodings. S. Josefsson. October 2006.
8. RFC 6979 — Deterministic Usage of DSA and ECDSA. T. Pornin. August 2013.
9. RFC 7518 — JSON Web Algorithms (JWA). M. Jones. May 2015.
10. FIPS 186-4 — Digital Signature Standard (DSS). NIST. July 2013.
11. Gambling Regulation Act 2024 (Ireland).
12. Directive (EU) 2022/2555 — NIS2 Directive.
13. Regulation (EU) 2024/1183 — eIDAS 2.0.

II. Intellectual Property & Patent Strategy

1. Patent Considerations for GL1

GL1 is an open protocol designed for global adoption by gambling regulators, operators, and intermediaries. The IP strategy must balance two objectives:

• Openness: The protocol must be freely implementable by any party, without licensing fees, to maximise adoption and achieve the public policy objective of combating illegal gambling.
• Protection: The protocol must be protected from being patented by a third party who could then restrict or charge for its use, undermining the public-interest purpose of GL1.

The combination of specific GL1 innovations — the three-mechanism defence-in-depth approach to licence verification (well-known URI, DNS TXT, and API), the authority-issued/operator-hosted credential model, and the federated Trust Directory for multi-authority key discovery — may be patentable as a system and method. If GRAI does not secure defensive protection, a commercial entity could potentially patent aspects of the protocol and impede adoption.

2. Options Analysis

3. Recommendation: Option C — Defensive Patent with Irrevocable Royalty-Free Pledge

3.1 Inventor and Ownership

The GL1 protocol was conceived and designed by Ed Campbell, security consultant to GRAI. As the inventor, Campbell is named on any patent filing. The ownership and licensing arrangements between Campbell and GRAI are governed by the terms of the consultancy engagement.

Options for patent ownership structure:

• Inventor holds patent, licences to GRAI: Campbell files as inventor and patent holder; grants GRAI an irrevocable, royalty-free licence; both parties publish the open pledge. Campbell retains recognition as inventor.
• Joint ownership: Campbell and GRAI file jointly as co-owners, with both parties bound by the royalty-free pledge.
• Assignment to GRAI: Campbell assigns patent rights to GRAI, with Campbell named as inventor on the filing. Requires appropriate consideration in the consultancy terms.

Regardless of ownership structure, Campbell must be named as inventor on the patent filing, as this is a legal requirement in all major patent jurisdictions.

3.2 Rationale for Defensive Patent

Filing a defensive patent serves the public interest because:

• It prevents encumbrance. A patent combined with an irrevocable pledge creates a legal barrier against any entity attempting to patent and restrict GL1 or substantially similar protocols.
• It provides certainty to implementers. An irrevocable pledge is a stronger guarantee than prior art alone. Implementers (ISPs, payment processors, operators) can invest in GL1 integration with confidence that they will never face patent claims.
• It establishes the originator. The patent filing creates a formal, legally recognised record of Campbell's innovation, providing clear attribution and supporting GRAI's international standing.
• It aligns with standards body expectations. The IETF requires disclosure of known patent claims on standards-track protocols (RFC 8179). A defensive patent with a royalty-free pledge satisfies this requirement cleanly.

3.3 Precedent: Industry Patent Pledges for Open Standards

3.4 Proposed Patent Pledge Language

3.5 Filing Jurisdiction

The patent should be filed in:

• European Patent Office (EPO) — covering all EU/EEA member states, which represents the primary initial adoption market
• United States Patent and Trademark Office (USPTO) — to provide protection in the largest single-jurisdiction gambling market and to prevent US-based patent trolls from filing
• Patent Cooperation Treaty (PCT) — to reserve the right to file in additional jurisdictions if needed

3.6 Estimated Costs

These costs are modest relative to the value of protecting an international enforcement protocol from encumbrance.

4. Specification Licensing

5. Timeline

III. GL1 Credential JSON Schema

The GL1 credential schema is published at:
https://verify.grai.ie/schemas/gl1/v1/credential.json

Schema draft: JSON Schema 2020-12. The credential is a JSON object with three required top-level properties. All fields are fully defined below.

Top-Level Object

additionalProperties: false — no other top-level properties are permitted.

Licence Object

The core licence details. All required fields MUST be present.

Operator Object

Authority Object

Scope Object

App Object

Validity Object

Signature Object

Complete Schema

The full JSON Schema document (gl1-schema.json):

JSON Schema 2020-12
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://verify.grai.ie/schemas/gl1/v1/credential.json",
  "title": "GL1 Gambling Licence Credential",
  "type": "object",
  "required": ["gl1", "licence", "signature"],
  "additionalProperties": false,
  "properties": {
    "gl1": { "type": "string", "const": "1.0" },
    "licence": { "$ref": "#/$defs/Licence" },
    "signature": { "$ref": "#/$defs/Signature" }
  },
  "$defs": {
    // Licence, Operator, Authority, Scope, App,
    // Validity, Signature definitions as above
    // See gl1-schema.json for complete definitions
  }
}

IV. Verification API Reference

Public API for verifying gambling licence credentials issued under the GL1 protocol. Each Issuing Authority operates its own instance of this API. This specification defines the common interface that all GL1-conformant authorities MUST implement.

Base URL

https://verify.grai.ie/api/v1

GRAI Production — Gambling Regulatory Authority of Ireland

Authentication Tiers

JSON
{
  "gl1": "1.0",
  "licence": {
    "id": "GRL-2026-001234",
    "status": "active",
    "type": "remote_gambling",
    "activities": ["sports_betting", "casino", "poker"],
    "operator": {
      "name": "Example Gambling Ltd",
      "trading_as": "ExampleBet",
      "country": "IE"
    },
    "validity": {
      "issued": "2026-04-01",
      "expires": "2027-03-31"
    },
    "domains": ["examplebet.ie", "examplebet.com"],
    "enforcement_actions": [],
    "last_updated": "2026-04-01T00:00:00Z"
  },
  "authority": {
    "id": "GRAI",
    "name": "Gambling Regulatory Authority of Ireland"
  }
}

JSON
{
  "gl1": "1.0",
  "error": {
    "code": "DOMAIN_NOT_FOUND",
    "message": "No GL1 licence covers the domain 'unlicensed-site.com'"
  }
}

JSON
{
  "domains": [
    "examplebet.ie",
    "examplebet.com",
    "unlicensed-site.com",
    "another-operator.ie"
  ]
}

JSON
{
  "gl1": "1.0",
  "results": [
    {
      "domain": "examplebet.ie",
      "licensed": true,
      "licence_id": "GRL-2026-001234",
      "status": "active",
      "authority": "GRAI"
    },
    {
      "domain": "unlicensed-site.com",
      "licensed": false,
      "licence_id": null,
      "status": null,
      "authority": null
    }
  ],
  "total": 4,
  "licensed_count": 3,
  "unlicensed_count": 1
}

JSON
{
  "gl1": "1.0",
  "authority": {
    "id": "GRAI",
    "name": "Gambling Regulatory Authority of Ireland",
    "country": "IE",
    "uri": "https://www.grai.ie",
    "contact": "enforcement@grai.ie"
  },
  "keys": [
    {
      "kid": "grai-licence-signing-2026-01",
      "alg": "ES384",
      "use": "sig",
      "x5c": ["MIIBxTCCAWugAwIBAgI...base64-cert"],
      "valid_from": "2026-01-01",
      "valid_until": "2027-01-01"
    }
  ],
  "federation": {
    "trust_directory": "https://gl1.gamblinglicence.org",
    "member_since": "2026-04-01"
  }
}

Error Codes

API Licence

The GL1 Verification API specification is published under CC BY 4.0 (Creative Commons Attribution 4.0 International).

V. IETF Internet-Draft

Draft Identifier

draft-grai-gl1-gambling-licence-00

A formal IETF Internet-Draft has been prepared for submission to the Applications and Real-Time Area (ART) of the IETF. The draft formalises the GL1 protocol specification as defined in this white paper, with the precision and structure required by the IETF standards process.

Document Metadata

IANA Registration Requests

The Internet-Draft requests two IANA registrations:

1. Well-Known URI Registration

2. DNS Underscore Label Registration

Standardisation Timeline