Motivation and overview

We need a mechanism for users to create an account for an identity and an account for a Pod, potentially with an identity provider that is different from the pod provider. Hence, we propose the introduction of a uniform registration endpoint.

There is currently nothing in the spec to enforce a uniform registration endpoint exposed by Pod Servers (PS). In order to ensure a consistent user experience in the ecosystem, it would be beneficial that any Identity Provider (IdP) can provision an account for a user on any PS in a uniform manner.

To be specific, the registration process is the process through which a user goes when creating a new identity, which typically means roughly following the following interaction diagram (in the current ecosystem):

The end goal of this process is for the user to be granted with (details about all this in the following sections):

• An IdP account
• Resources backing this account on the PS (e.g. a profile document stored in a Pod)
• Appropriate permissions for the resources in the newly created Pod

This issue aims at fostering discussion around this process. It specifically aims at onboarding new, non-technical users, which is why the assumption is made that the user does not have a prior WebID, and cannot be required to take any steps to manually edit and/or publish an RDF document on the web.

Depiction of the current process

This description details what happens in steps A, B and C of the interaction diagram in a current implementation of a Pod Provider not embedding its own IdP.

Current assumptions

• There is a trust relationship between the IdP and the PS:
  • The IdP knows which PS it should register to, and the IRI of the registration endpoint relative to the PS IRI (e.g. /register) .
  • The IdP is known by the PS, and it is authorized to call the registration endpoint by issuing an Authentication token identifying a Registrar Agent with special access rights authorizing it to create resources and hand them to the user.

The trust relationship from the IdP to the PS is I more of an implementation detail coming from the original lack of separation between IdP and PS in NSS. The trust from the PS to the IdP is introduced as a security mechanism, to prevent flooding the PS with registration requests. Any request on the register endpoint which is not authenticated with a token identifying a Registrar user recognized by the PS rejected as '401 Unauthorized'.

A - Registration request

POST request with Content-type: application/x-www-form-urlencoded, the form containing username: <myUsername>, and authenticating thanks to a bearer token Authorization header. The token is a JWT with a WebId as a subject claim. This WebId identifies the IdP, and is authorized by the PS to register a new user. Currently, there is an assumption that a trust relationship exists between the IdP and the PS, materialized by a Registrar Agent (i.e. an admin user) recognized by both. The IdP can create an Authorization token for this Registrar Agent, and it is the only credential that is allowed to call the registration endpoint.

This request triggers the next step.

B - Registration process from the PS

• A profile document is created, pointed to by the user WebID
• A hierarchy of containers is created (e.g. public/private directories, type indexes, etc.)
• The user WebID is given Read, Write and Control access to the created resources

At the end of the registration process, a status code 200 OK is returned.

C - Giving access to the “registering” app

This step aims at ensuring the app which initially redirected the user towards the IdP has access to the created resources. Currently, it is achieved through a hard-coded PATCH request adding a SDK generated app to the trusted apps. This request is performed with an Authorization token identifying the admin recognized by both the IdP and the PS (i.e. the Registrar Agent). This is useful for demonstration purposes, but should not be part of the spec.

There is ongoing work to find a replacement to the trusted app mechanism in a dedicated panel, and clarity on this track will be required before pursuing this part of the registration process further.

Elements up for discussion

These are the elements identified in the previous paragraph that should be made explicit by the spec.

Mitigating the identified assumptions

• The IdP should not make assumptions regarding the PS. This would require UI work (which is outside of the scope of the spec I believe) to help the user select an appropriate PS. This means, however, that the IdP should be able to discover the PS registration endpoint. This could be done for instance through a Link header.
• Should the protection mechanism for the registration endpoint on the PS side be part of the specification ?

A - Registration request

Instead of the IdP POSTing a form to the PS, would it be possible/desirable to redirect the user to a registration page managed by the PS ? This could add flexibility to the registration process, as different PS may expect different information when creating a user account, and therefore making a spec decision about the form that should be POSTed will constrain implementation choices. However, I'm not sure of the consequences regarding security/trust.

B - Registration process

Most of the details for this will be left to implementation, at least initially.

• Desirable post-conditions:
  • A valid profile document MUST exist and be hosted by the PS
  • A hierarchy of containers MAY have been created, including but not limited to type indexes, public/private containers, a setting container, etc.
  • All the created resources MUST have appropriate ACLs attached, with the user WebId having READ, WRITE and CONTROL access.
• What should be returned to the IdP ?
  • If the registration request is changed to a redirection, then the completion of this process should redirect back to the IdP, with a link to the created profile document.
  • If the registration request is kept the way it is, a “201 Created” response seems appropriate.
• In the future, it would be interesting to be able to provision Pods in a fully automated way, with no user involvement. Generally, it is an issue that provisioning a Pod is only considered when creating a Profile Document, which suggests a tight coupling between one Pod and one user in particular, which is untrue. For this, a more complete Pod provisioning API would be required.
  • This API will require some WebID as an input to initialize access rights, and therefore it may be used to support the registration process, but it should not conflict with it, so in the short-term I think it is safe to focus on user registration, which is likely to be a more urgent requirement.

C - Giving access to the “registering” app

• If a user registers a new account through an app, should this app have specific access rights by default ?

Appendix

This is the markup for the sequence diagram:

participant User
participant App
participant IdP
participant PS

note over User, App: The user is not authenticated and is not registered to the IdP.
User -> App: Tries to log in
App -> User: Redirects/Pop-up (solid-auth-client)
note over User, App: The user interacts with the IdP to create an account.
User -> IdP: Starts creating an account
IdP -> User: Redirects to the account creation page
User -> IdP: Fills in the account creation form
note over IdP, PS: The IdP interacts with the PS authenticated as the Registrar Agent.
IdP -> PS: Registration request (A)
activate PS
note left of PS: Performs registration\n (B)
PS -> IdP: 200 OK
deactivate PS
IdP -> PS: Gives access to the "registering" app (C)
PS -> IdP: 200 OK
IdP -> App: Redirects (HTTP 302) to the created profile document
note over User, PS: The user now interacts with the App, which makes requests to the PS with the user Auth token supplied by the IdP.
User -> App: Clicks 'n stuff
App -> PS: Authenticated access
PS -> App: Authorized resources
App -> User: App-related enjoyment