Re: [GNAP] Support of FIDO

Dick Hardt <> Thu, 13 August 2020 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A1693A101C for <>; Thu, 13 Aug 2020 11:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hK_pXzoYfyBy for <>; Thu, 13 Aug 2020 11:21:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1797A3A102D for <>; Thu, 13 Aug 2020 11:21:52 -0700 (PDT)
Received: by with SMTP id z14so7264108ljm.1 for <>; Thu, 13 Aug 2020 11:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fdLIEYfjtsOQXuo9CM4e3vjePtyJYx4UckjeJ/3QtSE=; b=nTycVe4YA1JZccnn1SahW+mae/4t6ipzz5dH0ncetcxZt8BQHRdJ5ECUWMUmAIO4gL 8YMoZSkkTnuyCho/nE2GazvC9fLQXTFB1XqyGcuNHNgsBT8HJGamOC8d//SY+P/MPvQ8 ft85IsvEsOIpfaTJq8Pf0i8WNfTPfgOtW9zBahfXd9DvUVGe6JTlPYd+ulANcf6kWjSF QKHO5QeBoDIrkd+WHkcTFtK/PkF83eytzMt18zRBUirP++r86FSEHYRCcv1AyROzBHO9 nwOdkui7H1qsdfL6diy/D9FWgCwgGR5+0PLJFgkvi/JA/EDu7cKKL657rPV+u5alvHUa Hn1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fdLIEYfjtsOQXuo9CM4e3vjePtyJYx4UckjeJ/3QtSE=; b=Rg6JZUiRJQAXOAYXdEQR03K0cCFUBxp+4ndlOP2YiWq1QIODiqPz/jEUg3MSY2ATvG 0Q4nUmqf1rj231cyDEVXHLq2BoMzKgfVBt1h7qZ7yBjdDL2sGPoNWM54K2LkY0gAVObD r/B7INlNNpU6ub6b5FPrcl0Gnar0THibsZz0Iu1I+cNhbC5p8Wz8SyK+2jxVXhcxsJet ejqxxfcZLZudvK1gqGN4OBJelg2eAAwZahHPihCW5R5wTcEVaTFP0F28+onsJYltMl+4 PzUWy1yoTeSvum5p9excmwkB90g4ElMaAgYbJsoEaRujLlLoGwMIH8AhVj0PAmLlvRIe 6XWA==
X-Gm-Message-State: AOAM5301WsCj+kYzdiogdAJYCTr/SP7vypoYeXuqorZTMghfx055N6aC 5xZOeuXIK6qPUAxYpZI0gSM6okOArXNVVygdpQjLgtGf
X-Google-Smtp-Source: ABdhPJylc2u4iQVqrvLDV8Yo4UcIpf94rOvsKMBiCkSkg6WSG8W02uTmPWQ1jWV79h4kSQwMHd7p/ndCI1ADDcDmRoM=
X-Received: by 2002:a2e:7215:: with SMTP id n21mr351020ljc.242.1597342910156; Thu, 13 Aug 2020 11:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Thu, 13 Aug 2020 11:21:14 -0700
Message-ID: <>
To: Denis <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000be961605acc66086"
Archived-At: <>
Subject: Re: [GNAP] Support of FIDO
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2020 18:21:54 -0000

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to
stop site A from asking for the user's username and password at site B so
that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think should be
out of scope. There are a plethora of authentication mechanisms, and
standardizing how the user authenticates is not required for interop.
Sharing the "quality" of the authentication is an area of standardization
that has been done in OpenID Connect, and I think should be included in

Having said that, the Client could optionally use FIDO to authenticate the
User and somehow transmit that to the AS.


On Thu, Aug 13, 2020 at 10:31 AM Denis <> wrote:

> This topic has already been tackled on the list, but I open a new thread
> for it.
> In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since
> the solution in OAuth 2.0 was to use access tokens,
> there have been used everywhere, even when they were not strictly needed.
> It is also possible to get rid of IDs and passwords using FIDO. FIDO
> discloses no private information at all about the user
> and no trust relationships need to be defined since there is no AS.
> FIDO should be one allowed possibility for the user authentication. In the
> case of FIDO, the user is authenticated under a pseudonym
> specific to the RS. It may observed that there is no equivalent in OAuth
> because of the two different semantics of the subject claim.
> RFC 7519 states:
> The "sub" (subject) claim identifies the principal that is the subject of
> the JWT.  The claims in a JWT are normally statements about the subject.
> The subject value MUST either be scoped to be locally unique in the
> context of the issuer or be globally unique.
> In one case, it is possible to link the subject claim of two users between
> two RSs (i.e. using a locally unique identifier in the context of the
> issuer)
> while in the other case (i.e. using a globally unique identifier) it is
> possible, in addition, to link the subject claim between one RS and any
> other server
> (i.e. not supporting OAuth) that is using the same globally unique
> identifier.
> None of these two semantics fit with the FIDO use case where the subject
> value is scoped to be locally unique in the context of one RS.
> Hence, the linkage of users between two RSs (or between one RS and any
> other server) becomes impossible.
> There are cases where a user would like to enjoy the unlinkeability
> properties of FIDO which cannot be met using the claims currently defined
> in OAuth.
> Denis
> --
> TXAuth mailing list