Wire up grpc server with empty service implementations about openboard HOT 2 CLOSED

Requesting a voucher will result in an email being sent out with a token that can be used within a certain window of time in order to do things like confirm an email address or update a password. This allows the auth portion of the code to focus on authentication and the user portion of the code to focus on user data. They then "interact" in the authorization layer (likely to be called "user access control(ler)".

For example:

1. Request new User
2. Receive valid User response with "hold" placed on sensitive field values
3. Request Voucher using an email field
4. Receive valid Voucher response (indicating the caller should check the provided email address inbox)
5. Check for Token by email
6. Request update to User with hold removed (limited by email address in Token) before expiration
7. Receive valid User response with field values set correctly

I suspect that we'll be able to add an "input token" and "token" field to the Voucher request/response messages to enable programmatic third-party authentication (e.g. github, google). This would allow the user to do something like:

1. Request Voucher using a "third-party token" field
2. Receive valid Voucher response (with Token)
3. Request new User without hold set (limited by email address in Token) before expiration
4. Receive valid User response with field values set correctly

from openboard.

What is a Voucher?

from openboard.