Services/Identity/InternalSpec: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "= Internal Mozilla ID API = The Mozilla ID service acts as a secondary authority, issuing identity assertions Pages ID service must implement: * Provide a login page to the u...")
 
(Deprecate; Point to BrowserID)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{| class="fullwidth-table"
|-
| '''Note: The Verified Email Protocol has been deprecated. Please check the [[Identity/BrowserID|BrowserID]] protocol.'''
|}<br>
= Internal Mozilla ID API =
= Internal Mozilla ID API =


The Mozilla ID service acts as a secondary authority, issuing identity assertions  
The Mozilla ID service acts as a secondary authority, issuing identity assertions to relying parties when requested to do so by an authenticated client.
 
Pages ID service must implement:
 
* Provide a login page to the user sets a cookie which allows the page to make an XHR request to return an Identity Assertion for that user.
* Provide account creation page(s) to create a new account.
* Provide an account recovery page to send a verification token via email
* Provide disclosure dialog page


=== ID Server Cookies: ===
''See the [[MozillaID/Spec]] document for general terms and the external API to relying parties. This document describes the API our clients will use to sign-in and request identity assertions from the Mozilla ID service''
ID Server cookies are used by the ''service.js'' (see Sec. 41.5.2) script inside of the server provided frame to allow for continuous end-customer service. These cookies are permanent and contains and interal "freshness date" for when to become "passive"


==== ID Active Session:  ====
== General Notes ==
User has actively logged in to id.moz


provides the ability for JS Library contained in secured iframe to request an Identity Assertion
All API endpoints are SSL only and require an HTTP POST request.


'''TTL:''' (TBD)
;Responses
 
 
==== ID Passive Session:  ====
(Active cookie freshness expired. Need to re-auth)
 
Active Session has expired
 
Requires user action before setting to Acitve Session
 
'''TTL''': (TBD)
 
=== Server API Endpoints  ===
==== General ====
All API endpoints are SSL only and require a POST. All calls are made XMLHTTPRequest POST and return JSON objects unless otherwise specified.


Unless a callback is specified, the request will use standard HTTP status codes to indicate errors.  
Unless a callback is specified, the request will use standard HTTP status codes to indicate errors.  
Line 48: Line 30:
"Data" is short-hand for the function specific data elements returned. See individual functions for return results.
"Data" is short-hand for the function specific data elements returned. See individual functions for return results.


==== Service APIs ====
;Session Authentication
The following API calls are made by the ''service.js ''(see Sec. 41.5.2) code inside the trusted iframe back to the ID Server. The API calls shall check the origin of the requests to ensure that they are from the mozilla.com served iframe. See Status (Sec. 1.8) for a description of the return status types.


===== https://servername/1/logged_in =====
The Mozilla ID server uses a token to maintain session information. This token is provided by the server, and acquired by the client by providing user credentials via HTTP Basic Auth according to the Firefox Sync API.
Is the user logged into Mozilla ID service (Is the Active_Session cookie valid)


''Parameters:''
The token is generally sent back to the server as a cookie, although it can optionally be provided as a POST parameter (when cookies are not available). Once an active session has been established, the token will be valid for a predetermined period, after which the token will continue to be sent, but the session will be considered inactive.


none.
Returning the session to an active state requires user credentials to be re-sent, which causes the session to be replaced.


''Returns'':
Active session timeout: TBD.


returns *SUCCESS*
The Mozilla ID server MUST require an active session before executing any of the APIs described in this document.


''Errors'':
== API  ==


If there is no Active Session, returns *LOGIN ERROR*
;logged_in


===== https://server/1/get_default_email =====
Is the user logged into Mozilla ID service (Is the Active_Session cookie valid)
''Parameters'':


audience: RP
*type: POST
*SSL: required
*path: /1/logged_in
*parameters:
**(none)
*returns:
***SUCCESS* if there is an active session to the Mozilla ID server
***LOGIN_ERROR* if there is no active session


''Returns'':
;get_default_email


Return the default email associated with this RP
Returns the default email associated with this RP (if the user has previously done so).


''Errors'':
*type: POST
*SSL: required
*path: /1/get_default_email
*parameters:
**audience: RP
*returns:
**email string if there is an associated email
**&nbsp;?? if there is no default email?
***LOGIN_ERROR* if there is no active session with the Mozilla ID server


