| 17 Jan 2020 |
 richvdh | In reply to @sorunome:sorunome.de
also, how come synapse implements m.login.jwt? Don't see anything of that in the specs, either because it got implemented by a community contribution. I'm not sure if it works or if it has ever been tested | 10:56:55 |
 Sorunome | In reply to @richvdh:sw1v.org
which doc https://github.com/matrix-org/synapse/blob/master/docs/password_auth_providers.md
"get_supported_login_types" and "check_auth" specify any type, not just m.login.password
| 10:57:12 |
| Sorunome | In reply to @richvdh:sw1v.org
well, the only thing that is valid to pass into m.login.token is something that synapse has generated just tested and it seems to be fully functional. However, it seems more like it should be part of m.login.token, as, in essence, it is just a token | 10:57:42 |
| richvdh | no, that's really not how token login is meant to work | 10:57:57 |
| richvdh | it sounds like you're implementing something which isn't m.login.token, which means you should use a different auth type | 10:59:24 |
| Sorunome | https://matrix.org/docs/spec/client_server/latest#token-based doesn't say anywhere at all what type of token the token is supposed to be | 10:59:45 |
| Sorunome | sounds like the spec is incomplete, then | 10:59:51 |
| Sorunome |
The server must encode the user id in the token. There is therefore no need for the client to submit a separate username.
Doesn't specify how at all
| 11:00:28 |
| richvdh | it's up to the server implementation | 11:01:02 |
| Sorunome | richvdh: exactly. Which means the docs for synapse auth provider is wrong, then, if it expects macrons and not any tokens | 11:01:19 |
| Sorunome | either way, something doesn't add up here | 11:01:32 |
| Sorunome | either the spec, or synapse, or both | 11:01:41 |
 jcgruenhage | Okay, so m.login.token tokens are supposed to be created and consumed by the homeserver, with the delivery being via some third party means? | 11:01:42 |
| richvdh | jcgruenhage: at the moment the only specced use of m.login.token is in https://matrix.org/docs/spec/client_server/latest#module-sso-login | 11:02:47 |
| richvdh | but the intention is that maybe there could be other ways of getting hold of a login token in the future, which is why the docs on token-based login are a little vague | 11:03:24 |
| * Sorunome has the feeling we are drifting away from what soru was originally asking | 11:03:31 |
| * Sorunome wonders if synapse-dev is a more accurate channel for one of the two questions | 11:03:56 |
| richvdh | the is that you can't just go and implement your own auth provider which claims to implement m.login.token but uses your own style of tokens | 11:04:49 |
| richvdh | * the point is that you can't just go and implement your own auth provider which claims to implement m.login.token but uses your own style of tokens | 11:05:00 |
| Sorunome | In reply to @richvdh:sw1v.org
the point is that you can't just go and implement your own auth provider which claims to implement m.login.token but uses your own style of tokens why? Which part of the spec prohibits that? | 11:05:31 |
| * Sorunome read it through multiple times and couldn't find any such segment | 11:05:46 |
| richvdh | the spec should say that m.login.token is for tokens generated by the homeserver | 11:06:51 |
| richvdh | I agree that https://matrix.org/docs/spec/client_server/latest#token-based is a bit misleading | 11:07:20 |
| Sorunome | In reply to @richvdh:sw1v.org
the spec should say that m.login.token is for tokens generated by the homeserver "should" say isn't the same as "does" say. So, consider this a spec bug report? | 11:08:05 |
| richvdh | file an issue then | 11:08:30 |
| Sorunome | https://github.com/matrix-org/matrix-doc/issues/2412 | 11:11:25 |
| jcgruenhage | That means that there currently is no way to log in to a spec compliant homeserver by possession of a token signed by a third party, because m.login.token is specifically a token created by the homeserver? | 11:11:43 |
| jcgruenhage | "spec compliant homeserver" is intentionally abstract, because (afaict) one like that can't exist, I'm not referring to any specific implementation there | 11:12:59 |
| richvdh | jcgruenhage: well, you'd have to make assumptions about the format of the token, which you can't do while conforming to the spec | 11:13:36 |
| richvdh | it begins to feel like you're looking for something like oauth, which is certainly a thing that the spec should support | 11:14:42 |
