Full Title or Meme
- The major feature of OpenID Connect (OIDC) was its ability to operate on the "Front Channel" so that he user browser context was maintained and the user could get on with the work at hand.
- The browser makers are currently completing on which one provides the best privacy considerations. As the security of the user information is increased, it inevitably impedes the flows that worked well for OIDC.
- No implementation of the Self-issued Section 7 of the OIDC has ever received a wide public presence.
- Especially with Federation Signing, the connections used between different browser widows has make the user extence good, but is indistinguishable from user tracking which the browser manufacturers have vowed to drastically reduce.
- Any Self-issued Identity Provider (SIOP) requires some method to authentication while preserving the user work flow. The existing techniques available from the browser do not do that.
- Native code can get control from the browser by some well-known URL, but that is subject to be overridden by an attacker and does not allow the native app to return control to the same user browser context.
- Web apps require a user-owned URL that is used to install the app. That URL must be known to the RP to use the existing front channel solutions. That results is what is know as the "NASCAR problem" of too many choices being presented to the user. It is unlikely that a web site would like more that 3-6 choices to avoid taking the user off track for why they went to the web site in the first place.
- At least as good as UX
- Improve user Privacy by increasing the security of both user data and user attention.
Version 2 of ODIC
- Disruptive innovation requires any business to eat their own childern or someone else will come along and do it first.
- Front channel communication had a long run, it may be time to look seriously at alternatives.
Focus on W3C
- Whether version 2 is started or not, it is important to help the W3C, and the browser folk in particular, to work with OpenID and DIF to create a win-win solution.
User Permanent Presence
One intriguing solution is to give the user a URL that is "always on". This would allow very convenient ways for the user to be in control. It is hard to imagine a successful business model that would not create a worse privacy problem for the user than the one that exists today.
- It is interesting to note that the DID can get a DID document from the web in the current design. That document is not currently oriented to the authentication issues addressed here.
- While the IPFS could host user data, it is not protected in any way and so could be a major privacy issue. In general, if the user can be give a collection of value from some sort of web presence beyond just authentication, the balance could switch in favor of a permeant presence of some sort.