Can we get data about RP adoption windows to IDP protocol changes?

[groovecoder]

IDP tracking is a still a major concern of this WebID proposal. A few docs here mention Persona's design for browser-issued JWT's as a solution. But, it would require RP changes to handle JWT's signed by the browser, which would be harder to change, and result in a longer adoption window.

To be better informed on that problem, we'd like to understand what length of adoption window we might expect from RP's. Can we get some data on the adoption lengths that have been observed for other similar IDP changes?

[gffletch]

I'd argue that if the goal is for the browser to be in control of the identifiers shared, why not look at the SSI (self-sovereign identity) efforts and make the browser a "wallet" that can create pair-wise pseudonymous identifiers (DIDs) and "push" them at the relying party. In that context, the browser is in complete control of the information flow and can work with the user to ensure that only the desired verifiable credentials are shared with the relying party.

[samuelgoto]

make the browser a "wallet" that can create pair-wise pseudonymous identifiers (DIDs) and "push" them at the relying party. In that context, the browser is in complete control of the information flow and can work with the user to ensure that only the desired verifiable credentials are shared with the relying party.

FWIW, we did look into a variant of this approach (have the browser generate public/private keys signed by the IDP) somewhat close to personas here:

https://github.com/WICG/WebID/blob/master/design.md#browser-issued-jwt

This is a really interesting option to explore, but is one that isn't backwards compatible, so isn't something that can be meaningfully deployed at scale in a short timespan.

So, worth exploring longer time, but unfortunately has a longer activation window.

[samuelgoto]

To be better informed on that problem, we'd like to understand what length of adoption window we might expect from RP's. Can we get some data on the adoption lengths that have been observed for other similar IDP changes?

I think it is worth collecting harder data, but here is some back of the envelope calculations:

• there are at least O(thousands) of relying parties that depend on federation
• weighted by traffic/users, there is a head, torso and tail here in this corpus
• the head is composed of tech-savy companies that depend on federation, have in-house engineering and can very quickly react to things
• the torso is composed of companies that delegate the engineering
• the long tail is composed of hobby/amateurs/personal/small websites that are not as tech-savy

The challenge here, as you'd expect, is with the long tail.

In my experience, ballpark, I think it can easily take O(5-10) years to convince the entirety of the long tail to redeploy their servers with a different federation system.

[gffletch]

Personally, if the goal is to allow the browser to separate identity flows from other redirect flows used for other purposes, and to roll out that change relatively quickly, it may make sense to separate the privacy related elements from the identity federation flows. I realize this doesn't completely solve all the identified problems, but it feels like a much simpler problem to solve. (crawl, walk, run:)

For example, if the RP had a .well-known/webid file that defined the IDPs this RP uses, the browser could load that file and flag the redirects that are used for identity and handle appropriately. Any other link decorated redirects could be treated differently. Something like this would keep the existing protocols in tact while still allowing the browser to provide browser specific chrome and intermediate the flows. If the browser knows a specific redirect is for identity, then it's much easier for the browser to parse the redirect requests into the identity flow components (e.g. a parser for ODIC flows and one for SAML flows).

Given the plethora of deployment use cases where identity federation is used, roll out time that doesn't break the majority of the web will be a long time. 5-10 yrs may be optimistic :)

[surfnet-niels]

As mentioned in other issues as well, for Research and Education the assumptions in the Deployment Structure section do not hold: the global eduGAIN interfederation (https://edugain.org/ and https://technical.edugain.org/) currently includes almost 4000 IdP and some 3000 RPs, from 70 countries. For many researchers and students in e.g. the major US universities, federated access is one of the corner stones for allowing them to collaborate on a global scale and do stuff like finding Higgs particals, gravitational waves or a cure for Covid-19.

In regard to adoption, although some IdP and RP products are more preferred, generally speaking the software ecosystem is very diverse. Significant changes in the software stack because of a protocol change (like e.g. moving from SAML1 to SAML2) have in the past taken well over 5 years. Note that IdM is a critical aspect of many processes, but it is also a supporting infrastructure to the core business in R&E, so it may not always get the attention needed.

In addition, and this may hold true also for other sectors like gov and healthcare, the IdP itself has little control over it's technical capabilities as it uses products like for example ADFS where it is Microsoft who determines which features and capabilities are available and what the timelines are.

[samuelgoto]

Can we get some data on the adoption lengths that have been observed for other similar IDP changes?

Many years have passed since this was initially filled, and I don't think we (collectively) managed to collect a lot more data on this other than the data that we are gathering by actually gaining deployment experience.

I'm going to close this and suggest that we operate with incomplete data, unless anyone thinks there is something actionable here that anyone could do to actually collect the hard data that can inform decisions. If you feel like you can, feel free to re-open to provide it.