Skip to content

Commit

Permalink
Merge pull request #373 from dhh1128/351
Browse files Browse the repository at this point in the history
remove conflict with issue #351
mccown authored Apr 25, 2022
2 parents eadf419 + 0e711f9 commit ba541f1
Showing 2 changed files with 2 additions and 2 deletions.
2 changes: 1 addition & 1 deletion docs/spec-files/out_of_band.md
Original file line number Diff line number Diff line change
@@ -80,7 +80,7 @@ https://<domain>/<path>?_oob=<encodedplaintextjwm>

> `_oob` is a shortened form of Out of Band, and was chosen to not conflict with query parameter names in use at a particular domain. When the query parameter is detected, it may be assumed to be an Out Of Band message with a reasonably high confidence.
> 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).
> When this spec was written, the `didcomm://` URL scheme was in active use for deep linking in mobile apps, and had features that intersect with the OOB protocol described here. That scheme is defined elsewhere; we only note it here to advise against its overloading for other purposes.
The `<encodedplaintextjwm>` is a JWM plaintext message that has been base64-url encoded.

2 changes: 1 addition & 1 deletion docs/spec-files/threading.md
Original file line number Diff line number Diff line change
@@ -32,7 +32,7 @@ When a child protocol is a simple two-party interaction, mentioning the `pthid`

### Message URIs

The `id`, `thid`, and `pthid` properties of any DIDComm message may be combined to form a URI that uniquely identifies the message (e.g., in debuggers, in log files, in archives). Such a scheme is out of scope for this spec, and support for it is OPTIONAL for implementers. This spec reserves the `didcomm://` URI prefix for future work with semantics like these; it MUST NOT be used for other purposes.
The `id`, `thid`, and `pthid` properties of any DIDComm message may be combined to form a URI that uniquely identifies the message (e.g., in debuggers, in log files, in archives). Such a scheme is out of scope for this spec, and support for it is OPTIONAL for implementers.

### Gaps, Resends, and Sophisticated Ordering

0 comments on commit ba541f1

Please sign in to comment.