Copyright © 2025 The Mee Foundation.
This document defines a handshake process wherein a person and a service provider (or other person) exchange signals to negotiate the terms of their interactions. The handshake is conducted between the person's agent and the service provider’s website/app.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This section is non-normative.
The internet has evolved to exhibit a power asymmetry between organizations and individuals--an asymmetry that comes at the expense of the autonomy, agency, and privacy of the individual. The power imbalance between internet technology users and service providers (businesses and governments) has been recognized for some time. It was described over a decade ago by the World Economic Forum [WEF2014]:For the past two decades, hundreds of independent developers, and organized groups have explored different paths to restore the power imbalance we've described. A main thrust of this work is the development personal agents and other kinds of “empowerment” tools that work “on the individual's side” [ProjectVRM] and represent their interests.
Possibly the simplest example of “empowerment” tooling is a browser that implements the Global Privacy Control [GPC]. The GPC is signal from the browser communicates the person's Do Not Sell or Share request to the service provider. This signal is legally binding under the California Consumer Privacy Act, and similar state privacy laws that allow users to opt out of data sales or the use of their data for cross-context targeted advertising. The GPC signal was implemented by adding aSec-GPC: 1 field to user agent HTTP header in HTTP Request messages sent to the web server. For example: GET /something/here HTTP/2
Host: example.com
Sec-GPC: 1Implementing a handshake using custom Sec-* header field for each type of signal has disadvantages:
MySignals is a handshake process between a person's agent and a service provider website/app. It is an extensible communications framework that allows developers to define specific kinds of signals (signaltypes) that can be exchanged. It defines a common namespace for these signaltypes and a syntax for passing parameters. During this handshake each side conveys the signaltypes it supports. It has these characteristics:
Sec-MS: 1 field in the GET request. This announces that agent supports the MySignals framework itself.Sec-MS type=<signaltype>... field that includes a subset of the set from step two that are acceptable to the agent.The MySignals framework is designed to support a range of current and anticipated handshaking/signaling needs. Use cases include:
A signaltype is string that uniquely specifies a type of signal that can be sent by a person to a service provider. Implementers of this spec MUST use signaltypes defined in section 4 below. The semantics of each signaltype are defined by an implementer--they are outside of the MySignals spec. When a signal of a given signaltype is sent other parameters MAY be sent along with it. The definition and semantics of these parameters are also out of scope of the MySignals spec.
A set of one or more parameters MAY be passed along with a signal by including a reference to a Signal Parameters Resource (SPR) that contains these parameters.This section describes the three step process when implemented over HTTP.
The user agent MUST insert a Sec-MS header field with a value of 1, for example:
GET /something/here HTTP/2
Host: example.com
Sec-MS: 1The server MUST respond with an Accept-MS header field if it supports the MySignals framework. If it supports the MySignals frameork the Accept-MS field MUST specifying one or more supported signaltypes:
HTTP/1.1 200 OK
Accept-MS: type=signaltype1; type=signaltype2; ... type=signaltypeNThe user agent MUST send one or more MySignals headers specifying the signaltype string value along with an optional Signal Parameters Resource (SPR) URL value. The example below shows a signaltype of "OpenIDConnect" and an SPR URL "https://google.com/mysignals.json":
GET /something/here HTTP/2
Host: example.com
Sec-MS type=OpenIDConnect; SPR="https://google.com/mysignals.json"In step 3 when the agent is sending a specific signaltype, an optional reference (URL) to a Signal Parameteres Resource MAY be included. The value of signaltype MUST be one of:
In step 3 when the agent is sending a specific signaltype, an optional URL reference to a Signal Parameters Resource (SPR) MAY be included.
An SPR is a [JSON] format resource that contains additional parameters to pass with a signal. It MUST contain the title and version fields. The rest of the fields are determined by the specifics of the signaltype. Each signaltype has its own section of the SPR (e.g. "[SIOPv2]") followed by one or more signaltype-specific fields.
The following example shows a SPR containing parameters for the "SIOPv2" signaltype. Two URL-valued parameters are "image" and "SIOPAuthorized".
{
"title": "Signal Parameters Resource",
"version": "1.0",
"SIOPv2": {
"image": "https://mee.foundation/continue-with-mee-smartwallet.png",
"SIOPAuthorized": "https://mee.foundation/authorize"
}
}