[Openid-specs-fapi] Possible contribution of new login API specification

[Travis Spencer]

About a year ago, Mike Leszcz posted on the OIDF blog about app2app
sharing.[1] In that post, he wrote:

> As app2app is still relatively new, in most cases it will involve the bank adding a (relatively simple) custom plugin to a new authorization flow in their authorization server (there is no standard protocol for API used between the bank’s app and the bank’s authorization server). There is no standard that defines the details how how this is done, there are generally two choices:
>
>    1. Entirely native user experience, and the banks authorization server has an API that the native mobile app can use to complete the consent process and obtain the authorization code given the biometric proof
>    2. Partially native user experience, the app collects the biometric then sends the proof as an additional parameter to the authorization endpoint url, which is then presented in a web view to complete the consent process
>
> The exact solution used is likely to be dictated by the capabilities available in the IdP software in use on the authorization server.

Before and much more since, we have seen a tremendous need for such an
API that can be used to perform login. This app2app case in banking
and finance is certainly one of the biggest drivers, but we've seen it
in other industries as well. The reduced friction and improved UX, for
instance, are highly desired in retail even where the security
requirements aren't as high.

For this reason, we have invented an API that:

* Is compatible with OAuth 2 and OpenID Connect core -- our product
supports it and simultaneously passes all OIDF OP profiles* Conforms
to the principles of REST in the highest sense
* Allows login with ANY type of credential -- from 1-factor (like IP
address or something) to MFA (e.g., using biometrics or WebAuthn) and
everything in between
* Can handle federated login (using SAML, OpenID Connect, or other)
* Works with not only single device flows but also multi-device flows
* Supports any number of requests/responses necessary to complete login
* Works with mobile apps and Web apps
* Ensures that client applications are attested and that an attested
client doesn't start the flow and an unattested one finishes it
* Facilitates interoperability -- my client can be used with your
server and vise-versa

We believe that the ecosystem would benefit significantly from a
standard login API that exhibits these features instead of various
proprietary ones.

Our API is patent pending, but we're willing to offer royalty free use
of our invention should any of its embodiments end up in a spec.

Given all of this, I wonder if it's interesting enough to the
community that we submit a draft of such an API for discussion.
Creating this would involve significant effort, so I'd like to get
some sort of commitment to review it and consider it with an open mind
prior to exerting the effort necessary to write it.

TIA!

[1] https://openid.net/2019/10/21/guest-blog-implementing-app-to-app-authorisation-in-oauth2-openid-connect/