Services/Identity/Spec: Difference between revisions

Jump to navigation Jump to search

Services/Identity/Spec (view source)

Revision as of 23:44, 8 March 2011

999 bytes removed ,  8 March 2011
→‎Protocol Flow
Line 25: Line 25:
== Protocol Flow ==
== Protocol Flow ==


There are two ways for the protocol to operate, on current-generation browsers and on smart clients. Current-generation browsers are supported by means of a JavaScript library which creates an identical DOM API as a smart client would have. Thus, it makes no difference to relying parties--but the legacy scenario creates a dependency on a live service.
;Setup


;Current-generation client flow
A relying party declares its ability to accept verified emails by setting the ''onVerifiedEmail'' handler:
 
A relying party includes a JavaScript library which injects new APIs into the DOM if they do not already exist (navigator.id.*). The relying party executes code like:


  navigator.id.onVerifiedEmail = function(identity_assertion) {
  navigator.id.onVerifiedEmail = function(identity_assertion) {
Line 35: Line 33:
  });
  });


And also creates a "Sign In button on their page which, when clicked by a user, invokes the ''navigator.id.getVerifiedEmail()'' method. This method will start the verified email disclosure process.
;Requesting a verified email
 
The relying party may then execute the ''getVerifiedEmail'' method, which could be the result of the user clicking a 'Sign In' button, for example. This method informs the user agent that the relying party requires a verified email before proceeding, and should therefore request one from the user as soon as possible:
 
navigator.id.getVerifiedEmail();


Behind the scenes, the JavaScript library has created a hidden iframe to the ''secondary authority'' server (using SSL). When the getVerifiedEmail method executes, it sends a PostMessage to the hidden secondary authority iframe requesting an identity assertion for the relying party.
;Receiving and verifying the ''identity assertion''


Another JavaScript library inside the secondary authority iframe is responsible for responding to these PostMessage requests, as well as for communicating with the secondary authority's server using an internal API.
Once the user agent has acquired an ''identity assertion'' (most likely after prompting the user, and requesting an assertion from a primary or secondary authority), it executes the ''onVerifiedEmail'' handler, with the ''identity assertion'' as an argument.


This inner library first ensures the user has an active session with the secondary authority itself. If it doesn't, it opens a pop-up window for the user to sign into the secondary authority, or create a new account.
The relying party may then send the ''identity assertion'' to their server, where it can be cryptographically verified, or sent to the issuer of the assertion for verification.


After the user is signed into the secondary authority, the inner library requests a list of verified email addresses from the secondary authority. It then displays a pop-up window so the user can choose which email to disclose to the relying party.
;Declaring an active session


Once the user has chosen an email, the inner library requests an identity assertion from the secondary authority, scoped to the relying party, and returns the assertion via PostMessage to the relying party.
After verifying the assertion, the relying party should consider the browser session to be active (authenticated), and would reflect that by setting the ''sessions'' property:


The JS library included by the relying party receives the identity assertion via PostMessage, and executes the navigator.id.onVerifiedEmail callback.
navigator.id.sessions = [{...}];


The relying party may then send the assertion to their own server, and either cryptographically verify the assertion (it will be signed by the secondary authority's public key), or send it to the secondary authority over SSL for on-line verification. After the assertion is verified, the relying party may consider the session with the browser it came from to be ''active'', and set a cookie in the same way it would do today after a user signs in.
Setting a session object informs the user agent that there is an active session, how long to consider it active for, and gives the user agent a method to terminate the session (if the user wishes to do so).


Client-side, the relying party may set the navigator.id.sessions array with a Session object that informs the user agent that there is an active session, how long to consider it active for, and with a method for the user agent to terminate the session (if the user wishes to do so).
;Graceful degradation


Note that the wrapper JS library won't inject the getVerifiedEmail() method if it already exists, and thus a native client could implement the same API calls natively in the browser.
Note that this API is specifically designed so it can be implemented by a browser, or injected by a script loaded from content (by the relying party). In the latter case, the script would open an iframe to a trusted domain and communicate with it via PostMessage. Such a script would not inject the API if it already existed, thus enabling graceful degradation on current-generation browsers without interfering with the ability to provide native support for this protocol. For more details, see the [[MozillaID/InternalSpec]] document.


== Identity Assertions ==
== Identity Assertions ==
Thunder
946

edits

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

Navigation menu