With this endpoint you can create a use.id account and WebID.

Plain vanilla account

By default, each use.id account that is created via this endpoint will be configured as follows:

  • The user will receive a WebID in the form of use.id/{username} or sandbox.use.id/{username}.
  • The profile document of the user is located at use.id/{username}/profile or sandbox.use.id/{username}/profile.
  • The user will receive an account at our identity provider
  • The user will have this identity provider added to his or her profile document
  • The user will receive a space on our storage
  • The user will have this storage space added to his or her profile document
  • The user will have the use.id authorisation agent added to his or her profile document
  • The user's WebID will receive read, write and control access in the root of its storage space. Only the use.id app's WebID will have control access.
  • The WebID profile document will be public. Only the use.id WebID will have write and control access to the profile document.

Attention: we urge you not to read from or write data to a container on which the user's WebID has read or write access (e.g. the root container). Remember: any app could use the user's access token to authenticate into the user's WebID as if it were the user. This means that if you would use storage on which the user has access rights, the data your app writes to this storage can be accessed by any other app in which the user authenticates. Instead, we strongly encourage you to rely on the use.id access request or access needs mechanism and not to give the user's WebID any access to the data your app writes to the user's storage (indeed: not even read access!).

Non-plain vanilla account

If you are a use.id customer, you have the possibility to create accounts that deviate from the plain-vanilla configuration. In order to do this, you might be required to fulfil several other requirements (such as agreeing with certain policies - ask your Digita representative for more information).

Currently, if you have the right permissions, you are able to do the following:

  • Circumvent the access request screen by providing the access needs of your application straight away
  • Add an additional identity provider.

Providing an access need group

Normally, if you want to read and write data to the storage location of the user to which only the WebID of your app has access to (and not necesarily the user), you would need to create an access request and have it exchanged.

However, in this case, the user would be prompted with an extra screen in which he or she has to approve the accces request.

To avoid this extra step in the user experience, we provide a selected group of customers with the opportunity to add the access need group of the app. When this access need group is added to the request, the result would be the same as if an access request has been created and approved:

  • The user will have a container in its storage space uniquely for the app that has created the account. The name of this container is the SHA256 hash of the WebID of the app that sent the request to this endpoint, including trailing slash. For example, suppose My Move has sent a request to this endpoint on the sandbox environment, the name of the container is 6ab2f7282267417f83cc1088c8f503a80a030e16b851c3bb2f28e92580117325 (i.e. the SHA256 hash of https://webid.my-move.app/). Attention: if your app has a different sandbox WebID, the container that will be created on the sandbox environment will also have a different name!
    • The WebID of the app that used endpoint will have read and write access to this container
    • The WebID of the use.id app will have read, write and controll access to this container
    • The WebID of the user will have no access to this container
  • Within this container, for each access need in the access need group, we will create a container for each shape tree.
    • Each container will be named as the fragment of the shape tree URI.
    • Each container will receive the access rights as defined in the access needs.
    • The WebID of the use.id app will have read, write and control access on each container.

Adding other items to the WebID profile document

Each use.id account will have the use.id identity provider and a use.id storage included in its profile document. This endpoint also enables you to add other items (such as another identity provider) to the use.id WebIDs that you create (if you have the right permissions).

Click Try It! to start a request and see the response here!