668
edits
Changes
→Assertion Verification
# If there is more than one Identity Certificate, then reject the assertion unless each certificate after the first one is properly signed by the prior certificate's public key.
# If the first certificate (or only certificate when there is only one) is not properly signed by the expected issuer's public key, reject the assertion. The expected issuer is either the domain of the certified email address in the last certificate, or the issuer listed in the first certificate if the email-address domain does not support BrowserID.
# WORK HERE# The If the expected issuer was designated by the certificate must be verified using rather than discovered given the issueruser's public key. If the certificate contains an Issuer elementemail address, then the certificate is secondary; in this caseissuer SHOULD be <tt>browserid.org</tt>, otherwise reject the Relying Party must further decide whether the issuer is one that it trustsassertion.
Note that a relying party may, at its discretion, use a verification service that performs these steps and returns a summary of results. In that case, the verification service is acting as a relying party, and MUST perform all the checks described here. In order to perform audience checking, the verification service must be told what audience to expect by the relying party.
== Security Considerations ==
