Re: [GNAP] Support of FIDO

nadalin@prodigy.net Thu, 13 August 2020 18:25 UTC

Return-Path: <nadalin@prodigy.net>
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 3FB3A3A0F7B for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=prodigy.net
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 AGz_Uv-th_Gw for <txauth@ietfa.amsl.com>; Thu, 13 Aug 2020 11:25:39 -0700 (PDT)
Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 405593A0E01 for <txauth@ietf.org>; Thu, 13 Aug 2020 11:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597343137; bh=IaOr4Yt7YMcqY5BS1UW8T8O7kpOIHSReAy5/52LBfpE=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=b3QtgcR4s/rihb8BZfSqIdZXuZr7Gw2uoX02sjBe01Ete7OuaY4Nfl/3CXRTakgdfHEm0SceOUaMM9+Xfcpg5nB/NDpbwI1DpXuh3viWxD1pibS5lee1gk13SPUbPIcEkX8i2c04OJWA+BTI/zLXWthnOUgLAbjLnwwTQt7zDY5tRA+QI90f8uIGEj/7JnUp5VuWWMxWDvFL26/KyUQX4RAY0S5sym7yfMDZ+i2nYSINnFWk3JDJ2xBbfzOaQBXvWbqV33Lz1upJx6u9SQ0jnDjPcSZumt5GR3ZGM9oQgJK+V4YxJ9zq5ZxQQLmmNO3aTnqQ9VioMlGrZg3Omjk7Ag==
X-YMail-OSG: fJRGV8MVM1kkOMdH6ZjcNAVPA08LR3cLe6SFfw7EXDj.nHhtxFqYIfEranI.Da6 frq_bQkPsyz4BfWB7CV5MMg_UOI8Qf9BemRDy6HgBkTf_216gbMTXKct1xluIzrlbI9vsSviOw38 i8C6wm8xX_G3QfWGAngspv0Geb6zHwoeAH2hkgw0RznRfhhTUNVYet8IsFMFcmhlinB_HgYk3jBN _C1vZeptj6Q67L0kiT.cave9cmwIkByMP1wg53ffi6mSEv3o5c6nzpgjbXLXzZ8duGZofJLxoBs3 n2pobDhtuaiJxQ652AyCNEMi2eqqeFTkntqDyMZG6MgeosvjjFSenLVQffdOcly9DOzl6f9p2fUW btsGB8Pe1DuMN0ECOph4I6MjwrBOp4q6AAPSIsQpDeNSk_RnY5jUPsIWkhWVwXrgVJvBSm1KHukD YRt8OxLisOIDVEPDDv7R2ZWH9AoL5Bsyc0bVNieULyeBEjARlRUcoT51m0ZowIgHKaWg242_u5bq Y9eYLRsaL0XuYGLZunmc8rciUUn2_CbQHA6Td0RWvplU9Whob4txjmeUn0Wwdjx_IUGhbzgB.WlF 3t8WQCMopIlzQZrKbLECJz7uDNyb73BjjbpTKAuBAbem.yGlhOZm4.0IcIG_vXFD7jTKZFg2nwyM Q983T0Nd.q3ByTGAWlRG55LCZTHfTiaDdH8S6RzdFk6RNckaZo1xe1SrMoqCKPGcXRvakvbrobVj brFcBWhYy6Lsw1pRaqkKIAOzcrhgfsiP5Vn5azUCNDhetcRNkbompoXoh4pRVr0mqpn5vIvpazIt XO0xmfxn9WvLq4xEhfoW29oXQVMU5E63DI1H1If5e2mHksi92XdHwLKcfQY0kOZQtKBverMlwjaT KOiBDpghExBd51iW7AN21KL134E6PWfne62sw9RG8MCzXkAMqxQtCwHRWpjjEnE2V5ViXr9i9sJ8 KkvMoY9HE6ZW5FUk5E7_cEPw5dznmjDLcGfnfC0xy4r9Gu7CEbGkvVIwvRu7OVSb4lJy8fKJl7Vk MdWwB_gwSkOyL_JvShzuYFckg85qaDG2acJ.q8qbO8PsIoLKuhHSOKgBwyY7tcrvSXWUT9UVBEaA J5VCc1gomTe_2PflGXINsCh9qtCJHcTZvzHo.RRTcg2Vlpmn1Dw1hQJ7kCaXg9Xpfald_w5eb0n5 LMEsaQbLq4BaZqFmuIKf3BHvhX6DUxIJkUkPzvApLzbTW8s.fzK9ciuECiTzx_nRuaJ4JDsvpY8A 5j2NWqXmkC9LJ_0Bew4vpSQp7sntUYKaVX9g6imjHYKTV5j.OCuzWxIhYJx415gEor8mHrXdEeB1 FVLsGW6ih5y_aoaNBjXSGN4XbzQ2kQOy9Hf142aAv9Z4MjzSDdKs7R.lX0v_un1nxA5foXj2Xc3x d18k.VKe5m4hKtxdPflJSQrl36opQ2nG4knY20wU_xcbsOeouEbbb5OcHKdfcLRlDYFVChMYHIet 1XsQ-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Thu, 13 Aug 2020 18:25:37 +0000
Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e2bf197c4f79239591fa5270ff90836b; Thu, 13 Aug 2020 18:25:34 +0000 (UTC)
From: nadalin@prodigy.net
To: 'Denis' <denis.ietf@free.fr>, txauth@ietf.org
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr>
In-Reply-To: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr>
Date: Thu, 13 Aug 2020 11:25:32 -0700
Message-ID: <018901d6719f$22593a20$670bae60$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01D67164.75FBE8C0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrKl/KwmA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/pCZEXZ2l4Zl0vMj08RaJzyYx6ws>
Subject: Re: [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 18:25:41 -0000

Dennis, not all the way correct

 

*	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

Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

 

*	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 is nothing that prohibits the RS from sharing registration information between RS 

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
Sent: Thursday, August 13, 2020 10:31 AM
To: txauth@ietf.org
Subject: [GNAP] Support of FIDO

 

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