I just realized after we closed #22: the store implementation will be able to read all the DIDs, including the pairwise mappings. This could result in a breach of privacy in the case where the storage is an external service.

Ideally, no stores should know what DIDs I am interacting with. This could be uniformly enforced across all implementations by a change in API. For example, a K-V store:

// The layer that consumes this interface is responsible to 
// encrypting the data such that providers cannot interpret it.
// That layer remains secured in aries-framework-go.
type Store interface {
    Put(k string, v []byte)  error
    Get(k string) ([]byte, error)
}

See RFC 0050 - Wallets

@rolsonquadras @troyronda thoughts?

The agent should provide a storage to save the Peer DID Docs.

The peer DID docs need to be associated with some type of backing storage that adds metadata and history (not raw documents). It should store a sequence of deltas and each delta is a JSON object.

Delta structure:

{ "change": <base64 encoding of a change fragment>, "by": [ 

{"key": <id of key>, "sig": <signature value>}

... ],
"when": <ISO8601 UTC timestamp with at least second precision>
}

Here, a change fragment is a sparse version of a DID doc that shows just the section being updated. Also, the agent should have the capability to construct a Peer DID Document from these deltas.

Standard JWE encryption/decryption operations does not support Chacha20 algorithm with Poly1035 authentication.

There are talks to update the JWE spec with this new addition. An IETF draft can be found here:
https://datatracker.ietf.org/doc/draft-amringer-jose-chacha/

The aim of this issue is to create a new package that will support this new JWE spec.

finally, for reference, Aries-rfc has an issue to update its spec using this new format:
hyperledger/aries-rfcs#133

A PHP example is found here:
https://github.com/gamringer/php-authcrypt

the task here is to follow the same format in Go

Part of #36

As per the discussion in #47, the scope was reduced to implementing the backing storage without Conflict resolution. This issue is created to track the conflict resolution requirements.

The parallel flag(maximum number of tests to run simultaneously) is set in unit-test to 1. This will result in running tests in sequence. If this flag is not present, it is set to the value of GOMAXPROCS. At this moment there is no need to set this to 1. By setting to default, we can decrease the test execution time.

Add following setup to the project

• Circle CI config file
• Scripts for licence, lint and unit test along with Makefile

Part of Epic #42

High-level description in planning for 0.1.0 here: https://wiki.hyperledger.org/display/ARIES/Framework+Go+v0.1.0

Ideally, DID Resolution should be implemented as a local API. As defined in the Spec, the DID Resolution function may be provided by a remote service. The agent should support this remote resolution protocol.

The related Aries RFC is 0124: DID Resolution Protocol

Need a REST API (Swagger) that allows the control of the reference agent.

Should be loosely based on hl/aries-cloudagent-python

The agent should have the capability to push the Peer DID doc changes to other peer agents(which knows about the DID). This is documented in Update/Sync State.

The related Aries RFC is 0030: Sync Connection Protocol.

Validate that the DID Document conforms to the serialization of the DID Document data model

spec: https://w3c-ccg.github.io/did-spec/#did-documents

Define generic logging interface for aries framework and provide default implementation.

Once Go-Jose has Chacha20/Poly1035 support, create the UnPack interface and implementation for Anoncrypt using this new addition as per the new standardized JWE format in this Aries-rfc issue:
hyperledger/aries-rfcs#133

and following the UnPack spec for Anoncrypt (disregard format from this RFC):
https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope

ref #36

Enhancement:

Implement a peer.NewDID constructor function that will create the peer DID.

Once Go-Jose has Chacha20/Poly1035 support, create the Pack interface and implementation for Anoncrypt using this new addition as per the new standardized JWE format in this Aries-rfc issue:
hyperledger/aries-rfcs#133

and following the Pack spec for Anoncrypt (disregard format from this RFC):
https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope

ref #36

users of the library should not be forced to call make to test the library, a simpler go generate mechanism for the library authors needs to be introduced instead

Peer DIDs are non-anchored DIDs shared directly between N parties. The Peer DID specification reserves peer as the did method.

