Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IS interactions proxied through the HS also need terms agreement #10525

Open
jryans opened this issue Aug 8, 2019 · 7 comments

Comments

@jryans
Copy link
Member

commented Aug 8, 2019

There are several places where we send data to the IS via the HS, such as:

  • Adding 3PIDs at registration
  • Adding 3PIDs in settings

These currently don't trigger terms on use in Riot because they don't happen directly with the IS and the HS is not aware of terms yet... In any case, we need to get user agreement for these flows as well.

@jryans

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2019

@turt2live

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

Do they? Wouldn't the homeserver ToS take care of this?

@jryans

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2019

Hmm, it seems at the very least unclear and confusing... I don't think we want to force HS admins to participate in a formal data processing arrangement with the ISes, so it would seem we'd need to get user consent for any operation that can flow to the IS.

@lampholder

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

Very quickly thinking about this:

It's right that (at the present time) we don't want the HS admin to have a formal DPA with the IS provider. The relationship should be:

  • between the user and the homeserver
  • between the user and the identity server

When the user makes a request to the identity server that is proxied via the homeserver (there are a few of these) then:

  • the data being shared with the homeserver should be covered by the homeserver's relationship with the user
  • the client arranges an IS access token directly with the identity server and agrees to terms with the IS as needed
  • the client passes this IS access token to the homeserver for interacting with the identity server on the user's behalf
  • the homeserver should use this token to check that the user has read and agreed to the terms of service before it sends any personal data (in the same way that the client does)
  • if the homeserver discovers that the user has not agreed to the terms of serivce, it should reject the request
@jryans

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

After another look at the MSC, the client is meant to send the is_token to the HS for requests that the HS proxies to the IS, so this implies the client will contact the IS directly to work out a valid token first, and then pass that to the HS.

I have edited @lampholder's bullets above to match.

@jryans

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

It seems clear how to proceed, so I have removed the blocked label.

@jryans jryans self-assigned this Aug 13, 2019

@jryans jryans added this to In Progress in Workflow via automation Aug 13, 2019

@jryans jryans removed their assignment Aug 13, 2019

@jryans jryans removed this from In Progress in Workflow Aug 13, 2019

@jryans jryans self-assigned this Aug 19, 2019

@jryans jryans added this to In Progress in Workflow via automation Aug 19, 2019

@jryans

This comment has been minimized.

Copy link
Member Author

commented Aug 20, 2019

Based on discussion in the Synapse issue, it looks like the APIs to consider here are:

  • /account/3pid/email/requestToken
  • /account/3pid/msisdn/requestToken
  • /rooms/{roomId}/invite for 3PID invites

jryans added a commit to matrix-org/matrix-js-sdk that referenced this issue Aug 22, 2019

Send id_access_token to HS for use in proxied IS requests
This passes along the `id_access_token` to the HS, which it will need when
speaking v2 IS APIs to the IS.

Unfortunately, some HSes seem to explode when given this new parameter, so we
only pass it along for the moment if an unstable feature `m.id_access_token` is
also set.

Part of vector-im/riot-web#10525
Defined in MSC2140

jryans added a commit to matrix-org/matrix-react-sdk that referenced this issue Aug 22, 2019

Add IS access token callback
This passes a callback to the JS SDK which it can use to get IS access tokens
whenever needed for either talking to the IS directly or passing along to the
HS.

Fixes vector-im/riot-web#10525

@jryans jryans moved this from In Progress to In Review in Workflow Aug 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.