From 204732099bb98ebed02eee8b546a9f10de805b21 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Mon, 9 Nov 2020 12:11:07 +0000 Subject: [PATCH 01/29] Multiple SSO Identity Providers --- .../2857-Multiple-SSO-Identity-Providers.md | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 proposals/2857-Multiple-SSO-Identity-Providers.md diff --git a/proposals/2857-Multiple-SSO-Identity-Providers.md b/proposals/2857-Multiple-SSO-Identity-Providers.md new file mode 100644 index 00000000..ced0ff3b --- /dev/null +++ b/proposals/2857-Multiple-SSO-Identity-Providers.md @@ -0,0 +1,92 @@ +# MSC2857: Multiple SSO Identity Providers + +Matrix already has generic SSO support, but it does not yield the best user experience especially for +instances which wish to offer multiple identity providers. This MSC provides a simple and fully +backwards compatible way to extend the current spec which would allow clients to give users options +like `Continue with Google` and `Continue with Github` side-by-side. + + +## Proposal + +Currently, Matrix supports `m.login.sso`, `m.login.token` and `/login/sso/redirect` for clients to +pass their user to the configured Identity provider and for them to come back with something which +is exchangeable for a Matrix access token. This flow offers no insight to the user as to what +Identity providers are available. It allows clients to offer a super generic `Sign in with SSO` +button only. + +By augmenting the `m.login.sso` flow discovery definition to include metadata on the supported IDPs +the client can show a button for each of the supported providers, yielding a much more usable +experience. This would look like this: + +```json +{ + "flows": [ + { + "type": "m.login.sso", + "identity_providers": [ + { + "id": "google", + "name": "Google", + "icon": "mxc://..." + }, + { + "id": "github", + "name": "Github", + "icon": "mxc://..." + } + ] + }, + { + "type": "m.login.token" + } + ] +} +``` + +A new endpoint would be needed to support redirecting directly to one of the IDPs: + +`GET /_matrix/client/r0/login/sso/redirect/{idp_id}` + +This would behave identically to the existing endpoint without the last argument +except would allow the server to forward the user directly to the correct IDP. + +For the case of User Interactive Auth the server would just give the appropriate +identity provider as an option, that being the same as the user used to login with. + +For the case of backwards compatibility the existing endpoint should remain, +and if the server supports multiple SSO IDPs it should offer the user a page +which lets them choose between the available IDP options as a fallback. + + +## Potential issues + +None discovered at this time + + +## Alternatives + +An alternative to the whole approach would be to allow `m.login.sso.$idp` but this forces +treating an opaque identifier as hierarchical and offers worse backwards compatibility. + +An alternative to the proposed backwards compatibility plan where the server offers a +fallback page which fills the gap and lets the user choose which SSO IDP they need is +for the server to deterministically always pick one, maybe the first option and let +old clients only auth via that one but that means potentially locking users out of their +accounts. + + +## Security considerations + +This could potentially aid phishing attacks by bad homeservers, where if the app says +`Continue with Google` and then they are taken to a page which is styled to look like +the Google login page they might be a tiny bit more susceptible to being phished as opposed +as to when they click a more generic `Sign in with SSO` button, but this attack was possible +anyhow using a different vector of a controlled Element/client instance which modifies +the text. + + +## Unstable prefix + +Whilst in development use `msc2857.identity_providers` for the flow discovery and `/unstable` +for the new endpoints. + From a7eba773beeb6d12206ce1cbd04290fc96806f95 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Mon, 9 Nov 2020 12:14:57 +0000 Subject: [PATCH 02/29] Fix MSC number --- ...y-Providers.md => 2858-Multiple-SSO-Identity-Providers.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{2857-Multiple-SSO-Identity-Providers.md => 2858-Multiple-SSO-Identity-Providers.md} (96%) diff --git a/proposals/2857-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md similarity index 96% rename from proposals/2857-Multiple-SSO-Identity-Providers.md rename to proposals/2858-Multiple-SSO-Identity-Providers.md index ced0ff3b..b018fb66 100644 --- a/proposals/2857-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -1,4 +1,4 @@ -# MSC2857: Multiple SSO Identity Providers +# MSC2858: Multiple SSO Identity Providers Matrix already has generic SSO support, but it does not yield the best user experience especially for instances which wish to offer multiple identity providers. This MSC provides a simple and fully @@ -87,6 +87,6 @@ the text. ## Unstable prefix -Whilst in development use `msc2857.identity_providers` for the flow discovery and `/unstable` +Whilst in development use `msc2858.identity_providers` for the flow discovery and `/unstable` for the new endpoints. From 20645365f4a2f65e21ed2fc01fb36a0b069e9057 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Thu, 12 Nov 2020 12:50:37 +0000 Subject: [PATCH 03/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2858-Multiple-SSO-Identity-Providers.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index b018fb66..96c9d3b6 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -87,6 +87,5 @@ the text. ## Unstable prefix -Whilst in development use `msc2858.identity_providers` for the flow discovery and `/unstable` +Whilst in development use `org.matrix.msc2858.identity_providers` for the flow discovery and `/_matrix/client/unstable/org.matrix.msc2858/login/sso/redirect/{idp_id}` for the new endpoints. - From a391a4a05db4c4bc5be3eace721441e215ed39f0 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Fri, 13 Nov 2020 11:41:06 +0000 Subject: [PATCH 04/29] Iterate the MSC --- .../2858-Multiple-SSO-Identity-Providers.md | 53 ++++++++++++++++--- 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index b018fb66..5d202921 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -27,12 +27,12 @@ experience. This would look like this: { "id": "google", "name": "Google", - "icon": "mxc://..." + "icon": "https://..." }, { "id": "github", "name": "Github", - "icon": "mxc://..." + "icon": "https://..." } ] }, @@ -43,19 +43,58 @@ experience. This would look like this: } ``` +The `id` field would be opaque with the accepted characters matching unreserved URI characters +as defined in [RFC3986](http://www.ietf.org/rfc/rfc3986.txt) - this was chosen to avoid +having to encode special characters in the URL. Max length 128. Defined as: +``` +ALPHA DIGIT "-" / "." / "_" / "~" +``` + +The `name` field should be the human readable string intended for printing by the client. + +The `icon` field is the only optional field and should point to an icon representing the IdP. + + A new endpoint would be needed to support redirecting directly to one of the IDPs: `GET /_matrix/client/r0/login/sso/redirect/{idp_id}` This would behave identically to the existing endpoint without the last argument -except would allow the server to forward the user directly to the correct IDP. +except would allow the server to forward the user directly to the correct IdP. + +For the case of backwards compatibility the existing endpoint should remain, +and if the server supports multiple SSO IDPs it should offer the user a page +which lets them choose between the available IdP options as a fallback. For the case of User Interactive Auth the server would just give the appropriate identity provider as an option, that being the same as the user used to login with. +An example UIA 401 response is shown below: +```json +{ + "session": "session_id", + "flows":[ + { + "stages": ["m.login.sso"] + } + ], + "params": { + "m.login.sso": { + "identity_providers": [ + { + "id": "google", + "name": "Google", + "icon": "https://..." + } + ] + } + } +} +``` -For the case of backwards compatibility the existing endpoint should remain, -and if the server supports multiple SSO IDPs it should offer the user a page -which lets them choose between the available IDP options as a fallback. +The exact format of `identity_providers` is kept between Login flows and UIA, +this allows better code reuse and in future for multiple IdPs to map to the +same Matrix account and the user having the ability to use either to complete +UIA. ## Potential issues @@ -69,7 +108,7 @@ An alternative to the whole approach would be to allow `m.login.sso.$idp` but th treating an opaque identifier as hierarchical and offers worse backwards compatibility. An alternative to the proposed backwards compatibility plan where the server offers a -fallback page which fills the gap and lets the user choose which SSO IDP they need is +fallback page which fills the gap and lets the user choose which SSO IdP they need is for the server to deterministically always pick one, maybe the first option and let old clients only auth via that one but that means potentially locking users out of their accounts. From f444273a4202da2c44416a9352e90dde75507648 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Fri, 13 Nov 2020 12:00:45 +0000 Subject: [PATCH 05/29] be stricter on the icon url --- proposals/2858-Multiple-SSO-Identity-Providers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index d7321d36..e3d3059c 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -53,6 +53,7 @@ ALPHA DIGIT "-" / "." / "_" / "~" The `name` field should be the human readable string intended for printing by the client. The `icon` field is the only optional field and should point to an icon representing the IdP. +If present then it must be an HTTPS URL to an image resource of type `image/png` or `image/svg+xml`. A new endpoint would be needed to support redirecting directly to one of the IDPs: From 8ac23599b28d104927e263809e1bd8999e30a9fe Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Thu, 19 Nov 2020 09:36:34 +0000 Subject: [PATCH 06/29] Iterate MSC based on feedback --- proposals/2858-Multiple-SSO-Identity-Providers.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index e3d3059c..75f377cb 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -53,7 +53,8 @@ ALPHA DIGIT "-" / "." / "_" / "~" The `name` field should be the human readable string intended for printing by the client. The `icon` field is the only optional field and should point to an icon representing the IdP. -If present then it must be an HTTPS URL to an image resource of type `image/png` or `image/svg+xml`. +If present then it must be an HTTPS URL to an image resource. This should be hosted by the +homeserver service provider to not leak the client's IP address unnecessarily. A new endpoint would be needed to support redirecting directly to one of the IDPs: From 153c55788dfae7bee858c945de5cac650f7a7e26 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Thu, 26 Nov 2020 10:47:05 +0000 Subject: [PATCH 07/29] Add more explanation --- proposals/2858-Multiple-SSO-Identity-Providers.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 75f377cb..c87279cb 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -12,7 +12,10 @@ Currently, Matrix supports `m.login.sso`, `m.login.token` and `/login/sso/redire pass their user to the configured Identity provider and for them to come back with something which is exchangeable for a Matrix access token. This flow offers no insight to the user as to what Identity providers are available. It allows clients to offer a super generic `Sign in with SSO` -button only. +button only. With the currently possible solutions and workarounds the experience is far from great +and user's have to blindly click `Sign in with SSO` without any clue as to what's hiding on the other +side of the door. Some users will definitely not be familiar with `SSO` but will be with the concept of +"Continue with Google" or similar. By augmenting the `m.login.sso` flow discovery definition to include metadata on the supported IDPs the client can show a button for each of the supported providers, yielding a much more usable From c7063a4eeca073ecc9cac0368381e8b7338d98fd Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Mon, 18 Jan 2021 09:30:07 +0000 Subject: [PATCH 08/29] Iterate PR based on feedback --- .../2858-Multiple-SSO-Identity-Providers.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index c87279cb..4787fbe5 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -30,12 +30,12 @@ experience. This would look like this: { "id": "google", "name": "Google", - "icon": "https://..." + "icon": "mxc://..." }, { "id": "github", "name": "Github", - "icon": "https://..." + "icon": "mxc://..." } ] }, @@ -46,18 +46,13 @@ experience. This would look like this: } ``` -The `id` field would be opaque with the accepted characters matching unreserved URI characters -as defined in [RFC3986](http://www.ietf.org/rfc/rfc3986.txt) - this was chosen to avoid -having to encode special characters in the URL. Max length 128. Defined as: -``` -ALPHA DIGIT "-" / "." / "_" / "~" -``` +The `id` field is a string using the common identifier grammar as defined in +https://github.com/matrix-org/matrix-doc/pull/2858. The `name` field should be the human readable string intended for printing by the client. The `icon` field is the only optional field and should point to an icon representing the IdP. -If present then it must be an HTTPS URL to an image resource. This should be hosted by the -homeserver service provider to not leak the client's IP address unnecessarily. +If present then it must be an MXC URI to an image resource. A new endpoint would be needed to support redirecting directly to one of the IDPs: @@ -67,7 +62,7 @@ A new endpoint would be needed to support redirecting directly to one of the IDP This would behave identically to the existing endpoint without the last argument except would allow the server to forward the user directly to the correct IdP. -For the case of backwards compatibility the existing endpoint should remain, +For the case of backwards compatibility the existing endpoint is to remain, and if the server supports multiple SSO IDPs it should offer the user a page which lets them choose between the available IdP options as a fallback. From 8be6540eaf8c456b0ab99222b58516f012d587e3 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Tue, 19 Jan 2021 13:43:49 +0000 Subject: [PATCH 09/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 4787fbe5..05ecfa4d 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -47,7 +47,7 @@ experience. This would look like this: ``` The `id` field is a string using the common identifier grammar as defined in -https://github.com/matrix-org/matrix-doc/pull/2858. +https://github.com/matrix-org/matrix-doc/pull/2758. The `name` field should be the human readable string intended for printing by the client. From 85ccf93c6a73d377e38c1adb3d04dcf5c2c9ed19 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Tue, 19 Jan 2021 13:52:57 +0000 Subject: [PATCH 10/29] Remove UIA stuff --- .../2858-Multiple-SSO-Identity-Providers.md | 33 +++---------------- 1 file changed, 4 insertions(+), 29 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 4787fbe5..de6b1e2c 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -66,35 +66,10 @@ For the case of backwards compatibility the existing endpoint is to remain, and if the server supports multiple SSO IDPs it should offer the user a page which lets them choose between the available IdP options as a fallback. -For the case of User Interactive Auth the server would just give the appropriate -identity provider as an option, that being the same as the user used to login with. -An example UIA 401 response is shown below: -```json -{ - "session": "session_id", - "flows":[ - { - "stages": ["m.login.sso"] - } - ], - "params": { - "m.login.sso": { - "identity_providers": [ - { - "id": "google", - "name": "Google", - "icon": "https://..." - } - ] - } - } -} -``` - -The exact format of `identity_providers` is kept between Login flows and UIA, -this allows better code reuse and in future for multiple IdPs to map to the -same Matrix account and the user having the ability to use either to complete -UIA. +For the case of User Interactive Auth the server would just give the standard +SSO flow option without any identity_providers as there is no method for +a client to choose an idp within that flow at this time nor is it as +essential. ## Potential issues From 277ff682d67e403697c2bafb7586796ccb8486c4 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 27 Jan 2021 12:33:16 +0000 Subject: [PATCH 11/29] Formatting tweaks --- .../2858-Multiple-SSO-Identity-Providers.md | 50 ++++++++++++------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 504c29f8..e95f7989 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -1,25 +1,30 @@ # MSC2858: Multiple SSO Identity Providers Matrix already has generic SSO support, but it does not yield the best user experience especially for -instances which wish to offer multiple identity providers. This MSC provides a simple and fully +instances which wish to offer multiple identity providers (IdPs). This MSC provides a simple and fully backwards compatible way to extend the current spec which would allow clients to give users options like `Continue with Google` and `Continue with Github` side-by-side. - -## Proposal - Currently, Matrix supports `m.login.sso`, `m.login.token` and `/login/sso/redirect` for clients to pass their user to the configured Identity provider and for them to come back with something which is exchangeable for a Matrix access token. This flow offers no insight to the user as to what -Identity providers are available. It allows clients to offer a super generic `Sign in with SSO` -button only. With the currently possible solutions and workarounds the experience is far from great +Identity providers are available: clients can offer only a very generic `Sign in with SSO` +button. With the currently possible solutions and workarounds the experience is far from great and user's have to blindly click `Sign in with SSO` without any clue as to what's hiding on the other side of the door. Some users will definitely not be familiar with `SSO` but will be with the concept of "Continue with Google" or similar. -By augmenting the `m.login.sso` flow discovery definition to include metadata on the supported IDPs -the client can show a button for each of the supported providers, yielding a much more usable -experience. This would look like this: +## Proposal + +We extend the [login +flow](https://matrix.org/docs/spec/client_server/r0.6.1#login) to allow clients +to choose an SSO Identity provider before control is handed over to the server. + +### Extensions to login flow discovery + +The response to [`GET /_matrix/client/r0/login`](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-login) +is extended to **optionally** include an `identity_providers` property for +flows whose type `m.login.sso`. This would look like this: ```json { @@ -46,16 +51,22 @@ experience. This would look like this: } ``` -The `id` field is a string using the common identifier grammar as defined in -https://github.com/matrix-org/matrix-doc/pull/2758. +The value of the `identity_providers` property is a list, each entry consisting +of an object with the following fields: + + * The `id` field is **required**. It should be a string using the common + identifier grammar as defined in + https://github.com/matrix-org/matrix-doc/pull/2758. -The `name` field should be the human readable string intended for printing by the client. + * The `name` field is **required**. It should be the human readable string + intended for printing by the client. -The `icon` field is the only optional field and should point to an icon representing the IdP. -If present then it must be an MXC URI to an image resource. + * The `icon` field is **optional**. It should point to an icon representing + the IdP. If present then it must be an MXC URI to an image resource. +### Extend the `/login/sso/redirect` endpoint -A new endpoint would be needed to support redirecting directly to one of the IDPs: +A new endpoint is added to support redirecting directly to one of the IdPs: `GET /_matrix/client/r0/login/sso/redirect/{idp_id}` @@ -63,15 +74,16 @@ This would behave identically to the existing endpoint without the last argument except would allow the server to forward the user directly to the correct IdP. For the case of backwards compatibility the existing endpoint is to remain, -and if the server supports multiple SSO IDPs it should offer the user a page +and if the server supports multiple SSO IdPs it should offer the user a page which lets them choose between the available IdP options as a fallback. +### Notes on user-interactive auth + For the case of User Interactive Auth the server would just give the standard -SSO flow option without any identity_providers as there is no method for -a client to choose an idp within that flow at this time nor is it as +SSO flow option without any `identity_providers` as there is no method for +a client to choose an IdP within that flow at this time nor is it as essential. - ## Potential issues None discovered at this time From 0c18f8363612e704f9723a5495750230ab77fa5c Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 27 Jan 2021 12:45:11 +0000 Subject: [PATCH 12/29] grammar clarifications --- .../2858-Multiple-SSO-Identity-Providers.md | 20 +++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index e95f7989..f7dad705 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -54,12 +54,20 @@ flows whose type `m.login.sso`. This would look like this: The value of the `identity_providers` property is a list, each entry consisting of an object with the following fields: - * The `id` field is **required**. It should be a string using the common - identifier grammar as defined in - https://github.com/matrix-org/matrix-doc/pull/2758. - - * The `name` field is **required**. It should be the human readable string - intended for printing by the client. + * The `id` field is **required**. It is an opaque string chosen by the + homeserver implementation, and uniquely identifies the identity provider on + that server. Clients should not infer any semantic meaning from the + identifier. The identifier should be between 1 and 255 characters in length, + and should consist of the characters matching unreserved URI characters as + defined in [RFC3986](http://www.ietf.org/rfc/rfc3986.txt): + + ``` + ALPHA DIGIT "-" / "." / "_" / "~" + ``` + + * The `name` field is **required**. It should be a human readable string + intended for printing by the client. No explicit length limit or grammar is + specified. * The `icon` field is **optional**. It should point to an icon representing the IdP. If present then it must be an MXC URI to an image resource. From 09d41c59b9b682a7fad66929887d12be0ef1a588 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 27 Jan 2021 13:00:12 +0000 Subject: [PATCH 13/29] add 'brand' --- .../2858-Multiple-SSO-Identity-Providers.md | 27 +++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index f7dad705..a503678d 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -35,12 +35,14 @@ flows whose type `m.login.sso`. This would look like this: { "id": "google", "name": "Google", - "icon": "mxc://..." + "icon": "mxc://...", + "brand": "org.matrix.google" }, { "id": "github", "name": "Github", - "icon": "mxc://..." + "icon": "mxc://...", + "brand": "org.matrix.github" } ] }, @@ -72,6 +74,27 @@ of an object with the following fields: * The `icon` field is **optional**. It should point to an icon representing the IdP. If present then it must be an MXC URI to an image resource. + * The `brand` field is **optional**. It allows the client to style the login + button to suit a particular brand. It should be a string matching the + "Common namespaced identifier grammar" as defined in + [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). + + Initially the following identifiers are specified: + * `org.matrix.gitlab` + * `org.matrix.github` + * `org.matrix.apple` + * `org.matrix.google` + * `org.matrix.facebook` + * `org.matrix.twitter` + + Server implementations are free to add additional brands, though they should + be mindful of clients which do not recognise any given brand. + + Clients are free to implement any set of brands they wish, including all or + any of the above, but are expected to apply a sensible unbranded fallback + for any brand they do not recognise/support. + + ### Extend the `/login/sso/redirect` endpoint A new endpoint is added to support redirecting directly to one of the IdPs: From 84346055e9138b658f8706983f610b6c58cd5578 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 27 Jan 2021 15:22:03 +0000 Subject: [PATCH 14/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Michael Telatynski <7t3chguy@gmail.com> --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index a503678d..981eb4bf 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -72,7 +72,7 @@ of an object with the following fields: specified. * The `icon` field is **optional**. It should point to an icon representing - the IdP. If present then it must be an MXC URI to an image resource. + the IdP. If present then it must be an MXC URI to an image resource. * The `brand` field is **optional**. It allows the client to style the login button to suit a particular brand. It should be a string matching the From ba08c9fe36c4c7c7a9f657cfcb3636482e775457 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 27 Jan 2021 16:47:49 +0000 Subject: [PATCH 15/29] notes on and alternatives --- .../2858-Multiple-SSO-Identity-Providers.md | 29 +++++++++++++++--- proposals/images/2858-login.png | Bin 0 -> 12618 bytes 2 files changed, 25 insertions(+), 4 deletions(-) create mode 100644 proposals/images/2858-login.png diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 981eb4bf..65877c00 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -94,6 +94,8 @@ of an object with the following fields: any of the above, but are expected to apply a sensible unbranded fallback for any brand they do not recognise/support. + Where `icon` and `brand` are both present, it is recommended that clients + which support the `brand` give precedence to `brand` over `icon`. ### Extend the `/login/sso/redirect` endpoint @@ -115,10 +117,6 @@ SSO flow option without any `identity_providers` as there is no method for a client to choose an IdP within that flow at this time nor is it as essential. -## Potential issues - -None discovered at this time - ## Alternatives @@ -131,6 +129,29 @@ for the server to deterministically always pick one, maybe the first option and old clients only auth via that one but that means potentially locking users out of their accounts. +### Styling information as an alternative to `brand` + +The `brand` field is intended to allow clients to style "login" buttons according +to the identity provider in question. For example, a mobile application might +show: + +![login buttons](images/2858-login.png) + +Some identity providers have very specific rules about how such buttons should +be presented, so a fine level of control is important. + +An alternative way to achieve this would be for the server to give full details +about the styling: icon, font colour, border colour, background colour, +etc. However, this soon becomes unscalable. For example, it might be desirable +to offer each logo at a range of resolutions to suit different screen sizes. +Likewise, some brands need different styling depending on the background +colour, so a complete second set of colours must be specified to account for +dark or light themes. + +## Potential issues + + * New Identity Providers added by server administators will be unbranded until + clients adopt support for the new brand. ## Security considerations diff --git a/proposals/images/2858-login.png b/proposals/images/2858-login.png new file mode 100644 index 0000000000000000000000000000000000000000..0d0a06f618c9416219ecdad9857462b33b6dfe8a GIT binary patch literal 12618 zcma*O1yq&M*Y1mg2vVB{$xSLLt#petQqtYsAt|*fN$CzLVbk4>bW2N@GzduD#s9nK zj`N){?l+EOFa-9ydDmKVuKCP&J-;2QDE}Vg#mg562nZM-q{KfWAUweaUl=IJ;5V=Q zlx)F&NKT?3R8YV_FBD@K0s6a&$4SJ4_IF3*#>WBVkVw6zI zXX5d%Fe6{h6qCUZUg@mo*OYST$n%x;xt2DXURNvd9h{kO@2*Ek_wg#@Gk+}cr%HVB zB2Y$(k|sJ3;@FmvmbQPim?32NRib}5PE6|5yL3}C<7}aAWsW`&>+{jd{XyxAAW>)_ zWDV`3g3Gf&$Yg3D3_?YPLnR7>Nx@K{R8&x^Kp5=*{+F&)L43TtS9eFgqfJMxB&Gjk z(FnqW^78VE%7P(E*o1`dEi7K==jV6#^+jpuaxLd0{5@J3^}XNrtu!5edH>h$fuL%R z)WM{HF{DdGL19!yT?|%OK4(qJ?;id2E9TFiKR>m2UKDQj;ZucRQJCKRJy>*KkF@?( zZZN^X7+BBi!B75kaImPPWPMQYo}HGKmO6pVNw#~{er#q&($%#V2?nVO95>IauEq=K zXzvJke&Ws#F5wWjw6rw0wl+SPuZh$A0PUV;78K0*^5toSBsF)cO}C>_u#}!2MOcoa zqT-t(d^}O@yN}As6?4{8Gc#X5N!p&gfJ)*~PzY_2y+p-^ii>~e6xY)W2st@9k0)dvM7+F6XZ6~GRTab}9a#zpM-M>K1R-(IW#F@C3wf1NCp8X;gQ{xJ;Zl=@wKb{3m+0C3oft6$dNge?B}-Po!AwErL3k#@GUbG)>>F2 z{?CS6Q>&Nf!N}H;owlckhK@$Ogtw~m*h&6!(FyD1OjHI} zg9;#+83m>pGHPdGvHGjRsJpuxF zNRh>RmgF1v=Bj4BR<^cVAel%(65ILSEP%`%A0HQSbaZq_eO@yC@}7f@2p!az^|R}p z{e84H@%3&r5ej8 zweiHd`49D&GDrJjsNY{_c|EU7@P4PMnliq(zkhP=#eegsYBit4?Pyuf#Kfe&gw0DG zDfs@Wo2%=ZGcQ}RY+^NvrlzL3g@wU*j>KvW4LUNSWNwUViQ38eq(aCb=JPRe_ZHo+ zbU#_MN2BK9AuLrJY`Yz7`+a%SaQ|=rH6x>#5?*Xv99YQs#Kg&kg~8kF zv$<*uTvSw48W5(qxPSp;!>(YAS7DtA%v#4ccaP)ux%(%x74@l9t+KLGN=mBTu;Pu` z2&sIgpq#QYE^>f>ef?WqU3Q5G?fwkCItyZl{A&6LzZ$ zwEm$XW02T87ykxZ;jdmS)Y?$LdzajF*vLpa)n!D(#l_V=*1j)>B@no9&}x2b4EFGk zPZd=Brl;+QSmh4ul8d&Nv_`MHz|bT?<|79@snHycQxNn}a@&Q&S-;nTLa7Tca9)b! zKW@KkzS{RCsYsJAFk0``@;Du^dtb%Nk)R82qY)0)U`hzr)heAi){Yz{$rwEGP%FVN zndUWZ7}Xope-o$|rK&5dr{wEudbrrYe|pRVi>y&}*myO|qSq^zpI!YW>nJf(Qz~KM;TCpwiImue z1jNfzpWO+YVQ;PGzkjC#a^5*=h5|KB0I6MTvmj|>!wmLQuI&~^7HCYe zPjs7GTQiuoY891~{MAY@;Hqp3pO^?xmDs2~_%n{ln@iM6bMo?xr_@kn--vfZ{}?AsyvOPsU=MO`Cy88z+9A!ry?jcD2au$=xl6@ zMcgEmO#Rv+L~2aX?{wUDQR^YRJ?KoY{);HABuPH%Cr-HSI8KCKE7{V-rcv-f{Z=T_ z0iyduHO96T>*(@K2&5{4*M$6g(@|gjYOPX$v9=La>rd+X<$vjqy@*tK71`0(%j5L7 z+?EY&Vl-o(Px9ArMgRJLC`p4DdLHwnb-1m)g7*D}ne?K^=&L{XuX2ggWP^5}WAB*L zkBtkioq%_3T;iTe^GL$x7&b_0HX^cUsRALnF%WD~@r|%Qe27^YsbN0Dyyqn|S;Iqg z8)w*m4#kW3znms6v0sYAEEx8nIVo|llNq>v<4voKsfQ&y`#AFr&i9*p%%d_#ZTP)j z0~$>?C+_rN1TQn<8FdtH)%A%|L1>AbY4!DN)-Wr~)Flw21gS}Y{WR|^HzoTXsrQ5u z+~=(u!BMNg)o2FYhI7`y07VLh8T;M1&!QmFJPLm zorKbM_t_SNz(tnk8`sr;2W_~24$%`&W~a0MtOWctZ`|=_d&g-(Ow{Vd_wSn(B~iD! z3+d6a&^o*%bl$9ZeOtdiKO%Y|XnUzt>4wzd0wxVBG%PiDBFstVtF}sLt3@8IEltD- z8_P-`%eoEcnyYTOPHOdJ-9fMSxqN|ynE6%68*wzVc9qZZjb&yjyOwZC`20oBG%W)( zCnFB#=|k}5{5a#tnD+kPXzi-X@CRYHVX7$yCzj7XSr<=R^NpRFck zJ|>@4vYxY^a(m@72nw@PdAD3RVr!B+Yl*iS+ypHoe|F6lQvl`#` z`7<~ln|IXVJ?{HtNH%v!ODxWVYQKe4gUoIg3b)M+n)A_BWznIT6kU<~C+WqVEf;M{ zJ(_H{!;;k+b4UvdiUp(ZwLZyawPIds!9#=;Ot_6+E%_bJe|vn5mM&Y%#d}IibnR!O z;hA{%x7GTqTi<{CoVi`?TaFns3&*h^#d;RTeN?0` z_+7#uX4dz)P?kQWBvYQl&9g9J4x8ZSY`BBh=ljFy>Qr5^e$`Q#8!UEaMR>)Qf_?6A-d-@jEX z(pg1MSi z?!bUpdNj;qWQ=Y2i?%4@U7?{7>V-6H2nmes_iu!bvTPBR8ZJzm4nxkfs!q9mFz4k{ zq2NI)$FuP~6LhjFEXb|)<$GCK5a~iV;Wq>Go37}|(4!61TQe)R#ak23r5#b@xgCgZlJFmy|&G`Hekt-!z z6YL#zfhu#qMTbx=lVI4q@1rtPFY~k5&}bZ9k9k*9f`F1H6mkR`A`BJJf+uDfLAvHs z$8?%r+zN`;3aUs_r^Ks#(Mi7|89`vEo@-b|7#os#Z&R@bFQR*^FUG<1%w=sXqie6) zdFpi$(t)ceHwl9b)BKmtY@;*wF{b{eJaQ2&A^!~9+wIijKkitgA$-R?Gq{etCYS^0 zI5lk8zDuv;mp08Qd`N2sA}l6#b`pJ2M@KFd88AiPz{>R5{?+hg>#^ZcLhHhXm8tL1 zmYka zJ=MD`&fy8@>7c3!loJ|8Z1cu}|yA>7|I7 zM{E1n-dCeDYeHI|2VA;`AQxKA*&QN_b`Ly1=_w5AuLsS;WfbY@awp7Do!!>>e2_M& zHD2iRo@CmI$Hj#DOuuv&D$&}spdR5 z`$6)JDXg&6p-}l_9|K)rQa0!7GnO0csqzXj8fL`1u<68f8-~E7Ik4@hJnecDS1`a+y3r+f_ao#PB z^&|+9#vx!ECfL{G3G&V(F^uikY?w(LBV;VB=T_FHhwUW{{K$o@F%(=qCFOPS7gHrv z^rFVni6Exh*1Rbyv`wG-i3s*l@he#r3%Uot#iPv28ya-1CXK z*B;U&Aow-SI{6mzp`y}q*GrUMG>(Kysj;lS@;i;V*F7b<9fDuHINI#DA$mr++PyTC zbhUsrwBwWUGeUvb-=|ld5Af;2aZ45V_;!;K^<1^0<9|;Ro9(8ol)U_9zDBx|`^^=K zl_(jxdD1&)BrTVj!>(?hkg~7}aMP2U>?AH7oJ=kYz~=I(XMXgVkLe6B$XWULMhiBD z{~aBEMQ*#KQ$>mD7gmhcd}Dy&S|FEHv++!87uFn>VA{r%VZRg+_NS4aWJS*XNDi>RTbN zs9Yt)x(|;})viD2J{Xx?wd`?_@!wTp^$*H!#5BP-d-3PgE2Sq>)Jo_&EKPMM#+E4s zeGzJ2oO0mqQrMrs;a=jFj!gNCg!WyD1oq9}(<^Jxo?K-<*s&IUsIb;{!+05)(lyQe zLn~QK*-D7jPC!)GluCx+JNu3bN-(A1jFi$Y3-ZSw8Jhf4EY120qfW`tOfMM3Mqx-W%4S zrROB(yYT|v-{W4Be7fV0Q+luc!+P=^_UllBFoN&)gBKnM)z0Y09eR6j?f>wz(Fynq zN7sL%wyX);c*nM3M$gUz4NiYP;<)9-YBqA|*jRzqqALUTvyZP|@jNCTtuPpFP{RP; z*2t!@H=%r;XjhQnNZQdeeIHBGS(Xn4<^~L4!h4OFU(;TCDo$q2I-c#3N~>={D6H~I zMh6bXB40`SDadoi#p{26L!VqV>@CKe#^r&|i|L6wc`3Vsj_ry9&t8eCv z7oITq#BL{9?7!SQeY^C+wa?6mVCjwpVTNgNL#F2}w1!AYkgV=as&jRQC1Shj<=E0T zdgiRqPRHionABvc=4tnFbfbdz9S0Xiq2sw~CH8MyR`tssUxdWmel!pDlNHor0qHmR_Ja#g6ZC z5}jw>HFhUCn{zSndLpwCRTDX9lBK5VL#cbD<&1dti11NQOwTT= zG4PAXOzEfg&L84xtm&iFZg71M174R%0i>tUR+V^vT{x6cAVY4Su)=wqA7P8GyS(^q zKu*x>AG*AmHM6Gcf3J#)jyg@ILfkU;8+=JKkV{g?L`aCuL47z0mP7=?+Ew)XPW!B_ zq_1PnX=$;|;&t6}^ytatLE4Xfux%%1xcWn$lQg&)VL$vEvOx-f3jT5nZXJmE z%<^R;jBWqZW&SfJo%r7O?^C{SJ!hn|9tujqO0RE!@HkjUmD6X?Oyb=`bZ_BSzhW8w zxrW|)bHPREVz%*wA6iBZ)~VvU%t}Ko$#rghA{{&^(=aS0f1mNWziGiG74W#O(O4p< zDA?nBVt!D4HZl^|?cEp^4s_~JJE~eVFo`Y)hblmx_4(KI?e>Z@qXe7Bt1_)}lrW&( z_>@b;zykQs*#j|$xFIw0M?r6Ha6WSLX$YB#jrwSS&lE<}n>-*Jo;oG{sGcqIU2Dw^ zF*do$vBs-gsttI|q~6MU(C#7SN^|l-!SovbSck|^urar?`J_K3rE|W<#{~|=X(djB zlQ%T{?7f|E#5%9U8C5A~uxL_f~MaBP@PXE{O$>TACai`3a`a2O#GQoLL zpXMhG71Z6bIkSaH6eZMMIbv|7$o({j5ZD66hI?X2-6*pHfLI_y0*SvDNen8@ZyLI6UR(_a54Thftg~iYRQhvU}gZ3#*`>h z@b}^6H!HFc^1~!9h^xf#0aIp)554w&w>6(ykmDqu(tHfZ#fWFFcb;U^qwJ2sy~Y!pRyu=qu)N zy6k*gCc{xxFgI|*!lPO9qU3%8;mOto=6gLW(tCmwu2P&1A9zCO% zrW8+|z6{bU`5imk0U@ek5H)`-%NdPbvObT8OC~RLX5=zdw>M^?;@otbcA!31 zY_Lj-h_-ePZk6`uBnL^1CYiIFn6uE|gH4lH+h^o_kZC8G$`WcgUesXv)&E*;seTls z8+t!Cp3){(XDki%E&;Qa{Ct1ti)z~BH2xS8pvDEYeI%Sapy@(T~Mwn-z^R{891W+LV@qrSt5>UUmV6Nj-)?CQdGeNmGX zG(5Tr`&m&@S~?(_j%(-Vp0|2e31zG(cgw<8wsJacogPi1y>IVtd(QEvAG799>u(wq zFB=0=r{Tnhw{=4OeKstvobPfp$WC52@xT@c4ILVvz=isgeOQSrcpcZziMSX9Ez_@( zdi;2VLk8cs49mDg5mu>5GzRwlfJ{T45UG5*Z5Z&MrC7`Eyps81?7rK>vyYsk^X>KO z{!#a&wpc$8myrMqK53JFZ=sUGLy1;J-~L6narYR1mZD3?2e$|U z0W><6o#|h!Z;MK1a~0TejMR_MJuRk+DriWQiiBqmR@*-u=OvXFLtFb~q$3hksuK3d zu_9k``M)JAT_XRJ`$Gm>E+y$LxZ6pj>EYn$iiVxy_*vC+Z>~ zKrS9x05z%9u0Bu_IBK7*{os?m{Oj8_>un&tKkk`)$?G2_blG_7WFknE&);6ermJVe zG-yj_v7Wm_BSohQQf`IhH#n{oq3u7#qke{p9HGf&s~1hz6xDUW^3}P~>^v>HUH>8e zIqWI|UPqR{o)*|o6K?7DeT76{FFek>%30Tsg$=`K28VxJLEc3bDN8}ND>{W^dOFD= zN05#^HJJb}#_>pK)gl&>Y?)GT9I<RYKf1JkI?kd zh5{d@i|?peOkN%n3%Eu9rHAviHYDG^eOvU{PR~UiNHU@d%NhIi3pQ=}4Lqt75Fd{G zS!yDTGTTUh-G?6Y^QW|Y2LHf(jTL>(qbH%|<;7p34yWVd!cQIMHUy>upda+PQ#D$> zuJhCsf!xZ-$(iWu`_0eKV-H4@@U1%z$RCOhNlNBo2Xwr#Bu=LP|Bw%L>lI=!ZD1t- zs<9#@WI?xKPEJi71g5u$t}eN0)wQ&$1PWVd4mlWMIq(;O_w)|%9KHi5+Zms~f>p`z z{;Sb|2)qNlX^0YD5HKl2C~kj0=j7pu`eX_m|9Wkf4BvYXR2=B{?MAYirqk z@4a~W_+GQHY$cmz7;OIh2F%Z$|JCpR znCh*qg7WFS5+)|JfOTj-=_LUUu>KpOtC_mip1tW3z!WrJ%xK+C3fk*WYK)`LcjE*i)e|@zcRpou-TGp`jGQ)H4HMjLI z$f0y-GIZ}uJXni3m$)RKif#mCYu&=Yz(7MDW2N;RJ9w|Gk`lISQ#u$E;4k_Vd`@v6 z-(71x*BRw=PObk61yDMCu77^_5bEVMHl_&Ou3~|JAR{B&H!ZF1W9nI5J(QG`Xw+EZ zgXAz8PT{his|*7CfnEc}mwGCYz3a)`tjhcJnK`en?(V}oJ%CBR=sYR+_{D!dCI(FE zD35fL!GsEsAX~$!eJNa4{UF4xtv*9%z}k0Pba)=ce~NN_ef{X3=gTC1)X^auzr<0` z1pESk3xMN{j#a)4_A|As5(6Wn$K{fn|4EH@_pftLfe!uX+FI^KTON=;(BmJ8_c(=6>>wT~$IqX!Q&c|)X#N4xkDo8$eICRK8BGLv3wT5~hM zmmozdkKNWcbzM}f6oxQS;H3&ZT#tJE+bwwK`iID~B_k(?s)3IK6%6PV6H~WoRZtTI zggibWAvQ7by`v*LsB3Y5J#^uhIc1RmsR0+PR4p95O_wLeO7_nopz`qWcw7?m8qL_) z*f+_t&9|q6AeqpKUc_83e`Y16L;%3mW7Qfjp7>GaxG4=B^4@(opfA2Wf*K$ho)t`f zP*NJF-F9|!oBZ|5U5Qd#9^5!v5vE)qzv|lb&i$AYL=uJK(zC_u_N4F6Vnf`>h`iwK zv6!c)=cfk8%?+OqY@0bV=@p-t9zz2P$lpJ6T|&2ALW%$_@$&MzatA04NZRwif5Ei+ zRvzwFstme<%~dUC9-*9$=M)! z70B(u+#As$Me?W+n}u2+DwwUO-{9qd7f~845zSUKZzhEQ_^}a0s9SG5kpxf!pq1yB zm&zYMc6MP2@t1jMdGCo50a0-#amKLe)1^mUCM4I&gL8qab|32AW`K10che}Ku&77*B2`= zjs{`~JzUkj0`J-$1m;!2qrAuzpbVyiZ`O5QnJMV}bq81jy!NG?9PNGCUvu^M5uN)N zYpzWNjV}#TLM>r|UV>hPBddbtB%99o(9!(1tkzmne)_0YJAtT=-kd4Z$roQKght$2 z&&XzeXaHn~TJ*X?rZLs=c*{j#fp(y7r>vpzC?JLt?Kl;AxiVdePebzV+j3$3Y$VyPJxtf{U zXV8OPUyu5Z6swjz?y}v30~1iP0p)hKPVtcBvOiPdy!#RK4L~#!bv;oN2YY}}0lQ zfb{dLtYim$%JuOL80ury1B!4KY3CIHY7^&63`9i4M zB`JwKtK&unYAYex1IUftot-QY(*JZTllV8SYd^zuVMut@Q#gt4NREE`gok%+`8UI} zL_W5k%w8DCVHyq~qYHa7GR%I6h9s*1Iti2+0M4*@`d;i!;}H<7UEWv#&)ShbBI#4w#h=%@bCR;3|e{{6Z zobzBEqyASi;>OYqZw}8 zzKH2vU~s=8UZPp`5fF}Gu>%7GkN10fdygqCB_$>6e@t7N-2J-%IO=c5hO2+GZSpcQ zGFSDp`xpVtJ# zpcOYQEDVA%&|we=AqT$;EcU?=!Loc-jj329Y=v%69Y~3pgf%oQQL}+Mg~lyWB3-2h zBn;u=;sTV73ed5D`T0s(T6~5c0Ueau>G%SMM%Yw(}Ep4RPy!6*T*g;x_6H zsNi=1vkc3zKU{oA{`pUZJ>mNyextGqOFDTy?qwwH9j@+>CFt9g@1}bQr>3U50p>U`GV;B; z`n=Kv*lg%%9%+Gi&uUaPDMYo0dvU48k4ChEe-Z`!B;vrQU=B<&uEg{EZ=n2tkU7t4 z&C)+jjNMEdC+>KKp=`PbMhvVNO%ifnd2`oB4l@$cIEE$pLAXEqdp4QSD1eL0DUk;#mn7QNq z6ZtX#$|P|i-GIye-#rljUwt@0(<4m}1sk<=*fe#I7X|vAZFl6qf281n!tEo+1Iz34 SWANb!gbxz(;$@=xU;ZCi^u5sl literal 0 HcmV?d00001 From 6badb3b6d8f69abf342a50742cf5be3b37739555 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 1 Mar 2021 19:19:41 +0000 Subject: [PATCH 16/29] Notes on OAuth2 and unknown idps --- proposals/2858-Multiple-SSO-Identity-Providers.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 65877c00..c12e5ab9 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -110,6 +110,10 @@ For the case of backwards compatibility the existing endpoint is to remain, and if the server supports multiple SSO IdPs it should offer the user a page which lets them choose between the available IdP options as a fallback. +If the `idp_id` is unrecognised, the server should display some sort of error +page to the user. (A protocol whereby an error can be returned to the original +client could be a matter for a future improvement, but is out of scope for now.) + ### Notes on user-interactive auth For the case of User Interactive Auth the server would just give the standard @@ -129,6 +133,12 @@ for the server to deterministically always pick one, maybe the first option and old clients only auth via that one but that means potentially locking users out of their accounts. +[MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964) proposes +replacing much of Matrix's authentication mechanism with OAuth2.0. If that is +adopted, then the Matrix client would not be able to specify an authentication +mechanism; rather it is left up to the server to host pages allowing the user +to choose their authentication mechanism. + ### Styling information as an alternative to `brand` The `brand` field is intended to allow clients to style "login" buttons according From ba3e204a4840e84619b6c6a0ba4c0a6fbfa3536b Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Mon, 1 Mar 2021 22:25:45 +0000 Subject: [PATCH 17/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Matthew Hodgson --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index c12e5ab9..298911b1 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -10,7 +10,7 @@ pass their user to the configured Identity provider and for them to come back wi is exchangeable for a Matrix access token. This flow offers no insight to the user as to what Identity providers are available: clients can offer only a very generic `Sign in with SSO` button. With the currently possible solutions and workarounds the experience is far from great -and user's have to blindly click `Sign in with SSO` without any clue as to what's hiding on the other +and users have to blindly click `Sign in with SSO` without any clue as to what's hiding on the other side of the door. Some users will definitely not be familiar with `SSO` but will be with the concept of "Continue with Google" or similar. From dce9c9f09a6a5fd4b5d04426bd1e2d75b0a4e167 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 2 Mar 2021 19:13:36 +0000 Subject: [PATCH 18/29] Move the idp `brand` assignments out to a registry --- README.rst | 4 +- .../2858-Multiple-SSO-Identity-Providers.md | 31 +++++++----- registry/m.login.sso_brand.md | 49 +++++++++++++++++++ 3 files changed, 72 insertions(+), 12 deletions(-) create mode 100644 registry/m.login.sso_brand.md diff --git a/README.rst b/README.rst index 61c27f15..8b04d8da 100644 --- a/README.rst +++ b/README.rst @@ -25,10 +25,12 @@ Structure of this repository contained in the specification, along with example JSON files. - ``meta``: documents outlining the processes involved when writing documents, e.g. documentation style, guidelines. +- ``registry``: Lists of identifiers for use in various parts of the Matrix protocol. - ``scripts``: scripts to generate formatted versions of the documentation, typically HTML. - ``specification``: the specification split up into sections. + .. _OpenAPI: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md .. _JSON Schema: http://json-schema.org/ @@ -66,7 +68,7 @@ The above will write the rendered version of the specification to Windows users ~~~~~~~~~~~~~ -The ``source`` program does not exist on Windows, so instead run one of the +The ``source`` program does not exist on Windows, so instead run one of the ``activate`` files in ``.\env\Scripts\`` to activate the virtual environment. If you're on Windows Vista or higher, be sure that the "Symbolic Links" diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 298911b1..791efc1f 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -79,20 +79,16 @@ of an object with the following fields: "Common namespaced identifier grammar" as defined in [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). - Initially the following identifiers are specified: - * `org.matrix.gitlab` - * `org.matrix.github` - * `org.matrix.apple` - * `org.matrix.google` - * `org.matrix.facebook` - * `org.matrix.twitter` + A registry of brand identifiers is maintained at + [`matrix-doc/registry/m.login.sso_brand.md`](../registry/m.login.sso_brand.md). Contributors + are encouraged to add more brands to the registry. Server implementations are free to add additional brands, though they should be mindful of clients which do not recognise any given brand. Clients are free to implement any set of brands they wish, including all or - any of the above, but are expected to apply a sensible unbranded fallback - for any brand they do not recognise/support. + any of the brands listed in the registry, but are expected to apply a + sensible unbranded fallback for any brand they do not recognise/support. Where `icon` and `brand` are both present, it is recommended that clients which support the `brand` give precedence to `brand` over `icon`. @@ -175,5 +171,18 @@ the text. ## Unstable prefix -Whilst in development use `org.matrix.msc2858.identity_providers` for the flow discovery and `/_matrix/client/unstable/org.matrix.msc2858/login/sso/redirect/{idp_id}` -for the new endpoints. +Whilst in development use `org.matrix.msc2858.identity_providers` for the flow +discovery and +`/_matrix/client/unstable/org.matrix.msc2858/login/sso/redirect/{idp_id}` for +the new endpoints. + +When identity providers are listed under the experimental +`org.matrix.msc2858.identity_providers` field of the response to `/login`, +(instead of `identity_providers`), different values for the `brand` field are +used. In particular the following were defined: + * `org.matrix.gitlab` (now `com.gitlab`). + * `org.matrix.github` (now `com.github`). + * `org.matrix.apple` (now `com.apple`). + * `org.matrix.google` (now `com.google`). + * `org.matrix.facebook` (now `com.facebook`). + * `org.matrix.twitter` (now `com.twitter`). diff --git a/registry/m.login.sso_brand.md b/registry/m.login.sso_brand.md new file mode 100644 index 00000000..a001ab8e --- /dev/null +++ b/registry/m.login.sso_brand.md @@ -0,0 +1,49 @@ +# `m.login.sso` `brand` identifier registry + +The following is a list of identifiers for use in the optional `brand` field of the +`identity_providers` property of the response to the [`GET /_matrix/client/r0/login` +endpoint](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-login). + +This field was originally proposed in +[MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858). + +Links to other organisations' branding guidelines are provided on an +informational basis, to help client developers understand the expected +behaviour. No guarantee is given as to their accuracy, and each client author +remains responsible for maintaining their application according to the latest +best practices. + +## Assignments + + + + * Identifier: `com.apple` + Description: "Sign in with Apple". See + https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. + * Identifier: `com.facebook` + Description: "Continue with Facebook". See + https://developers.facebook.com/docs/facebook-login/web/login-button/. + * Identifier: `com.github` + Description: Logos available at https://github.com/logos. + * Identifier: `com.gitlab`: + Description: Login in via the hosted https:/gitlab.com SaaS platform. + * Identifier: `com.google`: + Description: "Sign in with Google". See + https://developers.google.com/identity/branding-guidelines. + * Identifier: `com.twitter` + Description: "Log in with Twitter". See + https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. + + + +## Requesting updates to the list + +Members of the community wishing to add new brands to this list are encouraged +to open a pull request to update the list. + +Contributors are reminded that identifiers for the `brand` field should follow +the [common textual identifier +grammar](https://github.com/matrix-org/matrix-doc/blob/rav/proposals/textual_identifier_grammar/proposals/2758-textual-id-grammar.md). From 434d686b2dfa15a217b5325d89b4ee74c8443f14 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 2 Mar 2021 19:16:48 +0000 Subject: [PATCH 19/29] fix up markdown --- registry/m.login.sso_brand.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/registry/m.login.sso_brand.md b/registry/m.login.sso_brand.md index a001ab8e..b25983e3 100644 --- a/registry/m.login.sso_brand.md +++ b/registry/m.login.sso_brand.md @@ -21,24 +21,34 @@ that way! --> * Identifier: `com.apple` + Description: "Sign in with Apple". See https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. + * Identifier: `com.facebook` + Description: "Continue with Facebook". See https://developers.facebook.com/docs/facebook-login/web/login-button/. + * Identifier: `com.github` + Description: Logos available at https://github.com/logos. - * Identifier: `com.gitlab`: + + * Identifier: `com.gitlab` + Description: Login in via the hosted https:/gitlab.com SaaS platform. - * Identifier: `com.google`: + + * Identifier: `com.google` + Description: "Sign in with Google". See https://developers.google.com/identity/branding-guidelines. + * Identifier: `com.twitter` + Description: "Log in with Twitter". See https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. - ## Requesting updates to the list Members of the community wishing to add new brands to this list are encouraged From 2d4da148d8d5f3a162690ece46ea14b44dbe508f Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 2 Mar 2021 19:19:45 +0000 Subject: [PATCH 20/29] more fix markdown --- proposals/2858-Multiple-SSO-Identity-Providers.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 791efc1f..7da2811c 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -180,9 +180,10 @@ When identity providers are listed under the experimental `org.matrix.msc2858.identity_providers` field of the response to `/login`, (instead of `identity_providers`), different values for the `brand` field are used. In particular the following were defined: - * `org.matrix.gitlab` (now `com.gitlab`). - * `org.matrix.github` (now `com.github`). - * `org.matrix.apple` (now `com.apple`). - * `org.matrix.google` (now `com.google`). - * `org.matrix.facebook` (now `com.facebook`). - * `org.matrix.twitter` (now `com.twitter`). + + * `org.matrix.gitlab` (now `com.gitlab`). + * `org.matrix.github` (now `com.github`). + * `org.matrix.apple` (now `com.apple`). + * `org.matrix.google` (now `com.google`). + * `org.matrix.facebook` (now `com.facebook`). + * `org.matrix.twitter` (now `com.twitter`). From 9a4e821ddc4c3a6a59940632c742ef22f58641df Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 2 Mar 2021 19:20:29 +0000 Subject: [PATCH 21/29] fix link --- registry/m.login.sso_brand.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/registry/m.login.sso_brand.md b/registry/m.login.sso_brand.md index b25983e3..1def73bd 100644 --- a/registry/m.login.sso_brand.md +++ b/registry/m.login.sso_brand.md @@ -36,7 +36,7 @@ that way! * Identifier: `com.gitlab` - Description: Login in via the hosted https:/gitlab.com SaaS platform. + Description: Login in via the hosted https://gitlab.com SaaS platform. * Identifier: `com.google` From 62cc76f28bce8f10936c84b4933b09fce6b8faaf Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 3 Mar 2021 11:32:07 +0000 Subject: [PATCH 22/29] Move sequence diagram into doc --- proposals/2858-Multiple-SSO-Identity-Providers.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 7da2811c..192b094b 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -18,7 +18,12 @@ side of the door. Some users will definitely not be familiar with `SSO` but will We extend the [login flow](https://matrix.org/docs/spec/client_server/r0.6.1#login) to allow clients -to choose an SSO Identity provider before control is handed over to the server. +to choose an SSO Identity provider before control is handed over to the +server. The following sequence diagram illustrates the proposed, updated, login flow: + + + +![Sequence diagram](https://user-images.githubusercontent.com/2403652/104897523-61fb4b00-5970-11eb-88f7-9fc0956b33a2.png) ### Extensions to login flow discovery From a596efdf8bd08c7f60f591779f100d36656b341f Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 3 Mar 2021 11:51:25 +0000 Subject: [PATCH 23/29] Get rid of the registry for now it should just be a proposal. We can add the registry later. --- README.rst | 4 +- .../2858-Multiple-SSO-Identity-Providers.md | 37 +++++++++++- registry/m.login.sso_brand.md | 59 ------------------- 3 files changed, 35 insertions(+), 65 deletions(-) delete mode 100644 registry/m.login.sso_brand.md diff --git a/README.rst b/README.rst index 8b04d8da..61c27f15 100644 --- a/README.rst +++ b/README.rst @@ -25,12 +25,10 @@ Structure of this repository contained in the specification, along with example JSON files. - ``meta``: documents outlining the processes involved when writing documents, e.g. documentation style, guidelines. -- ``registry``: Lists of identifiers for use in various parts of the Matrix protocol. - ``scripts``: scripts to generate formatted versions of the documentation, typically HTML. - ``specification``: the specification split up into sections. - .. _OpenAPI: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md .. _JSON Schema: http://json-schema.org/ @@ -68,7 +66,7 @@ The above will write the rendered version of the specification to Windows users ~~~~~~~~~~~~~ -The ``source`` program does not exist on Windows, so instead run one of the +The ``source`` program does not exist on Windows, so instead run one of the ``activate`` files in ``.\env\Scripts\`` to activate the virtual environment. If you're on Windows Vista or higher, be sure that the "Symbolic Links" diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 192b094b..3dbc8aa4 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -84,9 +84,11 @@ of an object with the following fields: "Common namespaced identifier grammar" as defined in [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). - A registry of brand identifiers is maintained at - [`matrix-doc/registry/m.login.sso_brand.md`](../registry/m.login.sso_brand.md). Contributors - are encouraged to add more brands to the registry. + To reduce confusion over which indentifier should be used for each brand + (for example: should "Sign in with Microsoft" be `com.microsoft` or + `com.azure`?), it is proposed to maintain a registry of identifiers outside + the core specification document, avoiding the need for a full MSC to add + entries to the list. An initial list of proposed identifiers is given below. Server implementations are free to add additional brands, though they should be mindful of clients which do not recognise any given brand. @@ -122,6 +124,35 @@ SSO flow option without any `identity_providers` as there is no method for a client to choose an IdP within that flow at this time nor is it as essential. +### Proposed initial identifiers for the `brand` indentifier + + * Identifier: `com.apple` + + Description: "Sign in with Apple". See + https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. + + * Identifier: `com.facebook` + + Description: "Continue with Facebook". See + https://developers.facebook.com/docs/facebook-login/web/login-button/. + + * Identifier: `com.github` + + Description: Logos available at https://github.com/logos. + + * Identifier: `com.gitlab` + + Description: Login in via the hosted https://gitlab.com SaaS platform. + + * Identifier: `com.google` + + Description: "Sign in with Google". See + https://developers.google.com/identity/branding-guidelines. + + * Identifier: `com.twitter` + + Description: "Log in with Twitter". See + https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. ## Alternatives diff --git a/registry/m.login.sso_brand.md b/registry/m.login.sso_brand.md deleted file mode 100644 index 1def73bd..00000000 --- a/registry/m.login.sso_brand.md +++ /dev/null @@ -1,59 +0,0 @@ -# `m.login.sso` `brand` identifier registry - -The following is a list of identifiers for use in the optional `brand` field of the -`identity_providers` property of the response to the [`GET /_matrix/client/r0/login` -endpoint](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-login). - -This field was originally proposed in -[MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858). - -Links to other organisations' branding guidelines are provided on an -informational basis, to help client developers understand the expected -behaviour. No guarantee is given as to their accuracy, and each client author -remains responsible for maintaining their application according to the latest -best practices. - -## Assignments - - - - * Identifier: `com.apple` - - Description: "Sign in with Apple". See - https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. - - * Identifier: `com.facebook` - - Description: "Continue with Facebook". See - https://developers.facebook.com/docs/facebook-login/web/login-button/. - - * Identifier: `com.github` - - Description: Logos available at https://github.com/logos. - - * Identifier: `com.gitlab` - - Description: Login in via the hosted https://gitlab.com SaaS platform. - - * Identifier: `com.google` - - Description: "Sign in with Google". See - https://developers.google.com/identity/branding-guidelines. - - * Identifier: `com.twitter` - - Description: "Log in with Twitter". See - https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. - - -## Requesting updates to the list - -Members of the community wishing to add new brands to this list are encouraged -to open a pull request to update the list. - -Contributors are reminded that identifiers for the `brand` field should follow -the [common textual identifier -grammar](https://github.com/matrix-org/matrix-doc/blob/rav/proposals/textual_identifier_grammar/proposals/2758-textual-id-grammar.md). From 178cbe1c3a88966330caf2186e75c89cb3e56f42 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 3 Mar 2021 18:50:27 +0000 Subject: [PATCH 24/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Travis Ralston --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 3dbc8aa4..3e08888d 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -84,7 +84,7 @@ of an object with the following fields: "Common namespaced identifier grammar" as defined in [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). - To reduce confusion over which indentifier should be used for each brand + To reduce confusion over which identifier should be used for each brand (for example: should "Sign in with Microsoft" be `com.microsoft` or `com.azure`?), it is proposed to maintain a registry of identifiers outside the core specification document, avoiding the need for a full MSC to add From 1ba0c39b1433e15390096bc21e3a3acc9f99db60 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 9 Mar 2021 14:33:39 +0000 Subject: [PATCH 25/29] Change the brand identifiers again --- .../2858-Multiple-SSO-Identity-Providers.md | 54 ++++++++++++------- 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 3e08888d..d3f31694 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -41,13 +41,13 @@ flows whose type `m.login.sso`. This would look like this: "id": "google", "name": "Google", "icon": "mxc://...", - "brand": "org.matrix.google" + "brand": "google" }, { "id": "github", "name": "Github", "icon": "mxc://...", - "brand": "org.matrix.github" + "brand": "github" } ] }, @@ -80,16 +80,28 @@ of an object with the following fields: the IdP. If present then it must be an MXC URI to an image resource. * The `brand` field is **optional**. It allows the client to style the login - button to suit a particular brand. It should be a string matching the - "Common namespaced identifier grammar" as defined in - [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). + button to suit a particular brand. It should be a string using the following + grammar: + + * Must be at least one character and no more than 255 characters in length. + * Must start with one of the characters `[a-z]`, and be entirely composed + of the characters `[a-z]`, `[0-9]`, `-`, `_` and `.`. To reduce confusion over which identifier should be used for each brand - (for example: should "Sign in with Microsoft" be `com.microsoft` or - `com.azure`?), it is proposed to maintain a registry of identifiers outside + (for example: should "Sign in with Microsoft" be `microsoft` or + `azure`?), it is proposed to maintain a registry of identifiers outside the core specification document, avoiding the need for a full MSC to add entries to the list. An initial list of proposed identifiers is given below. + [Rationale: this grammar is based on the + [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758), removing the + requirements for a namespaced heirarchy. In + [discussion](https://github.com/matrix-org/matrix-doc/pull/2858#discussion_r565506802), + it was agreed that a separate registry was seen as important for a + lightweight process by which implementations can agree on identifiers. The + registry makes the namespacing of MSC2758 redundant; the namespacing system + was also somewhat confusing.] + Server implementations are free to add additional brands, though they should be mindful of clients which do not recognise any given brand. @@ -126,34 +138,38 @@ essential. ### Proposed initial identifiers for the `brand` indentifier - * Identifier: `com.apple` + * Identifier: `apple` Description: "Sign in with Apple". See https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. - * Identifier: `com.facebook` + * Identifier: `facebook` Description: "Continue with Facebook". See https://developers.facebook.com/docs/facebook-login/web/login-button/. - * Identifier: `com.github` + * Identifier: `github` Description: Logos available at https://github.com/logos. - * Identifier: `com.gitlab` + * Identifier: `gitlab` Description: Login in via the hosted https://gitlab.com SaaS platform. - * Identifier: `com.google` + * Identifier: `google` Description: "Sign in with Google". See https://developers.google.com/identity/branding-guidelines. - * Identifier: `com.twitter` + * Identifier: `twitter` Description: "Log in with Twitter". See https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. +When considering a new identifier for private use, administrators should pick +some sensible name follosing the advice of [RFC6648 sec +3](https://tools.ietf.org/html/rfc6648#section-3). + ## Alternatives An alternative to the whole approach would be to allow `m.login.sso.$idp` but this forces @@ -217,9 +233,9 @@ When identity providers are listed under the experimental (instead of `identity_providers`), different values for the `brand` field are used. In particular the following were defined: - * `org.matrix.gitlab` (now `com.gitlab`). - * `org.matrix.github` (now `com.github`). - * `org.matrix.apple` (now `com.apple`). - * `org.matrix.google` (now `com.google`). - * `org.matrix.facebook` (now `com.facebook`). - * `org.matrix.twitter` (now `com.twitter`). + * `org.matrix.gitlab` (now `gitlab`). + * `org.matrix.github` (now `github`). + * `org.matrix.apple` (now `apple`). + * `org.matrix.google` (now `google`). + * `org.matrix.facebook` (now `facebook`). + * `org.matrix.twitter` (now `twitter`). From 7871da7565fb9e4384936838f87d6c47952d12b6 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 9 Mar 2021 16:53:16 +0000 Subject: [PATCH 26/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md Co-authored-by: Hubert Chathi --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index d3f31694..f57ec995 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -167,7 +167,7 @@ essential. https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. When considering a new identifier for private use, administrators should pick -some sensible name follosing the advice of [RFC6648 sec +some sensible name following the advice of [RFC6648 sec 3](https://tools.ietf.org/html/rfc6648#section-3). ## Alternatives From d5166ebc1a3caf848a91c3d299fbc2d27678fd28 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 9 Mar 2021 18:04:19 +0000 Subject: [PATCH 27/29] Update proposals/2858-Multiple-SSO-Identity-Providers.md --- proposals/2858-Multiple-SSO-Identity-Providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index f57ec995..5bd440d1 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -154,7 +154,7 @@ essential. * Identifier: `gitlab` - Description: Login in via the hosted https://gitlab.com SaaS platform. + Description: Logos available at https://about.gitlab.com/press/press-kit/. * Identifier: `google` From 49f7624d554ab672ac6d6f94d9a0f641c2194548 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 9 Mar 2021 18:07:37 +0000 Subject: [PATCH 28/29] update brand descriptions --- proposals/2858-Multiple-SSO-Identity-Providers.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 5bd440d1..825771fe 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -138,14 +138,19 @@ essential. ### Proposed initial identifiers for the `brand` indentifier +The following identifiers are proposed for the initial content of the `brand` +identifier registry. The descriptions are guidelines to help server +administrators pick a suitable brand identifier, and to help client authors +style buttons in their clients. + * Identifier: `apple` - Description: "Sign in with Apple". See + Description: Suitable for "Sign in with Apple": see https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/. * Identifier: `facebook` - Description: "Continue with Facebook". See + Description: "Continue with Facebook": see https://developers.facebook.com/docs/facebook-login/web/login-button/. * Identifier: `github` @@ -158,12 +163,12 @@ essential. * Identifier: `google` - Description: "Sign in with Google". See + Description: Suitable for "Google Sign-In": see https://developers.google.com/identity/branding-guidelines. * Identifier: `twitter` - Description: "Log in with Twitter". See + Description: Suitable for "Log in with Twitter": see https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1. When considering a new identifier for private use, administrators should pick From a8a7acce1e8b17521a1ef6dae93e7e8e7881d7f6 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 9 Mar 2021 18:10:17 +0000 Subject: [PATCH 29/29] update UIA --- proposals/2858-Multiple-SSO-Identity-Providers.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/proposals/2858-Multiple-SSO-Identity-Providers.md b/proposals/2858-Multiple-SSO-Identity-Providers.md index 825771fe..1e49d070 100644 --- a/proposals/2858-Multiple-SSO-Identity-Providers.md +++ b/proposals/2858-Multiple-SSO-Identity-Providers.md @@ -131,10 +131,11 @@ client could be a matter for a future improvement, but is out of scope for now.) ### Notes on user-interactive auth -For the case of User Interactive Auth the server would just give the standard -SSO flow option without any `identity_providers` as there is no method for -a client to choose an IdP within that flow at this time nor is it as -essential. +No change is proposed to the SSO flow for User-Interactive Authentication. + +For a reauthentication operation, the server implementation is free to choose +any suitable IdP to authenticate the user. (Often, this will simply be +the IdP that the user logged in with.) ### Proposed initial identifiers for the `brand` indentifier