LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • High-level Overview
  • Data Structures
  • Negotiation Protocol
  • JSON Message Example
  • HTTP Message Example
  • Certificate Inclusion Re-scoping Procedures
  • Implementations

Was this helpful?

Edit on GitHub
Export as PDF
  1. Peer-to-Peer

Authrite Mutual Authentication

PreviousHTTP Service Monetization FrameworkNextPeerServ Message Relay Interface

Last updated 1 year ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

Abstract

This specification defines Authrite, a system for the mutual authentication of two parties over a communications channel. It facilitates the exchange of identity certificates between users, allowing them to certify each other's identities and share identity information selectively. Authrite leverages the Identity Keys of MetaNet Users and relies on Permissions and Certificate management functions to allow Users to control how identity information is shared. This specification defines the nonce exchanges, certificate and field exchange negotiation protocol, and message signing scheme for two-party Authrite communications channels.

Motivation

Identity on the internet relies heavily on trusted third parties to authenticate users. However, this centralization creates potential security and privacy risks, as third parties may collect and misuse user data. addresses this problem by introducing a privacy-centric version of digital identity certificates that facilitate selective revelation and UTXO-based revocation. This standard builds upon by providing a secure and efficient mechanism for exchanging identity information between users over an authenticated communications channel. By leveraging the Identity Keys of MetaNet Users, Authrite provides a decentralized approach to mutual authentication that reduces reliance on third parties and thereby enhances user privacy.

Specification

Authrite facilitates the exchange of identity information between two parties over a communications channel, allowing them to mutually authenticate each other. The following sections describe the requisite data structures, nonce exchanges, negotiation protocol, and message signing scheme for Authrite.

High-level Overview

When Alice initiates communication with Bob, she requests Bob's identity public key, and optionally, a list of certificate type IDs and certifiers she trusts. Bob responds with his identity public key, any certificates that Alice requested, and a list of certificate type IDs and certifiers he needs from Alice. To verify Bob's information, Alice validates his signature, checks that the certified key from all certificates matches his identity public key, and decrypts certificate fields with provided keys. If Alice has met Bob's certification requirements, she may send any messages of her choosing to Bob, including certificates he indicated he could trust. Bob verifies Alice's information and may respond with messages and certificates of his own. If at any point either party wants to re-scope the certificate inclusion in messages, they can initiate a new request for the other's identity public key.

Data Structures

We incorporate by reference all the data structures that were defined by . Nonces, as well as some other necessary higher-level data structures are specified as follows:

Nonce

The Nonce structure is a 256-bit number, converted to a base64 string.

Example

L9t1aQLkWkmMw1Poi1ofIjHV6GO+BNN63v8Na8/gW4Y=

RequestedCertificateCertifierList

The RequestedCertificateCertifierList structure is an array of PublicKey structures, each denoting a certifier which the sending party will trust.

Example

[
  “0295ddf37f406a1dcdf23a0418d5cdc824b4d092e165add14697ce1b8d31e4f3e8”,
  “035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
  “020940955c81c7052583b4bab9c87c81cca92ab7e84d360812a7cdf327d4143ca9”
]

RequestedCertificateTypeIDAndFieldList

The RequestedCertificateTypeIDAndFieldList structure is an object whose keys are CertificateTypeID structures and whose values are each an array of field names from certificates of that type which the sending party requests to examine.

Example

{
  “eHFASF5sUWTHV40NNKigyFFC57pSEnobe/7lzk4XTKI=+BNN63v8Na8/gW4Y=”: [
    “first_name”,
    “last_name”
  ],
  “4nst50RUw4WD1VberI0pJzGMAwX81ozrzvL9fMe7ZhE=”: [
    “firstName”,
    “middleInitial”,
    “lastName”
  ],
  “M4Al7B4C8rY4ajTODGCLl2i0OQlScgOagNg9xEtbud0=”: [
    “full_legal_name”
  ]
}

