Services/Sync/Features/BrowserID Authentication: Difference between revisions

Jump to navigation Jump to search
m
note on functional implementation
mNo edit summary
m (note on functional implementation)
Line 15: Line 15:
# The authentication mechanism cannot be raw BrowserID assertions, as these can be quite large and unsuitable for repeated use.
# The authentication mechanism cannot be raw BrowserID assertions, as these can be quite large and unsuitable for repeated use.
|Feature non-goals=This feature does not involve changing Sync's data encryption model (currently using a cryptographically secure randomly generated private key for client-side encryption): it only involves changing the mechanism by which new user accounts are handled and how Sync HTTP requests are authenticated.
|Feature non-goals=This feature does not involve changing Sync's data encryption model (currently using a cryptographically secure randomly generated private key for client-side encryption): it only involves changing the mechanism by which new user accounts are handled and how Sync HTTP requests are authenticated.
|Feature functional spec=Technical details are still being decided.
A rough proposal exists at [[Identity/BrowserIDSync]]. Much discussion has occurred on the services-dev mailing list and on IRC. More formal "getting involved" info will follow.
}}
}}
{{FeatureInfo
{{FeatureInfo
canmove, Confirmed users
409

edits

Navigation menu