An email address is considered a credential for two reasons:

  • It is often used as a unique identifier for login.
  • The (primary) email address is typically used for password reset. Because email accounts enforce their own passwords, the owner of the account is the only person who can set a new password using this method.

Typically a unique email address is associated with an identity. iWelcome calls that the primary email address.

iWelcome uses the primary email address for the following:

  • Identifier (username) for login and password reset request.
  • Password reset. A link is sent to the user's email address which indirectly gives the recipient access.
  • To send identity related notifications.

In the first two cases, the email address contributes to authentication so the email address is considered to be a credential.

NOTE: iWelcome does not support the possibility to use a unique email address for logging in and use a different non-unique email address for notifications and password reset emails.

Besides storing a primary email address in the user's profile, iWelcome supports the option to store additional (non-primary) email addresses.

Non-primary email addresses provide the following benefits:

  • A secondary email address can be added and changed to being primary at a later time.
  • A secondary email address can be used as 'fallback' when the user has lost access to the mailbox that is associated with his primary email address. (not yet supported)
  • Secondary email addresses create a 360-degree view of the user, which is relevant in the CIAM context. It allows for 'linking' an identity to email correspondence that may have happened 'out-of-band' with iWelcome.

Managing User Email Addresses

iWelcome uses email addresses according to the following use cases:

  • Login
  • Password reset; request and execute
  • Notifications
  • Looking up a user via ServiceDesk based on email address
  • Viewing a user's email address via ServiceDesk
  • Providing email to SP via SAML-assertion or OAuth-attribute

You can set user email addresses through the following processes:

  • Account registration
  • Account activation
  • Viewing/changing/adding/deleting email addresses via self-service
  • Add email address via social registration
  • Viewing/changing/adding/deleting email addresses via SCIM

Email Address Validity

The format of email address is local-part@domain where local-part may contain up to 64 characters, and the domain may have a maximum of 255 characters. The formal definitions are to be found in RFC 5322 and RFC 5321 with a more readable form provided in RFC 3696 and the associated errata. iWelcome follows this specification with the exception of the quoted forms which are rarely used in practice. Thus email addresses containing backslashes are rejected.

The local-part of a valid email address that is accepted by iWelcome has at most 64 of the following characters:

  • alphabetic characters;
  • digits;
  • special characters (! # $ % & ' * + - / = ? ^ _ . { | } ~).

Note: The period (".") may appear, but may not be used to start or end the local-part, nor may two or more consecutive periods appear.

Business Rules for Verification

iWelcome applies the following logic with respect to uniqueness of email addresses:

  • The combination of segment and primary email address is unique for accounts that have been activated.
  • If an email address originates from a social media account like Facebook during social registration (or social account linking), iWelcome considers the email address as verified by the social media platform and does not initiate the verification process. The whole point of social registration is to provide the end user with a registration process that is as 'lean' as possible.
  • A primary email address can have a type (home, work, other), see SCIM definition.
  • An email address can only be primary if it has been successfully verified.
  • iWelcome initiates a verification process for any email address that is not verified/confirmed.
  • Verified email addresses can be primary or not primary.
  • Verified email addresses can be unique but this is not required.
  • The combination of segment and primary email address does NOT have to be unique for email addresses that are still pending verification. This may be the case during registration/activation, for example. An unverified email address gets allocated to an account when the legitimate user of that account is able to confirm his or her mail address and the email address was marked as the 'target' primary email address. Malicious users may create accounts using an email address that they cannot confirm. This should not prevent legitimate users from creating and confirming their email addresses.


  • iWelcome UIs (self-registration and Self Service) can apply whitelisting and/or blacklisting of email domains. This depends on the customer-specific configuration.
  • You can choose which identifier that you want to enter on the login screen. Email address is the most common identifier used for this purpose, but the identifier can be configured based on your preference.