Introduce GRANTEE_TYPE_MAIL

[aduffeck]

This grantee type will be used for sharing with "guests" via their email address, e.g. by implementing a magic link auth pattern.

[glpatcern]

Hello @aduffeck, we implement this by sharing to a User, whose type is guest or one of those: https://github.com/cs3org/cs3apis/blob/main/cs3/identity/user/v1beta1/resources.proto#L117-L122 - which includes more options. Wouldn't that fit your needs?

[aduffeck]

@glpatcern we gave it some more thought and the guest user type should indeed work for us, thanks.

[glpatcern]

OK, thanks Andre. The "funny" thing is we also discussed in our team and we could have a use-case where your proposal would fit! Imagine you want to create a share to a prospected user who didn't register with the IdP yet: you'd create a share to an email address, the recipient would get a link to register, and then the share might get converted to have a regular user as grantee.

[rhafer]

OK, thanks Andre. The "funny" thing is we also discussed in our team and we could have a use-case where your proposal would fit! Imagine you want to create a share to a prospected user who didn't register with the IdP yet: you'd create a share to an email address, the recipient would get a link to register, and then the share might get converted to have a regular user as grantee.

@glpatcern Hm, now I am bit confused. Isn't that what USER_TYPE_GUEST is for? At least the comment in the spec says:

// A guest user not affiliated to the IDP.
USER_TYPE_GUEST = 5;

Please clarify.

[glpatcern]

Right, let's expand a bit: in our IdP, we have external users that can register as guests, and yet they are part of the IdP. So if we were to stick to OIDC tokens minted by the IdP we would not have an option for users that are not registered.

But I'd argue that we do mint Reva tokens for external users, we do that for OCM for example, so we can definitely mint a Reva token including a user with type GUEST that would fit that use case without a "guest grantee".

Conclusion: minting Reva tokens is a valid and already given assumption, therefore let's use the User types as initially suggested.

cc @jessegeens