RequestedCertificateSet

The RequestedCertificateSet structure is an object with the following JSON fields:

  • certifiers — A RequestedCertificateCertifierList structure denoting the certifiers trusted by the sending party.

  • types — A RequestedCertificateTypeIDAndFieldList structure denoting the types of certificates trusted by the sending party, and which fields from each type the sending party would like to examine.

Example

{
  “certifiers”: [
    “0295ddf37f406a1dcdf23a0418d5cdc824b4d092e165add14697ce1b8d31e4f3e8”,	
    “035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
    “020940955c81c7052583b4bab9c87c81cca92ab7e84d360812a7cdf327d4143ca9”
  ],
  “types”: {
    “eHFASF5sUWTHV40NNKigyFFC57pSEnobe/7lzk4XTKI=+BNN63v8Na8/gW4Y=”: [
      “first_name”,
      “last_name”
    ],
    “4nst50RUw4WD1VberI0pJzGMAwX81ozrzvL9fMe7ZhE=”: [
      “firstName”,
      “middleInitial”,
      “lastName”
    ],
    “M4Al7B4C8rY4ajTODGCLl2i0OQlScgOagNg9xEtbud0=”: [
      “full_legal_name”
    ]
  }
}

CertificateList

The CertificateList structure is an array comprising a list of Certificate structures, given in response to a RequestedCertificateSet structure.

Example

[{
  “type”: ”8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=”,
  “subject”: ”0376d67c86b45be3c36c328c2aa5c5dd79c546d22859e39439bd5d934058345abc”,
  “validationKey”: ”G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=”,
  “serialNumber”: ”kUahacBHmYL2nkzemkatFg==”,
  “fields”: {
    “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
    “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
    “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
    “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
    “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
    “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
    “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
  },
  “certifier”: ”035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
  “revocationOutpoint”: “48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1”,
  “signature”: “3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6”,
  “keyring”: {
    “first_name”: “kulDaJWJmzDH/5/qYuEIaDyHrS/PbLCSXPGClC4gLc0=”,
    “last_name”: “26ymqbJl9gMxb00do+kOg950/aE5H+m/PyCgwEXBD/8=”
  }
}]

Negotiation Protocol

Alice’s Initial Request

When Alice starts an interaction with Bob, she sends a message with the following JSON fields:

  • authrite — The version of this specification to use (currently 0.1).

  • messageType — For Alice’s initial message, this should be initialRequest

  • identityKey — A PublicKey structure comprising the Identity Public Key belonging to Alice.

  • nonce — A Nonce structure which was randomly generated by Alice.

  • requestedCertificates — A RequestedCertificateSet structure indicating which certificates Bob should include in future messages, if he has them. If Alice does not require certificates from Bob, this is optional.

NOTE that Alice cannot create a signature for this initial request, because she does not yet know Bob’s identity public key.

Example

{
  “authrite”: “0.1”,
  “messageType”: “initialRequest”,
  “identityKey”: “02a08a4bbba07eadf350f2821a7ab6deaecda3a1c91d487576c80333e9f7a2a635”,
  “nonce”: “0LzpPd0hSjqzVWeW6yOwrms/GD/obTz7Skc/mMxsgg8=”,
  “requestedCertificates”: {
    “certifiers”: [
      “0295ddf37f406a1dcdf23a0418d5cdc824b4d092e165add14697ce1b8d31e4f3e8”,
      “035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
      “020940955c81c7052583b4bab9c87c81cca92ab7e84d360812a7cdf327d4143ca9”
    ],
    “types”: {
      “eHFASF5sUWTHV40NNKigyFFC57pSEnobe/7lzk4XTKI=+BNN63v8Na8/gW4Y=”: [
        “first_name”,
        “last_name”
      ],
      “4nst50RUw4WD1VberI0pJzGMAwX81ozrzvL9fMe7ZhE=”: [
        “firstName”,
        “middleInitial”,
        “lastName”
      ],
      “M4Al7B4C8rY4ajTODGCLl2i0OQlScgOagNg9xEtbud0=”: [
        “full_legal_name”
      ]
    }
  }
}