Peer DIDs are used to preserve privacy by making it harder for attackers to correlate your identity across interactions with different parties.

Agents need the ability to create and share Peer DIDs during the did-exchange protocol. They also need to synchronize state of these peer DIDs with each other:

• state is managed as a sequence of signed patches
• changes in state are communicated via the sync-state protocol

The Peer DIDs can be resolved in two ways:

• Resolution can directly query the owning Agent with a "resolve" message
• Resolution can query its local storage or cache

In all cases, the source against which the Peer DID will be resolved needs to maintain patches (as opposed to just keeping an "up-to-date" copy) because:

• It's required to maintain proof of authority over the evolution of the DID document
• Following from previous point: both the owning Agent and the Agent(s) to which it has been shared need to merge those patches and resolve any conflicts (there is a section on conflict resolution in the Peer DID spec).

(Interestingly, the peer DID spec defines several "levels of support" for peer DIDs)

References

• Peer DIDs
• DID Resolution
• sync-state protocol

Add following badges to the project

• circle ci
• release
• licence
• codecov
• go report card

Resolving DIDs is the act of fetching the DID document associated with the DID from a datasource identified by the DID's method (read the DID spec for details on the DID identifier format). If the DID has a fragment, then only the portion of the DID document identified by that fragment is returned.

The solution's architecture must support plugging in additional "drivers" for other DID methods.

Example: resolving a kid with value did:example:123456789abcdefghi#1 results in fetching the DID document associated to did:example:123456789abcdefghi and returning the element in the array of publicKey that has the id set to did:example:123456789abcdefghi#1. Note that the DID's context provides a hint as to where in the DID document to search for the element identified; in this case, kid implies that we are searching for a key, hence why in this case we would narrow the search to the publicKey array.

References

• DID spec: https://w3c-ccg.github.io/did-spec/
• DID Resolution spec: https://w3c-ccg.github.io/did-resolution/

https://w3c.github.io/vc-data-model/

New package: cmd/agent

• template for building the reference agent
• implements and exposes the controller API

Type up a CONTRIBUTING.md file

Add Generic did resolver framework to handle multiple DID methods

spec: https://w3c-ccg.github.io/did-resolution/

https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports#https

Once Go-Jose has Chacha20/Poly1035 support, create the UnPack interface and implementation for Authcrypt using this new addition as per the new standardized JWE format in this Aries-rfc issue:
hyperledger/aries-rfcs#133

and following the UnPack spec for Authcrypt (disregard format from this RFC):
https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope

ref #36

https://github.com/hyperledger/aries-framework-go/blob/695f0bf9ae71b8fee6a3b66397d34a5101bb35e6/pkg/framework/didresolver/api.go#L22

All args aside from the DID should be optional.

Let's also add a bool return arg that indicates whether the DID method found a result or not.

This is to track issue hyperledger/aries-rfcs#104

It is currently unclear how to identify the Sender of a message with the current specs for DIDComm:

• Both non-repudiable and repudiable envelopes are inlining the keys
• None of the plaintext messages define who the sender is. Eg. request-credential

Right now the specs imply that the Agent identifies the Sender by their public key. This encroaches on DID territory, as DIDs are meant to be used as identifiers.

did document spec: https://w3c-ccg.github.io/did-spec/#did-documents

The agents exchange Peer DIDs using DID Exchange Protocol. 

The receiving agent should have the capability to validate the DID Document against the name-string component of the DID Identifier.

The generation of Identifier is described in #46.

The Agent Framework should provide a default storage for Documents and Connections. The interfaces for these storages were defined in #22 and merged as part of #23.

The following requirement are considered for the default implementation.

• No network call
• Pure golang implementation
• Backed by file system

The Golang LevelDB provider(based on lib https://github.com/syndtr/goleveldb) looks to be the best fit considering the above requirements.

As part of the requirements in #74, the consumer of the lib should have the ability to initialize the framework and pass in different configuration options.

As part of this issue, build a template for framework initialization.

• Add New(opts) function which takes in the options to configuration
• Support outbound transport configuration

The Aries Framework should support pluggable storage(e.g file store, embedded db store, cloud store, etc.) for DID documents along with Connections(pairwise mapping).

Define test framework which will have basic steps for interaction with aries-agents.

This should include:

• spinning up agents (wrapped in docker so as it runs in Circle CI)
• integration tests for different DIDComm scenarios
  -- did exchange
• reusable steps so that it can be reused in downstream demos/tests
• document how to run BDD locally

BDD tests that run all steps in CI

Following from #26, we should add support for Tags and Queries to enable richer queries against the Store.

https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange

Example provided here (from a previous PR): https://github.com/hyperledger/aries-framework-go/pull/55/files#diff-d9e817deb772fd4e55da4b57afbca798R16

Once Go-Jose has Chacha20/Poly1035 support, create the Pack interface and implementation for Authcrypt using this new addition as per the new standardized JWE format in this Aries-rfc issue:
hyperledger/aries-rfcs#133

and following the Pack spec for Authcrypt (disregard format from this RFC):
https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope

ref #36

Peer DID should have an identifier as defined in the Spec.

ABNF Syntax for Peer DID:

peer-did = "did:peer:" numalgo encalgo "-" numbasis 
numalgo = "1" 
encalgo = "1" 
numbasis = 64*HEXDIGCI 
HEXDIGCI = HEXDIG / "a" / "b" / "c" / "d" / "e" / "f"

The numbasis is generated from Genesis Version of the Peer DID. 

• Should be a framework package that glues together the chosen handlers, resolvers, stores, etc.
• Protocols need to be implementable both inside the main Aries repo and outside by downstream repos. i.e., use decoupled patterns.
• Should include a defaults Option that provides the (curated) default list of handlers, resolvers, stores, etc. to make a default instantiation of the framework easy.
• Used by agent implementations (including reference agents).

The agents doesn't require to communicate the termination of the connection/relationship to other peer agents. But its best practice to let the other agent know about this. This is documented in Deactivate Spec

The related Aries RFC is 0030: Sync Connection Protocol.

We should be signing the connection response. Specifically, the connection object needs to be replaced by connection-sig.

The reason for this is that the keys shared in the initial invitation to exchange will likely NOT be the keys present in the DID shared in the connection response:

• The keys in the initial invitation to exchange will likely be ephemeral since they are sent in plaintext (by design) and because DIDComm uses keys as identifiers. Identifiers should not be revealed to outside parties.
• The party has to prove that they own the DID that they are sharing and this is a mechanism to do so in a single message (as opposed to a later challenge-response protocol).

Validate input DID conforms to the did rule of the Generic DID Syntax.

//////////////////////////////////////////////////
did = "did:" method-name ":" method-specific-id
method-name = 1*method-char
method-char = %x61-7A / DIGIT
method-specific-id = *idchar *( ":" *idchar )
idchar = ALPHA / DIGIT / "." / "-" / ""
did-url = did ( ";" param ) path-abempty [ "?" query ]
[ "#" fragment ]
param = param-name [ "=" param-value ]
param-name = 1param-char
param-value = *param-char
param-char = ALPHA / DIGIT / "." / "-" / "" / ":" /
pct-encoded

////////////////////////////////////////////////////

There is implementation in java

https://github.com/decentralized-identity/did-common-java/tree/master/src/main/java/did/parser

The framework provides a DID Resolver API.

Framework needs to provide a Peer DID Resolver against the Backing Storage.

Implement following DID exchange client APIs documented in Aries spec - https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange

1. Generate Invitation
2. Send Exchange Request
3. Send Exchange Response

To keep the project organized, we should document a preliminary idea of the package hierarchy.

Add the capability for Aries Agents to safely communicate over HTTPS transport.

This implements the HTTP(S) Aries-RFC 25: https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports#https

Only HTTPS will be supported for secured communications.

And must support the DID Exchange Protocol 1.0 as per Aries-RFC 23: https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange

To complete transport security, future work (after this issue) will include the Pack/Unpack messaging capability as described in Aries-RFC 19 to encode/decode & authenticate senders and receivers: https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope