|
|
@ -98,14 +98,6 @@ could store this information rather than calling `POST /login` at all. This does
|
|
|
|
|
|
|
|
|
|
|
|
While `POST /register` does work, it is impactical as the sole method of fetching an access token.
|
|
|
|
While `POST /register` does work, it is impactical as the sole method of fetching an access token.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Most appservices
|
|
|
|
|
|
|
|
which do not implement encryption do not store this information as neither the device_id or access_token are needed f However critically
|
|
|
|
|
|
|
|
this means that bridges will need to be designed to store the access_token and device_id from the point of creating the user,
|
|
|
|
|
|
|
|
so older bridges would be unable to get an access token for existing users as `POST /register` would fail.
|
|
|
|
|
|
|
|
It would difficult to log out these tokens if they got exposed additionally, as the AS would not be able to fetch a new access token.
|
|
|
|
|
|
|
|
Furthermore, the ability to generate access tokens for real users who registered elsewhere would not be possible with this mechanism.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Security considerations
|
|
|
|
## Security considerations
|
|
|
|
|
|
|
|
|
|
|
|
Appservices could use this new functionality to generate devices for any userId that are within its namespace e.g. setting the
|
|
|
|
Appservices could use this new functionality to generate devices for any userId that are within its namespace e.g. setting the
|
|
|
|