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: > > - 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 > > -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
