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

Travis Spencer travis.spencer at curity.io
Thu Aug 20 08:21:44 UTC 2020


Just wanted to bump this to the top of the list, and ask again if this
of interest to the group.

On Wed, Jul 29, 2020 at 3:45 PM Travis Spencer <travis.spencer at curity.io> wrote:
>
> 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/


More information about the Openid-specs-fapi mailing list