[OAUTH-WG] oauth-adjacent: draft-thornburgh-fwk-dc-token-iss-00

[Michael Thornburgh <[e-mail]>]

hi WG.

i'd like to bring to your attention my OAuth-adjacent draft, draft-thornburgh-fwk-dc-token-iss, for examination, comment, and maybe even consideration:

- title: A Framework For Decentralized Bearer Token Issuance in HTTP
- datatracker: https://datatracker.ietf.org/doc/draft-thornburgh-fwk-dc-token-iss/
- fancy-html: https://www.ietf.org/id/draft-thornburgh-fwk-dc-token-iss-00.html

TL;DR:
------
* bearer tokens are (still) appropriate, and even beneficial, for many use cases.

* OAuth has gaps (see for example TxAuth, draft-ietf-oauth-distributed), especially for the motivating case of decentralized identity systems and decentralized, independent RSes.

* this draft proposes a general form to support the motivating use case, but is applicable in other cases as well (including some of DPoP's).

the introduction section of the draft elaborates on the motivation and envisioned use cases.

longer intro:
-------------
my proposal was initially motivated by semantic and security problems i saw [1] in the Solid Project's [2] existing authentication system. that system is based on WebID, OIDC, and proof-of-possession. it addresses the decentralized identity problem (WebID + OIDC) and the decentralized, multiple, independent RS problem, where neither the client nor the user's OpenID Provider has prior knowledge of what RSes will be visited, and where the RS's authorization infrastructure is not (necessarily) the user's OpenID Provider. the system is especially intended to enable authenticated access without requiring the user to log in separately to each RS. other than its problems [1] it's pretty cool.

my solution to the problems with Solid's existing system is (essentially) for the client to be able to discover where and how to get a bearer token from a competent AS for a new RS it's visiting. initial versions (pre-I-D) [5][3] were very WebID-specific, but while developing it a more general solution emerged. reading through past messages in this WG, i think my approach may be of interest to some here. there is a superficial similarity to Jpop (in that there is a nonce in the WWW-Authenticate), but it is otherwise substantially different.

of particular note, at least one (but definitely not all) use cases for DPoP can also be addressed by this proposal. in particular, a client can prove current possession of a POP key to obtain a reusable bearer token constrained to one origin+realm, for an independent and arbitrarily short lifetime.

i have an example/POC implementation of the "token_pop_endpoint" mechanism specifically for WebID and the Solid use case, in the form of an nginx ngx_auth_request_module, at [4].

full disclosure: at present the Solid Authentication Panel is leaning toward an approach that uses substantially the same semantics as their current system, but adapted to the syntax of DPoP. i am not in favor of this approach, but i am in the minority.

this is long. thanks if you read this far.

-michael thornburgh


  [1]: https://github.com/solid/authentication-panel/issues/1
  [2]: https://solidproject.org/
  [3]: https://github.com/zenomt/webid-auth-protocol
  [4]: https://github.com/zenomt/webid-auth-nginx
  [5]: https://github.com/solid/webid-oidc-spec/issues/25