Use cases

Background

Alice is a researcher at a lab and she is in the process of starting a new project. She is trying to recruit people to join her research team to work on her new project. Alice thinks that her friend Bob who is a researcher at a different lab might be interested in joining her team.

Use case A - Alice wants to invite Bob to join her Synapse team.

...

Use cases

Background

Alice is a researcher at a lab and she is in the process of starting a new project. She is trying to recruit people to join her research team to work on her new project. Alice thinks that her friend Bob who is a researcher at a different lab might be interested in joining her team.

Use case A - Alice wants to invite Bob to join her Synapse team.

Workflow

Mockups

Use case B - Alice wants to invalidate the invitation she sent previously.

Workflow

Mockups

Use case

...

C -

...

 Bob wants to

...

Alice wants to invalidate the invitation she sent previously.

...

1. Alice has sent an email invitation to Bob.
2. Bob hasn't accepted the email invitation yet.

...

Workflow

...

...

Step 1. Alice retrieves the pending invitations to her team and removes the one associated with Bob.

Step 2. System invalidates the invitation link sent to Bob.

Mockups

Use case C - Bob wants to create a Synapse account and accept Alice's invitation.

Sub use case C1 - Bob wants to create a Synapse account using the same email address to which Alice sent the email invitation.

Sub use case C2 - Bob wants to create a Synapse account using a different email address, not the one to which Alice sent the email invitation.

...

Bob wants to create a Synapse account and accept Alice's invitation.

...

Primary actor

...

Bob

...

1. Alice has sent an email invitation to Bob.
2. Bob doesn't have a Synapse account.

...

Workflow

...

Step 1. Bob clicks on the invitation link in the email he received and is directed to the Synapse web client.

Step 2. The web client presents Bob with the option to create a Synapse account or sign in with an existing account.

Step 3. Bob creates his new Synapse account.

...

create a Synapse account and accept Alice's invitation.

Sub use case C1 - Bob wants to create a Synapse account using the same email address to which Alice sent the email invitation.

Sub use case C2 - Bob wants to create a Synapse account using a different email address, not the one to which Alice sent the email invitation.

Workflow

Mockups

Use case D - Bob wants to sign in to his existing Synapse account and accept Alice's invitation.

Sub use case D1 - Bob wants to sign in to his existing Synapse account which is associated with the same email address to which Alice sent the invitation.

Step 5. The web client prompts Bob to verify that he owns the above email address by clicking the link in the verification email.

Step 6. Bob clicks on the verification link and is directed to the Synapse web client.

Step 7. The web client displays Alice's invitation to Bob.

Step 8. Bob accepts Alice's team invitation.

Step 9. System sends a notification email to Alice saying that Bob has joined her team.

Mockups

Use case D - Bob wants to sign in to his existing Synapse account and accept Alice's invitation.

Sub use case D1 - Bob wants to sign in to his existing Synapse account which is associated with the same email address to which Alice sent the invitation.

Sub use case D2 - Bob wants to sign in to his existing Synapse account which is not associated with the email address to which Alice sent the invitation.

...

Bob wants to sign in to his existing Synapse account and accept Alice's invitation.

...

Primary actor

...

Bob

...

1. Alice has sent an email invitation to Bob.
2. Bob has one or more Synapse accounts.

...

Workflow

...

...

Sub use case D2 - Bob wants to sign in to his existing Synapse account which is not associated with the email address to which Alice sent the invitation.

Workflow

Mockups

Use case E - Bob wants to create a new Synapse account but doesn't want to accept Alice's invitation yet.

This use case is covered by use case C.

Complete workflow diagram

Image Removed

Security concerns

Guaranteeing the security of our users' data is a top priority. Inviting a person to join your team is effectively giving that person access to all the data contained in all the projects your team has access to. This means that inviting someone through email inherently carries some risk.

Consider the following scenarios that could result in data breaches:

• Alice sends an email invitation to join her team to Bob, granting him access to the data accessible by Alice's team. However, Bob forwards his invitation to Claire. Now Claire has access to all the data Bob was supposed to have access to. Alice may not have intended for this to happen.
• Alice makes a typo when typing Bob's email address, sending it to some other (existent) email address.

In order to protect our users from these types of situations, we could make the following design decisions:

• Inform our users of the risks in the email invitation widget.
• Require the user to type the recipient email address a second time for confirmation.
• Allow the user to invalidate pending invitations.
• Make all invitation links single-use. Also, make them expire after a certain period of time. This prevents a malicious person from using an invitation link they found in an email inbox they hacked.
• Require the consumer of the invitation link to prove that they are the owner of the email address to which Alice sent the email invitation, i.e. prove that they are Bob.
  We can do this by sending a verification email to Bob's email address when the invitation link is used.

