MSC1960: OpenID information exchange with widgets #1960

turt2live · 2019-04-09T03:23:59Z

Rendered
Upstream proposal: MSC1956 - Integrations API
Discussion room: #msc-integrations-api:t2bot.io

This is being contributed under the hat of "author of Dimension":

Signed-off-by: Travis Ralston <[email protected]>

jaywink

Looks very good 👍

clokep · 2020-08-11T18:20:52Z

@turt2live and I had a discussion about this a bit on Matrix, something somewhere needs to spec out a bit more how the client gets the OpenID credentials to pass to the widget. It was suggested something like https:/matrix-org/matrix-doc/pull/1961/files#diff-46763da5dcada9c6bd410e646df8390bR21 could be added.

I also wonder if this should be generalized a bit to broader SSO access? I'm not sure how hard that would be, but the current way that clients can login is a generic "SSO" type, not OpenID specifically.

proposals/1960-integrations-openid.md

Co-authored-by: David Baker <[email protected]> Co-authored-by: Andrew Morgan <[email protected]>

turt2live · 2020-08-21T14:39:31Z

@dbkr @anoadragon453 I've ruined your comment threads by making significant formatting changes to the diff, sorry. There's also some clarifications if @richvdh, @clokep, and @jaywink have a chance to review them.

richvdh

This all sounds sane to me.

proposals/1960-integrations-openid.md

richvdh · 2020-08-27T10:04:13Z

@mscbot fcp merge

mscbot · 2020-08-27T10:04:15Z

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

Concerns:

~~This is blocked on untangling the mess between MSC1236 and reality.~~

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

anoadragon453

Some minor clarifications, but overall looks good!

proposals/1960-integrations-openid.md

turt2live · 2020-09-05T21:00:33Z

right, so enough of the widget spec has been specified for this to get the clarifications it needed. Originally the success convention was introduced by implementations however it's clearly adding confusion here, so I've excluded it from the MSC and the spec itself is formalizing specific instances where success is needed rather than on everything.

Functionally the MSC is the same with this new wording, though most of it has been replaced with clearer (hopefully) words.

@richvdh @dbkr @anoadragon453 please take another read, which may involve skimming parts of the widget spec (see diff for links).

For now, I think my concern can be lifted:

@mscbot resolve This is blocked on untangling the mess between MSC1236 and reality.

anoadragon453

Sans some small details, I think I'm pretty happy with this as it stands.

anoadragon453 · 2020-09-15T09:38:59Z

proposals/1960-integrations-openid.md

+
+Widgets are currently left with no options to verify the user's ID, making it hard for
+personalized and authenticated widgets to exist. The spec says the `$matrix_user_id`
+template variable cannot be relied upon due to how easy it is to faslify, which is true.


Suggested change

template variable cannot be relied upon due to how easy it is to faslify, which is true.

template variable cannot be relied upon due to how easy it is to falsify, which is true.

proposals/1960-integrations-openid.md

dbkr · 2020-09-15T17:27:39Z

proposals/1960-integrations-openid.md

+ "widgetId": "CCCDDD",
+ "data": {
+ "state": "allowed",
+ "original_request_id": "AAABBB",


The mix of snake & camel case is unfortunate but this is probably the least terrible way of combining the two worlds.

yea, it's a mess. It is however consistent with the other API actions (which are also awful).

dbkr · 2020-09-15T17:29:59Z

proposals/1960-integrations-openid.md

+The request SHOULD result in the user being prompted to confirm that the widget can have
+their information. Because of this user interaction, it's not always possible for the user
+to complete the approval within the 10 second suggested timeout by the widget spec. As
+such, the initial request by the widget can have one of three states:


It feels a bit out-of-order that we're talking about the responses before we've seen what the request is.

dbkr · 2020-09-15T17:31:42Z

proposals/1960-integrations-openid.md

+```
+
+Which then receives a response which has a `state` field alongside potentially the credentials
+to be verified. Matching the order of possible responses above, here are examples:


I would probably have just talked about what responses at the same time as the examples rather than having the reader refer back up to the list of possible responses, but ok - the content is fine, probably not worth re-wording.

mscbot · 2020-09-15T17:33:31Z

🔔 This is now entering its final comment period, as per the review above. 🔔

mscbot · 2020-09-20T17:33:41Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

toger5 · 2023-07-19T12:37:05Z

proposals/1960-integrations-openid.md

+In the case of `state: "request"`, the user is being asked to approve the widget's attempt to
+verify their identity. To ensure that future requests are quicker, clients are encouraged to
+include a "remember this widget" option to make use of the immediate `state: "allowed"` or
+`state: "blocked"` responses above.


This seems to be redundant to what we have with the capability system. I would propose making this a capability as well. This would

give the widget developer the choice to ask the user for oidc permissions on first startup.

the client developer does not need to track oidc permissions + capabilitis but can treat oidc as a capability without any custom logic.

thinking further capabilites imply a rethinking of this:
to conform to the rest of the widget logic It seems It should be like this:

there should only be on action: fromWidget get_openId.

there should be a capability allow_open_id

it is the widgets responsibility to first aquire the capability. (the client is responsible to prompt the user with a clear explanation) -> then the token request via get_openid is instant and does not need two actions: one for asking for the token get_openid (which might already return a token but not necassarly) and another one for sending over the token openid_credentials.

In other words get_oidc seems to be equivalent to a request capabilites call with a confusing name.

Proposal for OpenID information exchange with widgets

e8de142

turt2live added proposal-in-review proposal A matrix spec change proposal labels Apr 9, 2019

turt2live changed the title ~~Proposal for OpenID information exchange with widgets~~ MSC1960: OpenID information exchange with widgets Apr 9, 2019

Assign MSC number

bd0211b

This was referenced Apr 9, 2019

MSC1958: Widget architecture changes #1958

Closed

[WIP] MSC1956: Integrations API (base) #1956

Draft

turt2live added the integrations Integration (Manager) API label Jun 20, 2019

turt2live mentioned this pull request Jun 29, 2019

Placeholder issue for "integrations API" implementation turt2live/matrix-dimension#262

Open

7 tasks

jaywink reviewed Aug 12, 2019

View reviewed changes

lampholder mentioned this pull request Oct 29, 2019

As a service provider I want to provide a default integration manager for users with accounts on a homeserver instance I manage element-hq/user-stories#8

Open

turt2live added the kind:feature MSC for not-core and not-maintenance stuff label Apr 20, 2020

dbkr reviewed Aug 21, 2020

View reviewed changes

richvdh reviewed Aug 21, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

anoadragon453 reviewed Aug 21, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

richvdh reviewed Aug 21, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

turt2live and others added 3 commits August 21, 2020 07:07

Apply suggestions from code review

6490fda

Co-authored-by: David Baker <[email protected]> Co-authored-by: Andrew Morgan <[email protected]>

Merge branch 'master' into travis/msc/integrations/openid

df74c7d

Various clarifications to structure

8021499

richvdh approved these changes Aug 27, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

mscbot added disposition-merge proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Aug 27, 2020

anoadragon453 reviewed Aug 27, 2020

View reviewed changes

dbkr reviewed Aug 27, 2020

View reviewed changes

proposals/1960-integrations-openid.md Show resolved Hide resolved

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

dbkr reviewed Aug 27, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

dbkr reviewed Aug 27, 2020

View reviewed changes

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved

turt2live removed the blocked Something needs to be done before action can be taken on this PR/issue. label Sep 5, 2020

anoadragon453 approved these changes Sep 15, 2020

View reviewed changes

dbkr reviewed Sep 15, 2020

View reviewed changes

mscbot added final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Sep 15, 2020

This was referenced Sep 16, 2020

Implement widget credentials request as per MSC1960 element-hq/element-android#2115

Open

Implement widget credentials request as per MSC1960 element-hq/element-ios#3654

Open

mscbot added finished-final-comment-period and removed disposition-merge final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. labels Sep 20, 2020

turt2live merged commit 5610436 into master Sep 20, 2020

turt2live deleted the travis/msc/integrations/openid branch September 20, 2020 17:46

turt2live added spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec and removed finished-final-comment-period labels Sep 20, 2020

turt2live self-assigned this Sep 20, 2020

turt2live added spec-pr-in-review A proposal which has been PR'd against the spec and is in review widgets anything to do with widgets and removed spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec labels Nov 23, 2020

turt2live added the blocked Something needs to be done before action can be taken on this PR/issue. label Apr 6, 2021

ShadowJonathan mentioned this pull request Feb 6, 2022

Widget Support ruma/ruma#861

Open

toger5 reviewed Jul 19, 2023

View reviewed changes

NicolasBuquet mentioned this pull request Feb 6, 2024

Etude : OpenID dans Tchap iOS tchapgouv/tchap-ios#965

Open

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC1960: OpenID information exchange with widgets #1960

MSC1960: OpenID information exchange with widgets #1960

turt2live commented Apr 9, 2019 •

edited

Loading

jaywink left a comment

clokep commented Aug 11, 2020

turt2live commented Aug 21, 2020

richvdh left a comment

richvdh commented Aug 27, 2020

mscbot commented Aug 27, 2020 •

edited by dbkr

Loading

anoadragon453 left a comment

turt2live commented Sep 5, 2020

anoadragon453 left a comment

anoadragon453 Sep 15, 2020

dbkr Sep 15, 2020

turt2live Sep 15, 2020

dbkr Sep 15, 2020

dbkr Sep 15, 2020

mscbot commented Sep 15, 2020

mscbot commented Sep 20, 2020

toger5 Jul 19, 2023

toger5 Jul 19, 2023 •

edited

Loading

	template variable cannot be relied upon due to how easy it is to faslify, which is true.
	template variable cannot be relied upon due to how easy it is to falsify, which is true.

MSC1960: OpenID information exchange with widgets #1960

MSC1960: OpenID information exchange with widgets #1960

Conversation

turt2live commented Apr 9, 2019 • edited Loading

jaywink left a comment

Choose a reason for hiding this comment

clokep commented Aug 11, 2020

turt2live commented Aug 21, 2020

richvdh left a comment

Choose a reason for hiding this comment

richvdh commented Aug 27, 2020

mscbot commented Aug 27, 2020 • edited by dbkr Loading

anoadragon453 left a comment

Choose a reason for hiding this comment

turt2live commented Sep 5, 2020

anoadragon453 left a comment

Choose a reason for hiding this comment

anoadragon453 Sep 15, 2020

Choose a reason for hiding this comment

dbkr Sep 15, 2020

Choose a reason for hiding this comment

turt2live Sep 15, 2020

Choose a reason for hiding this comment

dbkr Sep 15, 2020

Choose a reason for hiding this comment

dbkr Sep 15, 2020

Choose a reason for hiding this comment

mscbot commented Sep 15, 2020

mscbot commented Sep 20, 2020

toger5 Jul 19, 2023

Choose a reason for hiding this comment

toger5 Jul 19, 2023 • edited Loading

Choose a reason for hiding this comment

turt2live commented Apr 9, 2019 •

edited

Loading

mscbot commented Aug 27, 2020 •

edited by dbkr

Loading

toger5 Jul 19, 2023 •

edited

Loading