added url and qr code details #74
Conversation
Signed-off-by: Sam Curren <[email protected]>
advanced_message_passing.md
Outdated
| Example Email Message: | ||
|
|
||
| To: [email protected] |
There was a problem hiding this comment.
prefer @example.com email addresses.
advanced_message_passing.md
Outdated
|
|
||
| A usable QR code will always be able to be generated from the shortened form of the URL. | ||
|
|
||
| Note: Due to the privacy implications, a standard URL shortening service SHOULD NOT be used. |
There was a problem hiding this comment.
This is excellent, but perhaps a reference to some privacy considerations section where an explanation of why can be provided would be helpful.
There was a problem hiding this comment.
Section added at the top.
There was a problem hiding this comment.
Added a suggestion in there to help further clarify why they shouldn't be used. Hopefully it helps a bit.
Signed-off-by: Sam Curren <[email protected]>
|
@OR13 Section added and email address fixed. |
advanced_message_passing.md
Outdated
| First, no private information may be passed in the message. Private information should be passed between parties in encrypted messages only. Any protocol message that contains private information should not be passed via URL or QR code. | ||
|
|
||
| Second, any identifiers passed in a message sent via URL or QR code must no longer be considered private. Any DID used or other identifier no longer considered private MUST be rotated over a secure connection if privacy is required. | ||
|
|
There was a problem hiding this comment.
| Additionally, because of the way URL shortening services work, using these services are SHOULD NOT be used because it allows the services to track and identify the recipient who's receiving the message based on IP, time of day, and frequency of message retrieval. | |
There was a problem hiding this comment.
This is slightly redundant with the warning in about message retrieval (name different than URL shortening on purpose) at the bottom of the doc. Should we at least include a reference to that section in this warning? Thoughts?
advanced_message_passing.md
Outdated
|
|
||
| ##### Example Out-of-Band Message Encoding | ||
|
|
||
| Invitation: |
There was a problem hiding this comment.
@troyronda @llorllale Does adding this address your concerns about a common invitation format?
advanced_message_passing.md
Outdated
|
|
||
| Invitation: | ||
|
|
||
| ```json |
There was a problem hiding this comment.
I think the Out-Of-Band concept (along with a JWM example) should have its own section prior to specific implementations. The concept is not specific to URL / QR code encodings.
There was a problem hiding this comment.
As an example, the out-of-band message could be embedded into a larger JSON object; or provided to an API; or submitted to an endpoint (as its own argument). In those cases, the URL encoding isn't being employed but the out-of-band concept and basic message example is still useful.
There was a problem hiding this comment.
I've added that in a new section.
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
|
I also feel happy with this. Let's merge! |
|
Multiple re-views and approvals, merging |
Signed-off-by: Sam Curren [email protected]