Closed majido closed 6 months ago
@kenrb I tried to capture some of our offline discussion in this issue. Feel free to add additional context or ideas.
I agree that it makes sense for the platform to offer something like the capability described in the delegation model. In that case the browser can just make use of those exposed platform APIs and possibly not have to implement it. This is analogous to the model for WebAuthn platform APIs, where both apps can call them, and browsers can call them on behalf of websites.
This was filled many years ago, and I think this is no longer a valid concern, because we did indeed go with the "mediation-oriented variation", rather than the "delegation-oriented variation" (for good reasons, mostly backwards compatibility). So, I'm going to mark this as "closed" since it is no longer applicable to the direction that we took. Feel free to re-open if you disagree and feel like there is something actionable here.
OAuth and OIDC are both available and useful outside of web browsing context. For example native apps (mobile or desktop) can use these flows to authenticate the user.
While permission-oriented and mediation-oriented variations are probably only meaningful in the context of the browser but the delegation-oriented variation seems particularly useful and applicable outside browser.
In particular the ability for IDP to delegate its token minting to another party (in this case browser) can easily be made generalized such that other user clients (e.g., the operating system) can play that role. I argue that delegation-oriented variation would benefit from this expansion of supported clients because it means that with more clients supporting WebID then user can sign in to their accounts in more places while maintaining IDP blindness.
If we accept that certain formulations of WebID are meaningful outside of the browser then this may have implication in the API design. For example one such implication may be that we would prefer the Browser <-> IDP interactions to be specified in terms of HTTP request/response as opposed to Javascript based callbacks. Any other implications?