OCM-API icon indicating copy to clipboard operation
OCM-API copied to clipboard

Why are email address and name required in Invite Acceptance Request/Response?

Open michielbdejong opened this issue 1 year ago • 2 comments

It would make more sense to me if only recipientProvider, token, and userID were required, and the other two were optional, since they don't influence the flow and meaning of the protocol, right?

michielbdejong avatar Sep 05 '24 12:09 michielbdejong

If they are required for something in particular then we should describe how they are used

michielbdejong avatar Sep 05 '24 12:09 michielbdejong

I cannot think of a reason for any of them to be required.

They are used for:

  1. searching through your contacts in EFSS while sending a share
  2. Contacts page

MahdiBaghbani avatar Sep 05 '24 12:09 MahdiBaghbani

I must say I had missed this issue a month ago, and rediscovered it following #143.

IMHO the Invite flow is like a business card exchange among persons, and it would be awkward to not disclose full names and email addresses. In Reva (and ScienceMesh) we made them required. What is the reason NOT to have them required?

glpatcern avatar Sep 30 '24 15:09 glpatcern

As an implementer of the invitation workflow the business card exchange comparison speaks to me, I like it. Also, leaving out personal info such as name, email would complicate handling the invitation as you still would want (need) to make the user discoverable as a contact.

redblom avatar Oct 02 '24 15:10 redblom

They are used for:

  1. searching through your contacts in EFSS while sending a share

  2. Contacts page

To be honest, those are exactly the reasons why those fields ought to be required, otherwise how do you implement a GUI to search through your federated contacts?

Sure enough, if an EFSS user provided a "fake" identity, that identity will be distributed as is - pretty much like we use GitHub handles or avatars or the like. But at least it's a user-friendly and searchable identifier.

glpatcern avatar Oct 02 '24 15:10 glpatcern

I agree with the

Also, leaving out personal info such as name, email would complicate handling the invitation as you still would want (need) to make the user discoverable as a contact.

To be honest, those are exactly the reasons why those fields ought to be required, otherwise how do you implement a GUI to search through your federated contacts?

So OCM spec keeps everything in the invite flow required and lets the vendors decide how to provide the info if the user didn't provide it to the vendor itself.

MahdiBaghbani avatar Oct 02 '24 16:10 MahdiBaghbani

This was eventually resolved in #148

glpatcern avatar Oct 17 '24 09:10 glpatcern