jorabin / derec-tests Goto Github PK

The notifications should be changed so that there is a parent interface DeRecStatusNotification, and then each particular type of notification is an interface that extends the parent interface. The reason for this is that the current implementation with an enum is not extensible by implementations (because they can't add to an enum, but they could add more classes).

The parent should have a method getType which returns an enum from {NORMAL, WARNING, ERROR}.

All of the methods that are currently in the interface are kept.

With the comment:

/**
 * Information about a helper or sharer. This information is not tied to a specific secret.
 */

hence does not try to pair. Update documentation on other overloaded methods that make it clear that they do try to pair with the nominated helpers.

String Encoded PEM

The package org.derecalliance should contain:

• org.derecalliance.derec.interface for API (the interface files)
• org.derecalliance.derec.protobuf for Java files created from the protobuf
• org.derecalliance.derec.cryptography for cryptography library

Those files should all have their copyright assigned to the Alliance, once it exists officially.

Helper notifications:
Ideally we want to know:

• When Helper is paired (successfully or unsuccessfully) - defined as AVAILABLE or NOT AVAILABLE, and
• Whether they are responding to verification messages or not (HEALTHY or NOT HEALTHY).

In DeRecStatusNotification, we should add notifications for when a helper is available/not available, and a helper is healthy/not healthy.

Pairing notifications:

• During pairing, one would want to know that the person they are pairing with is in recovery mode, to help them be extra vigilant about who they are pairing with. A notification should be added to accommodate that.

Recovery notifications:

• We should have a notification for sharer when the secret has been recovered.

The API should have a notification registration, where the app passes a lambda that takes one parameter: the notification. The comments should say that this might throw a UnsupportedOperationException if the library implemented some other form of message passing.

this is potentially best expressed as crating a new Version, where it's the version that has the description rather than the secret.

and make it an interface

Make the secretId a byte array rather than a UUID class. There should be a comment that says it must be 1 to 16 bytes in length, and must be unique among all secrets for a given sharer.

to describe the success of the last update to the secret

this would be removeHelpersAsync() and closeAsync()

Use creative powers to come up with a name that describes the role of the class as being "the representation at the sharer of a helper".