Bob’s Initial Response

When Bob receives the Initial Request message from Alice, he responds by sending a message with the following JSON fields:

  • authrite — The version of this specification to use (currently 0.1).

  • messageType — For Bob’s initial response this should be initialResponse

  • identityKey — A PublicKey structure comprising the Identity Public Key belonging to Bob.

  • nonce — A Nonce structure which was randomly generated by Bob.

  • certificates — A CertificateList structure created in response to Alice’s RequestedCertificateSet: Bob includes every certificate he has matching the CertificateTypeIDs Alice specified, as long as it was issued by one of Alice’s trusted certifiers. If Alice did not ask for any certificates, or if Bob does not have (or wish to provide) any of the certificates which Alice specified, this is optional.

  • requestedCertificates — A RequestedCertificateSet structure indicating which certificates Alice should include in her future messages, if she has them. If Bob does not require certificates from Alice, this is optional.

  • signature — A Signature structure created in accordance with the Message Signing section.

Example

{
  “authrite”: “0.1”,
  “messageType”: “initialResponse”,
  “identityKey”: “0375454679f3b020c2a255d1cedde607339102704b8cebf11c63e1d7fe6a329327”,
  “nonce”: “Ej0uwfGivItPlY0TWbm554qLIidwmliSRe6xPXK0FH0=”,
  “certificates”: [{
    “type”: ”8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=”,
    “subject”: ”0376d67c86b45be3c36c328c2aa5c5dd79c546d22859e39439bd5d934058345abc”,
    “validationKey”: ”G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=”,
    “serialNumber”: ”kUahacBHmYL2nkzemkatFg==”,
    “fields”: {
      “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
      “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
      “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
      “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
      “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
      “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
      “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
    },
    “certifier”: ”035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
    “revocationOutpoint”: “48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1”,
    “signature”: “3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6”,
    “keyring”: {
      “first_name”: “G2GmxIWNPkO2SUP0XpQvQqX31yz58aLHk9e7JxO+q/MT3k9ZjTe3t8aN2Qwg2+AtBulXZpKhuvxOgxicfd8GqCjFkGtyUrbSdmCFjPUJm7z/P/LWkJHByeBzh3/yOWa7”,
      “last_name”: “YZAHgs+P8Tgci3+5uuAuHr0k3CXPEcB3trpqtEUygV+uwoTgDWk01XTT1eOW6n7qjcDt4g7tlzuWtkawDkvRbCcVe3oBsEI5X8+A10s8TAsyNQV5O1R8mkGoL8/Hec4K”
    }
  }],
  “requestedCertificates”: {
    “certifiers”: [
      “0295ddf37f406a1dcdf23a0418d5cdc824b4d092e165add14697ce1b8d31e4f3e8”,
      “035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
      “020940955c81c7052583b4bab9c87c81cca92ab7e84d360812a7cdf327d4143ca9”
    ],
    “types”: {
      “eHFASF5sUWTHV40NNKigyFFC57pSEnobe/7lzk4XTKI=+BNN63v8Na8/gW4Y=”: [
        “first_name”,
        “last_name”
      ],
      “4nst50RUw4WD1VberI0pJzGMAwX81ozrzvL9fMe7ZhE=”: [
        “firstName”,
        “middleInitial”,
        “lastName”
      ],
      “M4Al7B4C8rY4ajTODGCLl2i0OQlScgOagNg9xEtbud0=”: [
        “full_legal_name”
      ]
    }
  },
  “signature”: “3045022100fc0946c97393ffd48b34a333a82a69343bed3d43b52932da62cb0e75cc07ca1602200822693d7fd2cb3cd54ebeb610bd1646eaea34cfb99109f393a3bf59ccc50231”
}

Bob's Initial Message Signing