If there is no active session, fails with *LOGIN ERROR*
;get_emails


===== https://servername/1/get_emails =====
(TBD) returns a JSON block of all verified email addresses. If an audience is specified, also indicates which email may have been previously used with this site and which email is "preferred".
''Parameters'':


audience: RP
*type: POST
*SSL: required
*path: /1/get_emails
*parameters:
**audience: RP  
*returns:
**TBD
***LOGIN_ERROR* if there is no active session with the Mozilla ID server


''Returns'':
;get_identity_assertion


(TBD) returns a JSON block of candidate email addresses indicating which email may have been previously used with this site and which email is "preferred"
Returns an ''identity assertion'' for the given audience and email. The client MUST ensure the user has consented to the disclosure of information to the RP before making this call. [[MozillaID/Spec]] for the format of identity assertions.


''Errors'':
*type: POST
*SSL: required
*path: /1/get_identity_assertion
*parameters:
**audience: RP
**email: verified email to disclose
*returns:
**serialized identity assertion object
***LOGIN_ERROR* if there is no active session with the Mozilla ID server


If there is no active session, fails with *LOGIN ERROR*
;remove_association


===== https://servername/1/get_identity_assertion =====
Removes the "automatic" flag, requiring user to confirm access to the site, and specify the preferred email (if more than one is available)
This is the Identity Assertion Request (IAR). It returns an Identity Assertion for the given audience and email.


''Parameters'':
*type: POST
*SSL: required
*path: /1/remove_association
*parameters:
**audience: RP
*returns:
***SUCCESS*
***FAILURE*
***LOGIN_ERROR* if there is no active session with the Mozilla ID server


audience: requesting site (to come from trusted iframe)


email: user email address to use for this assertion.
[[Image:DataFlow.png|thumb|Data flow for most common data call]]


''Returns'':ver
== Pages to be implemented ==
 
Returns Identity Assertion. (as decribed in Sec 1.3)
 
''Errors'':
 
If there is no Active Session, the IAR will fail with a '''<nowiki>*LOGIN ERROR*</nowiki>''', and the JS Library should prompt for login.
 
 
===== https://server/1/remove_association =====
removes the "automatic" flag, requiring user to confirm access to the site, and specify the preferred email (if more than one is available)
 
''Parameter'':
 
audience: RP
 
''Returns'':
 
<nowiki>*</nowiki>'''SUCCESS*, FAILURE*'''
 
''Errors'':
 
If there is no active session, fails with *LOGIN ERROR*
 
=== Service API ===
<nowiki>*** PostMessage API ***</nowiki>
 
 
see: jschannel
 
...
 
- how does it open a popup? does it need to talk to the wrapper to request a popup?
 
- how does it report failure to the wrapper API?
 
* how does it communicate with a popup?
*
 
1. page calls wrapper::getVerifiedEmail(cb)
 
2. wrapper::getVerifedEmail() calls service js to determine the current user's email
 
if customer
 
3. service js determines if user has active session
 
if no, then get an active session by use of a pop-up
 
(if service js fails to establish an active session, then return a failure)
 
4. service js determines if there is a default email already set to be disclosed to this RP
 
if no, then
 
make an API call to the ID server to fetch the list of possible email addresses to use, and show a pop-up to let the user decide if/what to disclose to the RP
 
if user cancels, return a failure (the same failure!)
 
5. once the service js has established the desired email to be disclosed, make an IAR (identity assertion request) to the ID server to obtain an IA that will be returned to the page
 
6. the wrapper gets back the IA from the service JS and calls the callback with status and IA.
 
 
== Identity Assertion Request (IAR) ==
An IAR is the call the JS library does, from a trusted and authenticated iframe, to acquire an Identity Assertion (IA) for a given email address and requesting site (RP). The JS library must ensure the user has consented to the disclosure of information to the RP before making this call. See below for the IA format.


Pages ID service must implement:


Note that:
* Login page to the user sets a cookie which allows the page to make an XHR request to return an Identity Assertion for that user.
* Account creation page(s) to create a new account.
* Account recovery page to send a verification token via email
* Disclosure dialog page


* IAs are returned only if authorized by cookie (in a trusted iframe).
(WIP. See UX mockups on [[MozillaID]] for more info.)
* IAs should be requested by the JS library only after it has determined that the user wishes to disclose their email to the site.


