Skip to content

Latest commit

 

History

History
405 lines (327 loc) · 24.3 KB

0031.md

File metadata and controls

405 lines (327 loc) · 24.3 KB
Raw

BRC-31: Authrite Mutual Authentication

Ty Everett ([email protected])

Abstract

This specification defines Authrite, a system for the mutual authentication of two parties over a communications channel. It facilitates the exchange of BRC-52 identity certificates between users, allowing them to certify each other's identities and share identity information selectively. Authrite leverages the BRC-42 Identity Keys of MetaNet Users and relies on BRC-43 Permissions and BRC-53 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. BRC-52 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 BRC-52 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 BRC-52. 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

Bob creates a BRC-3 digital signature for Alice with the following BRC-43 protocol and key IDs:

BRC-43 Attribute 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

When Alice receives the initialResponse message type from Bob, she will verify the BRC-3 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 BRC-52.

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

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

BRC-43 Attribute 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

When the recipient receives the message from the sender, they will verify the BRC-3 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 BRC-52.

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:

  • Authrite-JS implements the client-side functionality
  • Authrite-Express implements the server-side functionality, for use on Express servers