Loop/Architecture/ID: Difference between revisions

m
 
(28 intermediate revisions by the same user not shown)
Line 10: Line 10:
== HAWK ==
== HAWK ==
Following [https://ozten.com/psto/2013/05/07/proposal-for-securing-mozilla-web-services-with-hawk/ Austin Kings's recommendation] we will be using [https://github.com/hueniverse/hawk HAWK] to secure client requests and server responses.
Following [https://ozten.com/psto/2013/05/07/proposal-for-securing-mozilla-web-services-with-hawk/ Austin Kings's recommendation] we will be using [https://github.com/hueniverse/hawk HAWK] to secure client requests and server responses.
During the sign up process, the client will be providing either a Firefox Account assertion or an MSISDN ('''or both if available'''). The server will be responsible for using the verification mechanisms for both of these identities. For Firefox Accounts, [https://wiki.mozilla.org/Identity/Firefox_Accounts#Verifier Firefox Accounts verifier], which will provide the user's email. For MSISDNs, an SMS based authentication service (details '''TBD''').
During the sign up process, the client will be providing either a Firefox Account or an MSISDN assertion ('''or both if available'''). The server will be responsible for using the verification mechanisms for both of these identities. For Firefox Accounts, [https://wiki.mozilla.org/Identity/Firefox_Accounts#Verifier Firefox Accounts verifier], which will provide the user's email. For MSISDNs, [https://github.com/mozilla/fxa-auth-server/wiki/API-extensions-for-supporting-MSISDN-verification-in-FxA-auth-server MSISDN verifier], which will provide the user's phone number.
Once the server verifies the given identity/identities, an UUID and a private key will be generated, stored in the server associated to the given identities/identity and provided to the client. These values will be used to authenticate HAWK requests for following requests. The UUID uniquely identifies a Loop user (we can even use Mongo's _id field for each user document).
Once the server verifies the given identity/identities, an UUID and a shared key will be generated, stored in the server associated to the given identities/identity and provided to the client. These values will be used to authenticate HAWK requests for following requests. The UUID uniquely identifies a Loop user (we can even use Mongo's _id field for each user document).


== MSISDN verification service ==
== MSISDN verification service ==
// TBD
[https://github.com/mozilla-services/msisdn-gateway/blob/master/API.md API extensions for supporting MSISDN verification in FxA auth server]


= User Data Schema =
= User Data Schema =
Line 25: Line 25:
(Rename ''urlStore'' to ''userStore'')
(Rename ''urlStore'' to ''userStore'')
   userStoreSchema {
   userStoreSchema {
     id: <string>,
     _id: <string>,
     privateKey: <string>,
     sharedKey: <string>,
     alias: [{
     alias: [{
       type: <string>, // "fxa" or "msisdn"
       type: <string>, // "fxa" or "msisdn"
       id: <string>, // Could be the email or msisdn in plain text or a hash of them as proposed (and done) at bug 984288
       _id: <string>, // MAC from email or msisdn (bug 984288)
       verified: <boolean>
       verified: <boolean>
     }],
     }],
     simplepushURL: [ <string> ],
     simplepushEndpoint: [{
      url: <string>,
      online: <boolean>
    }],
     dirty: <boolean>
     dirty: <boolean>
   }
   }


* '''id''': Uniquely identifies a Loop user. One ''id'' can contain multiple alias. HAWK requests will contain this value within the authentication header.
* '''id''': Uniquely identifies a Loop user. One ''id'' can contain multiple alias. HAWK requests will contain this value within the authentication header.
* '''privateKey''': Server generated key that will be used to create the HAWK requests MAC values. There will be one key per loop user and will be shared with clients that proof owenrship of the identity used to login in Loop (Firefox Accounts and/or MSISDN).
* '''sharedKey''': Server generated key that will be used to create the HAWK requests MAC values. There will be one key per loop user and will be shared with clients that proof ownership of the identity used to login in Loop (Firefox Accounts and/or MSISDN).
* '''alias''': Personal information about the owner of the Loop account. Can be multiple. Firefox Accounts and MSISDNs so far.
* '''alias''' (subdocument): Personal information about the owner of the Loop account. Can be multiple. Firefox Accounts emails and MSISDNs so far.
* '''simplepushURL''': List of [https://wiki.mozilla.org/WebAPI/SimplePush SimplePush] endpoints to notify users about calls. There will be one SimplePush endpoint per device.
* '''simplepushURL''': List of [https://wiki.mozilla.org/WebAPI/SimplePush SimplePush] endpoints to notify users about calls. There will be one SimplePush endpoint per device and we should be able to set them as online/offline.
* '''dirty''': Flag to allow account linkage. If true means that the alias of this account has been associated with other account and so it is no longer valid. In this case, we expect clients containing the credentials of the 'dirty' account to renew them.
* '''dirty''': Flag to allow account linkage. If true means that the alias of this account has been associated with other account and so it is no longer valid. In this case, we expect clients containing the credentials of the 'dirty' account to renew them.


Line 49: Line 52:
This document assumes that an user can log into Loop using her MSISDN or her Firefox Accounts email in any Firefox platform (Firefox Desktop and Firefox OS so far).
This document assumes that an user can log into Loop using her MSISDN or her Firefox Accounts email in any Firefox platform (Firefox Desktop and Firefox OS so far).


=== User logs in with new Firefox Accounts email (Sign Up)===
=== User logs in with new Firefox Accounts email ===
[[File:Loop-fxa-login.png|800px]]
[[File:Loop-fxa-login.png|800px]]


=== User logs in with new MSISDN (Sign Up) ===
=== User logs in with new MSISDN ===
If the login is done from Desktop, the MSISDN verification SMS won't be sent to the Loop client, but to the phone specified by the user.


[[File:Loop-msisdn-login.png|800px]]
[[File:Loop-msisdn-login.png|800px]]
=== User logs in with registered Firefox Accounts email (Sign In) ===
Loop clients should be able to store a match between user identities (Firefox Accounts email and/or MSISDN) and HAWK credentials so following sign in requests don't require a new verification of the provided identity. There is no diagram for this case cause it is quite simple. It is basically a HAWK authenticated POST /credentials that will return a 200 OK from the server. We might want to set that the user is logged in again in our presence solution, but this is out of the scope of this doc.
In case that the sign in request is done from a new device, or the client doesn't provide the appropriate HAWK credentials in the sign in request (POST /credentials), a new verification should be triggered. The following diagram is only for this case.
[[File:Loop-fxa-signin.png|800px]]
In '''Step 12''' if the push endpoint already exists, we don't add it to the list.
=== User logs in with registered MSISDN (Sign In) ===
If the login is done from Desktop, the MSISDN verification SMS won't be sent to the Loop client, but to the phone specified by the user.
Loop clients should be able to store a match between user identities (Firefox Accounts email and/or MSISDN) and HAWK credentials so following sign in requests don't require a new verification of the provided identity. There is no diagram for this case cause it is quite simple. It is basically a HAWK authenticated POST /credentials that will return a 200 OK from the server. We might want to set that the user is logged in again in our presence solution, but this is out of the scope of this doc.
In case that the sign in request is done from a new device, or the client doesn't provide the appropriate HAWK credentials in the sign in request (POST /credentials), a new verification should be triggered. The following diagram is only for this case.
[[File:Loop-msisdn-signin.png|800px]]


== Linking accounts ==
== Linking accounts ==
Based on the requirement that users should be able to log into Loop with any alias (MSISDN and/or Firefox Accounts email) from '''both''' Desktop and Mobile, the key differentiator of these use cases (apart from the chosen ID) is if the alias being linked is already a registered alias associated to a Loop account.
Based on the requirement that users should be able to log into Loop with any alias (MSISDN and/or Firefox Accounts email) from '''both''' Desktop and Mobile, the key differentiator of these use cases (apart from the chosen ID) is if the alias being linked is already a registered alias associated to a Loop account or not. That would affect the need of setting the existing alias as "dirty".


=== User links NOT registered Firefox Accounts email to registered MSISDN ===
=== User links NOT registered Firefox Accounts email to registered MSISDN ===
Line 84: Line 67:
* Alice wants to register and use her Firefox Accounts email to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.
* Alice wants to register and use her Firefox Accounts email to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.


'''// TODO: Diagram'''
[[File:Loop-link-fxa-to-msisdn.png|800px]]


=== User links registered Firefox Accounts email to registered MSISDN ===
=== User links registered Firefox Accounts email to registered MSISDN ===
Line 92: Line 75:


[[File:Loop-link-existing-fxa-to-msisdn.png|800px]]
[[File:Loop-link-existing-fxa-to-msisdn.png|800px]]
This request is done from a device where Alice is logged into Loop with the account that has been marked as dirty (the one associated to her Firefox Accounts email) and so the client is asked to renew its credentials.
[[File:Loop-dirty-request.png|800px]]


=== User links NOT registered MSISDN to registered Firefox Accounts email ===
=== User links NOT registered MSISDN to registered Firefox Accounts email ===
Line 98: Line 85:
* Alice wants to register and use her MSISDN to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.
* Alice wants to register and use her MSISDN to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.


'''// TODO: Diagram'''
[[File:Loop-link-msisdn-to-fxa.png|800px]]
 
=== User links registered MSISDN to registered Firefox Accounts email ===
=== User links registered MSISDN to registered Firefox Accounts email ===
* Alice is using a device (Desktop or Mobile) where she is '''logged in Loop using her Firefox Account'''
* Alice is using a device (Desktop or Mobile) where she is '''logged in Loop using her Firefox Account'''
Line 104: Line 92:
* Alice wants to use her MSISDN to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.
* Alice wants to use her MSISDN to log in Loop. So she can use both MSISDN and Firefox Accounts email to make and receive Loop calls.


'''TODO: Diagram'''
[[File:Loop-link-existing-msisdn-to-fxa.png|800px]]
 
This request is done from a device where Alice is logged into Loop with the account that has been marked as dirty (the one associated to her MSISDN) and so the client is asked to renew its credentials.
 
[[File:Loop-dirty-request-msisdn.png]]


= Silent MSISDN verification on Firefox OS =
= Silent MSISDN verification on Firefox OS =
There is a parallel work to allow privileged apps to get a verified MSISDN from the platform in Firefox OS. We will link the details here as soon as they are ready.
There is a parallel work to allow privileged apps to get a verified MSISDN from the platform in Firefox OS. We will link the details here as soon as they are ready.
[https://bugzilla.mozilla.org/show_bug.cgi?id=988469]
Confirmed users
483

edits