Value

Security Level

2

Protocol ID

authrite message signature

Key ID

xxxxx yyyyy

Counterparty

Alice's public key.

Where:

  • xxxxx is the nonce provided by Alice, and

  • yyyyy is the nonce provided by Bob.

The data to be signed by Bob with this key is the nonce provided by Alice, concatenated with the nonce Bob is sending back.

Bob's Initial Message Verification

General Messages

After the initialRequest and initialResponse message types have been exchanged, either party can exchange general messages that include arbitrary signed payloads. These payloads constitute the authenticated communications channel defined by Authrite. The messages should generally have fields that convey the following information:

  • authrite — The version of this specification to use (currently 0.1).

  • identityKey — A PublicKey structure comprising the Identity Public Key belonging to the sender.

  • nonce — A Nonce structure which was randomly generated by the sender.

  • yourNonce — The Nonce structure which the recipient had originally provided as part of the initial request or initial response.

  • certificates — A CertificateList structure created in response to the counterparty’s RequestedCertificateSet: The sender includes every certificate they have matching the CertificateTypeIDs the counterparty specified, as long as it was issued by one of the counterparty’s trusted certifiers. If the counterparty did not ask for any certificates, or if the sender does not have any of the certificates which the counterparty had specified, this is optional.

  • payload — This is the data to be sent to the counterparty. It could be a JSON object, an image, or any other generalized data of any kind. Examples of different Authrite messages implemented in different contexts are given below.

  • signature — A Signature structure created in accordance with the Message Signing section.

General Message Signing

Value

Security Level

2

Protocol ID

authrite message signature

Key ID

xxxxx yyyyy

Counterparty

The recipient's public key.

Where:

  • xxxxx is the original nonce (from the initial request or initial response) provided by the counterparty, and

  • yyyyy is the nonce provided by the sender, which is specified as part of this message.

The data to be signed by the sender with this key is the message payload.

General Message Verification

The recipient should also ensure that the yourNonce value was originally generated by them if they rely on it during verification.

JSON Message Example

When JSON is used, a message payload can simply be added to an Authrite JSON object:

{
  “authrite”: “0.1”,
  “identityKey”: “0375454679f3b020c2a255d1cedde607339102704b8cebf11c63e1d7fe6a329327”,
  “nonce”: “Ej0uwfGivItPlY0TWbm554qLIidwmliSRe6xPXK0FH0=”,
  “yourNonce”: “VBEk9m0CFlgG/cCpRf0QWKErMGI1wNuHIoCpWSY8+50=”,
  “certificates”: [{
    “type”: ”8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=”,
    “subject”: ”0376d67c86b45be3c36c328c2aa5c5dd79c546d22859e39439bd5d934058345abc”,
    “validationKey”: ”G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=”,
    “serialNumber”: ”kUahacBHmYL2nkzemkatFg==”,
    “fields”: {
      “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
      “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
      “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
      “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
      “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
      “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
      “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
    },
    “certifier”: ”035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
    “revocationOutpoint”: “48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1”,
    “signature”: “3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6”,
    “keyring”: {
      “first_name”: “G2GmxIWNPkO2SUP0XpQvQqX31yz58aLHk9e7JxO+q/MT3k9ZjTe3t8aN2Qwg2+AtBulXZpKhuvxOgxicfd8GqCjFkGtyUrbSdmCFjPUJm7z/P/LWkJHByeBzh3/yOWa7”,
      “last_name”: “YZAHgs+P8Tgci3+5uuAuHr0k3CXPEcB3trpqtEUygV+uwoTgDWk01XTT1eOW6n7qjcDt4g7tlzuWtkawDkvRbCcVe3oBsEI5X8+A10s8TAsyNQV5O1R8mkGoL8/Hec4K”
    }
  }],
  “payload”: {
    “hello”: “Authrite!”
  },
  “signature”: “3045022100fc0946c97393ffd48b34a333a82a69343bed3d43b52932da62cb0e75cc07ca1602200822693d7fd2cb3cd54ebeb610bd1646eaea34cfb99109f393a3bf59ccc50231”
}

