[GNAP] Support of FIDO

Denis <denis.ietf@free.fr> Thu, 13 August 2020 17:31 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6A3A0F6D for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 10:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.312
X-Spam-Level:
X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no
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 eXsJ02bHz9XE for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 10:31:19 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F7A3A1009 for <txauth@ietf.org>; Thu, 13 Aug 2020 10:31:01 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d82 with ME id F5Wz230062bcEcA035WzgA; Thu, 13 Aug 2020 19:30:59 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 13 Aug 2020 19:30:59 +0200
X-ME-IP: 90.79.51.120
To: "txauth@ietf.org" <txauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr>
Date: Thu, 13 Aug 2020 19:30:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------B30B4802B6F5F49FA66EE5AA"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/JTVIXZV6d8SiTI978smJ2nnRs3Q>
Subject: [GNAP] Support of FIDO
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 17:31:21 -0000

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