via API, CLI and network

include documentation on how to use API/CLI based on configured concepts.

Useful to show, since it has a new peer ID every time it restarts.

Since it's a public endpoint it should be under 'public'.

see also in discussion of #14

Update checks are not complete.

• Version of a new doc does not start with 0
• Version or updatedAt timestamp of a updated doc !> previous
• New keys added should be added to the keystore
• Removed keys should be removed from the keystore
• Resolving a chain of controllers (more than 1)
• Deactivation of ducuments
• Timeline validation according to RFC004 3.4.1
• Full e2e test which will test the complete life cycle of a document:
  • Creation of a new document A
  • Update Document A with a new service
  • Update Document A with a new authentication key, old one should be removed
  • Creation of New Document B
  • Update of Document B controller which transfers control to Document A
  • Update of Document B with new service endpoints, signed by Document A
  • Creation of Document C
  • Update of Document C which makes Document B the controller
  • Deactivation of Document C
  • Deactivation of Document A and thus also Document B

naming conflicts with json documents and DID documents.
transaction is a better term, but not the ideal one....

required info from VDR is needed so network can do proper signature validation

nuts server --network.bootstrapNodes node1:5555 results in
network.bootstrapNodes -> [node1:5555 node1:5555 node1:5555]

nuts server --network.bootstrapNodes node1:5555,node2:555 results in
network.bootstrapNodes -> [node1:5555 node2:5555 node1:5555 node2:5555 node1:5555 node2:5555]

EN:PractitionerLogin:v3 I hereby declare to act on behalf of Company #686. This declaration is valid from maandag, 22 februari 2021 16:07:17 until maandag, 22 februari 2021 17:07:17.

See unit test: auth/services/contract/notary_test.go

The IRMA setup still uses singletons, e.g. auth/services/irma/irmaconfig.go.

They need to go.

annoying when using curl and cli

See https://medium.com/@smyrman/writing-constant-errors-with-go-1-13-10c4191617

Still needs to be implemented, but we can do that now we have the KeyStore.

Instead of pointer to the internal struct. Now you can alter the DID Document without going through Update().

Suggestion: provide Copy() func on DIDDocument

all top level flags for the server command seem to be broken. Only the config file works.

The Engine struct could be refactored to an interface which can be composed of the existing Runnable, Configurable and Diagnosable interfaces.

This now simply returns '0'. The idea is that it contains the size of the network data storage in bytes.

Node could not parse network documents:

nuts  | time="2021-02-18T12:25:05Z" level=error msg="Error while checking peer document on local node (peer=71d2a790-6bef-4db7-8a6f-bb81e57fc11d, document=cc137e657740fd2bddb042258268877d8c6ca26b1d21f75fd8f1a8c313932ba9): received document is invalid (peer=71d2a790-6bef-4db7-8a6f-bb81e57fc11d,pref=cc137e657740fd2bddb042258268877d8c6ca26b1d21f75fd8f1a8c313932ba9): document validation failed: when present, the `jwk` must contain a valid `kid`" module=Network

This check is not according to RFC004. The check for a kid on an embedded key is wrong.

Since it binds on localhost:1323 you'd have to configure it to have any endpoints being available from the outside at all, which is not very convenient.

http:
  default:
    address: :1323

Maybe better: bind on :1323 (all interfaces) by default so it's available from the outside (Docker container e.g.), and add some extra checks to strict mode, disallowing unsafe configuration. Maybe disallow this 'bind to all interfaces' in strict mode to enforce administrators to provide alternative bindings?

currently it calls the store directly. It must do everything via the network and use the callbacks to store data in the store.

• name of the image
• what to mount
• config requirements/tips/tricks

Now each engine defines a HTTP bind address (or remote server address when running the client). The global config also defines the bind address. Since we don't plan to start just some modules per node (fine-grained microservices) but use the all-or-nothing approach, there's (imo) no need to specify a bind address per engine.

As spec-ed by RFC006 chapter 4;

The service identifier MUST be constructed from the DID followed by a #, the service type, a - and an identifier unique to the DID document.

See https://blog.golang.org/go1.16

• Replace bindata with 1.16's fs.Embed

Applications (like the registry) can subscribe to specific document types on the network. Then the network engine will call the receiver func. when a document is received. The current implementation is very naive however;

• It's not persistent, meaning if the server crashes halfway some documents may not be received by the subscriber
• It's not ordered, so subscribers will receive documents out-of-order at some point
• It's not retryable, so error'd documents will never be retried by the application.

This needs a better solution.

After #69 has been merged, we can resolve organzations names to include in Nuts Auth contracts instead of the dummy name resolver we currently have.

Endpoints are specified in the DID Documents. The RFC describes the use of compound endpoints to use endpoints from another DID document. This needs to be supported by Nuts Auth.

And implement DIDs according the new updated RFC003 at the same time.

Now there's no way to determine what version a running node has. It would be convenient if it was displayed on the status page and logged on node startup;

• Git branch that the build was made from
• Git commit ID
• Build time(?)
• Git tag (for identifying releases?)

Currently CORS is enabled for all endpoints (because appearantly nuts-auth needs it?), but this could lead to security vulnerabilities. We need to decide which endpoints really need it and just enable it on those. Maybe using the new HTTPConfig configuration options.

Which can handle error message format and logging.

See https://echo.labstack.com/guide/error-handling

types.VDR and vdr.VDR

• can't the impl be private?
• or change naming

make up our minds on returning nil, nil or nil, ErrNotFound when nothing is found.

Currently not implemented, because we have no consents in the new system yet.

We now have 1 type of config (core/engine) which is loaded for both CLI and server, which creates ambiguity. This should be separated; the CLI should have specific flags (e.g. remote server address, time-outs) which are specific for the invocation of CLI and the server config shouldn't include these CLI-specific flags.

Now disabled, after migration (auth/services/contract/notary.go:84)

Appearantly not used.

awful code

https://github.com/knadh/koanf might be an (lightweight) alternative to viper

Should return the diagnostics of the remote server

we now have v0/v1/experimental

let's merge back into 1

This is a tracking issue

• implement concept mapping structure #69
• add NutsOrganizationCredential #100
• update documentation
• search API #131
• implement issuing #100
• implement revocation #130
• implement resolving #125
• connect to network #127
• keep in line with RFC011 and RFC012
• embed templates using go1.16 #100
• add config params for trusted issuers #149
• CLI #173

instead of Var

See https://medium.com/@smyrman/writing-constant-errors-with-go-1-13-10c4191617