Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FCP HIPE: trust ping protocol #67

Merged
merged 10 commits into from Mar 14, 2019

Conversation

Projects
None yet
4 participants
@dhh1128
Copy link
Member

commented Dec 12, 2018

Signed-off-by: Daniel Hardman daniel.hardman@gmail.com

Describe how agents could ping one another to prove connectivity and security.

dhh1128 added some commits Dec 12, 2018

Initial draft
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Add notion of requesting no response.
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Add sentence of clarification
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Fix some minor json bugs in sample msgs
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
minor typo fix
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Remove TODO
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Fix misplaced comma in JSON sample
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
@devin-fisher

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

I think the protocol needs at least an optional nonce. I think it should be required but those with better crypto chops could convince me that the overhead is not needed sometimes.

Cryptographic Nonce

@devin-fisher

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

I'm confused, if the @id is not required for the ping but the @thread is required for the pong and the @thread really requires an thid that is based on the @id of the ping. How could this logically work without an @id?

The `response_requested` field deserves special mention. The normal
expectation of a trust ping is that it elicits a response. However, it
may be desirable to do a unilateral trust ping at times--communicate
information without any expecation of a reaction. In this case,

This comment has been minimized.

Copy link
@swcurran

swcurran Dec 16, 2018

Contributor

expectation

example, to defeat correlation between request and response (to generate
noise). Or agents A and B might agree that periodically A will ping B
without a response, as a way of evidencing that A is up and functional.
If `response_requested` is false, then the receiver MUST NOT respond.

This comment has been minimized.

Copy link
@swcurran

swcurran Dec 16, 2018

Contributor

Might add here - If response_requested is true, @id is required.

The "trust" in its name comes from several features that the interaction
gains by virtue of its use of standard agent-to-agent conventions:

1. Messages should be associated with a [__message trust context__](

This comment has been minimized.

Copy link
@swcurran

swcurran Dec 16, 2018

Contributor

If a message is received but is not in the expected message trust context, should there be a way to respond but with a message that says "Hey, this is not going to work because of X"?

in the channel. For example, both sender and receiver can check whether
messages are encrypted with suitable algorithms and keys.

2. Messages may be targeted at any known agent in the other party's sovereign

This comment has been minimized.

Copy link
@swcurran

swcurran Dec 16, 2018

Contributor

There are limitations on this that should be acknowledged. At minimum, the Domain Endpoint (Agency) will never have a private key for a Sender (at least as part of a pairwise DID), so it can't be pinged in this way. Likewise, if a Routing Agent is ONLY a Routing Agent, it will also not have a key for the Sender and so cannot respond.

{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/trust_ping/1.0/ping",
"@id": "518be002-de8e-456e-b3d5-8fe472477a86",
"@timing": {

This comment has been minimized.

Copy link
@swcurran

swcurran Dec 16, 2018

Contributor

I've made some comments in the Proposed HIPE about timing that might (or might not) affect this.

Adjust to ~ as decorator prefix
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>

@TelegramSam TelegramSam changed the title propose HIPE: trust ping protocol FCP HIPE: trust ping protocol Feb 28, 2019

@TelegramSam TelegramSam merged commit a0c7dba into hyperledger:master Mar 14, 2019

1 check passed

DCO DCO
Details

brentzundel pushed a commit to brentzundel/indy-hipe that referenced this pull request Apr 16, 2019

Merge pull request hyperledger#67 from dhh1128/trust-ping
FCP HIPE: trust ping protocol

Signed-off-by: Brent <brent.zundel@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.