Improve Co-Registrations

[silkroadnomad]

The user (Peter) which receives a DOI-Request should be informed about the fact that he gives the DOI to more then one email address (and other information)

e.g. 1) Doi-Sender Email(s) 2) Doi-Recipient Email 3) Link to nameID on a DOI explorerer where DOI(s) are stored (the dApp needs a "wallet" function which show's any DOI when querying a nameId. The NameId should be given by a query parameter. 4) additional data? 5) expiration date of DOI

See: https://github.com/Doichain/dapp/issues/9

[silkroadnomad]

Should be done or discussed with #54

Remark: When we send out a DOI-Request-Email it contains by default the {{confirmationLink}} tag which gets parsed and replaced with the correct confirmation link. I suggest to invent a new tag {{doiInformation}} which displays the above mentioned data in a standard layout.

In case {{doiInfomation}} is not given in the template (e.g. accidentally forgotten) I suggest to print this information anyways just below {{confirmationLink}}

We can discuss the necessity of styling each information line separately.

I could even imagine to design a special "Doichain" seal like https://business.trustedshops.co.uk/

[silkroadnomad]

Remark: When developing "Multiple-Validators" it appears that an email will be sent from hosts which we might not trust. Such hosts could record sender and receiver and abuse this data for othe r commercial (or even worse) use.

Which means: Above stated requirement will be very difficult to develop since those data could be stored and abused on the acting validator.

We should discuss the possibilities:

• encrypting & decrypting confidential data in the DOI-Request email (e.g. with a second decryption email from Alice which stores a decryption key in e.g. localstorage when first email trys to decrypt confidential data)
• completely changing the DOI-procedure e.g. Sending only a standard DOI-Request email from Bob and another classic "Welcome email" from Alice