[Openid-specs-fapi] Presentation about hypermedia login API

Travis Spencer travis at curity.io
Wed Feb 10 15:49:42 UTC 2021


Thank you all for the discussion today on the meeting. I really
appreciated your time and inputs.

Here's a nicer formatted version of the preso:
https://travisspencer.com/articles/fapi-wg-preso/ It includes a small
change to the last slide about next steps.

Nat, you said I had the action item of creating the subgroup within
FAPI to start drafting a doc (or two or three). Can you help me with
the particulars of that?

On Tue, Feb 9, 2021 at 5:24 PM Travis Spencer <travis at curity.io> wrote:
>
> In the summer, I emailed the list about working on a new protocol that
> would facilitate strong login without requiring a browser[1]. Since
> then, I've been talking with Mike Schwartz, Nat, and others about
> this. To move this conversation forward, I would like to talk through
> the following presentation[2] on tomorrow's Atlantic call. Please have
> a look beforehand if you have a moment.
>
> Talk to you all tomorrow.
>
> [1] https://lists.openid.net/pipermail/openid-specs-fapi/2020-August/002037.html
> [2] It's in Asciidoc format in case the syntax isn't familiar
>
> = Hypermedia Authentication API
>
> == Agenda
>
> * Requirements
> * Brief overview of solution
> * More info
>
> [small]#Slide 1#
>
> == Our Customers' Demands
>
> * Non-browser-based login and authorization
> * Integration between OP and RP on different domains without cookies
> * As secure as browser-based solution (or more so)
> * Existing deployments keep working as-is
>
> [small]#Slide 2#
>
> == OpenID Connect is a Hypermedia API
>
> * All Websites are hypermedia (i.e., REST) APIs, ∴ OpenID Connect is a
> hypermedia API
> * Simplify non-browser-based login and consent by:
> [arabic]
> .. Replace HTML hypermedia representation with JSON
> .. Attest to the client's provenance
>
> [small]#Slide 3#
>
> == App Provenance
>
> * Provenance == origin (i.e., provider) of RP
> * Traditionally verified by control of redirect URI
> * Provenance verification happens at flow's end
> * Deep linking required on mobile (PKCE isn't enough)
> * New tools available to ascertain origin on modern mobile devices
>
> [small]#Slide 4#
>
> == Proving Provenance
>
> * Modern mobile devices have Hardware Security Modules (HSM) built-in
> * Can be used to sign a challenge
> * Verifiable up to trusted root
> * DPoP allows all login API calls to be tied to attested RP
> * Establishes provenance prior to or instead of redirection
>
> [small]#Slide 5#
>
> == Flow Used to Prove Provenance
>
> [ditta]
> ....
>                                                         Get
>                                                +-(A)-Challenge----+
>     Authorization
>                                                |                  |
>        Server
>                                                v                  |
> +-------------------+
> +---------------+   (B) Request   +------------+---+              v
> | +---------------+ |
> |               +<--attestation---+
> +------(D)---->o-----|  CAT endpoint | |
> |  Attestation  |                 |  OAuth Client  |  Attestation |
> | +---------------+ |
> |    System     |                 |  Application   |              |
> |                   |
> |               +-------(C)------>+                +<--(E)-CAT----+
> |                   |
> +---------------+   Attestation   +---+----+---+---+
> |                   |
>                                       |    ^   |
> | +---------------+ |
>                                       |    |
> +---(F)-CAT------>o------|Token endpoint | |
>                                       |    |                     |
> | +---------------+ |
>                                       |    +-(G)-AAT-------------+
> |                   |
>                                       |
> | +---------------+ |
>
> +----(H)-AAT-------------->o------|Login endpoints| |
>
> | +---------------+ |
>
> +-------------------+
> ....
>
> * CAT is sent to token endpoint using client assertion framework
> * API calls to login API are protected with sender-constrained access token
>
> [small]#Slide 6#
>
> == Adapting to First- or Third-party Provenance
>
> * Provenance establishes whether RP is from first- or third-party provider
> * OP can adapt login methods based on this
> * Hypermedia allows support for any kind of credential (incl. short-lived ones)
> ** First-party: End user can provide all factors (same as OP in system browser)
> ** Third-party: End user cannot provide all factors, consent may be
> verified out of band
>
> [small]#Slide 7#
>
> == More Info
>
> * Very short summary
> * See https://travisspencer.com/articles/hypermedia-api-resources/[my
> website] for an ever-growing list of resources
>
> [small]#Slide 8#


More information about the Openid-specs-fapi mailing list