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

Francis Pouatcha <fpo@adorsys.de> Sun, 24 May 2020 21:37 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A393A0C63 for <oauth@ietfa.amsl.com>; Sun, 24 May 2020 14:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4zQYIBMr-8z for <oauth@ietfa.amsl.com>; Sun, 24 May 2020 14:37:34 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B653A0C59 for <oauth@ietf.org>; Sun, 24 May 2020 14:37:33 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id e1so15422357wrt.5 for <oauth@ietf.org>; Sun, 24 May 2020 14:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rRHWJK/R7jkkh0SZkR/N91tulzAFlks2/69Ko/NFePI=; b=g8v6Lv9YNmABaAmrFpiy50h52Qq+TDipBxxF8wEc6ezC0J+y2k6clFgZDxgnZW+z7f B53W0S4o7RRvgxichDLlW9M6ER/6O+gJ0HzKhCzqPSYeE3WH84jUZIAz7JPqqWp43Kis A9s/x6sIrOJFi8y2+KRuZhyyUlrbmLik21lpw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rRHWJK/R7jkkh0SZkR/N91tulzAFlks2/69Ko/NFePI=; b=qJd9ZXILGD+r7R1xEuWuKUl6oxjMXVKZ55JMpjP7r++5lorjVKJNPldnomfvcqHnyd fHkvrbTw/+MG6G5E+QwoRGNNQAi6tx/zorI6FDBsKH0zlIiaucpRSnaV2NGQO7azuO9f KlmhswK9FQn3p1jFG2sw1CWDn2hHue6ROocpR4LGrDwrwafBlSXwld9o6A2P/1dQS4Ia seWEhYfopVXOymQawskdFZ0FyH4fn+HqRtXgxVUcH55+udeZUNMautMeuBlTSeXW9O7T pVJGLG3fmRD8X4WNA5/K5tr6A3I2jCOwgCVZeDkfhbEWo5mhoWGmZzgUdpze1SchcdUZ GONg==
X-Gm-Message-State: AOAM5327AJH7csidO1LsbRo41/qvyx4lS2qR5tnQLTTY3v5qBY5Q7iS3 KBg9mTF/sRjt4Q0dns3LuSpKKMyY1wcNmnqbDbR15Eqj47Uj1Q==
X-Google-Smtp-Source: ABdhPJyX2jEgHx4fDoDKeyOnMj8sjLieaT9PhgrbJ+YQHw+cZgYeoGC26z2IHo1pvIpnprxqE3hJD73GgWSHrPMlZaQ=
X-Received: by 2002:a5d:4bc5:: with SMTP id l5mr8959139wrt.104.1590356251360; Sun, 24 May 2020 14:37:31 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.77.1590346834.17408.oauth@ietf.org>
In-Reply-To: <mailman.77.1590346834.17408.oauth@ietf.org>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sun, 24 May 2020 17:37:20 -0400
Message-ID: <CAOW4vyP49b7-0GfPuubpDFMEQrBd8JSEfBJh14-1oTNn3FLfWQ@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006dd0ca05a66bab02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U0GXeGDM9JRoS-34xi39l5rjhOs>
Subject: Re: [OAUTH-WG] oauth-adjacent: draft-thornburgh-fwk-dc-token-iss-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 21:37:37 -0000

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/