Indy Resolver - ARIES, Firewalls, and Ledgers

# Indy Resolver - ARIES, Firewalls, and Ledgers Aries mobile agents are often in restrictive or limited environments with limited or filtered access to the internet. Firewalls may include port limitations ( only port 80 and 443 are open ), and protocol limitations ( only HTTP/HTTPS available ) Today, to access ARIES nodes, agents will need to access TCP and a separate port (usually 9907). Example: Corporate environment using a mobile agent, cannot get to ledger to get transactions, can connect to issuer, but can't get cred def to receive an issued credential, or get rev registry to validate credential ## Solutions ### HTTP ZMQ proxy It may be more efficient to have the HTTP be a more efficient process, as it may not consult all the nodes, but just the local node. Passthrough operation. Nonce needs to be passed from client through HTTP to ZMQ. Pros -Existing calls are made with existing cryptography -Client passes existing cryptographic message over HTTP, and passes call directly over ZMQ -Verify node answer on client side? Cons -Need to implment new proxy Andrew may have done research on this. May be similar to observer node behavior Next steps: define it like code with us ( ) Discuss with Andrew and my team ### Indy VDR Proxy on Nodes running on port 80 or 443 We could have the Nodes provide HTTP or HTTPS access directly on the nodes. Pros - Reverse Proxy is hosted on source of truth - No extra encryption is needed ? - Reverse proxy only can access one source, limiting risk of DOS attacks, or other exploits - Uses HTTP or HTTPS and supports port 80 and 443 - May not require adjustment of Genesis File Cons - Nonce is not generated on client side ( Could miss out on cryptographic checks ) - Nodes would need to add a new method for access - ARIES Bifold or other agent needs support for new method ### Add DIDComm Support on Nodes Pros - Messages from nodes can be verified - DIDComm can only access one source, limiting risk of DOS attacks, or other exploits - Uses HTTP or HTTPS and supports port 80 and 443 - May not require adjustment of Genesis File Cons - Extra encryption overhead ( more nodes or larger nodes may be required in a Node environnent ) - ARIES Bifold or other agent needs support for new method ### Add mediator support to access Nodes Message through DIDComm to mediator, then mediator provides service. This could also be a VDR proxy hosted by a third party. Pros - Agents don't need access to anything other than the mediator Cons - Trust issues (Risk of man in the middle type of activities) - If mediator is not limited to a single source, nefarious behavior could be exploited, DOS attacks, typicaly proxy exploits - Additional overhead on mediators - ARIES Bifold or other agent needs support for new method ## DNS Issues HTTPS may require a DNS based entry. This may require adjusting genesis files, and may add more overhead.