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

From: Michael Thornburgh <[email-masked]>
Date: Sun, 24 May 2020 00:12:37 +0000

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

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 24 May 2020 17:37:20 -0400

Hello Michael,

The proposal looks very promising.There is a need for a framework with an
even higher abstraction. Decentralized issuance of bearer token is
gaining space, as in the open banking ecosystem we witness Clients which
have to deal with many AS or "Mechanism Endpoint" like you call it in the
proposal.

In some situations, the "Mechanism Endpoint" can be  a device in the
possession of the resource owner (RO) and it initiates the original service
request to the Client and it is not open to receive a POST request. In
which case the "POST token request" in Figure 1 will be replaced by a 401
response to the "Mechanism Endpoint" that will in turn produce the bearer
token and resent it to the Client.

/Francis

>
> 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:
>
> - 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:
> ------
> * 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).
>
> 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.
>
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/