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

[Travis Spencer]

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#