348
edits
| Line 185: | Line 185: | ||
The protocol can be enhanced with a certification process to remove these two problems. To wit: | The protocol can be enhanced with a certification process to remove these two problems. To wit: | ||
When the public key is returned to the | When the public key is returned to the authority during the saveVerifiedAddress flow, the authority: | ||
# Creates a bundle of the user's public key, the user's email address, a validity interval, and some optional metadata, and signs it with their private key (and, in practice, it would make sense to include a key identifier since a site will have more than one public key; most digital signature specifications provide this capability) | # Creates a bundle of the user's public key, the user's email address, a validity interval, and some optional metadata, and signs it with their private key (and, in practice, it would make sense to include a key identifier since a site will have more than one public key; most digital signature specifications provide this capability) | ||
# Returns this signed bundle (which is now an identity certificate) back to the user agent, who adds it to secure private local storage with navigator.id.saveVerifiedAddressCertificate(). | # Returns this signed bundle (which is now an '''identity certificate''') back to the user agent, who adds it to secure private local storage with navigator.id.saveVerifiedAddressCertificate(<identitifer>, <certificate>). | ||
When the user agent provides a verifiedEmail to a relying party, the certificate is included with the identity assertion: | When the user agent provides a verifiedEmail to a relying party, the certificate is included with the identity assertion: | ||
edits