Sometimes, when dealing with certain Domains, the Identities come naturally, with the client consuming the Domain Model. This is likely the ideal case, because the Identity can be modeled easily. Let's take a look at the book-selling market:

namespace DddCatalogDomainModelBook;

class ISBN
{
    private $isbn;

    private function __construct($anIsbn)
    {
        $this->setIsbn($anIsbn);
    }

    private function setIsbn($anIsbn)
    {
        $this->assertIsbnIsValid($anIsbn, 'The ISBN is invalid.');

        $this->isbn = $anIsbn;
    }

    public static function create($anIsbn)
    {
        return new static($anIsbn);
    }

    private function assertIsbnIsValid($anIsbn, $string)
    {
        // ... Validates an ISBN code
    }
}

According to Wikipedia: The International Standard Book Number (ISBN) is a unique numeric commercial book identifier. An ISBN is assigned to each edition and variation (except re-printings) of a book. For example, an e-book, a paperback and a hardcover edition of the same book would each have a different ISBN. The ISBN is 13 digits long if assigned on or after 1 January 2007, and 10 digits long if assigned before 2007. The method of assigning an ISBN is nation-based and varies from country to country, often depending on how large the publishing industry is within a country.

The cool thing about the ISBN is that it's already defined in the Domain, it's a valid identifier because it's unique, and it can be easily validated. This is a good example of an Identity provided by the client:

class Book
{
   private $isbn;
   private $title;

   public function __construct(ISBN $anIsbn, $aTitle)
   {
       $this->isbn  = $anIsbn;
       $this->title = $aTitle;
   }
} 

Now, it's just a matter of using it:

 $book = new Book(
     ISBN::create('...'),
     'Domain-Driven Design in PHP'
 );