Document ID: chunk:federal_register_of_legislation:F2024L01443:schedule:3:p2
Version: federal_register_of_legislation:F2024L01443
Segment Type: schedule
Provision Reference: sch 3 (pt 2/5)
Character Range: 221120–224167

Preferred Name attribute SHOULD be assumed to be self-asserted.

 Although it is a Core Attribute, a Preferred Name MUST not be used as an authoritative attribute in the same manner as a PRP would use any of the verified name attributes (Family Name, Give Names or Middle Names).

 The data representation for preferred names follows the requirements for the verified name attributes, and the data representation of the federation protocol(s) used to fulfill an attribute request.

      2.3.2      Addresses

 An individual MAY self-assert a residential, postal, business, or other addresses.

 Addresses MAY be collected during the identity proofing process or added by the individual during the normal use and management of their digital ID.

 The attribute response for addresses MAY be a single address or a collection of addresses. The data representation for an Address attribute MUST contain the following fields:
      1.             the address type;
      2.             street address;
      3.             locality;
      4.             region;
      5.             post code; and
      6.             validated.

 The data representation MAY also contain the following fields:

      1.             country; and
      2.             formatted.

 A list valid address type URNs is outlined in Table 33 below.

 The field locality maps to suburb, city, administrative area, or place name.

 The field region maps to the larger administrative areas like state, territory, province, or prefecture. The field formatted, a print-ready string of the address, MAY also be included in the address object. A detailed description of the fields in an address are outlined in Table 32 below.
 An ISP fulfilling an address attribute request where the type of address is not specified SHOULD return a default value nominated by the individual.

      2.3.3      Other Email Addresses

 An individual MAY self-assert additional email addresses for use in different contexts, for example when accessing business services with their personal digital ID.

 An ISP MUST NOT permit an individual to add an email address that is currently claimed as the validated email address for the individual's or other active digital ID accounts on their system.

 If an ISP uses the Validated Email Address as the account identifier, the ISP MAY use any of the other email addresses asserted by an individual as an ad hoc replacement for the individual's account identifier.

 An ISP MUST validate the individual has control over all other email addresses they assert if it is used as a replacement for the account identifier.

 The attribute response for other email addresses MAY be a single email address or a collection of email addresses.

 Each Other Email Address MUST contain:

      1.             the email address;
      2.             a flag indicating if the email address has been validated; and
      3.             a contact type label.

 The data representation for each other email address string MUST conform to the requirements outlined above