Proposal

Option 1

Models to implement or modify

...

inviteeEmail

teamId

createdBy

id

...

emailMembershipInvitationId

timestamp

hmac

...

results - ARRAY<EmailMembershipInvitation>

nextPageToken

...

email

timestamp

hmac

emailValidationSignedToken

emailMembershipInvitationSignedToken (optional)

...

inviteeId

emailMembershipInvitationId

timestamp

hmac

...

firstName

lastName

emailValidationToken

emailValidationSignedToken

username

password

...

email

lastName

firstName

userName

EmailMembershipInvitationSignedToken (optional)

Services to implement or modify

Mockups

Use case E - Bob wants to create a new Synapse account but doesn't want to accept Alice's invitation yet.

This use case is covered by use case C.

Complete workflow diagram

Image Added

Security concerns

Guaranteeing the security of our users' data is a top priority. Inviting a person to join your team is effectively giving that person access to all the data contained in all the projects your team has access to. This means that inviting someone through email inherently carries some risk.

Consider the following scenarios that could result in data breaches:

• Alice sends an email invitation to join her team to Bob, granting him access to the data accessible by Alice's team. However, Bob forwards his invitation to Claire. Now Claire has access to all the data Bob was supposed to have access to. Alice may not have intended for this to happen.
• Alice makes a typo when typing Bob's email address, sending it to some other (existent) email address.

In order to protect our users from these types of situations, we could make the following design decisions:

• Inform our users of the risks in the email invitation widget.
• Require the user to type the recipient email address a second time for confirmation.
• Allow the user to invalidate pending invitations.
• Make all invitation links single-use. Also, make them expire after a certain period of time. This prevents a malicious person from using an invitation link they found in an email inbox they hacked.
• Require the consumer of the invitation link to prove that they are the owner of the email address to which Alice sent the email invitation, i.e. prove that they are Bob.
  We can do this by sending a verification email to Bob's email address when the invitation link is used.

Proposal

Models to implement or modify

Services to implement or modify

Related services: POST /account, POST /session

Option 2

Models to implement or modify

...

membershipInvitationId

timestamp

hmac

...

email

timestamp

hmac

...

inviteeId

membershipInvitationId

timestamp

hmac

...

emailValidationSignedToken

membershipInvtnSignedToken (optional)

...

createdOn

message

id

createdBy

expiresOn

inviteeId

teamId

inviteeEmail

...

firstName

lastName

emailValidationToken

emailValidationSignedToken

username

password

...

email

lastName

firstName

userName

membershipInvtnSignedToken (optional)

Services to implement or modify

...

Create a membership invitation. The team must be specified. Either an inviteeId or an inviteeEmail must be specified.

If an inviteeEmail is specified, send an email containing an invitation link to the invitee. The link will contain a serialized MembershipInvtnSignedToken.

...

acceptInvitationEndpoint (optional)

notificationUnsubscribeEndpoint (optional)

...

Existing

...

Start the process of creating a new account, and optionally also the process of associating a membership invitation to the new account.

Send a 'validation email' message to the provided email address. The email will contain a link to complete the registration process.

The link will contain a serialized AccountCreationToken.

Intended to be used in conjunction with POST /account.

...

/account/emailValidation

...

portalEndpoint

...

Verify whether the inviteeEmail of the indicated MembershipInvitation is associated with the authenticated user.

If it is, the response body will contain an InviteeVerificationSignedToken.

If it is not, the response body will be null and an identity verification email containing a link will be sent to the inviteeEmail of the indicated MembershipInvitation. The link will contain a serialized InviteeVerificationSignedToken.

This call will only succeed if the indicated MembershipInvitation has a null inviteeId and a non null inviteeEmail.

...

New

...

Set the inviteeId of a MembershipInvitation.

A valid InviteeVerificationSignedToken must have an inviteeId equal to the id of the authenticated user and an membershipInvitationId equal to the id in the URI.

This call will only succeed if the indicated MembershipInvitation has a null inviteeId and a non null inviteeEmail.

...

Statistics to track

• Which users create invitations, when they create them, and from what teams they create them.
  • These statistics are captured by the MembershipInvitation (formerly MembershipInvtnSubmission) model, which is stored in the database.
• How many invitations are accepted and when they are accepted.
  • There is no easy way to track when the invitation to the team is accepted, but we can know how many times the invitee will use the email link to create a new account or sign in to their existing account. This is essentially the number of times that PUT /membershipInvitation/{id}/inviteeId is called.
• How many invitees choose to register a new account and how many choose to sign in.
  • We know the total number of membership invitations created from the number of POST /emailMembershipInvitation/{id}/membershipInvitation requests.
  • We know the total number of invitees who chose to register a new account from the number of POST /emailMembershipInvitation/{id}/account/emailValidation requests.
  • We can derive the total number of invitees who chose to sign in with an existing account from the above two numbers.
