Identity/BrowserID: Difference between revisions

Jump to navigation Jump to search
Line 177: Line 177:
<tt>navigator.id.get(object options);</tt>
<tt>navigator.id.get(object options);</tt>


The Relying Party MAY call the navigator.id.get method when it wishes to request that the User Agent generate an identity assertion as soon as it can. The User Agent SHOULD immediately seek to generate an Identity Assertion and complete it with appropriate certificates to form a Backed Identity Assertion. This is likely to require prompting the user, and the User Agent may do this in whatever way it deems appropriate.
The Relying Party MAY call the navigator.id.get method when it wishes to request that the User Agent generate an identity assertion as soon as it can. When this happens, the User Agent SHOULD pursue the following actions:
 
# Establish the origin of the requesting site (including scheme and non-standard port).
# Check local BrowserID store for known identities that have been successfully used previously. The User Agent MAY suggest a preferred identity out of that list based on heuristics or other internal state, e.g. the email last used on that site.
# If no associations are found, the User-Agent SHOULD ask the user for what to do, by presenting a list of known email identities to choose from.
# If no email identities are known, the User-Agent MAY assist the user in any way it sees fit. [xxx ?]
# Verify the expiry date of the certificate associated with the identity of the previously-chosen association. If the certificate has expired, or would expire before the intended validity period of the assertion to be generated, the User-Agent MUST follow the steps in the CERTIFICATE REFRESH section of this specification.
# Create an Identity Assertion object for the chosen identity, scoped to the full domain of the requesting site (including scheme and non-standard port), and sign it with the private key associated with the chosen identity.
# Execute the navigator.id.onVerifiedEmail callback and provide the newly-created Identity Assertion as an argument.


The User Agent MUST fire one of two events on the <tt>navigator.id</tt> object:
The User Agent MUST fire one of two events on the <tt>navigator.id</tt> object:
Line 242: Line 250:
# Save the new certificate, as well as the refreshURL and errorURL arguments of the registerVerifiedEmailCertificate function.
# Save the new certificate, as well as the refreshURL and errorURL arguments of the registerVerifiedEmailCertificate function.


=== Identity Assertion Generation ===
To process a request for a verified email, a User-Agent MUST:
# Reliably establish the full domain of the requesting site (including scheme and non-standard port).
# Check a local data store for previously established identity associations for the requesting site. If one or more associations are found, the User-Agent MAY ask the user for which identity to use, or automatically choose one based on some criteria (e.g., last-used).
# If no associations are found, the User-Agent SHOULD ask the user for what to do, by presenting a list of known email identities to choose from.
# If no email identities are known, the User-Agent MAY assist the user in any way it sees fit. [xxx ?]
# Verify the expiry date of the certificate associated with the identity of the previously-chosen association. If the certificate has expired, or would expire before the intended validity period of the assertion to be generated, the User-Agent MUST follow the steps in the CERTIFICATE REFRESH section of this specification.
# Create an Identity Assertion object for the chosen identity, scoped to the full domain of the requesting site (including scheme and non-standard port), and sign it with the private key associated with the chosen identity.
# Execute the navigator.id.onVerifiedEmail callback and provide the newly-created Identity Assertion as an argument.


=== Certificate Refresh ===
=== Certificate Refresh ===
668

edits

Navigation menu