OCM-API
OCM-API copied to clipboard
Why are email address and name required in Invite Acceptance Request/Response?
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?
If they are required for something in particular then we should describe how they are used
I cannot think of a reason for any of them to be required.
They are used for:
- searching through your contacts in EFSS while sending a share
- Contacts page
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?
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.
They are used for:
searching through your contacts in EFSS while sending a share
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.
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.
This was eventually resolved in #148