• We can know how often invitees attempt to sign in using an email address that is not associated with the inviteeEmail of the MembershipInvitation by looking at how often GET /membershipInvitation/{id}/inviteeVerificationSignedToken calls respond with 403 status.

Implementation outline

Phase 1

I expect that in most cases, invitees will choose to sign in or register with the invited email address. I'll refer to this as the "happy" case.

In phase 1 I will implement use cases A, B, C1, D1 and E. These use cases represent the happy case.

Phase 2

There will be some invitees that want to sign in or register with a different email address. I expect that the number of users who choose this path will be low enough that this will be an edge case.

In phase 2 I will implement use cases C2 and D2. These use cases represent the edge case described above.

Progress

Phase 1

Create new models

•  MembershipInvtnSignedToken
•  EmailValidationSignedToken
•  InviteeVerificationSignedToken
•  AccountCreationToken

Update existing models

•  MembershipInvtnSubmission
•  AccountSetupInfo
•  NewUser

Update existing services

•  POST /membershipInvitation
•  POST /account/emailValidation

Create new services

•  POST /membershipInvitation/{id}
•  POST /membershipInvitation/{id}/verification
•  PUT /membershipInvitation/{id}/inviteeId

...

Related services: POST /account, POST /session

Statistics to track

• Which users create invitations, when they create them, and from what teams they create them.
  • These statistics are captured by the EmailMembershipInvitation model, which is stored in the database.
• How many invitations are accepted and when they are accepted.
  • There is no easy way to track this.
• How many invitees choose to register a new account and how many choose to sign in.
  • We know the total number of membership invitations created from the number of POST /emailMembershipInvitation/{id}/membershipInvitation requests.
  • We know the total number of invitees who chose to register a new account from the number of POST /emailMembershipInvitation/{id}/account/emailValidation requests.
  • We can derive the total number of invitees who chose to sign in with an existing account from the above two numbers.

Implementation outline

Phase 1

I expect that in most cases, invitees will choose to sign in or register with the invited email address. I'll refer to this as the "happy" case.

In phase 1 I will implement use cases A, B, C1, D1 and E. These use cases represent the happy case.

Phase 2

There will be some invitees that want to sign in or register with a different email address. I expect that the number of users who choose this path will be low enough that this will be an edge case.

In phase 2 I will implement use cases C2 and D2. These use cases represent the edge case described above.

Progress

Phase 1

Create new models

•  MembershipInvtnSignedToken
•  EmailValidationSignedToken
•  InviteeVerificationSignedToken (Not merged yet)
•  AccountCreationToken

Update existing models

•  MembershipInvtnSubmission (Not merged yet)
•  AccountSetupInfo
•  NewUser

Update existing services

•  POST /membershipInvitation (Not merged yet)
•  GET /membershipInvitation/{id} (Not merged yet)
•  POST /account/emailValidation

Create new services

•  POST /membershipInvitation/{id}/verification (Not merged yet)
•  PUT /membershipInvitation/{id}/inviteeId

...

Update web client

•  Make everything work

Sequence of events

Image Added

Made on https://sequencediagram.org/ with the following markup:

entryspacing 0.9
Frontend->Backend:Invite the new user (POST membershipInvitation)
Backend->OUT OF BAND: Send email that contains MembershipInvtnSignedToken
OUT OF BAND->Frontend: User clicks Join link in email
Frontend->Backend:Get corresponding membershipInvitation (POST membershipInvitation/id)
Backend-->Frontend:Membership Invitation
note over Frontend,Backend:Already has an account
Frontend->Frontend:User clicks "Already have an Account?"
Backend->OUT OF BAND
OUT OF BAND->Frontend
Frontend->Backend: Login
Backend-->Frontend:Successful Login
Frontend->Backend:GET membershipInvitation/id/inviteeVerificationSignedToken
Backend-->Frontend:Return InviteeVerificationSignedToken
Frontend->Backend: Update invitation with user id: PUT /membershipInvitation/{id}/inviteeId
Backend-->Frontend:
Frontend->Frontend: User sent back to the Team page. Single click Join (since there's an open invitation)
note over Frontend,Backend:New account
Frontend->Frontend:User click "Send Registration Info"
Frontend->Backend:POST/account/emailValidation
Backend->OUT OF BAND: Send validation email
OUT OF BAND->Frontend: User clicks create account link
Frontend->Backend:Standard account creation (sign ToU...)
Backend-->Frontend:Standard account creation
Frontend->Frontend: User sent to associated Team page. Single click Join (since there's an open invitation)

Related JIRA issues