HTTP Message Example

When Authrite messages are sent over HTTP, X-Authrite-* headers can be added in addition to the normal headers. The signature is created over the data in the HTTP request or response body. If there is not a body to sign, the URL can be signed:

Content-Type: video/mp4
Content-Length: 140546213245
X-Authrite: 0.1
X-Authrite-Identity-Key: 0375454679f3b020c2a255d1cedde607339102704b8cebf11c63e1d7fe6a329327
X-Authrite-Nonce: Ej0uwfGivItPlY0TWbm554qLIidwmliSRe6xPXK0FH0=
X-Authrite-YourNonce: VBEk9m0CFlgG/cCpRf0QWKErMGI1wNuHIoCpWSY8+50=
X-Authrite-Certificates: [{
    “type”: ”8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=”,
    “subject”: ”0376d67c86b45be3c36c328c2aa5c5dd79c546d22859e39439bd5d934058345abc”,
    “validationKey”: ”G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=”,
    “serialNumber”: ”kUahacBHmYL2nkzemkatFg==”,
    “fields”: {
      “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
      “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
      “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
      “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
      “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
      “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
      “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
    },
    “certifier”: ”035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
    “revocationOutpoint”: “48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1”,
    “signature”: “3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6”,
    “keyring”: {
      “first_name”: “kulDaJWJmzDH/5/qYuEIaDyHrS/PbLCSXPGClC4gLc0=”,
      “last_name”: “26ymqbJl9gMxb00do+kOg950/aE5H+m/PyCgwEXBD/8=”
    }
  }]
X-Authrite-Signature: 3045022100fc0946c97393ffd48b34a333a82a69343bed3d43b52932da62cb0e75cc07ca1602200822693d7fd2cb3cd54ebeb610bd1646eaea34cfb99109f393a3bf59ccc50231

Certificate Inclusion Re-scoping Procedures

Certificate Inclusion Re-scoping is when one or both parties change the certificates and/or certificate fields that they are requesting the other party provide. This mechanism can also be used to add or remove certifiers from the list of trusted entities, causing old certificates to be removed or new ones to be added.

For Alice to trigger this process, she simply sends a new initial request to Bob. This new request contains her updated RequestedCertificateSet, and Bob should reflect the update for any future communications.

For Bob to trigger the process, he must return an error and ask Alice to send a new initial request. Bob replies with a JSON object like the following:

{
  “authrite”: “0.1”,
  “messageType”: “rescopingTrigger”,
  “message”: “Send a new initialRequest message to re-scope required certificates, fields and/or trusted certifiers.”
}

Implementations

The Authrite protocol has been implemented in JavaScript through the following two NPM packages:

Bob creates a digital signature for Alice with the following protocol and key IDs:

Attribute

When Alice receives the initialResponse message type from Bob, she will verify the signature with the corresponding values, with Bob as counterparty.

After checking that the signature is valid, Alice then checks that the subject of all the provided certificates is equal to Bob’s identity public key. She then moves on to checking the validity of the certificates themselves, as per .

The sender creates a digital signature for the recipient with the following protocol and key IDs:

Attribute

When the recipient receives the message from the sender, they will verify the signature with the corresponding values, with the sender as counterparty.

After checking that the signature is valid, the recipient then checks that the subject of all the provided certificates is equal to the sender's identity public key. They then move on to checking the validity of the certificates themselves, as per .

implements the client-side functionality

implements the server-side functionality, for use on Express servers

BRC-52
BRC-42
BRC-43
BRC-53
BRC-52
BRC-52
BRC-52
BRC-3
BRC-43
BRC-3
BRC-52
BRC-3
BRC-43
BRC-3
BRC-52
Authrite-JS
Authrite-Express
BRC-43
BRC-43