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.
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.
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.
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.
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.
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:
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:
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:
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
