Identity/BrowserID: Difference between revisions

Jump to navigation Jump to search

Identity/BrowserID (view source)

Revision as of 21:51, 19 January 2012

911 bytes added ,  19 January 2012
→‎User-Agent Compliance
Line 169: Line 169:
''This section is normative.''
''This section is normative.''


The User-Agent is critical for BrowserID support. Here, we define, normatively, the API that user agents MUST implement, including specific behaviors in response to these API calls. Relying Parties and Identity Providers can safely skip this section.
The User-Agent plays an important role in BrowserID support. Here, we define, normatively, the API that user agents MUST implement, including specific behaviors in response to these API calls. Relying Parties and Identity Providers can safely skip this section.


=== API ===
=== API ===
Line 198: Line 198:
<tt>navigator.id.beginProvisioning(object callback)</tt>
<tt>navigator.id.beginProvisioning(object callback)</tt>


The callback function SHOULD expect the callback function to accept parameters <tt>email</tt> and <tt>cert_duration_s</tt>.
The User Agent SHOULD expect the callback function to accept parameters <tt>email</tt> and <tt>cert_duration_s</tt>.


In response to this call, the user agent should invoke the callback
In response to this call, the User Agent should invoke the callback with parameters based on the provisioning context. The <tt>email</tt> parameter MUST be the email address which the user-agent is attempting to provision. The <tt>cert_duration_s</tt> parameter should be the requested validity duration for the certificate, which the User Agent SHOULD determine based on the security level of the session. For example, public computers should have very short certificate validity.


<tt>navigator.id.genKeyPair(object callback);</tt>
<tt>navigator.id.genKeyPair(object callback);</tt>


The callback function SHOULD accept parameter <tt>pubkey</tt>, a serialized public-key string as per the above public-key spec.
The User Agent SHOULD expect the callback to accept parameter <tt>pubkey</tt>, a serialized public-key string as per the above public-key spec.
 
In response to this call, the User Agent MUST generate a fresh keypair associated with the email address for this provisioning context. The secret key should be stored internally, and the <tt>callback</tt> should be invoked with the serialized public-key as sole argument.


<tt>navigator.id.registerCertificate(certificate);</tt>
<tt>navigator.id.registerCertificate(certificate);</tt>


The certificate parameter MUST be a valid serialized certificate, as per the above spec. The trust root for this certificate SHOULD comply with the characteristics described in the "Acceptable Trust Paths" section below.
The User Agent SHOULD expect the certificate to be a valid serialized certificate, as per the above spec. The User Agent SHOULD expect the trust root for this certificate to comply with the characteristics described in the "Acceptable Trust Paths" section.
 
The User Agent MUST associate this certificate with the email address for this provisioning context and store this association internally for later issuance of Backed Identity Assertions.


<tt>navigator.id.raiseProvisioningFailure(string reason);</tt>
<tt>navigator.id.raiseProvisioningFailure(string reason);</tt>


The reason parameter MUST be a string that can be reported to the user regarding the reason why a certificate failed to be provisioned.
The User Agent MUST interrupt this provisioning workflow and return with a failure for the given <tt>reason</tt>.


WebIDL:
WebIDL:
BenAdida
668

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/388686"

Navigation menu