-
Notifications
You must be signed in to change notification settings - Fork 66
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
Allow IDP registration #240
Comments
I strongly support this overall vision for FedCM, making it so that IDPs interoperate (e.g. don't require pre-registration). We've been thinking along those lines too and calling it affectionally BYOIDP ("bring your own IDP"), as an analogy to how signing-up with email works (i.e. it is not like there is a list of email providers that the websites works with, right?). As you may have guessed, we are deliberately not choosing to start there, because we have a responsibility to preserve the current deployment of federation, but we are in agreement of where it should/could go. I don't think that the solution is as simple as you are making it seem (from a design of incentives perspective first, but also from a UX perspective second), but I think you got the problem and the broad strokes of how to go about it right. Any chance you could come over some time at the FedID CG to present your work / proposal? |
Yes very much aligned with this framing.
Yes there are a bunch of additional incentives and UX complexities to consider here, some we have already discussed a bit but im sure there are others.
Yes we would be more than happy to. |
Wonderful! @hlflanagan any chance you can help us coordinate a presentation by @tplooker sometime in the upcoming meetings that intersects with his availability? |
This model is very similar to the approach of decentralized identity. Rather than inventing something new, I highly recommend to look at making the browser be a viable "wallet" for the user and then just use decentralized identity protocols. Note that the OpenID Foundation is working in this space as well with the SIOPv2 spec and it's associated specs. https://openid.net/specs/openid-connect-self-issued-v2-1_0.html |
@gffletch my mental model here is that the browser is a mediator able to facilitate an End-User using an IDP of their choosing (within the constraints of the RP of course). That IDP could be a "wallet" taking a variety of different forms such as a server/web application or native application. So the "browser" itself isn't the wallet. I also agree with the reference to prior art, SIOP in particular needs a solution to mediation beyond the limitations of a custom URL scheme such as "openid://" |
There were a series of sessions that happened at IIW between Kristina (SIOP) / Tobias (this proposal) / Dimitri (CHAPI) / Wayne (Sign-in with ethereum) and I (FedCM) on topics adjacent to this issue, and I feel like we left with a good amount of synergy and a reasonable sense of where to start from. This is my personal recollection of what we discussed as a group at IIW, but others feel free to chime in and correct me where I'm wrong. Overall, I left with the sentiment that we had a good amount of appreciation for each other's work. As far as FedCM goes, SIOP aligns really well with FedCM because it addresses two key problems: (a) the portability problem and (b) keeping issuers blind to verifiers (through a self-issued and trusted OP). FedCM aligns well with SIOP and CHAPI because both seem to need a neutral / reliable wallet-selector: SIOP has to name IDP on desktop browsers (e.g. if a user doesn't have a phone to scan a QR code) and iOS (e.g. without an The overall idea that we floated around at IIW (largely based on @tplooker 's original architecture) was to expose a browser API to allow: (a) the registration of IDPs (Self-Issued OPs or not) and
For (a) something along the lines of following would write into browser storage the IDP's registration: navigator.credentials.registerProvider("https://my-idp.example"); This call registers with the Browser the IDP at We discussed a few UX options, and the most obvious one was to follow @tplooker 's original proposal to prompt at this point (this also matches what CHAPI does, so that's encouraging). We discussed a few more options and generally agreed that this needs more experimentation to determine what would work best. For (b), FedCM could expose an extra option to allow, not only named IDPs, but also allowing the user to bring their own. Something along the lines of: const credential = await navigator.credentials.get({
federated: {
providers: [{
// allows the account chooser to load named IDPs
url: 'https://named-idp.example',
clientId: '********'
}],
// The RP accepts IDPs that called registerIDP() before.
registered: true,
// the RP accepts SIOPs
selfIssued: true,
}
}) And, when invoked in this fashion, the account chooser would bring accounts from "named" IDPs as well as "registered" IDPs. If a "registered" IDP is called, then the We also discussed how this could be used to pass VCs/mDLs over SIOP, which didn't seem to conflict/disagree with this architectural choice. One of the challenges that Wayne brought up that I don't think we talked about enough was to have the ability to register not just IDPs but also types. Something along the lines of: navigator.credentials.registerProvider("https://my-idp.example", [
"UniversityDegree", "DriversLicense", "COVIDVaccine", ...
]); Such that the RP could then use a querying language to filter out SIOPs that contain them. We also discussed briefly that we'd like the resulting There is a lot of handwaving here, but this is more or less what I remember from the discussion. There were a series of diagrams that we drew in the whiteboard, and in case any of you still have them on your phones, sharing them would be appreciated. |
This all looks and sounds pretty fantastic, wish I had been there!
Not just directed, but a nonce would be essential for the resulting token to be bound and prevent replay as well. Signed requests will also be an important trust mechanism, so the RP initiation interface might be fairly rich. |
Instead of taking this approach: navigator.credentials.registerProvider("https://my-idp.example", [
"UniversityDegree", "DriversLicense", "COVIDVaccine", ...
]); I'd recommend that any sort of filters be provided / be updateable either through some Keeping the registration API surface light (i.e., base URL as the only param) also enables better future proofing for adding new feature expression via configs / I will note that adding filters for specific Verifiable Credential types may have challenges, given the unbounded set size. Certainly being able to specify that a provider supports VCs at all or the ability to produce Verifiable Presentations (or perhaps provides other types of credentials / supports other features / protocols) could be of value. So there are some additional considerations around what is to be filtered and at what "levels" or granularity. |
Ah, that would work too! So, something along the lines of: navigator.credentials.registerProvider("https://my-idp.example"); Which, as a convention, points towards something like:
Which could contain: {
"typesOfCredentialsICanProvide": [
"UniversityDegree", "DriversLicense", "COVIDVaccine",
]
} Did I understand that right? |
Yes! Thanks. |
I think a simple version of the bring-your-own IDP is interesting, where a user can use an arbitrary identity with a site. This would be akin to a wildcard in the provider list that searches through the users' preregistrations. This could be useful for RPs that need no guarantee of identity elements, just a unique identifier– especially if they don't want to deal with handling username-password management. |
Just to report back on this thread with an update, we started looking into this problem and building some prototypes to see where that takes us: Firefox seems initially supportive and it shows up in multiple places, e.g. #374. You can follow the prototype process and some early ideas on API design here: https://bugs.chromium.org/p/chromium/issues/detail?id=1406698. |
@samuelgoto It was great to discuss this in person last week at TPAC!
|
Hello, @janschill and I are Solid developers, and we believe this proposal would be a great feature for FedCM to integrate well with the Solid ecosystem. We're considering working on a Proof of Concept to explore potential solutions and understand the practical challenges.
@samuelgoto it seems that there has been no update since Feb 15. What is the status of the prototype? Is anyone else currently working on it? Otherwise, we are looking forward to the possibility of contributing to this effort, and we'd appreciate any guidance or feedback you could provide to help us get started. |
I'd love to participate in this. Is there a call that I can join or maybe a document that I can read to learn more about what you have in mind?
We have a basic prototype working in chrome canaries that anyone can try. We are currently blocked on getting feedback from developers if the current proposal meets needs and is a useful API. Any chance you'd be willing to give this a go and let us know if it works the way you'd expect it to work?
Not at the moment. Like I said, we feel blocked by meaningful developer's interest.
I think one first concrete step we could take is getting a better sense of: (a) what problem you currently have that you feel like this feature would help? At the moment, we feel like this would be a great addition to FedCM, but we are really worried about implementing and shipping something that doesn't get enough use (and then, paying a maintenance price). We are willing to take risks, but that's currently what's holding us back moving forward, so the more data points you can give us about market demand the easier we can make this happen. |
We want to improve user experience within the SoLiD ecosystem. Given the multitude of IdPs, it can be challenging for users often to recall their specific IdP. If browsers could display a list of previously used IdPs, it would significantly enhance the user experience and usability. We would love to dive deeper in this topic during a call. We also started working on a PoC.
We downloaded the latest version of chrome canary on MacOS activated the required flags ( including
Is there any resources on how to make it work ?
|
I'm not super familiar with the flag but I think the prototype is not usable yet. You can call |
Can you expand on this a bit more (just intuition is fine, we don't need super hard data at this point)? How many IdPs are operating today within the Solid ecosystem? How many users a typical IdP have? How many solid RPs exist, and how often are they used?
This is really neat, and typically a strong signal that browser vendors take to make an assessment of demand: are developers going out of their way to try to make this work. Is there an open source implementation of Solid that we could use to build some of these prototypes?
Ah, I think I'm still missing merging one more CL. Let me get that merged and report back to you here.
Yeah, I share that intuition. But we really need to make sure that we are developing something that will be ultimately useful for users and developers, because the cost of development and maintenance is extremely high. I think we'd be happy to move forward trying to complete prototypes and seeing where that takes us, but we are ultimately going to need a good set of developers who are excited about this before moving too far. Fair? |
In this CL (behind a flag), we use the permission context that was written in part 1 to insert IdPs that were registered, and expose a JS API that allows an RP to refer to the registered IdPs. Prototypes a proposal to solve the following bug [1] to allow us to gather guidance from developer if this is directionally correct. [1] fedidcg/FedCM#240 (comment) Design Doc: https://docs.google.com/document/d/1MKpxTTLi-1e5-0brsdy50TVk2YM9AghoL3diSpRv_vE/edit#heading=h.jdxq4526c2ip Change-Id: Id1bf4b2590ce55fcd6b8a50edcabe54abb652fc1 Bug: 1406698 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4163707 Reviewed-by: Yi Gu <yigu@chromium.org> Reviewed-by: Mustafa Emre Acer <meacer@chromium.org> Commit-Queue: Sam Goto <goto@chromium.org> Cr-Commit-Position: refs/heads/main@{#1226397}
@thhck I just merged a CL in chromium that implements some of the missing parts that you ran into. Can you try to use it in Chrome Canaries in a couple of days once it picks it up? |
@samuelgoto I work with @thhck on this. I just tested this in Google Chrome Canary and it works. I ran the demo IdP from @asr-enid with two IdPs, registered, logged into idp-1.localhost and in a Chrome console ran: IdentityProvider.register('http://idp-1.localhost:8080/fedcm.json');
navigator.credentials.get({
identity: {
providers: [{
nonce: "not-a-nonce",
configURL: "http://idp-2.localhost:8080/fedcm.json",
clientId: "yourClientID",
registered: true
}]
}
}); The browser then successfully prompted me with "Sign in to idp-1.localhost with idp-1.localhost". Thanks for getting this out. |
Great to see that this is useful beyond our own usage! |
Can you try this again? The code snippet you sent feels off to me: you want to skip the For example: IdentityProvider.register('http://idp-1.localhost:8080/fedcm.json');
navigator.credentials.get({
identity: {
providers: [{
nonce: "not-a-nonce",
// comment out the following line, so that the browser can load accounts
// from registered IdPs rather than by configURL
// configURL: "http://idp-2.localhost:8080/fedcm.json",
clientId: "yourClientID",
registered: true
}]
}
}); |
@samuelgoto yeah, that was also my understanding. I get this error though. I am on Google Chrome Canary: Version 121.0.6153.0 (Official Build) canary (x86_64) The FedCM prompt shows only after the last |
I implemented a working version into Rauthy and just wanted to provide some feedback. It is working pretty good so far with static pre-registered and dynamic ephemeral clients after a lot trying to debug things, which was pretty hard to do. I ran into some issues and have some open questions. IdP registration statusI don't know if such a functionality exists, but is it possible to do a registration clean up for an origin or list all registered IdP's? This would be important for 2 reasons:
Ephemeral / dynamic clientsAs mentioned already, it is working fine with ephemeral clients so far. You simply provide a URL pointing to a JSON in the correct format and that's it. Rauthy will then fetch this document and try to deserialize it into a format that is based on the OIDC Dynamic Client Regsitration spec: https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata The struct with proper validation in my code looks like this: pub struct EphemeralClientRequest {
#[validate(regex(
path = "RE_CLIENT_ID_EPHEMERAL",
code = "^[a-zA-Z0-9,.:/_\\-&?=~#!$'()*+%]{2,256}$"
))]
pub client_id: String,
/// Validation: `[a-zA-Z0-9À-ÿ-\\s]{2,128}`
#[validate(regex(path = "RE_CLIENT_NAME", code = "[a-zA-Z0-9À-ÿ-\\s]{2,128}"))]
pub client_name: Option<String>,
/// Validation: `[a-zA-Z0-9,.:/_-&?=~#!$'()*+%]+$`
#[validate(regex(path = "RE_URI", code = "[a-zA-Z0-9,.:/_-&?=~#!$'()*+%]+$"))]
pub client_uri: Option<String>,
/// Validation: `Vec<^[a-zA-Z0-9\+.@/]{0,48}$>`
#[validate(custom(function = "validate_vec_contact"))]
pub contacts: Option<Vec<String>>,
/// Validation: `Vec<^[a-zA-Z0-9,.:/_\\-&?=~#!$'()*+%]+$>`
#[validate(custom(function = "validate_vec_uri"))]
pub redirect_uris: Vec<String>,
/// Validation: `Vec<^[a-zA-Z0-9,.:/_\\-&?=~#!$'()*+%]+$>`
#[validate(custom(function = "validate_vec_uri"))]
pub post_logout_redirect_uris: Option<Vec<String>>,
/// Validation: `Vec<^(authorization_code|client_credentials|password|refresh_token)$>`
#[validate(custom(function = "validate_vec_grant_type"))]
pub grant_types: Option<Vec<String>>,
/// Validation: `60 <= access_token_lifetime <= 86400`
#[validate(range(min = 60, max = 86400))]
pub default_max_age: Option<i32>,
/// Validation: `[a-z0-9-_/:\s*]{0,512}`
#[validate(regex(path = "RE_SCOPE_SPACE", code = "[a-z0-9-_/:\\s*]{0,512}"))]
pub scope: Option<String>,
pub require_auth_time: Option<bool>,
/// Validation: `^(RS256|RS384|RS512|EdDSA)$`
pub access_token_signed_response_alg: Option<JwkKeyPairAlg>,
/// Validation: `^(RS256|RS384|RS512|EdDSA)$`
pub id_token_signed_response_alg: Option<JwkKeyPairAlg>,
} When Rauthy receives a URI as This is working fine in first tests so far. There is no real performance issue either, because the IdP can cache these fetches. There is not really a need to register a client dynamically in this case, apart from then having the ability to use a For an ephemeral client, the The assertion responseI know there is the open issue about it, but I just wanted to quickly share a thought about this. The FedCM internal login stateI had quite a bit of trouble with this. When I was logged in beforehand already, everything was fine. The problem came up, when I deleted my session cookies, so I would be logged out. With the next request to the But this problem maybe only exists because one issue I am left with, where I am stuck right now: TestingYou could test it on my instance yourself, if you like. I deployed a dedicated test-instance just for FedCM: You would need to create an account (easiest by just signing in with Github): The instance provides a sample config for ephemeral client testing as well: The test UI and IdP are on the same origin right now, but it should work the same when they are separated. I will create a dedicated test RP deployment when I fixed the login issue. As mentioned above, the only bigger problem I am left with is that the login window does not pop up, if we are actually in |
@sebadob can't remember if I already clarified this or not, but I believe the auto login popup is only intended for cases where the login state is out of sync, ie FedCM thinks you're logged in but you're not (maybe you manually deleted cookies), and it attempts to retrieve the list of accounts and gets a 401. At least I can reproduce this with my implementation by deleting login cookies on my IdP. Others can correct me if I'm wrong about this. |
So this means, if I am logged out, the FedCM would simply stop working (for that IdP) and it doesn't even provide me any link or action where it would provide a way of logging in again? So, the user would need to remember some IdP, go there manually in a new tab, login and then back to the original page? I just tried it the way you described, and the window still did not pop up. No matter if I am logging out on the normal way while the backend returns the |
@sebadob, you'll need to enable the 'button mode' API (chrome://flags/#fedcm-button-mode) and configure the 'button' flow in your credential options request to have it pop up a window if you have not set the |
@philsmart that did the trick. I wasn't aware of the 2 different modes, but its pretty cool that you could use widget as long as the user is logged in and fall back to a login button if not. Thanks a lot! |
@sebadob thank you so much for giving this a try!!! I'm trying to break down #240 (comment) into smaller parts, here it goes:
That's a great point, and something that I ran into myself too. I kick this off here #606 to discuss this feature independently from this large thread.
I'm not able to fully follow this section. Is there something that you think isn't working that FedCM could act on, or did you manage to make it work under these different circumstances?
Yeah, I hear you. We are tracking that here: #578
Yeah, as suggested by others above, I think that the #442 will cover this problem. |
@samuelgoto No everything is absolutely fine. You can share and self-manage the JSON document and don't need any upfront registration, its working very nicely. I released Rauthy v0.23.2 today which can act as a FedCM IdP with the above mentioned features, if you enable the support in the config. |
Just wanted to report back to this thread here another independent developer that managed to expose themselves as a FedCM IndieAuth IdP here. You can follow this thread here to read how they got through it: |
@aaronpk I'm working on making LastLogin compatible with webmention.io's FedCM implementation. I'm returning the following from my ID assertion endpoint: {"token":"{\"code\":\"dummy_code\",\"metadata_endpoint\":\"https://anderspitman.com/.well-known/oauth-authorization-server\"}"} But I'm never seeing any requests to the metadata endpoint after that and the login fails. Any ideas? |
The metadata endpoint isn't the oauth endpoint, it is the Indie Auth metadata endpoint.
|
@anderspitman can you check the dev console for any errors? You should see that JSON in the dev console too logged from here https://github.com/aaronpk/webmention.io/blob/main/public/js/fedcm.js#L45 |
The IndieAuth metadata endpoint is standard OAuth2 metadata, so it should be ok. |
Hmm it doesn't seem to be making it that far |
I tried a complete reset of Chrome canary as well, deleting all config and cache information and starting fresh. |
There's currently no security set up on this. You can confirm with the following curl whether I'm returning the correct info:
|
I found it useful to follow the code here while setting up my Indie Auth server: |
That looks to me like Chrome is rejecting the response from the ID assertion endpoint before it ever gets to the JS. Probably something wrong with the CORS headers. I do wish Chrome was a little more verbose on the error, because ERR_FAILED could be anything from no IP address found to rejected because of the HTTP headers not being right according to FedCM. |
You can easily test this theory by calling the FedCM API directly (e.g. using the developer console), rather than by loading webmention.io.
Yeah, we are starting to work on making debugging better. Agreed that it currently is lacking a lot. |
Good call. I was setting Thanks! |
Ok, here is a small update on what we've done recently and what we are planning to do next: Done Somewhat easy and non-controversial:
Somewhat non-controversial, but require more thought: |
If anyone wants to try logging in to webmention.io with FedCM and your own domain, without needing to host your own server, here's some somewhat clunky steps:
EDIT: You'll also need to go to chrome://flags, search for "fedcm", and enable IdP registration and multi-IdP support. |
This is really cool, good stuff @anderspitman !! |
Reminder to please also enable the multiIDP flag when playing with IDP registration. Since we may show multi IDP UI when requesting registered IDPs, we require the multi IDP flag to be enabled. |
Good point. I forgot to mention setting the necessary chrome flags. I just updated my comment. Both IdP registration and multi IdP are required, right? |
Yep! |
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 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 problem (https://github.com/fedidcg/FedCM/blob/main/explorations/related_problems.md#the-nascar-flag-problem). In order for a relying party to keep the UX on their login page from being overwhelming, they must pick a small number of IDPs to support (usually 2-3). How this decision is made by a relying party can be complex, but one major driving factor that applies to many is the existing user-base a particular IDP offers. Often the larger the user base, the more likely the relying party is in its desire to support it. This is because the relying party wants to offer as few login options as possible that services the largest possible user-base for them. This factor makes it difficult for new competition in the IDP side of the federated identity landscape, especially for entities that don’t have large pre-existing user-bases.
Who an IDP is, is often also important to factor in. As federated login technologies have developed, companies who built successful social networks, ISPs and commonly used search engines had the large user bases that made them attractive as IDPs to many Relying Parties. These IDPs have been very open about their interests in performing the IDP role, where the access it gives them to information about End User behavior, often supports their primary business models. In this context, concerns about user tracking are very real.
End Users looking to opt out of the limited federated identity login options available today are required to significantly compromise convenience because they are forced to manage a new set of credentials directly with the relying party, creating friction and usability challenges.
This equation in many cases has led to End Users using federated login options, trading off concerns such as the fear of being tracked by a particular IDP, for the convenience it offers. As a result, Relying Parties seeking large user bases continue to converge on the dominant IDPs and End User choice is further diminished. We end where we are today, in a self-reinforcing loop dominated by extremely limited choice at logon.
What we need to support instead is a federated login model that re-introduces the End-User into the mediation process so they can have more of a say on which provider they use and where.
Proposal
Currently the proposed FedCM API is focused around a browser mediated approach that assumes the relying party specifies a set of IDPs it supports login from. This model is largely a continuation of that described above and in many respects is just a browser mediated version of what we see most commonly on the web today.
Many Relying Parties will want to continue in a model where they specify the IDPs they support.
The challenge is for when this is not the case, to provide a viable way to achieve more End-User choice, greater inclusiveness, increased competition, and reduce vendor lock-in around the IDP options available.
In this proposed additional model, instead of the Relying Party specifying the IDPs it supports in the federation request, it communicates the capabilities it supports such as signature schemes, assertion formats and response modes.
End-Users can then register providers they wish to use with the browser, which are then available as options to present to the End-User when they go to login. This is enabled through the following two step process
Note - To prevent a scenario where a relying party is supporting this login model but no IDPs have been previously registered in the browser, the relying party could provide IDP hints.
Conclusions
Considering the cited basis for FedCM is to “preserve and elevate identity federation” please strongly consider adopting this in your work. Choosing this path would have a meaningful positive impact on federated identity on the web by improving the choices End-Users have to login on with. Ignoring this issue risks the continued consolidation of options available for End-Users and therefore undermining its value as a means of login.
Acknowledged Challenges
Prior Art
CHAPI
Mozilla Persona
Account Chooser
OpenID
Raised with @dmitrizagidulin
The text was updated successfully, but these errors were encountered: