Aries RFC 0434: Out-of-Band Protocol 1.1¶
- Authors: Ryan West, Daniel Bluhm, Matthew Hailstone, Stephen Curran, Sam Curren, George Aristy
- Status: ADOPTED
- Since: 2020-03-01
- Status Note: This RFC extracts the
invitation
messages from the DID Exchange protocol (and perhaps Connection), and replaces the combinedpresent_proof/1.0/request
combined with the~service
decorator to define an ephemeral (connection-less) challenge. - Supersedes: Invitation Message in 0160-Connections and Invitation Message in 0023-DID-Exchange.
- Start Date: 2020-03-01
- Tags: feature, protocol, test-anomaly
- URI:
https://didcomm.org/out-of-band/%VER
Summary¶
The Out-of-band protocol is used when you wish to engage with another agent and you don't have a DIDComm connection to use for the interaction.
Motivation¶
The use of the invitation
in the Connection and DID Exchange protocols has been relatively successful, but has some shortcomings, as follows.
Connection Reuse¶
A common pattern we have seen in the early days of Aries agents is a user with a browser getting to a point where a connection is needed between the website's (enterprise) agent and the user's mobile agent. A QR invitation is displayed, scanned and a protocol is executed to establish a connection. Life is good!
However, with the current invitation processes, when the same user returns to the same page, the same process is executed (QR code, scan, etc.) and a new connection is created between the two agents. There is no way for the user's agent to say "Hey, I've already got a connection with you. Let's use that one!"
We need the ability to reuse a connection.
Connection Establishment Versioning¶
In the existing Connections and DID Exchange invitation
handling, the inviter dictates what connection establishment protocol all invitee's will use. A more sustainable approach is for the inviter to offer the invitee a list of supported protocols and allow the invitee to use one that it supports.
Handling of all Out-of-Band Messages¶
We currently have two sets of out-of-band messages that cannot be delivered via DIDComm because there is no channel. We'd like to align those messages into a single "out-of-band" protocol so that their handling can be harmonized inside an agent, and a common QR code handling mechanism can be used.
URLs and QR Code Handling¶
We'd like to have the specification of QR handling harmonized into a single RFC (this one).
Tutorial¶
Key Concepts¶
The Out-of-band protocol is used when an agent doesn't know if it has a connection with another agent. This could be because you are trying to establish a new connection with that agent, you have connections but don't know who the other party is, or if you want to have a connection-less interaction. Since there is no DIDComm connection to use for the messages of this protocol, the messages are plaintext and sent out-of-band, such as via a QR code, in an email message or any other available channel. Since the delivery of out-of-band messages will often be via QR codes, this RFC also covers the use of QR codes.
Two well known use cases for using an out-of-band protocol are:
- A user on a web browser wants to execute a protocol (for example, to issue a verifiable credential) between the website operator's agent and a user's agent. To enable the execution of the protocol, the two agents must first have a connection. An out-of-band message is used to trigger the creation of a new, or the reuse an existing, connection.
- A website operator wants to request something from a user on their site where there is no (known) connection with the user's agent, and there is no need to create a connection.
In both cases, there is only a single out-of-band protocol message sent. The message responding to the out-of-band message is a DIDComm message from an appropriate protocol.
Note that the website-to-agent model is not the only such interaction enabled by the out-of-band protocol, and a QR code is not the only delivery mechanism for out-of-band messages. However, they are useful as examples of the purpose of the protocol.
Roles¶
The out-of-band protocol has two roles: sender and receiver.
sender¶
The agent that generates the out-of-band message and makes it available to the other party.
receiver¶
The agent that receives the out-of-band message and decides how to respond. There is no out-of-band protocol message with which the receiver will respond. Rather, if they respond, they will use a message from another protocol that the sender understands.
States¶
The state machines for the sender and receiver are a bit odd for the out-of-band protocol because it consists of a single message that kicks off a co-protocol and ends when evidence of the co-protocol's launch is received, in the form of some response. In the following state machine diagrams we generically describe the response message from the receiver as being a DIDComm message.
The sender state machine is as follows:
Note the "optional" reference under the second event in the await-response
state. That is to indicate that an out-of-band message might be a single use message with a transition to done, or reusable message (received by many receivers) with a transition back to await-response
.
The receiver state machine is as follows:
Worth noting is the first event of the done
state, where the receiver may receive the message multiple times. This represents, for example, an agent returning to the same website and being greeted with instances of the same QR code each time.
Messages¶
The out-of-band protocol a single message that is sent by the sender.
Invitation: https://didcomm.org/out-of-band/%VER/invitation
¶
{
"@type": "https://didcomm.org/out-of-band/%VER/invitation",
"@id": "<id used for context as pthid>",
"label": "Faber College",
"goal_code": "issue-vc",
"goal": "To issue a Faber College Graduate credential",
"accept": [
"didcomm/aip2;env=rfc587",
"didcomm/aip2;env=rfc19"
],
"handshake_protocols": [
"https://didcomm.org/didexchange/1.0",
"https://didcomm.org/connections/1.0"
],
"requests~attach": [
{
"@id": "request-0",
"mime-type": "application/json",
"data": {
"json": "<json of protocol message>"
}
}
],
"services": ["did:sov:LjgpST2rjsoxYegQDRm7EL"]
}
The items in the message are:
@type
- the DIDComm message type@id
- the unique ID of the message. The ID should be used as the parent thread ID (pthid
) for the response message, rather than the more common thread ID (thid
) of the response message. This enables multiple uses of a single out-of-band message.label
- [optional] a self-attested string that the receiver may want to display to the user, likely about who sent the out-of-band message.goal_code
- [optional] a self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message.goal
- [optional] a self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message.accept
- [optional] an array of media (aka mime) types in the order of preference of the sender that the receiver can use in responding to the message. Ifaccept
is not specified, the receiver uses its preferred choice to respond to the message. RFC 0044 provides a general discussion of media types.handshake_protocols
- [optional] an array of protocols in the order of preference of the sender that the receiver can use in responding to the message in order to create or reuse a connection with the sender. These are not arbitrary protocols but rather protocols that result in the establishment of a connection. One or both ofhandshake_protocols
andrequests~attach
MUST be included in the message.requests~attach
- [optional] an attachment decorator containing an array of request messages in order of preference that the receiver can using in responding to the message. One or both ofhandshake_protocols
andrequests~attach
MUST be included in the message.- While the JSON form of the attachment is used in the example above, the sender could choose to use the base64 form.
services
- an array of union types that the receiver uses when responding to the message. Each item is either a DIDCommservice
object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.
If only the handshake_protocols
item is included, the initial interaction will complete with the establishment (or reuse) of the connection. Either side may then use that connection for any purpose. A common use case (but not required) would be for the sender to initiate another protocol after the connection is established to accomplish some shared goal.
If only the requests~attach
item is included, no new connection is expected to be created, although one could be used if the receiver knows such a connection already exists. The receiver responds to one of the messages in the requests~attach
array. The requests~attach
item might include the first message of a protocol from the sender, or might be a please-play-the-role message requesting the receiver initiate a protocol. If the protocol requires a further response from the sender to the receiver, the receiver must include a ~service
decorator for the sender to use in responding.
If both the handshake_protocols
and requests~attach
items are included in the message, the receiver should first establish a connection and then respond (using that connection) to one of the messages in the requests~attach
message. If a connection already exists between the parties, the receiver may respond immediately to the request-attach
message using the established connection.
Reuse Messages¶
While the receiver is expected to respond with an initiating message from a handshake_protocols
or requests~attach
item using an offered service, the receiver may be able to respond by reusing an existing connection. Specifically, if a connection they have was created from an out-of-band invitation
from the same services
DID of a new invitation
message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection.
If a message has a service block instead of a DID in the services
list, you may enable reuse by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block.
If the receiver desires to reuse the existing connection and a requests~attach
item is included in the message, the receiver SHOULD respond to one of the attached messages using the existing connection.
If the receiver desires to reuse the existing connection and no requests~attach
item is included in the message, the receiver SHOULD attempt to do so with the reuse
and reuse-accepted
messages. This will notify the inviter that the existing connection should be used, along with the context that can be used for follow-on interactions.
While the invitation
message is passed unencrypted and out-of-band, both the handshake-reuse
and handshake-reuse-accepted
messages MUST be encrypted and transmitted as normal DIDComm messages.
Reuse: https://didcomm.org/out-of-band/%VER/handshake-reuse
¶
{
"@type": "https://didcomm.org/out-of-band/%VER/handshake-reuse",
"@id": "<id>",
"~thread": {
"thid": "<same as @id>",
"pthid": "<The @id of the Out-of-Band invitation>"
}
}
The items in the message are:
@type
- the DIDComm message type@id
- the unique ID of the message.pthid
- the @id of the invitation message. This provides the context link for the inviter to prompt additional protocol interactions.
Sending or receiving this message does not change the state of the existing connection.
When the inviter receives the handshake-reuse
message, they MUST respond with a handshake-reuse-accepted
message to notify that invitee that the request to reuse the existing connection is successful.
Reuse Accepted: https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted
¶
{
"@type": "https://didcomm.org/out-of-band/%VER/handshake-reuse-accepted",
"@id": "<id>",
"~thread": {
"thid": "<The Message @id of the reuse message>",
"pthid": "<The @id of the Out-of-Band invitation>"
}
}
The items in the message are:
@type
- the DIDComm message type@id
- the unique ID of the message.pthid
- the @id of the invitation message. This and thethid
provides context for the invitee to know the reuse attempt succeeded.
If this message is not received by the invitee, they should use the regular process. This message is a mechanism by which the invitee can detect a situation where the inviter no longer has a record of the connection and is unable to decrypt and process the handshake-reuse
message.
After sending this message, the inviter may continue any desired protocol interactions based on the context matched by the pthid
present in the handshake-reuse
message.
Responses¶
The following table summarizes the different forms of the out-of-band invitation
message depending on the presence (or not) of the handshake_protocols
item, the requests~attach
item and whether or not a connection between the agents already exists.
handshake_protocols Present? |
requests~attach Present? |
Existing connection? | Receiver action(s) |
---|---|---|---|
No | No | No | Impossible |
Yes | No | No | Uses the first supported protocol from handshake_protocols to make a new connection using the first supported services entry. |
No | Yes | No | Send a response to the first supported request message using the first supported services entry. Include a ~service decorator if the sender is expected to respond. |
No | No | Yes | Impossible |
Yes | Yes | No | Use the first supported protocol from handshake_protocols to make a new connection using the first supported services entry, and then send a response message to the first supported attachment message using the new connection. |
Yes | No | Yes | Send a handshake-reuse message. |
No | Yes | Yes | Send a response message to the first supported request message using the existing connection. |
Yes | Yes | Yes | Send a response message to the first supported request message using the existing connection. |
Both the goal_code
and goal
fields SHOULD be used with the localization service decorator. The two fields are to enable both human and machine handling of the out-of-band message. goal_code
is to specify a generic, protocol level outcome for sending the out-of-band message (e.g. issue verifiable credential, request proof, etc.) that is suitable for machine handling and possibly human display, while goal
provides context specific guidance, targeting mainly a person controlling the receiver's agent. The list of goal_code
values is provided in the Message Catalog section of this RFC.
The services
Item¶
As mentioned in the description above, the services
item array is intended to be analogous to the service
block of a DIDDoc. When not reusing an existing connection, the receiver scans the array and selects (according to the rules described below) a service entry to use for the response to the out-of-band message.
There are two forms of entries in the services
item array:
- a DID that is resolved to retrieve it's DIDDoc service block, and
- an inline service block.
The following is an example of a two entry array, one of each form:
{
"@type": "https://didcomm.org/out-of-band/%VER/invitation",
"@id": "<id used for context as pthid>",
"label": "Faber College",
"handshake_protocols": ["https://didcomm.org/didexchange/1.0"],
"services": [
{
"id": "#inline",
"type": "did-communication",
"recipientKeys": ["did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"],
"routingKeys": [],
"serviceEndpoint": "https://example.com:5000"
},
"did:sov:LjgpST2rjsoxYegQDRm7EL"
]
}
The processing rules for the services
block are:
- Use only entries where the
type
is equal todid-communication
. - Entries without a
type
are assumed to bedid-communication
. - The sender MUST put the array into their order of preference, and, as such, the receiver SHOULD prefer the entries in order.
The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The recipientKeys
and routingKeys
within the inline block decorator MUST be did:key
references.
As defined in the DIDComm Cross Domain Messaging RFC, if routingKeys
is present and non-empty, additional forwarding wrapping are necessary in the response message.
When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be.
Service Endpoint¶
The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the serviceEndpoint
in the DIDDoc of the resolved DID MUST be a URI, and the recipientKeys
MUST contain a single key. That key is appended to the end of the list of routingKeys
for processing. For more information about message forwarding and routing, see RFC 0094 Cross Domain Messaging.
Adoption Messages¶
The problem_report
message MAY be adopted by the out-of-band protocol if the agent wants to respond with problem reports to invalid messages, such as attempting to reuse a single-use invitation.
Constraints¶
An existing connection can only be reused based on a DID in the services
list in an out-of-band message.
Reference¶
Messages Reference¶
The full description of the message in this protocol can be found in the Tutorial section of this RFC.
Localization¶
The goal_code
and goal
fields SHOULD have localization applied. See the purpose of those fields in the message type definitions section and the message catalog section (immediately below).
Message Catalog¶
goal_code
¶
The following values are defined for the goal_code
field:
Code (cd) | English (en) |
---|---|
issue-vc | To issue a credential |
request-proof | To request a proof |
create-account | To create an account with a service |
p2p-messaging | To establish a peer-to-peer messaging relationship |
goal
¶
The goal
localization values are use case specific and localization is left to the agent implementor to enable using the techniques defined in the ~l10n RFC.
Roles Reference¶
The roles are defined in the Tutorial section of this RFC.
States Reference¶
initial¶
No out-of-band messages have been sent.
await-response¶
The sender has shared an out-of-band message with the intended receiver(s), and the sender has not yet received all of the responses. For a single-use out-of-band message, there will be only one response; for a multi-use out-of-band message, there is no defined limit on the number of responses.
prepare-response¶
The receiver has received the out-of-band message and is preparing a response. The response will not be an out-of-band protocol message, but a message from another protocol chosen based on the contents of the out-of-band message.
done¶
The out-of-band protocol has been completed. Note that if the out-of-band message was intended to be available to many receivers (a multiple use message), the sender returns to the await-response state rather than going to the done state.
Errors¶
There is an optional courtesy error message stemming from an out-of-band message that the sender could provide if they have sufficient recipient information. If the out-of-band message is a single use message and the sender receives multiple responses and each receiver's response includes a way for the sender to respond with a DIDComm message, all but the first MAY be answered with a problem_report
.
Error Message Example¶
{
"@type": "https://didcomm.org/out-of-band/%VER/problem_report",
"@id": "5678876542345",
"~thread": { "pthid": "<@id of the OutofBand message>" },
"description": {
"en": "The invitation has expired.",
"code": "expired-invitation"
},
"impact": "thread"
}
See the problem-report protocol for details on the items in the example.
Flow Overview¶
In an out-of-band message the sender gives information to the receiver about the kind of DIDComm protocol response messages it can handle and how to deliver the response. The receiver uses that information to determine what DIDComm protocol/message to use in responding to the sender, and (from the service item or an existing connection) how to deliver the response to the sender.
The handling of the response is specified by the protocol used.
To Do: Make sure that the following remains in the DID Exchange/Connections RFCs
Any Published DID that expresses support for DIDComm by defining a
service
that follows the DIDComm conventions serves as an implicit invitation. If an invitee wishes to connect to any Published DID, they need not wait for an out-of-band invitation message. Rather, they can designate their own label and initiate the appropriate protocol (e.g. 0160-Connections or 0023-DID-Exchange) for establishing a connection.
Standard Out-of-Band Message Encoding¶
Using a standard out-of-band message encoding allows for easier interoperability between multiple projects and software platforms. Using a URL for that standard encoding provides a built in fallback flow for users who are unable to automatically process the message. Those new users will load the URL in a browser as a default behavior, and may be presented with instructions on how to install software capable of processing the message. Already onboarded users will be able to process the message without loading in a browser via mobile app URL capture, or via capability detection after being loaded in a browser.
The standard out-of-band message format is a URL with a Base64Url encoded json object as a query parameter.
Please note the difference between Base64Url and Base64 encoding.
The Base64URL encoded JSON object SHOULD NOT use padding, but the decoding implementation used MUST correctly decode padded and unpadded Base64URL encoded data.
The URL format is as follows, with some elements described below:
<domain>
and <path>
should be kept as short as possible, and the full URL SHOULD return human readable instructions when loaded in a browser. This is intended to aid new users. The oob
query parameter is required and is reserved to contain the out-of-band message string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.
To do: We need to rationalize this approach
https://
approach with the use of a special protocol (e.g.didcomm://
) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can't scan the QR code because it is on a web page on device).
The <outofbandMessage>
is an agent plaintext message (not a DIDComm message) that has been Base64Url encoded such that the resulting string can be safely used in a URL.
During Base64Url encoding, whitespace from the JSON string SHOULD be eliminated to keep the resulting out-of-band message string as short as possible.
Example Out-of-Band Message Encoding¶
Invitation:
{
"@type": "https://didcomm.org/out-of-band/1.0/invitation",
"@id": "69212a3a-d068-4f9d-a2dd-4741bca89af3",
"label": "Faber College",
"goal_code": "issue-vc",
"goal": "To issue a Faber College Graduate credential",
"handshake_protocols": ["https://didcomm.org/didexchange/1.0", "https://didcomm.org/connections/1.0"],
"services": ["did:sov:LjgpST2rjsoxYegQDRm7EL"]
}
Whitespace removed:
{"@type":"https://didcomm.org/out-of-band/1.0/invitation","@id":"69212a3a-d068-4f9d-a2dd-4741bca89af3","label":"Faber College","goal_code":"issue-vc","goal":"To issue a Faber College Graduate credential","handshake_protocols":["https://didcomm.org/didexchange/1.0","https://didcomm.org/connections/1.0"],"services":["did:sov:LjgpST2rjsoxYegQDRm7EL"]}
Base64Url encoded:
eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0
Example URL with Base64Url encoded message:
http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0
Out-of-band message URLs can be transferred via any method that can send text, including an email, SMS, posting on a website, or QR Code.
Example URL encoded as a QR Code:
Example Email Message:
To: alice@alum.faber.edu
From: studentrecords@faber.edu
Subject: Your request to connect and receive your graduate verifiable credential
Dear Alice,
To receive your Faber College graduation certificate, click here to [connect](http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0) with us, or paste the following into your browser:
http://example.com/ssi?oob=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvb3V0LW9mLWJhbmQvMS4wL2ludml0YXRpb24iLCJAaWQiOiI2OTIxMmEzYS1kMDY4LTRmOWQtYTJkZC00NzQxYmNhODlhZjMiLCJsYWJlbCI6IkZhYmVyIENvbGxlZ2UiLCJnb2FsX2NvZGUiOiJpc3N1ZS12YyIsImdvYWwiOiJUbyBpc3N1ZSBhIEZhYmVyIENvbGxlZ2UgR3JhZHVhdGUgY3JlZGVudGlhbCIsImhhbmRzaGFrZV9wcm90b2NvbHMiOlsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiLCJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMCJdLCJzZXJ2aWNlcyI6WyJkaWQ6c292OkxqZ3BTVDJyanNveFllZ1FEUm03RUwiXX0
If you don't have an identity agent for holding credentials, you will be given instructions on how you can get one.
Thanks,
Faber College
Knowledge is Good
URL Shortening¶
It seems inevitable that the length of some out-of-band message will be too long to produce a useable QR code. Techniques to avoid unusable QR codes have been presented above, including using attachment links for requests, minimizing the routing of the response and eliminating unnecessary whitespace in the JSON. However, at some point a sender may need generate a very long URL. In that case, a DIDComm specific URL shortener redirection should be implemented by the sender as follows:
- The sender generates a unique URL for each shortened out-of-band message.
- The unique URL often includes a unique id component as part of the path or in a query parameter.
- The following URLs are valid examples:
https://example.com/ssi?id=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3
https://example.com/8E6nEcJ26TTE
https://example.com/sky/event/8DcnUW2h8m4jcfPdQ2uMN7/work-laptop-bag/s/u
- On receipt of this form of message, the agent MUST perform an HTTP GET to retrieve the associated out-of-band message. The agent SHOULD include an
Accept
header requesting theapplication/json
MIME type. - The sender MAY include a
Content-Type
header specifyingapplication/json; charset=utf-8
, and in the case where the agent included anAccept
header for theapplication/json
MIME type, the sender MUST include the header. If so, the sender MUST return the invitation in JSON format in the response body with astatus_code
of200
. - The sender MAY respond with a
status_code
of301
or302
and include aLocation
header specifying the long out-of-band message URL. - This redirect option operates like many commercial URL shorteners.
- The sender MUST invalidate the URL after message retrieval or after an expiration time to prevent unintended parties from retrieving a copy of the message.
- A sender MUST NOT use a commercial URL shortener unless it supports invalidating the URL.
A usable QR code will always be able to be generated from the shortened form of the URL.
URL Shortening Caveats¶
Some HTTP libraries don't support stopping redirects from occuring on reception of a 301
or 302
, in this instance the redirect is automatically followed and will result in a response that MAY have a status of 200
and MAY contain a URL that can be processed as a normal Out-of-Band
message.
If the agent performs a HTTP GET with the Accept
header requesting application/json
MIME type the response can either contain the message in json
or result in a redirect, processing of the response should attempt to determine which response type is received and process the message accordingly.
Out-of-Band Message Publishing¶
The sender will publish or transmit the out-of-band message URL in a manner available to the intended receiver. After publishing, the sender is in the await-response state, will the receiver is in the prepare-response state.
Out-of-Band Message Processing¶
If the receiver receives an out-of-band
message in the form of a QR code, the receiver should attempt to decode the QR code to an out-of-band message URL for processing.
When the receiver receives the out-of-band message URL, there are two possible user flows, depending on whether the individual has an Aries agent. If the individual is new to Aries, they will likely load the URL in a browser. The resulting page SHOULD contain instructions on how to get started by installing an Aries agent. That install flow will transfer the out-of-band message to the newly installed software.
A user that already has those steps accomplished will have the URL received by software directly. That software will attempt to base64URL decode the string and can read the out-of-band message directly out of the oob
query parameter, without loading the URL. If this process fails then the software should attempt the steps to process a shortened URL.
NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data.
If the receiver wants to respond to the out-of-band message, they will use the information in the message to prepare the request, including:
- the
handshake_protocols
orrequests~attach
to determine the acceptable response messages, and - the
services
block to determine how to get the response to the sender.
Correlating responses to Out-of-Band messages¶
The response to an out-of-band message MUST set its ~thread.pthid
equal to the @id
property of the out-of-band message.
Example referencing an explicit invitation:
{
"@id": "a46cdd0f-a2ca-4d12-afbf-2e78a6f1f3ef",
"@type": "https://didcomm.org/didexchange/1.0/request",
"~thread": { "pthid": "032fbd19-f6fd-48c5-9197-ba9a47040470" },
"label": "Bob",
"did": "B.did@B:A",
"did_doc~attach": {
"base64": "eyJ0eXAiOiJKV1Qi... (bytes omitted)",
"jws": {
"header": {
"kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th"
},
"protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)",
"signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)"
}
}
}
Response Transmission¶
The response message from the receiver is encoded according to the standards of the DIDComm encryption envelope, using the service
block present in (or resolved from) the out-of-band invitation.
Reusing Connections¶
If an out-of-band invitation has a DID in the services
block, and the receiver determines it has previously established a connection with that DID, the receiver MAY send its response on the established connection. See Reuse Messages for details.
Receiver Error Handling¶
If the receiver is unable to process the out-of-band message, the receiver may respond with a Problem Report identifying the problem using a DIDComm message. As with any response, the ~thread decorator of the pthid
MUST be the @id
of the out-of-band message. The problem report MUST be in the protocol of an expected response. An example of an error that might come up is that the receiver is not able to handle any of the proposed protocols in the out-of-band message. The receiver MAY include in the problem report a ~service
decorator that allows the sender to respond to the out-of-band message with a DIDComm message.
Response processing¶
The sender MAY look up the corresponding out-of-band message identified in the response's ~thread.pthid
to determine whether it should accept the response. Information about the related out-of-band message protocol may be required to provide the sender with context about processing the response and what to do after the protocol completes.
Sender Error Handling¶
If the sender receives a Problem Report message from the receiver, the sender has several options for responding. The sender will receive the message as part of an offered protocol in the out-of-band message.
If the receiver did not include a ~service
decorator in the response, the sender can only respond if it is still in session with the receiver. For example, if the sender is a website that displayed a QR code for the receiver to scan, the sender could create a new, presumably adjusted, out-of-band message, encode it and present it to the user in the same way as before.
If the receiver included a ~service
decorator in the response, the sender can provide a new message to the receiver, even a new version of the original out-of-band message, and send it to the receiver. The new message MUST include a ~thread
decorator with the thid
set to the @id
from the problem report message.
Drawbacks¶
- Publicly displayed out-of-band messages (say, a slide at the end of a presentation) all use the same DID. This is not a problem for institutions, and only provides a minor increase in correlation over sharing an endpoint, key, and routing information in a way that is observable by multiple parties.
Prior art¶
- The out-of-band message/response process is similar to other key exchange protocols.
- The Connections and DID Exchange protocols have (or had) their own
invitation
method. - The
~service
decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-bandrequest
message.
Unresolved questions¶
- None
Implementations¶
The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.
Name / Link | Implementation Notes |
---|---|