Users can't use IdPs outside of the ones enumerated by RPs
TL;DR there is a significant amount of context at the start of this issue before we get to the proposal, here is a [google doc version](https://docs.google.com/document/d/1zxRFhF6qwGTCOYZ6UwTutbXVyRiD3krXyfFkcp_6t98/edit) for an alternative form. # Background The origins of many federated identity technologies have deep ties to providing an open ecosystem of IDPs to give End Users ample choice in how they choose to “login”. Efforts like OpenID v1 and v2, SIOP, Mozilla Persona, CHAPI, and others, strongly embodied these principles and much of this has remained in future revisions of standards such as OpenID Connect core. However, due to numerous complex issues, much of the industry today, primarily around the “social login” market has consolidated leaving a few IDPs as the dominant market players. To counteract this, FedCM in this work on establishing new browser mechanisms for supporting federated identity has an opportunity to make a meaningful impact and help re-chart the course for the future of federated identity on the web. In the landscape of today, the choices around federated providers an End-User has available to them when going to “login” on the web is most often a small curated list of IDPs pre-determined by the Relying Party.  One of the main market forces that influences the options an End-User is presented with is often referred to as the NASCAR p
Posted by tplooker on Mar 31, 2022, 2:42 AM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (EdTech)
Message limit 10000 team edition
[NEW] Data Tiering - Valkey as general data store not just in-memory data store
Info: No releases on google play for now
proposal: spec: sum types based on general interfaces
Users can't use IdPs outside of the ones enumerated by RPs
Users can't use IdPs outside of the ones enumerated by RPs
TL;DR there is a significant amount of context at the start of this issue before we get to the proposal, here is a [google doc version](https://docs.google.com/document/d/1zxRFhF6qwGTCOYZ6UwTutbXVyRiD3krXyfFkcp_6t98/edit) for an alternative form. # Background The origins of many federated identity technologies have deep ties to providing an open ecosystem of IDPs to give End Users ample choice in how they choose to “login”. Efforts like OpenID v1 and v2, SIOP, Mozilla Persona, CHAPI, and others, strongly embodied these principles and much of this has remained in future revisions of standards such as OpenID Connect core. However, due to numerous complex issues, much of the industry today, primarily around the “social login” market has consolidated leaving a few IDPs as the dominant market players. To counteract this, FedCM in this work on establishing new browser mechanisms for supporting federated identity has an opportunity to make a meaningful impact and help re-chart the course for the future of federated identity on the web. In the landscape of today, the choices around federated providers an End-User has available to them when going to “login” on the web is most often a small curated list of IDPs pre-determined by the Relying Party.  One of the main market forces that influences the options an End-User is presented with is often referred to as the NASCAR p
Comments (0)
No comments yet. Start the discussion.