Manage Collaborators#
A collaborator has access to a space and the objects stored within it.
A person can be invited to join a space as a collaborator, or if his Skalio ID is known, he can be directly assigned to it. A collaborator can leave a space again, or he can be removed from it.
Invitation of new collaborators#
A space collaborator can invite other persons to collaborate with him in a space, provided he has the required admin privilege. The server will then prepare an invitation that is valid for a short period of time. An invitation contains a shared secret and must be accepted by presenting the secret before it expires. This completes the process; the invited person is now a collaborator.
The invitation itself takes the form of a URL, containing the shared secret. The inviter can request the invitation to be sent via email, in which case he has to provide a notification address of the invitee. Alternatively, he must take responsibility for the delivery of the invitation via other channels, for example instant messaging. When a new invitation matches an existing invitation by space and notification address, the new invitation replaces the previous one.
Note: The email address used in the invitation does not have to match any email address associated with the person in Skalio ID. It is simply a means to deliver the invitation.
An invitation can contain a note to the invitee as well as a reference text only visible to space administrators. This reference helps administrators to later understand who they invited, when, or why, and by what means.
An invitation can be accepted only once, by one person only. When accepting an invitation, the invitee must present his ID token, or sign-up at Skalio ID to obtain one. At this point, the server will clear the invitation and associate the person with the space as a collaborator. The optional administrators reference text from the invitation is transferred to the collaborator.
The invitation timeline is recorded in the statistics of a collaborator.
The administrators reference text can be edited by any space administrator.
Resolving information about the inviter#
An invitation contains the uid of the person who issued it, the inviter. The new collaborator can fetch the information about this person by requesting the public profile for the inviterUid at Skalio ID (api doc). Since this request must be authorized by a uidToken, the request for public information of an invitation provides such a token.
Note: the provided uidToken is very short lived and shall not be cached. It shall only be used to authorize requests for the public profile or avatar of the inviter. A new token is generated with every request.
List open invitations#
Space administrators can view the list of open invitations and cancel individual invitations. Expired invitations are removed automatically.
Assign new collaborators#
A space administrator can assign existing Skalio ID persons to be collaborators of a space. This process is more specific than inviting someone, since
- the collaborator must already have a Skalio ID,
- which the space administrator selects as the new collaborator.
The Skalio ID of a person can be found by searching the public Skalio ID directory. Identity can be confirmed through the persons public information (name, avatar, selected email addresses) or his fingerprint.
When assigning a collaborator to a space, the administrator can provide a reference text only visible to other administrators of the space. This reference helps administrators to later understand who they assigned, when, or why.
The newly assigned collaborator is in a pending state until he confirms the action. He is notified of the space assignment via his preferred notification channel. Typically, a message is sent to the primary email address of the assigned person. The message contains the name and description of the space and a URL to the space details. It does not include a personal note or a shared secret (compared with an invitation message).
After authenticating, a person can see the "pending collaborator" state in his list of accessible spaces.
Assigned collaborators stay in "pending" state indefinitely until they either accept or reject the assignment. While in pending state, the assigned collaborator can only view the description, name and avatar (Note: avatar currently requires an access token!) of the space, but not access any data stored in it.
The assignation timeline is recorded in the statistics of a collaborator.
Rejecting an assignment permanently removes it. This action is not recoverable.
API mapping#
| Usecase | API interaction | Comment |
|---|---|---|
| List assignments | Fetch list of spaces | These actions require an ID token, but no access token for individual spaces. |
| Accept assignment | Request access token for space | Implicitly converts a pending collaborator into a collaborator. |
| Reject assigment | Reject access token for space Note: not yet implemented! |
Explicitly removes a pending collaborator. Has no effect if the person is not a pending collaborator. |
Organization admin override#
Persons with organization admin privileges on the organization of the space can execute this operations without being a space administrator first.
Note: Not yet implemented
Update or remove collaborators#
Any person can remove himself as a collaborator of a space.
Any space administrator can change the privilege of existing or pending collaborators, or remove the collaborator completely from the space.
Removing collaborators can lead to abandoned spaces, or spaces without administrators. Such cases can be recovered by an organization-admin who can assign collaborators again.
List collaborators, invitations, spaces#
Collaborators of a space can fetch a list of all other collaborators and their privilege on the space.
For space administrators, this list includes pending collaborators, invitations and the respective administrators reference text.
Note: Since Spaces does not manage a persons profile information, the list contains only references to the persons behind each collaborator in the form of the
personUid. This unique ID can be used to lookup the public profile of the person at Skalio ID.
Similarly, a person can list all spaces he is a collaborator of. This includes pending space assignments, which need to be confirmed by the person.
Restrictions on unverified persons#
A person must prove to Skalio ID that he has control over his registered email addresses (and possibly other means of public identification). Until at least one of the addresses has been confirmed, he is considered not verified. This is the case right after a person has signed up to Skalio ID.
Until the person has verified his Skalio ID, he is barred from interacting with other people. As a result, an unverified person cannot
- invite other persons to collaborate on his space,
- accept an invitation to collaborate on another space,
- assign collaborators to his space,
- accept an assignation to collaborate on another space.
Other functionality is not affected.