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

MSC1960: OpenID information exchange with widgets #1960

Merged
merged 8 commits into from
Sep 20, 2020

Conversation

turt2live
Copy link
Member

@turt2live turt2live commented Apr 9, 2019

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 <travis@t2bot.io>

@turt2live turt2live added proposal-in-review proposal A matrix spec change proposal labels Apr 9, 2019
@turt2live turt2live changed the title Proposal for OpenID information exchange with widgets MSC1960: OpenID information exchange with widgets Apr 9, 2019
Copy link
Member

@jaywink jaywink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good 👍

@clokep
Copy link
Member

clokep commented Aug 11, 2020

@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://github.com/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 Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
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
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
@turt2live
Copy link
Member Author

@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.

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all sounds sane to me.

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
@richvdh
Copy link
Member

richvdh commented Aug 27, 2020

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Aug 27, 2020

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.

@mscbot 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
Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor clarifications, but overall looks good!

proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
proposals/1960-integrations-openid.md Outdated Show resolved Hide resolved
@turt2live turt2live removed the blocked Something needs to be done before action can be taken on this PR/issue. label Sep 5, 2020
@turt2live
Copy link
Member Author

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.

Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Show resolved Hide resolved
"widgetId": "CCCDDD",
"data": {
"state": "allowed",
"original_request_id": "AAABBB",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

```

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

mscbot commented Sep 15, 2020

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

@mscbot 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
@mscbot
Copy link
Collaborator

mscbot commented Sep 20, 2020

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

@mscbot 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 turt2live merged commit 5610436 into master Sep 20, 2020
@turt2live turt2live deleted the travis/msc/integrations/openid branch September 20, 2020 17:46
@turt2live 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 turt2live self-assigned this Sep 20, 2020
@turt2live 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 turt2live added the blocked Something needs to be done before action can be taken on this PR/issue. label Apr 6, 2021
Comment on lines +97 to +100
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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@toger5 toger5 Jul 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Something needs to be done before action can be taken on this PR/issue. integrations Integration (Manager) API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal spec-pr-in-review A proposal which has been PR'd against the spec and is in review widgets anything to do with widgets
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

8 participants