Re: [Txauth] Key handle vs client id & handle
Fabien Imbault <fabien.imbault@gmail.com> Thu, 16 July 2020 07:49 UTC
Return-Path: <fabien.imbault@gmail.com>
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 0D1DB3A0BE9 for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 00:49:46 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hl7Kr90IO0gG for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 00:49:43 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 B8B373A08B3 for <txauth@ietf.org>; Thu, 16 Jul 2020 00:49:43 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id a11so4283544ilk.0 for <txauth@ietf.org>; Thu, 16 Jul 2020 00:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2KOC+LUiZS9yANP7OehDMtL9E04r5STlgFFoAzhN3dk=; b=mwqOcylwsiTI5Jlreo/wN1IFm8fmjl1A/DlKKcGyg7OZzM8vcJLcHFr8q7TDoT32ih 8E8GNTCujYNFmzpHuUAXdTteSljS00XXT7Xl/HJFB7nJURmZE2SGn75429Q9Yni/ioAC 6759w7yr3yMmTiVotCAtFcnCMv/2qsXUUV3nGqqvyi5dE3ZcGTrzPw75uF4KuqD6LjXe vQEDmWs90CBR2lIPiTxi+2/IWU3DhG/apiZWaUblRji1+jUpYPcqNDd+VXnKaoWQxPlc A0FP9WfMRN09e8X5li9bNJwSoZ3a8eQCG2yiAYPGFXh1gN7/wXLMMsNHt77WJ/zyrikV gTRQ==
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:cc; bh=2KOC+LUiZS9yANP7OehDMtL9E04r5STlgFFoAzhN3dk=; b=II9ZaWiC6jzh67TPxB1gNFA09dQnPDTDqZMaZTdgIXhNt9pi7M+pd6tuzdO8nDcEDb nXVsUMPUTRXtv/3mg6LVJKY+ct6sVH/lZgj1Lzy+U09xy8oPbkGUZZsq1UQbLh8n0cAI ZTBDSbF4b2KXNwPoh6+tznEl88oAztNqwIa9C5bR6JXeeSbr8cVLlJwlQd7qh2E9026M /ZljdwQ083bBCqta9kKBOZME7bvA6AAk/SGuUwJyIuiU0cBjvJXAKVjHoT7mWq+FwKLa LHBIgux2UsJ07JQw1n4mBCVbOJQYKyoV/Xh/iZUkNhyXIKDF62vrUmNbziAXob5ZvmCK yDGg==
X-Gm-Message-State: AOAM533tx82c4tTYVMo1pWgUvG6dQq4bd7hQ5X6anL0nEVPZwVmE6QYp fkZUcJjeiPXxEQSfJrtaosBRksMNAXsmJLR3T08=
X-Google-Smtp-Source: ABdhPJxzrPJ81rFvKzsZYBwjk74rl+ebQLuMgzCgHPR6+n7p6MsRnxqIQuTR/u62Rd41szf6gbGKkXmpn3/AqsW6BSg=
X-Received: by 2002:a05:6e02:1313:: with SMTP id g19mr3152175ilr.123.1594885782948; Thu, 16 Jul 2020 00:49:42 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>
In-Reply-To: <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 16 Jul 2020 09:49:31 +0200
Message-ID: <CAM8feuR=jEoUWY7XHYdBtV1xQL3VBmKYffuS1zTF3hkmNUCr_Q@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Mike Varley <mike.varley@securekey.com>, "txauth@ietf.org" <txauth@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008cd10905aa8a4884"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BXWjUMWuCkTHL3LXl7ybmu_ok_A>
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 07:49:46 -0000
+1 on that. We can then see it more as life cycle management of the client than registration per say, and this comes with many benefits compared to the current client_id. Fabien On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote: > I not only agree with Mike Jones that “automatic registration” should be > part of the process, but I would argue that that kind of model should be a > default mode of operation. If you have an identifier that you can send to > short-circuit that, great! But we should focus on having the capability of > inlining a lot of this information wherever possible. This is already the > direction that the input proposals are heading. > > So I kind-of agree that “registration” is in scope for the protocol in > general, and since both XYZ and Xauth have mechanisms that allow the client > to present a key and get back an identifier that it can use in the future > we have something equivalent. > > But I think there’s a little more to it than that: Ultimately, I think we > should question thinking in terms of “registration”, a model which has > hampered the OAuth 2 model in a lot of use cases. For example, the > federation draft Mike Jones references below hacks the “client_id” > parameter and makes it point to a document that the AS has to fetch. This > construct is done for two reasons: (1) Oauth requires a “client_id” in the > request and (2) it’s difficult to pass information by value to the AS due > to front-channel restrictions. Since we’re defining a new protocol, we > don’t need to hack that functionality into a “client ID” or equivalent and > instead we can pass that information directly in the protocol. If we don’t > assume that the client *has* to have a client ID equivalent, but it *can* > have one in a set of defined circumstances, then I think we are in a much > better spot. This is the reasoning for XYZ’s model of having clients > identified by the key, and that key can potentially be passed by a > reference identifier. > > I think all of the use cases that Mike Varley presents below are all valid > directions, with the caveat that we shouldn’t assume a client should be > presenting an ID at all steps. Mechanisms like software statements should > be presentable apart from a client ID, as should on-device keys. We’re > probably going to want extensions for device posture and other forms of > attestation as well. > > This is one of the domains that I think we can clearly surpass OAuth 2’s > flexibility and capabilities if we are willing to look past OAuth 2’s > assumptions of what’s needed inline in the protocol. > > — Justin > > On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> > wrote: > > Is client registration in scope for the protocol? > > A generic way of handling clients (via ID or Handle or Key or whatever) is > to have processing rule on the AS such as “if the AS recognizes the client > ID (and authentication of that client ID) then it may process the request > on behalf of that client. If the AS does not recognize the client ID, it > must treat this as a new client registration and evaluate any authorization > evidence the client provides before enabling the client and mapping > policies to that client” (this means dynamic or automatic clients need to > provide additional assertions / software statements whatever to register > their ID. > > Something like this allows for very flexible systems: > System A can be unknown to the AS but can dynamically registered each time > with an appropriate software statement > System B can have a fairly stable client ID at the AS, but rotate that ID > every month through automatic registration (with an assertion it got from > the AS during a pre-registration for example) > System C can pre-register with the AS for a client ID because it doesn’t > deal with software statements etc… > … > And even ‘StatelessAS’ can operate by never storing client IDs because it > will always just rely on the software statements. > > I think a client registration protocol that allows these scenarios would > be very useful in GNAP, but hopefully avoiding having to define what > ‘evidence’ the AS needs to accept for each scenario. > > Thanks, > > MV > > *From: *Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones < > Michael.Jones=40microsoft.com@dmarc.ietf.org> > *Date: *Tuesday, July 14, 2020 at 12:18 PM > *To: *Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" < > txauth@ietf.org>, Justin Richer <jricher@mit.edu> > *Subject: *Re: [Txauth] Key handle vs client id & handle > > I agree that there are significant differences between statically and > dynamically registered clients and that’s appropriate to be able to > syntactically differentiate between them at runtime. For one thing, the > resource requirements at the authorization server can be very different. > > We should also be thinking about how to include what the OpenID Connect > Federation spec > https://openid.net/specs/openid-connect-federation-1_0.html calls > “Automatic Registration”. This lets the client encode a registration > request reference in the client ID, so no static or dynamic registration > even occurs. See > https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1 > <https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc..section.9.1> > . > > -- Mike > > *From:* Dick Hardt <dick.hardt@gmail.com> > *Sent:* Friday, July 10, 2020 1:17 PM > *To:* txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones < > Michael.Jones@microsoft.com> > *Subject:* Key handle vs client id & handle > > + Mike as he had interest in this topic > > My understanding is that an existing OAuth 2 client would use their > current client id as their key handle, and a dynamic client (one that was > not pre-registered) would be given a key handle by the AS. > > There are potentially some significant differences between a registered > client, and a dynamic client to an AS. > > The AS is likely to know the identity of a registered client, and have > different policies between the two types of clients. For example, a > registered client may have access to a 'write" scope, while a dynamic > client does not. > > The AS may have 100s or 1000s of registered clients, but a dynamic client > may have 10Ms or 100Ms of instances, which may dictate separate storage > services. Additionally, internal to the AS, which systems can write to the > registered client store is going to be different than the dynamic > client store. > > In XYZ, subsequent calls to the AS, both registered clients and dynamic > clients pass a key handle, so there is no easy way to differentiate between > the two. > > While the AS could embed semantics in the key handle identifier to > indicate which identifiers are pre-registered vs dynamic, there are many > cases where the AS does need to know the difference, so making the > difference a feature of GNAP seems like a better path. > > > > This email and any attachments are for the sole use of the intended > recipients and may be privileged, confidential or otherwise exempt from > disclosure under law. Any distribution, printing or other use by anyone > other than the intended recipient is prohibited. If you are not an intended > recipient, please contact the sender immediately, and permanently delete > this email and its attachments. > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [Txauth] Key handle vs client id & handle Dick Hardt
- Re: [Txauth] Key handle vs client id & handle Justin Richer
- Re: [Txauth] Key handle vs client id & handle Mike Jones
- Re: [Txauth] Key handle vs client id & handle Mike Varley
- Re: [Txauth] Key handle vs client id & handle Justin Richer
- [Txauth] Client Registration (Was: Key handle vs … Dick Hardt
- Re: [Txauth] Client Registration (Was: Key handle… Tom Jones
- Re: [Txauth] Client Registration (Was: Key handle… Mike Varley
- Re: [Txauth] Key handle vs client id & handle Fabien Imbault
- Re: [Txauth] Key handle vs client id & handle Justin Richer
- Re: [Txauth] Key handle vs client id & handle Dick Hardt
- Re: [Txauth] Key handle vs client id & handle Justin Richer
- Re: [Txauth] Key handle vs client id & handle Dick Hardt
- Re: [Txauth] Key handle vs client id & handle Justin Richer
- Re: [Txauth] Key handle vs client id & handle Tom Jones
- Re: [Txauth] Key handle vs client id & handle Francis Pouatcha
- Re: [Txauth] Key handle vs client id & handle Dick Hardt
- Re: [Txauth] Key handle vs client id & handle Tom Jones
- Re: [Txauth] Key handle vs client id & handle Francis Pouatcha
- Re: [Txauth] Key handle vs client id & handle Tom Jones
- Re: [Txauth] Key handle vs client id & handle Justin Richer