== States: ==
== Return Status ==
Samples of the following return status messages.


SUCCESS
SUCCESS

Latest revision as of 19:21, 3 April 2012

Note: The Verified Email Protocol has been deprecated. Please check the BrowserID protocol.


Internal Mozilla ID API

The Mozilla ID service acts as a secondary authority, issuing identity assertions to relying parties when requested to do so by an authenticated client.

See the MozillaID/Spec document for general terms and the external API to relying parties. This document describes the API our clients will use to sign-in and request identity assertions from the Mozilla ID service

General Notes

All API endpoints are SSL only and require an HTTP POST request.

Responses

Unless a callback is specified, the request will use standard HTTP status codes to indicate errors.

JSON responses (unless otherwise specified) follow the format of:

{"success":True|False,
  "error": {   // Only present if "success" is false
    "code": Numeric Code (reflecting the HTTP Status code), 
    "reason": Human Readable error reason },
  Data}

"error" only exists if there was an error with the transaction.

"Data" is short-hand for the function specific data elements returned. See individual functions for return results.

Session Authentication

The Mozilla ID server uses a token to maintain session information. This token is provided by the server, and acquired by the client by providing user credentials via HTTP Basic Auth according to the Firefox Sync API.

The token is generally sent back to the server as a cookie, although it can optionally be provided as a POST parameter (when cookies are not available). Once an active session has been established, the token will be valid for a predetermined period, after which the token will continue to be sent, but the session will be considered inactive.

Returning the session to an active state requires user credentials to be re-sent, which causes the session to be replaced.

Active session timeout: TBD.

The Mozilla ID server MUST require an active session before executing any of the APIs described in this document.

API

logged_in

Is the user logged into Mozilla ID service (Is the Active_Session cookie valid)

  • type: POST
  • SSL: required
  • path: /1/logged_in
  • parameters:
    • (none)
  • returns:
      • SUCCESS* if there is an active session to the Mozilla ID server
      • LOGIN_ERROR* if there is no active session
get_default_email

Returns the default email associated with this RP (if the user has previously done so).

  • type: POST
  • SSL: required
  • path: /1/get_default_email
  • parameters:
    • audience: RP
  • returns:
    • email string if there is an associated email
    •  ?? if there is no default email?
      • LOGIN_ERROR* if there is no active session with the Mozilla ID server
get_emails

(TBD) returns a JSON block of all verified email addresses. If an audience is specified, also indicates which email may have been previously used with this site and which email is "preferred".

  • type: POST
  • SSL: required
  • path: /1/get_emails
  • parameters:
    • audience: RP
  • returns:
    • TBD
      • LOGIN_ERROR* if there is no active session with the Mozilla ID server
get_identity_assertion

Returns an identity assertion for the given audience and email. The client MUST ensure the user has consented to the disclosure of information to the RP before making this call. MozillaID/Spec for the format of identity assertions.

  • type: POST
  • SSL: required
  • path: /1/get_identity_assertion
  • parameters:
    • audience: RP
    • email: verified email to disclose
  • returns:
    • serialized identity assertion object
      • LOGIN_ERROR* if there is no active session with the Mozilla ID server
remove_association

Removes the "automatic" flag, requiring user to confirm access to the site, and specify the preferred email (if more than one is available)

  • type: POST
  • SSL: required
  • path: /1/remove_association
  • parameters:
    • audience: RP
  • returns:
      • SUCCESS*
      • FAILURE*
      • LOGIN_ERROR* if there is no active session with the Mozilla ID server


Data flow for most common data call

Pages to be implemented

Pages ID service must implement:

  • Login page to the user sets a cookie which allows the page to make an XHR request to return an Identity Assertion for that user.
  • Account creation page(s) to create a new account.
  • Account recovery page to send a verification token via email
  • Disclosure dialog page

(WIP. See UX mockups on MozillaID for more info.)

Return Status

SUCCESS

{"success": True,
Data...}


LOGIN ERROR

{"success": False,
 "error": {"code": 401,
    "reason": TBD}}

PARSE_ERROR

{"success": False,
 "error": {"code": 400,
    "reason": TBD}}

INVALID (server to server)

{"success": False,
    "error": { "code": 403,
    "reason":""}}