From nobody Fri Oct 9 15:55:20 2020 Return-Path: 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 504FF3A15BE for ; Fri, 9 Oct 2020 15:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 4B38BRtkkW8V for ; Fri, 9 Oct 2020 15:55:18 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 EC9433A15BC for ; Fri, 9 Oct 2020 15:55:17 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id o21so9295865qtp.2 for ; Fri, 09 Oct 2020 15:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=EPO4twieZw1KBs9KAEvavpy4oIKHWy7fUj1OfWFyudk=; b=unXoD25hEIXES9ZQumWBnFJ6ndRSVt8CMFlUFUuxuconbnPRpYKPDWr5LlJUib0+gK o6ASk5Rjzef41YrWLs91JlreiTjZA+eqvUWH86AS/RuOaZYRZEAY1zmpVUmhFZttnW5Y f2G2B5AJSAvJ7ao6STDRUM/OoLOqCccfHssfq31UuO1W7HZ9+Ta4nU99Kvh2ucuhLZ3c ZHsxED89VQHoXSvJbRh915mmGwt69XllE1uZk4piFVd2Yu/yaQSQFK6GrEcq9T2mIobC /TT4K3GCIZVVMfh9jZ2DAYj5FQKV2j99abFD2EaFCAHy13riX2Y49KMkNAzno1Tl4Gm/ ReMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=EPO4twieZw1KBs9KAEvavpy4oIKHWy7fUj1OfWFyudk=; b=FI7i/KN2klODmcO8nXhREZ3jMzqn8BICdjGfoozspooEnWAHAjI4G/RdY2hhYSAMRy 2iBGKa5I+ygszqg4C65AgbnUkK49k2bCcy2WQDZKFZ8gG7ivxFr0dkFDD1IJIUyHERKY /OyDnRQA8tRr6N4A/8+f5Cmtq0QcPIvx1YrA2a/+1UhMLXW7Q9bgvMFpfkehlGABHBIT J+kQEniLQeLStZ2hsJoamEK/NJxzjLVnhpMSY309u2HQI9jax1g/PMBDWc46B4WzTJ6v D9k1S0BqWvq+m8PTbUP4L88y+y53r+bOnVoIt+8vGPujdKr7GmtyBHzXuJjUJPyM5Yew OaVw== X-Gm-Message-State: AOAM5308mMvvEpc6NTp9BK8X0JzWDjvCF+FBmh8YF55AxsYzvfniMSua W2N0UTZg2ZidFZNAxCLe6Njsr5yeiHNe1Q== X-Google-Smtp-Source: ABdhPJwtJhDW9hucU83OQOXF1Y7th9/PcPEMRYXuQmWTFo6eKu01Nypit/5W+S4Ej9XUT5G4tA8s6g== X-Received: by 2002:ac8:74d:: with SMTP id k13mr266642qth.191.1602284116700; Fri, 09 Oct 2020 15:55:16 -0700 (PDT) Received: from [192.168.1.3] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id 129sm3816277qkf.62.2020.10.09.15.55.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2020 15:55:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C5E9C8A0-9523-46A7-AF98-350D286DE301 Content-Transfer-Encoding: 7bit From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Fri, 9 Oct 2020 18:55:13 -0400 Message-Id: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> To: txauth@ietf.org X-Mailer: iPhone Mail (17H35) Archived-At: Subject: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 22:55:19 -0000 --Apple-Mail-C5E9C8A0-9523-46A7-AF98-350D286DE301 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Greetings! The design team has now come to a close. While there were too many issues t= o resolve to all design team member satisfaction, great effort was put in to= describe decision points for the WG to ease and hopefully speed the working= group process. As such, I am requesting that the WG adopts this version (1= 4 of XYZ) and works together to fully develop a single specification. https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ A tremendous thank you to each of the design team members for your hard work= and walking the fine line of when to put a stake in the ground (that the WG= can always change once adopted) and listing our options for decision points= to ease the WG process. Best regards, Kathleen=20 Sent from my mobile device= --Apple-Mail-C5E9C8A0-9523-46A7-AF98-350D286DE301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings!

The design team has now come to a close.  While there were t= oo many issues to resolve to all design team member satisfaction, great effo= rt was put in to describe decision points for the WG to ease and hopefully s= peed the working group process.  As such, I am requesting that the WG a= dopts this version (14 of XYZ) and works together to fully develop a single s= pecification.

=

Best regards,
Kathleen 

Sent from my mobile device
= --Apple-Mail-C5E9C8A0-9523-46A7-AF98-350D286DE301-- From nobody Fri Oct 9 17:04:38 2020 Return-Path: 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 57D1A3A0FD7 for ; Fri, 9 Oct 2020 17:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 uIJwTN6rkKbp for ; Fri, 9 Oct 2020 17:04:36 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16543A0FD1 for ; Fri, 9 Oct 2020 17:04:35 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 09A04WrA013906; Fri, 9 Oct 2020 20:04:32 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 9 Oct 2020 20:04:04 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 9 Oct 2020 20:04:31 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Fri, 9 Oct 2020 20:04:31 -0400 From: Justin Richer To: Kathleen Moriarty , "txauth@ietf.org" Thread-Topic: [GNAP] Design team Thread-Index: AQHWno9GJVp13Fw04Ee4yxLWcUfIGKmP8qM5 Date: Sat, 10 Oct 2020 00:04:31 +0000 Message-ID: References: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> In-Reply-To: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 00:04:37 -0000 Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their hard w= ork and discussion as well. This draft contains aspects of XYZ and Xauth, a= nd introduces some new elements and pieces as well. As you'll see, there ar= e many identified issues and decisions to be made, but even then I believe = it hangs together fairly cohesively already thanks to the good engineering = effort and discussion that's gone in so far.=20 Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.=20 - Justin ________________________________________ From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kath= leen.moriarty.ietf@gmail.com] Sent: Friday, October 9, 2020 6:55 PM To: txauth@ietf.org Subject: [GNAP] Design team Greetings! The design team has now come to a close. While there were too many issues = to resolve to all design team member satisfaction, great effort was put in = to describe decision points for the WG to ease and hopefully speed the work= ing group process. As such, I am requesting that the WG adopts this versio= n (14 of XYZ) and works together to fully develop a single specification. https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process. Best regards, Kathleen Sent from my mobile device From nobody Fri Oct 9 17:26:05 2020 Return-Path: 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 163653A164D for ; Fri, 9 Oct 2020 17:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 16NyYHy5a4kx for ; Fri, 9 Oct 2020 17:26:02 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 24A693A164C for ; Fri, 9 Oct 2020 17:26:01 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id j22so6927498lfe.10 for ; Fri, 09 Oct 2020 17:26:01 -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=knCz76lFrLAddeOFA0pc2FVdmzwkjWbWx0ZuEYFG080=; b=Ye1wcQTl1vqFMlwggIdZ3bFyDW2WBmNtjQuqzwkMz1qDIofLusV/9xkvqGIqHpPLkH D9h1EHAxZ9h7Eq+kIuQjMYbcfE8Cc8N/3xo915TbWiJHE2LvqgPivLEqLOWA5o/R93wP bqqL8rvDnt5TQpjgamMzv4BwCNSBcD6uw8ViLpZLF4KgdOdJoT7hC28HJ8rRZekB7z16 0sne1kE3Zvr0o5R9hpdA4VGxDdTZefZosL3WAcjS8HFGLuYN05y0owHK1LyZ+f2qlfSP wG5TFFrShTMTySxWGvQrd+rWWown/KVBYEAa3NTgSZIi8T6Fo9O8m8GUX/OUd7ddUYYW sg+g== 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=knCz76lFrLAddeOFA0pc2FVdmzwkjWbWx0ZuEYFG080=; b=JI1tMfK3pJb2eceDoUUnBF7HEAB4ef+hOHcxi5Qk25ZSG6yEEAHMBlUks8eT9mjrTs a5gxkVAz1hVLPmPzvpbzyWFlFc8F7nk1HSB9T/fw77FTbXwcQVzBq+tlwRC6KoOD2ax8 m4VwLri8fRFaDqx/GCQWPtYwOQc1tuPEqf9GLliw171t/xx1iew1AyxurrCBix0RMhnO CuP4KCDqqCci9OEemmcbisGPGT5fc5Y+jepnJZzNLwq/mhErkdMYWEqVTy82zOw/ejKQ zytN80QzGkUiNCU17+eBa9016WqqaZlPHCO0cx9KkFjmWaH/8o/CEEfF36Uxq/Znp8qO B2Wg== X-Gm-Message-State: AOAM530AtWQm8ZcjeYrAj5z+LPkCF/ZBBlGihg3i/zyMn+lK1Gqy6TpX 1XQRzPl5TgBt+lwwgYSxU7k8I/+mwDRgxXV4bs4= X-Google-Smtp-Source: ABdhPJzYVU285OKvYIoyvmAs/BLmbHKpKzVyKliEXP2l2sRklumGyurGwxKc2ilhZthsue30ZB8iqsewTtYExw1WKy8= X-Received: by 2002:a05:6512:31d2:: with SMTP id j18mr5429017lfe.316.1602289559792; Fri, 09 Oct 2020 17:25:59 -0700 (PDT) MIME-Version: 1.0 References: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> In-Reply-To: From: Dick Hardt Date: Fri, 9 Oct 2020 17:25:23 -0700 Message-ID: To: Justin Richer Cc: Kathleen Moriarty , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000009f37605b1461c67" Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 00:26:04 -0000 --00000000000009f37605b1461c67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting -14, but I propose someone other than Justin be the document editor. I was on the design team to work on the goals set out by the chairs [1]: "We expect the design team to decide on a solution outline that combines the best of both proposals, and present this outline by Sep. 15" Surprisingly, Kathleen convened the design team with her recommendation to start with the XYZ document with Justin as editor, and add in the diagrams from XAuth. The rest of the design team had an opportunity to express their concerns and Justin edited the document. In other words, I had to convince Justin to change the document, rather than the design team comparing and contrasting the proposals and selecting the best parts. I expressed my concerns with our AD, and decided to continue participating in the design team. We did make some progress on a number of issues thanks to the hard work of Fabien, Justin, and Mike -- but many issues have been punted to the WG. Justin has poured tons of energy into this project, and to his credit he was a good editor at times, but there are areas where he was unwilling to deviate from his vision. I am concerned about a repeat of what happened in OAuth 2.0: Erin had the pen and had strong views that often were not aligned with the rest of the WG. A good example was Erin's distaste for bearer tokens. He factored that out of the core document, which we are now adding back in with OAuth 2.1. Anyone that participated in the WG saw the issues this had. I'm not suggesting that Justin is Erin, but I think a more neutral editor of the core document will allow us to make progress more quickly. /Dick [1] https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/ =E1=90=A7 On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: > Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their hard > work and discussion as well. This draft contains aspects of XYZ and Xauth= , > and introduces some new elements and pieces as well. As you'll see, there > are many identified issues and decisions to be made, but even then I > believe it hangs together fairly cohesively already thanks to the good > engineering effort and discussion that's gone in so far. > > Nothing in the document is final, of course. To me, this document > represents a good starting point for working group discussion and > decisions, +1 for its adoption. > > - Justin > ________________________________________ > From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ > kathleen.moriarty.ietf@gmail.com] > Sent: Friday, October 9, 2020 6:55 PM > To: txauth@ietf.org > Subject: [GNAP] Design team > > Greetings! > > The design team has now come to a close. While there were too many issue= s > to resolve to all design team member satisfaction, great effort was put i= n > to describe decision points for the WG to ease and hopefully speed the > working group process. As such, I am requesting that the WG adopts this > version (14 of XYZ) and works together to fully develop a single > specification. > > https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > > A tremendous thank you to each of the design team members for your hard > work and walking the fine line of when to put a stake in the ground (that > the WG can always change once adopted) and listing our options for decisi= on > points to ease the WG process. > > Best regards, > Kathleen > > Sent from my mobile device > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000009f37605b1461c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tl;dr: Given where we are in the WG, I am not opposed to t= he WG adopting -14, but I propose someone other than Justin be the document= editor.

I was on the design team to work on the goals set out by t= he chairs [1]:

"We expect the design team to decide on a solut= ion outline that combines the best of both proposals, and present this outl= ine by Sep. 15"

Surprisingly, Kathleen convened the design team= with her recommendation to start with the XYZ document with Justin as edit= or, and add in the diagrams from XAuth. The rest of the design team had an = opportunity to express their concerns and Justin edited the document. In ot= her words, I had to convince Justin to change the document, rather than the= design team comparing and contrasting the proposals and selecting the best= parts. I expressed my concerns with our AD, and decided to continue partic= ipating in the design team. We did make some progress on a number of issues= thanks to the hard work of Fabien, Justin, and Mike -- but many issues hav= e been punted to the WG.

Justin has poured tons of energy into this= project, and to his credit he was a good editor at times, but there are ar= eas where he was unwilling to deviate from his vision.

I am concern= ed about a repeat of what happened in OAuth 2.0: Erin had the pen and had s= trong views that often were not aligned with the rest of the WG. A good exa= mple was Erin's distaste for bearer tokens. He factored that out of the= core document, which we are now adding back in with OAuth 2.1. Anyone that= participated in the WG saw the issues this had.

I'm not suggest= ing that Justin is Erin, but I think a more neutral editor of the core docu= ment will allow us to make progress more quickly.

/Dick

[1] = https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwu= bC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04= PM Justin Richer <jricher@mit.edu> wrote:
Tha= nks, Kathleen, and thanks to Dick, Mike, and Fabian for all their hard work= and discussion as well. This draft contains aspects of XYZ and Xauth, and = introduces some new elements and pieces as well. As you'll see, there a= re many identified issues and decisions to be made, but even then I believe= it hangs together fairly cohesively already thanks to the good engineering= effort and discussion that's gone in so far.

Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.

- Justin
________________________________________
From: TXAuth [= txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kathleen.moriarty.i= etf@gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.ietf.org/doc/d= raft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000009f37605b1461c67-- From nobody Fri Oct 9 18:34:54 2020 Return-Path: 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 6CF6E3A16EB for ; Fri, 9 Oct 2020 18:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, MIME_QP_LONG_LINE=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 (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 FJBTFU86brF0 for ; Fri, 9 Oct 2020 18:34:50 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 0C2273A16E6 for ; Fri, 9 Oct 2020 18:34:49 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id j3so5702239qvi.7 for ; Fri, 09 Oct 2020 18:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=PKvJLLV1oSHqalg0rfkJLb47ApKPSRKlnkOjiDrpN0M=; b=Ue64PjaPz/amSUg9pfNwYu+YRUri2j/2XpT5f7RzKYTFUXNfKdobslviVvHlqwDXF6 t27J+sD4uVURPZ4fuMn1NBlZWCnxbkxJBwikIB03qXKLUps5t78Wn/3jOWuwdGQEhd9y UfvzkdCE4tfomgvwK5zpZK6L4xXnabZKYg/s9bI952sJczilZs/JNCtri76MIMglEX1o JPjQeNYk7aQG3ntlSHfbAqPQY1d1JUC77NE0D/BxlitNa/coceVbEZdMIvsNtD9h9eKP OLHBrlCY6BfL37JrrgrxIYGunXAjqozI1KegZcYh25+qk/i3fb1KCjZnPC1672eNosQb UuAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=PKvJLLV1oSHqalg0rfkJLb47ApKPSRKlnkOjiDrpN0M=; b=SDbNkEbzPQ+JqMd7+RhzWjEUfahdkUUn9O3K17PbhccWXGhWmtw1cqgsu3Sr/hDT2H EX4jO5RC1/HSz4pZajAPuNauQ2fM1Z/52YHL0bKr5LVMtNlQmgA/6XBMEv2CQypM5QnW aJepA7IosJBrTWUbyxZxpdKuiRa2AzS7TXZJq4U81dj+99KY3l6PLQspEsBKETyNTUKI XlkFq4osLOUKTbsO4IV+M10KweAQJ8CWmOV2kKsI4MRVT2icOPdSKvsNEzKMIUJdig7D df+ixCPf3yp9UMtoimSBSZ5jNta8h3xcfs3FVlQvry80CjuGClzqBpnRdxBdkhHFoVIo KnrQ== X-Gm-Message-State: AOAM532mxehNpNJxywReuWz7rpWS599mGDkYdnhBIcviPxga1cmz0E6m p8XrLXDoUmq/M2XRwgpk5E8= X-Google-Smtp-Source: ABdhPJxU+DC962wkU6KRz/KFZPjOiXFErWbAN4aUBGQieUDy7lq2Uh6Er1vmXS29oq3A1Kr8OwYmSg== X-Received: by 2002:a05:6214:18cf:: with SMTP id cy15mr8850910qvb.53.1602293689000; Fri, 09 Oct 2020 18:34:49 -0700 (PDT) Received: from [192.168.1.3] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id d12sm7846318qtb.9.2020.10.09.18.34.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2020 18:34:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-FCD8D007-8073-43A7-BC36-B4B08B73B3C0 Content-Transfer-Encoding: 7bit From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Fri, 9 Oct 2020 21:34:47 -0400 Message-Id: References: Cc: Justin Richer , "txauth@ietf.org" In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (17H35) Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 01:34:53 -0000 --Apple-Mail-FCD8D007-8073-43A7-BC36-B4B08B73B3C0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My take is very different, Dick. I am starting a 2 week vacation and will n= ot be spending it arguing with you on the list. Multiple reviews pointed to Justin=E2=80=99s document as a better starting p= oint, not just mine. Your use case cases can be met and some of what you we= re asking for did not follow RESTful design patterns. They really don=E2=80= =99t map to a future protocol well. You may need to write extension documen= ts, but your goals can be met. Many calls were difficult as displayed in your message. Justin did a great j= ob handling the weekly tension and ensuring options were included for WG dis= cussion when agreement was not met. He=E2=80=99s completely amenable to fol= lowing the WG and chairs decisions. His document was also easier to follow a= nd aligned better with numerous IETF documents. Please do keep Justin on as= an editor. As you can see from the draft, there are many areas where WG inp= ut on decision points are requested. Best regards, Kathleen=20 Sent from my mobile device > On Oct 9, 2020, at 8:26 PM, Dick Hardt wrote: >=20 > =EF=BB=BF > Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting -= 14, but I propose someone other than Justin be the document editor.=20 >=20 > I was on the design team to work on the goals set out by the chairs [1]:=20= >=20 > "We expect the design team to decide on a solution outline that combines t= he best of both proposals, and present this outline by Sep. 15" >=20 > Surprisingly, Kathleen convened the design team with her recommendation to= start with the XYZ document with Justin as editor, and add in the diagrams f= rom XAuth. The rest of the design team had an opportunity to express their c= oncerns and Justin edited the document. In other words, I had to convince Ju= stin to change the document, rather than the design team comparing and contr= asting the proposals and selecting the best parts. I expressed my concerns w= ith our AD, and decided to continue participating in the design team. We did= make some progress on a number of issues thanks to the hard work of Fabien,= Justin, and Mike -- but many issues have been punted to the WG.=20 >=20 > Justin has poured tons of energy into this project, and to his credit he w= as a good editor at times, but there are areas where he was unwilling to dev= iate from his vision.=20 >=20 > I am concerned about a repeat of what happened in OAuth 2.0: Erin had the p= en and had strong views that often were not aligned with the rest of the WG.= A good example was Erin's distaste for bearer tokens. He factored that out o= f the core document, which we are now adding back in with OAuth 2.1. Anyone t= hat participated in the WG saw the issues this had. >=20 > I'm not suggesting that Justin is Erin, but I think a more neutral editor o= f the core document will allow us to make progress more quickly.=20 >=20 > /Dick >=20 > [1] https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW3= 8I/ > =E1=90=A7 >=20 >> On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: >> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their hard= work and discussion as well. This draft contains aspects of XYZ and Xauth, a= nd introduces some new elements and pieces as well. As you'll see, there are= many identified issues and decisions to be made, but even then I believe it= hangs together fairly cohesively already thanks to the good engineering eff= ort and discussion that's gone in so far.=20 >>=20 >> Nothing in the document is final, of course. To me, this document represe= nts a good starting point for working group discussion and decisions, +1 for= its adoption.=20 >>=20 >> - Justin >> ________________________________________ >> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ka= thleen.moriarty.ietf@gmail.com] >> Sent: Friday, October 9, 2020 6:55 PM >> To: txauth@ietf.org >> Subject: [GNAP] Design team >>=20 >> Greetings! >>=20 >> The design team has now come to a close. While there were too many issue= s to resolve to all design team member satisfaction, great effort was put in= to describe decision points for the WG to ease and hopefully speed the work= ing group process. As such, I am requesting that the WG adopts this version= (14 of XYZ) and works together to fully develop a single specification. >>=20 >> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >>=20 >> A tremendous thank you to each of the design team members for your hard w= ork and walking the fine line of when to put a stake in the ground (that the= WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process. >>=20 >> Best regards, >> Kathleen >>=20 >> Sent from my mobile device >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-FCD8D007-8073-43A7-BC36-B4B08B73B3C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My take is very different, Di= ck.  I am starting a 2 week vacation and will not be spending it arguin= g with you on the list.

Multiple reviews p= ointed to Justin=E2=80=99s document as a better starting point, not just min= e.  Your use case cases can be met and some of what you were asking for= did not follow RESTful design patterns.  They really don=E2=80=99t map= to a future protocol well.  You may need to write extension documents,= but your goals can be met.

Many calls were= difficult as displayed in your message.  Justin did a great job handli= ng the weekly tension and ensuring options were included for WG discussion w= hen agreement was not met.  He=E2=80=99s completely amenable to followi= ng the WG and chairs decisions.  His document was also easier to follow= and aligned better with numerous IETF documents.  Please do keep Justi= n on as an editor. As you can see from the draft, there are many areas where= WG input on decision points are requested.

Best regards,
Kathleen&= nbsp;

Sent from my mobile device

On Oct 9, 2020, at 8:26 PM, Dick Hardt <dick.hardt@gmail.com&= gt; wrote:

=EF=BB=BF
Tl;dr: Given where we are in the WG, I am not o= pposed to the WG adopting -14, but I propose someone other than Justin be th= e document editor.

I was on the design team to work on the goals set= out by the chairs [1]:

"We expect the design team to decide on a so= lution outline that combines the best of both proposals, and present this ou= tline by Sep. 15"

Surprisingly, Kathleen convened the design team wit= h her recommendation to start with the XYZ document with Justin as editor, a= nd add in the diagrams from XAuth. The rest of the design team had an opport= unity to express their concerns and Justin edited the document. In other wor= ds, I had to convince Justin to change the document, rather than the design t= eam comparing and contrasting the proposals and selecting the best parts. I e= xpressed my concerns with our AD, and decided to continue participating in t= he design team. We did make some progress on a number of issues thanks to th= e hard work of Fabien, Justin, and Mike -- but many issues have been punted t= o the WG.

Justin has poured tons of energy into this project, and to= his credit he was a good editor at times, but there are areas where he was u= nwilling to deviate from his vision.

I am concerned about a repeat o= f what happened in OAuth 2.0: Erin had the pen and had strong views that oft= en were not aligned with the rest of the WG. A good example was Erin's dista= ste for bearer tokens. He factored that out of the core document, which we a= re now adding back in with OAuth 2.1. Anyone that participated in the WG saw= the issues this had.

I'm not suggesting that Justin is Erin, but I t= hink a more neutral editor of the core document will allow us to make progre= ss more quickly.

/Dick

[1] https://mailarchive.ietf= .org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM Justin Rich= er <jricher@mit.edu> wrote:
=
Thanks, Kathleen, and= thanks to Dick, Mike, and Fabian for all their hard work and discussion as w= ell. This draft contains aspects of XYZ and Xauth, and introduces some new e= lements and pieces as well. As you'll see, there are many identified issues a= nd decisions to be made, but even then I believe it hangs together fairly co= hesively already thanks to the good engineering effort and discussion that's= gone in so far.

Nothing in the document is final, of course. To me, this document represents= a good starting point for working group discussion and decisions, +1 for it= s adoption.

- Justin
________________________________________
From: TXAuth [t= xauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kathleen.moriarty.ietf= @gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org=
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.  While there were too many iss= ues to resolve to all design team member satisfaction, great effort was put i= n to describe decision points for the WG to ease and hopefully speed the wor= king group process.  As such, I am requesting that the WG adopts this v= ersion (14 of XYZ) and works together to fully develop a single specificatio= n.

https://datatracker.ietf.org/doc/dra= ft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard work= and walking the fine line of when to put a stake in the ground (that the WG= can always change once adopted) and listing our options for decision points= to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-FCD8D007-8073-43A7-BC36-B4B08B73B3C0-- From nobody Fri Oct 9 19:15:02 2020 Return-Path: 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 5E6923A12B0 for ; Fri, 9 Oct 2020 19:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 nBvc9MdfkZCg for ; Fri, 9 Oct 2020 19:14:59 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 39F0F3A121A for ; Fri, 9 Oct 2020 19:14:59 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id t12so11035992ilh.3 for ; Fri, 09 Oct 2020 19:14:59 -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=3w8OyjuHO08PMJOEfdRIDlg7kYzut6rVDVvbyxDkDoc=; b=U3C8yjO6jf6jx0Eo7FILOGQBAdERbr1/gKAUimyolvRJb5KYB/2qiCpQCr+0Xwwbjd TtiMLLJfQWjot0oQ5R9u2mFseBw1LyEFnFi1m0olzyxwtR9ZrD+m3cFTqpne6ZmTskc1 Onwum2oewc13fPabX70WV5ylHenIhC/JVNX+NkofxMX89WwkjGb82a2Si12M3KRws8k1 won7mdqi1i5u/ZZOIhQDUPvalX5MjO7kq7WE0IHqzkGxbZwZZEDuoHz4AMtQRzmgB9u0 C3mkuRLR9RFcF5aZZmpvXrb8tDA8bA/q09VV2EOaXPcVIwwMctcV3gJZ88nYTrtNLymA cOmg== 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=3w8OyjuHO08PMJOEfdRIDlg7kYzut6rVDVvbyxDkDoc=; b=oL1TspOQtq4h3SmjvdfsfbvbIQRgOYzhsNEPZmHO5FSW1dByFWndKICtDBXQD++mjc pgQWFND9cPQZRh2d8FgFW3mb9TKsrcmlXQq9m6FrVWypQrrSQfkL7diihNFNZFzNEPU5 k88nkOzLJ5eL4jb1MWzTHQ+DAGLr+T6AsLyo6iYZ9Wd4ev0n8djZwaQKYYW7nZnT7nyW UEZqH3G+zEZbPkozxgHiicZV5ZykE/lSIbb20gyx4KN5t5FbOn5EszHilbn5eZ2ztt2J Vjyv8RO8bVQE9GQKz36u1OkXj7lNr2A/eOyN3WmosLfwLdT2kXI1OwsAQ2EmzatgPRPB aQoA== X-Gm-Message-State: AOAM5303BKMbP1xKlh9YTvzfI3KyQu3tR1oXAOvP4Fke88Yo0J+zs5B8 Dwn+kdE/YmuwoB0iKmmQy5uZg4kWVc+U0/1ichk= X-Google-Smtp-Source: ABdhPJw2vQrmpDTdUY8pIWruIEzxYX4zhpbLDTPAmM+axENhze4v3bEgbC2lKv4m+JRTIoFcimOCO+n+HajTmhOOHp8= X-Received: by 2002:a05:6e02:249:: with SMTP id w9mr11691163ilr.188.1602296097453; Fri, 09 Oct 2020 19:14:57 -0700 (PDT) MIME-Version: 1.0 References: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> In-Reply-To: From: Fabien Imbault Date: Sat, 10 Oct 2020 04:14:45 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , Kathleen Moriarty , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b6ba8a05b147a1b2" Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 02:15:01 -0000 --000000000000b6ba8a05b147a1b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, +1 for adopting v14 as a basis for the GNAP WG. I think really important to have one single document to get everyone started, and not be stuck on a xyz vs xauth comparison. Instead we now have a relatively consistent starting point, which is neither xyz nor xauth, for everyone to step in. The draft is still inspired by xyz at its core, but a lot of work has been put into taking the concerns raised in xauth (Dick did raise many issues into the original document, and made a great job), and others. As anyone will be able to see into the change logs. What's important is that editorial notes provide a good summary of the design choices we need to make. I can anticipate that some of you will raise other items discussed on the mailing list, such as privacy for instance. There was consensus on the fact that it needs to be one of the goals (amongst others) but our core focus during the work carried out in the small group was to focus on dissenting opinions about what the starting document should contain. It's not meant to be perfect (yeah, goal achieved :-)). I can attest Justin put a lot of hard work in taking into account the feedbacks and criticisms, and it's quite impressive to still have a fairly consistent document after so many changes in a short period of time. Of course neither of us had all of its wishes come true :-) Dick probably feels some issues he raised are not fully incorporated, because some are fundamentally different design choices. Again Dick raised very useful items, some of which made it through, others are only integrated as notes. At times the tension was palpable and sometimes Kathleen had to remind everyone to cool down (thanks for that!). And we see some of that into Dick's request today. I regret a bit that this might hinder the positive outcome of the work. All items were on the table. We made a fairly thorough comparison of the approaches, which led to many parts being rewritten. Justin was quite clear when he disagreed (it's explicit in the notes) but still captured with integrity the essence of the tradeoffs, with an open mind. Of course there's a specific power in holding the pen. I think Justin is aware of what the role implies. Of course it's sometimes hard to not be too opinionated, while still being able to say no when required. Probably the chairs could step in to clarify escalation rules to avoid the risk mentioned by Dick, in case it ever materializes. No one is perfect. But so far, Justin's mandate has not transformed into a benevolent dictatorship, but more a balanced guardianship. As such he keeps my continued support into the editor's role. Cheers Fabien Le sam. 10 oct. 2020 =C3=A0 02:26, Dick Hardt a =C3= =A9crit : > Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting > -14, but I propose someone other than Justin be the document editor. > > I was on the design team to work on the goals set out by the chairs [1]: > > "We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15" > > Surprisingly, Kathleen convened the design team with her recommendation t= o > start with the XYZ document with Justin as editor, and add in the diagram= s > from XAuth. The rest of the design team had an opportunity to express the= ir > concerns and Justin edited the document. In other words, I had to convinc= e > Justin to change the document, rather than the design team comparing and > contrasting the proposals and selecting the best parts. I expressed my > concerns with our AD, and decided to continue participating in the design > team. We did make some progress on a number of issues thanks to the hard > work of Fabien, Justin, and Mike -- but many issues have been punted to t= he > WG. > > Justin has poured tons of energy into this project, and to his credit he > was a good editor at times, but there are areas where he was unwilling to > deviate from his vision. > > I am concerned about a repeat of what happened in OAuth 2.0: Erin had the > pen and had strong views that often were not aligned with the rest of the > WG. A good example was Erin's distaste for bearer tokens. He factored tha= t > out of the core document, which we are now adding back in with OAuth 2.1. > Anyone that participated in the WG saw the issues this had. > > I'm not suggesting that Justin is Erin, but I think a more neutral editor > of the core document will allow us to make progress more quickly. > > /Dick > > [1] > https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/ > =E1=90=A7 > > On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: > >> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their har= d >> work and discussion as well. This draft contains aspects of XYZ and Xaut= h, >> and introduces some new elements and pieces as well. As you'll see, ther= e >> are many identified issues and decisions to be made, but even then I >> believe it hangs together fairly cohesively already thanks to the good >> engineering effort and discussion that's gone in so far. >> >> Nothing in the document is final, of course. To me, this document >> represents a good starting point for working group discussion and >> decisions, +1 for its adoption. >> >> - Justin >> ________________________________________ >> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ >> kathleen.moriarty.ietf@gmail.com] >> Sent: Friday, October 9, 2020 6:55 PM >> To: txauth@ietf.org >> Subject: [GNAP] Design team >> >> Greetings! >> >> The design team has now come to a close. While there were too many >> issues to resolve to all design team member satisfaction, great effort w= as >> put in to describe decision points for the WG to ease and hopefully spee= d >> the working group process. As such, I am requesting that the WG adopts >> this version (14 of XYZ) and works together to fully develop a single >> specification. >> >> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >> >> A tremendous thank you to each of the design team members for your hard >> work and walking the fine line of when to put a stake in the ground (tha= t >> the WG can always change once adopted) and listing our options for decis= ion >> points to ease the WG process. >> >> Best regards, >> Kathleen >> >> Sent from my mobile device >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b6ba8a05b147a1b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

+1= for adopting v14 as a basis for the GNAP WG.=C2=A0
=
I think really important to have one single doc= ument to get everyone started, and not be stuck on a xyz vs xauth compariso= n. Instead we now have a relatively consistent starting point, which is nei= ther xyz nor xauth, for everyone to step in.=C2=A0
<= br>
The draft is still inspired by xyz at its core, = but a lot of work has been put into taking the concerns raised in xauth (Di= ck did raise many issues into the original document, and made a great job),= and others. As anyone will be able to see into the change logs.=C2=A0

What's important is that= editorial notes provide a good summary of the design choices we need to ma= ke.=C2=A0
I can anticipate that some of you will rai= se other items discussed on the mailing list, such as privacy for instance.= There was consensus on the fact that it needs to be one of the goals (amon= gst others) but our core focus during the work carried out in the small gro= up was to focus on dissenting opinions about what the starting document sho= uld contain. It's not meant to be perfect (yeah, goal achieved :-)).=C2= =A0

I can attest Justin = put a lot of hard work in taking into account the feedbacks and criticisms,= and it's quite impressive to still have a fairly consistent document a= fter so many changes in a short period of time.=C2=A0

Of course neither of us had all of its wishes= come true :-) Dick probably feels some issues he raised are not fully inco= rporated, because some are fundamentally different design choices. Again Di= ck raised very useful items, some of which made it through, others are only= integrated as notes. At times the tension was palpable and sometimes Kathl= een had to remind everyone to cool down (thanks for that!). And we see some= of that into Dick's request today. I regret a bit that this might hind= er the positive outcome of the work.=C2=A0

All items were on the table. We made a fairly thorough c= omparison of the approaches, which led to many parts being rewritten. Justi= n was quite clear when he disagreed (it's explicit in the notes) but st= ill captured with integrity the essence of the tradeoffs, with an open mind= .=C2=A0

Of course there&= #39;s a specific power in holding the pen. I think Justin is aware of what = the role implies. Of course it's sometimes hard to not be too opinionat= ed, while still being able to say no when required.=C2=A0

Probably the chairs could step in to clar= ify escalation rules to avoid the risk mentioned by Dick, in case it ever m= aterializes. No one is perfect. But so far, Justin's mandate has not transformed into a benevolent dictator= ship, but more a balanced guardianship. As such he keeps my continued suppo= rt into the editor's role.=C2=A0

Cheers
Fabien=C2=A0

Le sam. 10 oct. 2020 =C3=A0 02:26, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Tl;dr: Given where we are= in the WG, I am not opposed to the WG adopting -14, but I propose someone = other than Justin be the document editor.

I was on the design team = to work on the goals set out by the chairs [1]:

"We expect the= design team to decide on a solution outline that combines the best of both= proposals, and present this outline by Sep. 15"

Surprisingly, = Kathleen convened the design team with her recommendation to start with the= XYZ document with Justin as editor, and add in the diagrams from XAuth. Th= e rest of the design team had an opportunity to express their concerns and = Justin edited the document. In other words, I had to convince Justin to cha= nge the document, rather than the design team comparing and contrasting the= proposals and selecting the best parts. I expressed my concerns with our A= D, and decided to continue participating in the design team. We did make so= me progress on a number of issues thanks to the hard work of Fabien, Justin= , and Mike -- but many issues have been punted to the WG.

Justin ha= s poured tons of energy into this project, and to his credit he was a good = editor at times, but there are areas where he was unwilling to deviate from= his vision.

I am concerned about a repeat of what happened in OAut= h 2.0: Erin had the pen and had strong views that often were not aligned wi= th the rest of the WG. A good example was Erin's distaste for bearer to= kens. He factored that out of the core document, which we are now adding ba= ck in with OAuth 2.1. Anyone that participated in the WG saw the issues thi= s had.

I'm not suggesting that Justin is Erin, but I think a mor= e neutral editor of the core document will allow us to make progress more q= uickly.

/Dick

[1] https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW= 38I/
<= img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden" src=3D"http= s://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&t= ype=3Dzerocontent&guid=3D23f4bf44-8074-4f2c-b0c8-f2639da4b686">=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM J= ustin Richer <jricher@mit.edu> wrote:
Thanks, Kathleen, and thanks to Dick, Mike= , and Fabian for all their hard work and discussion as well. This draft con= tains aspects of XYZ and Xauth, and introduces some new elements and pieces= as well. As you'll see, there are many identified issues and decisions= to be made, but even then I believe it hangs together fairly cohesively al= ready thanks to the good engineering effort and discussion that's gone = in so far.

Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.

- Justin
________________________________________
From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moria= rty [kathleen.moriarty.ietf@gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.iet= f.org/doc/draft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000b6ba8a05b147a1b2-- From nobody Sat Oct 10 06:00:57 2020 Return-Path: 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 C3F313A0ED6 for ; Sat, 10 Oct 2020 06:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 1HJAap8Fw9GJ for ; Sat, 10 Oct 2020 06:00:54 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 0A5243A0ED1 for ; Sat, 10 Oct 2020 06:00:54 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id g12so13050236wrp.10 for ; Sat, 10 Oct 2020 06:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=nr9+RBekIyDURgK0pJymIePrPOZNv4hBnrKqsbGOzFQ=; b=cM4MTKK/05bYzYqV0cgNJqf/Jwu6rBG5GUPm6zafi4GQUDje/UHaJw6b8/Iuunop94 GWOXJlFw+rPPmByj0eeZMZn5XCOfG/oWuk+6wBbIZz4CXkeOvTVoFCLuJ9gNmNom5ZmF RrjA4JtV1pyWCXIEujq7Sxdk4KPqe1ZhPxRMSIZkoBOBeffDd0/Y4YtKL1PgnVLaNO+R BPX++rdMnq/De0z/ZXZ2GEU0z0/lkMYrogJ8+jdMANyaHujr8O2LeK87a5z92AideISl u+M0OTZGUOg1cJCts2kxfJzKJfrIaNUOe6ZHkXXUsofmp9WQhGvxR3cfYWVeDYuXk8dq wUxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=nr9+RBekIyDURgK0pJymIePrPOZNv4hBnrKqsbGOzFQ=; b=mjwvDlBOF+WUyRYSyCupAN56tpS+Ssc53YMNEIGp3HaCxyfPP4SLtrHiuiNr0RJ+MJ OSzDl5vQHKGDbJk/Oru6hIkYzTnb46E8jbiwzHSzo9uHHOdZfR/8qtziTuShY0Tv6u0r +4Ep1KT1csHLdpCXTbA2SKA7QxT1JLtsQgeRnJOnKvRlU0SptNm1KiUA7FiNVF/CEfsY 0bazCLoUTboJ2AjgimONHX/rLRMtty8JWgwKOWgTKdBhcA/m7ecC8mxMeVjjjK2npxPa U6voUWSpMvEF4I0kWFEqhnrrOVIrX45PDMORrrYD/+kaViRmuTPybzDx4ZE1qlAAppYy 4FBA== X-Gm-Message-State: AOAM533hynrzx2t6Bm7bW53m64BwssWZxsQ+9z00axVj5+6rowl3NCgM ukGsst/sbSfUr2jzkrZM+UU= X-Google-Smtp-Source: ABdhPJyAqQ6T6R9NOrml0L9yyjy1ynBMZ8zykCFa8utH7XvPWyGqdxuz3SOvWauh75kxUxUrEbwYEQ== X-Received: by 2002:adf:e690:: with SMTP id r16mr19710319wrm.15.1602334852344; Sat, 10 Oct 2020 06:00:52 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-180-86-177.red.bezeqint.net. [79.180.86.177]) by smtp.gmail.com with ESMTPSA id u2sm16894114wre.7.2020.10.10.06.00.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Oct 2020 06:00:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.41.20091302 Date: Sat, 10 Oct 2020 16:00:49 +0300 From: Yaron Sheffer To: Kathleen Moriarty , Message-ID: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> Thread-Topic: Call for adoption: draft-richer-transactional-auth-14 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685190450_2069176163" Archived-At: Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 13:00:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685190450_2069176163 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Many thanks to Kathleen and the design team for the intensive work that bro= ught us to this point. =20 We would like to issue a short, one week call for adoption for draft-richer= -transactional-authz-14 as the basis of the working group=E2=80=99s GNAP protocol.= To clarify, this means that the design team, having achieved its goal, is d= isbanded, and that change control over the document passes into the working = group. Whether you=E2=80=99re for or against, please speak up. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron =20 From: TXAuth on behalf of Kathleen Moriarty Date: Saturday, October 10, 2020 at 01:55 To: GNAP Mailing List Subject: [GNAP] Design team =20 Greetings! =20 The design team has now come to a close. While there were too many issues = to resolve to all design team member satisfaction, great effort was put in t= o describe decision points for the WG to ease and hopefully speed the workin= g group process. As such, I am requesting that the WG adopts this version (= 14 of XYZ) and works together to fully develop a single specification. =20 https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ =20 A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the W= G can always change once adopted) and listing our options for decision point= s to ease the WG process. =20 Best regards, Kathleen=20 =20 Sent from my mobile device -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3685190450_2069176163 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Many thanks to Kathle= en and the design team for the intensive work that brought us to this point.=

 

We= would like to issue a short, one week call for adoption for draft-richer-tr= ansactional-authz-14 as the basis of the working group=E2=80=99s GNAP protocol. To= clarify, this means that the design team, having achieved its goal, is disb= anded, and that change control over the document passes into the working gro= up. Whether you=E2=80=99re for or against, please speak up.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron

=

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Saturd= ay, October 10, 2020 at 01:55
To: GNAP Mailing List <txauth@iet= f.org>
Subject: [GNAP] Design team

<= div>

 

Greetings!

 

The desig= n team has now come to a close.  While there were too many issues to re= solve to all design team member satisfaction, great effort was put in to des= cribe decision points for the WG to ease and hopefully speed the working gro= up process.  As such, I am requesting that the WG adopts this version (= 14 of XYZ) and works together to fully develop a single specification.<= /o:p>

 

 

<= /div>

A tremendous thank you to each of the design te= am members for your hard work and walking the fine line of when to put a sta= ke in the ground (that the WG can always change once adopted) and listing ou= r options for decision points to ease the WG process.

 

Bes= t regards,

Kathleen 

 

Sent from my mobile device

-- TXAut= h mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

--B_3685190450_2069176163-- From nobody Sat Oct 10 07:16:55 2020 Return-Path: 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 00C223A14E0 for ; Sat, 10 Oct 2020 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vL_CATAlb2XK for ; Sat, 10 Oct 2020 07:16:52 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB443A14DB for ; Sat, 10 Oct 2020 07:16:51 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 09AEGnAW017395; Sat, 10 Oct 2020 10:16:49 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sat, 10 Oct 2020 10:16:48 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 10 Oct 2020 10:16:49 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Sat, 10 Oct 2020 10:16:49 -0400 From: Justin Richer To: Yaron Sheffer , Kathleen Moriarty , "txauth@ietf.org" Thread-Topic: Call for adoption: draft-richer-transactional-auth-14 Thread-Index: AQHWnwVoEGLjhGWoskOGOUoh7DpEf6mQ4eGU Date: Sat, 10 Oct 2020 14:16:49 +0000 Message-ID: References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 14:16:54 -0000 +1 for adoption of the document ________________________________________ From: TXAuth [txauth-bounces@ietf.org] on behalf of Yaron Sheffer [yaronf.i= etf@gmail.com] Sent: Saturday, October 10, 2020 9:00 AM To: Kathleen Moriarty; txauth@ietf.org Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14 Many thanks to Kathleen and the design team for the intensive work that bro= ught us to this point. We would like to issue a short, one week call for adoption for draft-richer= -transactional-authz-14 as the basis of the working group=92s GNAP protocol= . To clarify, this means that the design team, having achieved its goal, is= disbanded, and that change control over the document passes into the worki= ng group. Whether you=92re for or against, please speak up. Thanks, Leif and Yaron From: TXAuth on behalf of Kathleen Moriarty Date: Saturday, October 10, 2020 at 01:55 To: GNAP Mailing List Subject: [GNAP] Design team Greetings! The design team has now come to a close. While there were too many issues = to resolve to all design team member satisfaction, great effort was put in = to describe decision points for the WG to ease and hopefully speed the work= ing group process. As such, I am requesting that the WG adopts this versio= n (14 of XYZ) and works together to fully develop a single specification. https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process. Best regards, Kathleen Sent from my mobile device -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth From nobody Sat Oct 10 10:44:41 2020 Return-Path: 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 919793A1611 for ; Sat, 10 Oct 2020 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLYTO=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FMrHv8aau2Yj for ; Sat, 10 Oct 2020 10:44:38 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 6F7933A160D for ; Sat, 10 Oct 2020 10:44:38 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id c3so9929866ybl.0 for ; Sat, 10 Oct 2020 10:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=TEfdnpU8lq4q8qmJMk0Xo2d+KNdUlHNezVx6rWtzsus=; b=rOTHSD07T600cC/Vdp0xwNJ09ag2QyeKCpG2N9Q0SwxC7ZhqbdZjYwmbFzkHF4q2dQ OtKvmpfBNLuO2rCW8elrSy1MFeTbflex63xh/Q+FcrM/Wu1U4bdrKsbiUa8VEa6jzZ3O lhKOl7i4gwKWRJGdcugNZqbtU18zTBO1Br74Jg2e8sningTbo0/sRVUE83Pd6zMKB02Q JJMsD2lzthbuWPaiYAtBB5wbvxj7L7xmkzzGfZmbA4wh0vAJi/ABEA9VvVs+flYUEOMI FXEU9igJV7WKs/8wIV9kbQ4Gr7tArXwJh5LORipFUe7ZAIg1CyPGKEDGDrXSeX5NyRYH KPdg== 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:reply-to :from:date:message-id:subject:to; bh=TEfdnpU8lq4q8qmJMk0Xo2d+KNdUlHNezVx6rWtzsus=; b=gyrcboxl4bhakzxYLGanc0Kjj7MQlh1dWLiDSjUlWiKeoemuKhAoUOU/6Jq4j5pJ0I 6qqxAmSy+et1y3KMdKVs8+WgAlsoN2h7SuY4kqhTd+ebpMFKopLD/MTJrZe1hdKFIXVc lkl6bvBGbAHKI0GBPtujCZ5EJUgRA/IRLbvTX+eEsI9L8m/TJIiXHkfJsgIhBeZqqPj+ 8LNksIiJ0d1zUfJ3SHs/z0T9Le5J9VKX7g4odWOGlRS8gyhJNMymil2udYReLokBXrG1 7Plmk5zaSWuaLvCS3lAV290HKIP0kQDeYy9P5IIuv6c42TAvWZDD9VTUlg+NIcnrFLBZ u2FA== X-Gm-Message-State: AOAM5309Rt4y8tq4m2JLDE/nxaFv7WcYojvkUfKf3JiC3CSOtqj2js4W 4BmlbNcrRzfkO+OJCQCWvQ3E5dnOVHDC4vXOp6ce9e4= X-Google-Smtp-Source: ABdhPJwKIq19qavsn6AIGt6qcjbLglFoBOeo/SyNSjCxQ91pZKZ7gpx7y+aI1Y7ZoH+/R6HRnoye8xYPtfUQkcJG/i8= X-Received: by 2002:a25:5f06:: with SMTP id t6mr23152447ybb.501.1602351877135; Sat, 10 Oct 2020 10:44:37 -0700 (PDT) MIME-Version: 1.0 References: <2853ADA4-6F92-4E83-80C0-DFED05D0C0E4@gmail.com> In-Reply-To: Reply-To: dzagidulin@gmail.com From: Dmitri Zagidulin Date: Sat, 10 Oct 2020 13:44:20 -0400 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007122cc05b1549e99" Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 17:44:41 -0000 --0000000000007122cc05b1549e99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Big congratulations to the design team. This looks like it was a titanic effort, and the resulting draft looks great. Thank you all for your hard work! On Fri, Oct 9, 2020 at 10:15 PM Fabien Imbault wrote: > Hi there, > > +1 for adopting v14 as a basis for the GNAP WG. > > I think really important to have one single document to get everyone > started, and not be stuck on a xyz vs xauth comparison. Instead we now ha= ve > a relatively consistent starting point, which is neither xyz nor xauth, f= or > everyone to step in. > > The draft is still inspired by xyz at its core, but a lot of work has bee= n > put into taking the concerns raised in xauth (Dick did raise many issues > into the original document, and made a great job), and others. As anyone > will be able to see into the change logs. > > What's important is that editorial notes provide a good summary of the > design choices we need to make. > I can anticipate that some of you will raise other items discussed on the > mailing list, such as privacy for instance. There was consensus on the fa= ct > that it needs to be one of the goals (amongst others) but our core focus > during the work carried out in the small group was to focus on dissenting > opinions about what the starting document should contain. It's not meant = to > be perfect (yeah, goal achieved :-)). > > I can attest Justin put a lot of hard work in taking into account the > feedbacks and criticisms, and it's quite impressive to still have a fairl= y > consistent document after so many changes in a short period of time. > > Of course neither of us had all of its wishes come true :-) Dick probably > feels some issues he raised are not fully incorporated, because some are > fundamentally different design choices. Again Dick raised very useful > items, some of which made it through, others are only integrated as notes= . > At times the tension was palpable and sometimes Kathleen had to remind > everyone to cool down (thanks for that!). And we see some of that into > Dick's request today. I regret a bit that this might hinder the positive > outcome of the work. > > All items were on the table. We made a fairly thorough comparison of the > approaches, which led to many parts being rewritten. Justin was quite cle= ar > when he disagreed (it's explicit in the notes) but still captured with > integrity the essence of the tradeoffs, with an open mind. > > Of course there's a specific power in holding the pen. I think Justin is > aware of what the role implies. Of course it's sometimes hard to not be t= oo > opinionated, while still being able to say no when required. > > Probably the chairs could step in to clarify escalation rules to avoid th= e > risk mentioned by Dick, in case it ever materializes. No one is perfect. > But so far, Justin's mandate has not transformed into a benevolent > dictatorship, but more a balanced guardianship. As such he keeps my > continued support into the editor's role. > > Cheers > Fabien > > > Le sam. 10 oct. 2020 =C3=A0 02:26, Dick Hardt a = =C3=A9crit : > >> Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting >> -14, but I propose someone other than Justin be the document editor. >> >> I was on the design team to work on the goals set out by the chairs [1]: >> >> "We expect the design team to decide on a solution outline that combines >> the best of both proposals, and present this outline by Sep. 15" >> >> Surprisingly, Kathleen convened the design team with her recommendation >> to start with the XYZ document with Justin as editor, and add in the >> diagrams from XAuth. The rest of the design team had an opportunity to >> express their concerns and Justin edited the document. In other words, I >> had to convince Justin to change the document, rather than the design te= am >> comparing and contrasting the proposals and selecting the best parts. I >> expressed my concerns with our AD, and decided to continue participating= in >> the design team. We did make some progress on a number of issues thanks = to >> the hard work of Fabien, Justin, and Mike -- but many issues have been >> punted to the WG. >> >> Justin has poured tons of energy into this project, and to his credit he >> was a good editor at times, but there are areas where he was unwilling t= o >> deviate from his vision. >> >> I am concerned about a repeat of what happened in OAuth 2.0: Erin had th= e >> pen and had strong views that often were not aligned with the rest of th= e >> WG. A good example was Erin's distaste for bearer tokens. He factored th= at >> out of the core document, which we are now adding back in with OAuth 2.1= . >> Anyone that participated in the WG saw the issues this had. >> >> I'm not suggesting that Justin is Erin, but I think a more neutral edito= r >> of the core document will allow us to make progress more quickly. >> >> /Dick >> >> [1] >> https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I= / >> =E1=90=A7 >> >> On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: >> >>> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their >>> hard work and discussion as well. This draft contains aspects of XYZ an= d >>> Xauth, and introduces some new elements and pieces as well. As you'll s= ee, >>> there are many identified issues and decisions to be made, but even the= n I >>> believe it hangs together fairly cohesively already thanks to the good >>> engineering effort and discussion that's gone in so far. >>> >>> Nothing in the document is final, of course. To me, this document >>> represents a good starting point for working group discussion and >>> decisions, +1 for its adoption. >>> >>> - Justin >>> ________________________________________ >>> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ >>> kathleen.moriarty.ietf@gmail.com] >>> Sent: Friday, October 9, 2020 6:55 PM >>> To: txauth@ietf.org >>> Subject: [GNAP] Design team >>> >>> Greetings! >>> >>> The design team has now come to a close. While there were too many >>> issues to resolve to all design team member satisfaction, great effort = was >>> put in to describe decision points for the WG to ease and hopefully spe= ed >>> the working group process. As such, I am requesting that the WG adopts >>> this version (14 of XYZ) and works together to fully develop a single >>> specification. >>> >>> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >>> >>> A tremendous thank you to each of the design team members for your hard >>> work and walking the fine line of when to put a stake in the ground (th= at >>> the WG can always change once adopted) and listing our options for deci= sion >>> points to ease the WG process. >>> >>> Best regards, >>> Kathleen >>> >>> Sent from my mobile device >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007122cc05b1549e99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Big congratulations to the design team. This looks like it= was a titanic effort, and the resulting draft looks great.

<= div>Thank you all for your hard work!

On Fri, Oct 9, 2020 at 10:15 PM = Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
Hi there,

+1 for adopting v14 as a basis for the GNAP WG.=C2=A0

I think really important to have on= e single document to get everyone started, and not be stuck on a xyz vs xau= th comparison. Instead we now have a relatively consistent starting point, = which is neither xyz nor xauth, for everyone to step in.=C2=A0

The draft is still inspired by xyz a= t its core, but a lot of work has been put into taking the concerns raised = in xauth (Dick did raise many issues into the original document, and made a= great job), and others. As anyone will be able to see into the change logs= .=C2=A0

What's impor= tant is that editorial notes provide a good summary of the design choices w= e need to make.=C2=A0
I can anticipate that some of = you will raise other items discussed on the mailing list, such as privacy f= or instance. There was consensus on the fact that it needs to be one of the= goals (amongst others) but our core focus during the work carried out in t= he small group was to focus on dissenting opinions about what the starting = document should contain. It's not meant to be perfect (yeah, goal achie= ved :-)).=C2=A0

I can at= test Justin put a lot of hard work in taking into account the feedbacks and= criticisms, and it's quite impressive to still have a fairly consisten= t document after so many changes in a short period of time.=C2=A0

Of course neither of us had all o= f its wishes come true :-) Dick probably feels some issues he raised are no= t fully incorporated, because some are fundamentally different design choic= es. Again Dick raised very useful items, some of which made it through, oth= ers are only integrated as notes. At times the tension was palpable and som= etimes Kathleen had to remind everyone to cool down (thanks for that!). And= we see some of that into Dick's request today. I regret a bit that thi= s might hinder the positive outcome of the work.=C2=A0

All items were on the table. We made a fairl= y thorough comparison of the approaches, which led to many parts being rewr= itten. Justin was quite clear when he disagreed (it's explicit in the n= otes) but still captured with integrity the essence of the tradeoffs, with = an open mind.=C2=A0

Of c= ourse there's a specific power in holding the pen. I think Justin is aw= are of what the role implies. Of course it's sometimes hard to not be t= oo opinionated, while still being able to say no when required.=C2=A0
=

Probably the chairs could ste= p in to clarify escalation rules to avoid the risk mentioned by Dick, in ca= se it ever materializes. No one is perfect. But so far, Justin's mandate has not transformed into a benevol= ent dictatorship, but more a balanced guardianship. As such he keeps my con= tinued support into the editor's role.=C2=A0

Cheers
Fabien=C2=A0<= /div>

Le sam. 10 oct. 2020 =C3=A0 02:26, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:
Tl;dr: Given where we are in the WG, I am not o= pposed to the WG adopting -14, but I propose someone other than Justin be t= he document editor.

I was on the design team to work on the goals s= et out by the chairs [1]:

"We expect the design team to decide= on a solution outline that combines the best of both proposals, and presen= t this outline by Sep. 15"

Surprisingly, Kathleen convened the = design team with her recommendation to start with the XYZ document with Jus= tin as editor, and add in the diagrams from XAuth. The rest of the design t= eam had an opportunity to express their concerns and Justin edited the docu= ment. In other words, I had to convince Justin to change the document, rath= er than the design team comparing and contrasting the proposals and selecti= ng the best parts. I expressed my concerns with our AD, and decided to cont= inue participating in the design team. We did make some progress on a numbe= r of issues thanks to the hard work of Fabien, Justin, and Mike -- but many= issues have been punted to the WG.

Justin has poured tons of energ= y into this project, and to his credit he was a good editor at times, but t= here are areas where he was unwilling to deviate from his vision.

I= am concerned about a repeat of what happened in OAuth 2.0: Erin had the pe= n and had strong views that often were not aligned with the rest of the WG.= A good example was Erin's distaste for bearer tokens. He factored that= out of the core document, which we are now adding back in with OAuth 2.1. = Anyone that participated in the WG saw the issues this had.

I'm = not suggesting that Justin is Erin, but I think a more neutral editor of th= e core document will allow us to make progress more quickly.

/Dick<= br>
[1] https://mailarch= ive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM Justin Richer <= ;jr= icher@mit.edu> wrote:
Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all= their hard work and discussion as well. This draft contains aspects of XYZ= and Xauth, and introduces some new elements and pieces as well. As you'= ;ll see, there are many identified issues and decisions to be made, but eve= n then I believe it hangs together fairly cohesively already thanks to the = good engineering effort and discussion that's gone in so far.

Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.

- Justin
________________________________________
From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moria= rty [kathleen.moriarty.ietf@gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.iet= f.org/doc/draft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007122cc05b1549e99-- From nobody Sat Oct 10 10:45:14 2020 Return-Path: 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 4D7493A1611 for ; Sat, 10 Oct 2020 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLYTO=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1PLmG_qJ0fhJ for ; Sat, 10 Oct 2020 10:45:11 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 8CBE53A160D for ; Sat, 10 Oct 2020 10:45:11 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id j76so9914172ybg.3 for ; Sat, 10 Oct 2020 10:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=Lgz8jJn0eiGbsBEPU42A9JFHxz7OPd9LN2mOM4M9KDY=; b=g+6dWEJJ15Xk7w1veuVDfiz/P+NDrlzQ6k4WFlII0O3gAcj8P6ywbzQf/9BjRpR/kZ A1IzqiSuVS6sEmbMPruehYxvUFLA3C4mxsmClTjPRBbPwYD8rYbP71sqjIa2WA85iTpZ JL/7tuT5TGQ/9MwXozxZbGYYOiAaVSNbL1h5P72cEdqmkbjMjQ1kfDc/YcK2/UinXWua qBtR+r3RakkGuBThpAfNTpmJz1l3uo/iwENlKGIEAYravRvvIUjdFnAwDyN+N9C+NDjN ouJJeH54LQ4IYbIFH2HUYf1TKoUquuJMkuixWdnOLyaQiw/vkkiQEByNr9lLeFMD2dzc Nmqg== 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:reply-to :from:date:message-id:subject:to; bh=Lgz8jJn0eiGbsBEPU42A9JFHxz7OPd9LN2mOM4M9KDY=; b=E2sZ/JhDXBP8drGTeYu4wsEGPSTPqY1SYRHy6nz2PGJ2AbAvl2GxdRlF52rFfw2Olx AQNKVrWw/LZ/gEdzux2ABPFxPbiSTgMAGqGqa1vr8o+VTRDr/W46J3szYe+fbc/j4LMZ igWYvvPfxhT0d0AMxn7LrjAW6Y/LixDPZDQXaiPix47CYVOPUOG6jQIO+/U0VTi7uUT7 tXzH1XWSzHIo8iip0sPK7NJevgu78Qw970b3Kwa8JN5Z4fY0Va54kpklFA2KU7U0CgWv tITUBoTpuEX+eFo9qaxTErc1xQc1nANV+bkENj9nqoo8Fficg9BZZvEv6H52M/qcOX84 Nrbg== X-Gm-Message-State: AOAM5318aSA5/OR9m6TZkSy01+HbTQozYzr+e390IjONqlpYL0ZotZxJ JpoMTpsgkUClXbuSvDe9UCRz64qeGWPjMcVHkp2GBfU= X-Google-Smtp-Source: ABdhPJy1x6CAoYzQHD+Ig51if8O6eFVh5ni9opfT+pJnhH68O4cYUdm5h4EPRmciemX00DfN4l0xAZt/KQNfKj3DYA0= X-Received: by 2002:a25:b98b:: with SMTP id r11mr26010829ybg.70.1602351910207; Sat, 10 Oct 2020 10:45:10 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: Reply-To: dzagidulin@gmail.com From: Dmitri Zagidulin Date: Sat, 10 Oct 2020 13:44:54 -0400 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000069c73b05b154a08e" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 17:45:13 -0000 --00000000000069c73b05b154a08e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption of the document. (Great job to the design team). On Sat, Oct 10, 2020 at 10:16 AM Justin Richer wrote: > +1 for adoption of the document > ________________________________________ > From: TXAuth [txauth-bounces@ietf.org] on behalf of Yaron Sheffer [ > yaronf.ietf@gmail.com] > Sent: Saturday, October 10, 2020 9:00 AM > To: Kathleen Moriarty; txauth@ietf.org > Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14 > > Many thanks to Kathleen and the design team for the intensive work that > brought us to this point. > > We would like to issue a short, one week call for adoption for > draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s > GNAP protocol. To clarify, this means that the design team, having achiev= ed > its goal, is disbanded, and that change control over the document passes > into the working group. Whether you=E2=80=99re for or against, please spe= ak up. > > Thanks, > Leif and Yaron > > From: TXAuth on behalf of Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> > Date: Saturday, October 10, 2020 at 01:55 > To: GNAP Mailing List > Subject: [GNAP] Design team > > Greetings! > > The design team has now come to a close. While there were too many issue= s > to resolve to all design team member satisfaction, great effort was put i= n > to describe decision points for the WG to ease and hopefully speed the > working group process. As such, I am requesting that the WG adopts this > version (14 of XYZ) and works together to fully develop a single > specification. > > https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > > A tremendous thank you to each of the design team members for your hard > work and walking the fine line of when to put a stake in the ground (that > the WG can always change once adopted) and listing our options for decisi= on > points to ease the WG process. > > Best regards, > Kathleen > > Sent from my mobile device > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000069c73b05b154a08e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption of the document.

(G= reat job to the design team).

On Sat, Oct 10, 2020 at 10:16 AM Justin = Richer <jricher@mit.edu> wrote= :
+1 for adoptio= n of the document
________________________________________
From: TXAuth [= txauth-bounces@ietf.org] on behalf of Yaron Sheffer [yaronf.ietf@gmail.com]
Sent: Saturday, October 10, 2020 9:00 AM
To: Kathleen Moriarty; txauth@ietf.org
Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14

Many thanks to Kathleen and the design team for the intensive work that bro= ught us to this point.

We would like to issue a short, one week call for adoption for draft-richer= -transactional-authz-14 as the basis of the working group=E2=80=99s GNAP pr= otocol. To clarify, this means that the design team, having achieved its go= al, is disbanded, and that change control over the document passes into the= working group. Whether you=E2=80=99re for or against, please speak up.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron

From: TXAuth <txauth-bounces@ietf.org> on behalf of Kathleen Moriarty <kathleen.m= oriarty.ietf@gmail.com>
Date: Saturday, October 10, 2020 at 01:55
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.ietf.org/doc/d= raft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device
-- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listin= fo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000069c73b05b154a08e-- From nobody Sun Oct 11 02:46:52 2020 Return-Path: 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 8F8CA3A03F8 for ; Sun, 11 Oct 2020 02:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hDUw36jnWtH2 for ; Sun, 11 Oct 2020 02:46:50 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 02A323A0365 for ; Sun, 11 Oct 2020 02:46:49 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q202so5364446iod.9 for ; Sun, 11 Oct 2020 02:46:49 -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=LJQwVD4iDxCvYM7CCNGm5/tsqOOW2GiEQ5Ua/NwrUkk=; b=QUdoMil+EqEMZXOgWv/ovgkiEvWNjlFGPXTCKyN+pW3vhbES5eaUr2npzHTcFdXG97 gP7vOh5nWfcCqqDCLFHCHpt7PKYTH0On1/wV5gNhJKzvzIblzbovKdPjgUvAi4UBgE/S 8EgytOwU+pCTkz6hWRwzKBeKxKIk/J9I3B4VeI5dWx0zH8n5W8e0kd1ABsITxrbiZMnS 2WvP3wIWdVfB+nqbSj30JU4ZxpBTTNMF8mNieiN6uQt71jH8BhPKRADaoYqrvDa2iuVg PkjPQAQhqiAVW2XECHKocYkaJzFalqt/Skzw06mVO288vEouUoy4v9Q5Qzd1qNNv1sy9 tv/A== 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=LJQwVD4iDxCvYM7CCNGm5/tsqOOW2GiEQ5Ua/NwrUkk=; b=hUqrq8/T6eeF6Uvtzt0s0gSzy0Lbspr0I7yc5gx4EpED7KPqHHk8qH8sS5UIVrLK7F AgoRdLEyuzsjbyIYUnSrb8BvrOVU+/zPd3/7TiXoCVD5qjzvLH0BID/tvMQnyhrCkHGm DlepG2R9h4utbSdtzn7lOmbpNUB6dsEq4Jw2FRB2EHCIFOZu8YroSmOHwj2ho8SB50v3 TNyGuIOFYrZzjTEze9toVF2qSYqIGUcAtoHOj4mkTHHQ7uLldQrCu95nWb2DXj46lfYq tHFVVZ+6eyTKblAKz6TFk1fYN1VmbGLHyKvOm7hbyd0P8/uv23H4t9mT9EDVyNWpco0z 8vjA== X-Gm-Message-State: AOAM531kAy0bG8LaS2KsUiE41lh+WUbm6Q4Tgk2s1LHQuWUyKa/Hmyeh oug7ftSbzOfCVmzB24WMVtiCXeA/XtNuoYt505k= X-Google-Smtp-Source: ABdhPJyIoGN6zBawV+DvtDh+nW1I3lSrOxYjnFtA5i3elGVMjDCB7ppZWqPgjK/gbFcGBM6/QZKnAPUvzDabq2CeyvA= X-Received: by 2002:a6b:dc15:: with SMTP id s21mr13498187ioc.162.1602409609060; Sun, 11 Oct 2020 02:46:49 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: From: Fabien Imbault Date: Sun, 11 Oct 2020 11:46:37 +0200 Message-ID: To: dzagidulin@gmail.com Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000008866e005b1620f10" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 09:46:52 -0000 --0000000000008866e005b1620f10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Le sam. 10 oct. 2020 =C3=A0 19:45, Dmitri Zagidulin = a =C3=A9crit : > +1 for adoption of the document. > > (Great job to the design team). > > On Sat, Oct 10, 2020 at 10:16 AM Justin Richer wrote: > >> +1 for adoption of the document >> ________________________________________ >> From: TXAuth [txauth-bounces@ietf.org] on behalf of Yaron Sheffer [ >> yaronf.ietf@gmail.com] >> Sent: Saturday, October 10, 2020 9:00 AM >> To: Kathleen Moriarty; txauth@ietf.org >> Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14 >> >> Many thanks to Kathleen and the design team for the intensive work that >> brought us to this point. >> >> We would like to issue a short, one week call for adoption for >> draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s >> GNAP protocol. To clarify, this means that the design team, having achie= ved >> its goal, is disbanded, and that change control over the document passes >> into the working group. Whether you=E2=80=99re for or against, please sp= eak up. >> >> Thanks, >> Leif and Yaron >> >> From: TXAuth on behalf of Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> >> Date: Saturday, October 10, 2020 at 01:55 >> To: GNAP Mailing List >> Subject: [GNAP] Design team >> >> Greetings! >> >> The design team has now come to a close. While there were too many >> issues to resolve to all design team member satisfaction, great effort w= as >> put in to describe decision points for the WG to ease and hopefully spee= d >> the working group process. As such, I am requesting that the WG adopts >> this version (14 of XYZ) and works together to fully develop a single >> specification. >> >> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >> >> A tremendous thank you to each of the design team members for your hard >> work and walking the fine line of when to put a stake in the ground (tha= t >> the WG can always change once adopted) and listing our options for decis= ion >> points to ease the WG process. >> >> Best regards, >> Kathleen >> >> Sent from my mobile device >> -- TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000008866e005b1620f10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Le sam. 10 oct. 2020 =C3=A0 19:45, Dmitri Zagidulin = <dzagidulin@gmail.com> a = =C3=A9crit=C2=A0:
= +1 for adoption of the document.

(Great job to the d= esign team).

On Sat, Oct 10, 2020 at 10:16 AM Justin Richer <jricher@m= it.edu> wrote:
+1 for adoption of the document
________________________________________
From: TXAuth [txauth-bounces@ietf.org] on behalf of Yaron Sheffer = [yaronf.ietf@gmail.com]
Sent: Saturday, October 10, 2020 9:00 AM
To: Kathleen Moriarty; txauth@ietf.org
Subject: [GNAP] Call for adoption: draft-richer-transactional-auth-14

Many thanks to Kathleen and the design team for the intensive work that bro= ught us to this point.

We would like to issue a short, one week call for adoption for draft-richer= -transactional-authz-14 as the basis of the working group=E2=80=99s GNAP pr= otocol. To clarify, this means that the design team, having achieved its go= al, is disbanded, and that change control over the document passes into the= working group. Whether you=E2=80=99re for or against, please speak up.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron

From: TXAuth <txauth-bounces@ietf.org> on behalf of Kathleen= Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Saturday, October 10, 2020 at 01:55
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.iet= f.org/doc/draft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device
-- TXAuth mailing list TXAuth@ietf.org https= ://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000008866e005b1620f10-- From nobody Sun Oct 11 21:27:53 2020 Return-Path: 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 F16B13A0AE0 for ; Sun, 11 Oct 2020 21:27:51 -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=moneyhub.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 QBJFpkOnIJ6d for ; Sun, 11 Oct 2020 21:27:50 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 0C7F23A0ABE for ; Sun, 11 Oct 2020 21:27:49 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id dt13so21273243ejb.12 for ; Sun, 11 Oct 2020 21:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2Nu158QHPsnMKzpozaHHlK4zMWU5pR811vTUnVnvzEA=; b=CqX+4bUCr7aSZX/I0cgaxkKVLb0C0Jy6BzBs7F2Zskwfq+SPA/vk+g8S9ou+nV2Rwb RUfm6tIcBkiPne8WXVb61X/QIefCtSa+FZSUuQP68ajpVusGLacEXnfuO4Es4L6J9OYQ 4A/GMEj7mMbq0BxgIp9AXifDs7arNa7PuwllU= 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=2Nu158QHPsnMKzpozaHHlK4zMWU5pR811vTUnVnvzEA=; b=sTkN45V+MZnirCqvMyJct5WZtFj9sNejWkjyCLumr8881xOVw1P7EzDn/URy61tsPS KLY8RdKUc5xIBgBePG0kxt6YD4vDiL+Av3M9VvWU7LzFDRx3Z8OK7msBJx+kEzLSUjNu UGA60AmoY7E4MKZpCu5uGwWQomkOz7Q+6qPMpc9Q1+ZpPtDDe0Hwt6IwErJgNSMeXY2a kX0TXUKt5a8pltfrgvyxHkbVtje+kjIR1tjzWCv1ug4ii4ZSOl7RCXYWKogsRl3hhemS 8t8gsronhjtrUW6mV3l+V2QOvuBqY9RpS88h75GUYatHacY5RtXyGDDqlO3ZeWJSJAAm nfSQ== X-Gm-Message-State: AOAM533J2hOr0Lo9ywh22tZiVYwqJ2/sYnp50Ax3q67yo7uGeZS2AAhI LGXJ9qO3jXt6LkrVGJhK6O8kg6fSUq0BzK150gIS4jAf3fMWjh0K0S1Dw+3tl/tk+jC3oYU1IFH CHfdAAudB3o3lV0o= X-Google-Smtp-Source: ABdhPJzgOayFkkucw5ZiHktrSkPLeX+QcxPluTj4Z/kLDkyf39M9i/qKq55iUXvl3grBI8oWBgse3Usdc+XsLjCZYo0= X-Received: by 2002:a17:906:a282:: with SMTP id i2mr26094050ejz.39.1602476868294; Sun, 11 Oct 2020 21:27:48 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> From: Dave Tonge Date: Mon, 12 Oct 2020 06:27:37 +0200 Message-ID: To: Yaron Sheffer Cc: Kathleen Moriarty , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007ef56305b171b8c5" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 04:27:52 -0000 --0000000000007ef56305b171b8c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer wrote: > Many thanks to Kathleen and the design team for the intensive work that > brought us to this point. > > > > We would like to issue a short, one week call for adoption for > draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s > GNAP protocol. To clarify, this means that the design team, having achiev= ed > its goal, is disbanded, and that change control over the document passes > into the working group. Whether you=E2=80=99re for or against, please spe= ak up. > > > > Thanks, > > Leif and Yaron > > > > > --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --0000000000007ef56305b171b8c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption

On Sat, 10 Oct 2= 020 at 15:01, Yaron Sheffer <ya= ronf.ietf@gmail.com> wrote:

Many thanks to Kathleen and the design team for the intensive work tha= t brought us to this point.

= =C2=A0

We would like to issue a short, one= week call for adoption for draft-richer-transactional-authz-14 as the basi= s of the working group=E2=80=99s GNAP protocol. To clarify, this means that= the design team, having achieved its goal, is disbanded, and that change c= ontrol over the document passes into the working group. Whether you=E2=80= =99re for or against, please speak up.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron

=C2=A0



Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--0000000000007ef56305b171b8c5-- From nobody Tue Oct 13 01:54:56 2020 Return-Path: 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 F13563A0EF4 for ; Tue, 13 Oct 2020 01:54:54 -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=hindleconsulting.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 EQcy33H5yh5r for ; Tue, 13 Oct 2020 01:54:52 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 E7EE63A0EF5 for ; Tue, 13 Oct 2020 01:54:51 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id l4so18347730ota.7 for ; Tue, 13 Oct 2020 01:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hindleconsulting.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LmDR0YTPlrkW67n0zuIZvy+Z5tYZHo5KIfbQ0yvDzT4=; b=g2lxM+oFaVWtCORfOxrkSD0jGG/8/gTXtRZqHrVa9Wh2WD0G1eP+sM7SMpK8rQTme/ y1xg5o5a6EazkYUZK44bW1sxp6/MSvkFMUZInSNKcY1ehgTA2bzoDXSzbBGfSlzQbpU9 zhLPxzG8z8PsH9o0zdb84kHVYMmlZLRMrRSTs= 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=LmDR0YTPlrkW67n0zuIZvy+Z5tYZHo5KIfbQ0yvDzT4=; b=qfiaWES2jiKXFLOKQIE3hZFz+Be190g4FYN+2ALmx9X14Dxt0e6RKh47WfNrEFYIJg rSYLVZl+O6Ex+tCsQrXN8bNLrsAGRjzS/iAE7bAwAoc0Tf1CiDUuY61AV7eAruCohWRS nmDBGC0zDuHH09J51KNcq26oFY7UyCdG/jTrpaB7ySoQ/+WvwIofBSwuVmfxE4HodWHv IXIr2id6zqs4+U1sDIIwyjcmjTLFG/ivmJolmZlItFS2CAVXWUo+p1/EMaa/Wlfn4lLc i7lOF9zXNcmd9JDpgd8AjFdtD80XGAwKMcLr/sED0m8sWSUVQS4CN0Pp9E4CypIMdTMt 9I8w== X-Gm-Message-State: AOAM5314OzOhT91gmyOh6z9GOx9CLkQom2fHt3VYnKZcrqQuEbJHEfIR Xg2xehcRxWdsSHmPVu+sRFhuQ5GXsyc31/NvFiy58Ly/3TC/Mzx2qKEHI2J4w4MC3shZU+m7mDg QHt2b/gLlcdl7dBkP X-Google-Smtp-Source: ABdhPJzCewGw4eSz4x4mgt3QAlCd7LBECPCLScD9n2GErgPCrMEODWP/GC1Q1ubhv+9qYoqyGzPf8Uf30iTofAarUjI= X-Received: by 2002:a9d:61d1:: with SMTP id h17mr7033057otk.146.1602579290690; Tue, 13 Oct 2020 01:54:50 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: From: Andrew Hindle Date: Tue, 13 Oct 2020 09:54:40 +0100 Message-ID: To: Dave Tonge Cc: Kathleen Moriarty , Yaron Sheffer , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000058a91305b18991de" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 08:54:55 -0000 --00000000000058a91305b18991de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption. =E2=80=94&e On Mon, 12 Oct 2020 at 05:27, Dave Tonge wrote: > +1 for adoption > > On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer wrote= : > >> Many thanks to Kathleen and the design team for the intensive work that >> brought us to this point. >> >> >> >> We would like to issue a short, one week call for adoption for >> draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s >> GNAP protocol. To clarify, this means that the design team, having achie= ved >> its goal, is disbanded, and that change control over the document passes >> into the working group. Whether you=E2=80=99re for or against, please sp= eak up. >> >> >> >> Thanks, >> >> Leif and Yaron >> >> >> >> >> > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Andrew Hindle; CIPM , CIPP/E , CIPT Hindle Consulting Limited +44 7966 136543 Schedule a meeting --=20 Hindle Consulting Limited is a company registered in England and Wales. =C2= =A0 Company number: 8888564. Registered office: Claremont House, 1 Market=20 Square, Bicester, Oxfordshire OX26 6AA, UK. --00000000000058a91305b18991de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption.

=E2=80=94&e

On Mon, 12 Oct 2020 at 05:27, Dave Tonge <= ;dave.tonge@moneyhub.com>= wrote:
+1 for adoption

On Sat, 10 Oct 2020 at 15:01, Yaron Sheff= er <yaronf.ie= tf@gmail.com> wrote:

Many thanks to = Kathleen and the design team for the intensive work that brought us to this= point.

=C2=A0

We would like to issue a short, one week call for adopt= ion for draft-richer-transactional-authz-14 as the basis of the working gro= up=E2=80=99s GNAP protocol. To clarify, this means that the design team, ha= ving achieved its goal, is disbanded, and that change control over the docu= ment passes into the working group. Whether you=E2=80=99re for or against, = please speak up.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Leif and Yaron

<= u>=C2=A0

=



Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
<= div>
Andrew Hindle; CIPM, CIPP/E, CIPT
Hindle Consulting Limited
+4= 4 7966 136543

Hindle Consulting Limited is a company registered in England and Wa= les. =C2=A0Company number: 8888564.
Registe= red office: Claremont House, 1 Market Square, Bicester, Oxfordshire OX26 6A= A, UK.
--00000000000058a91305b18991de-- From nobody Tue Oct 13 02:14:07 2020 Return-Path: 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 15DC83A0EF1 for ; Tue, 13 Oct 2020 02:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=willeke-com.20150623.gappssmtp.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 flV1ILRb18_c for ; Tue, 13 Oct 2020 02:14:04 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 A0B6B3A0ED6 for ; Tue, 13 Oct 2020 02:14:03 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id h20so19625654lji.9 for ; Tue, 13 Oct 2020 02:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CtTtZ8z7NSzCKWahwv5YEwS6u3W3SAG39zuRwEYx3rc=; b=WP+6YykM2eGyWIaNi3JbOgghjPWwqCh1XDx/qcRi9nk9G6M6jA38k7z46YAhDIHYEl PRomgUMkaFcWGucA0oIvCwui7lst7pbtMuf1rwVEtYcLfrC5hj0wjRoKJgrfjSnoPf0/ JhH2CZonLsoASUXeeiPje4X/sMUCPefRKo2EM2WOFkbbhK0jTIEIWPpMKlcQKR7fGQML QfDxme7gFobDcCbk8wfFFPK/XemmQyfYeHGdRTaQn8Q40Ra+afOQEIR+dbgdJB3N9KeS A/6T37LyFDjbtxbOczK7S0WX+5dZ1vb0dFBrrQub+fWTQuO9eY2wCDtlCgLGC9DIoKax MqRA== 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=CtTtZ8z7NSzCKWahwv5YEwS6u3W3SAG39zuRwEYx3rc=; b=LVao6I8CrcYquDNdKaJXrlOQIhW9xxU8mOqUkFDnaOSiLdicApTUAYtj/QcN9201T/ mnzBZROSfz31/4XETq1Vy+rnrOTYQpQO7toqiz1T0bd7kcE5bBUdCQ5Brk3iNVqyGyZ2 EP0TPhrVyO7SKE7dnZab0+hKkePK1RIXJl7xFaVtnOA6/4M+rG3kB2qjBwyUh7AobaVZ +J3HO17LYoZuyAalkIcmzARgwgm8YKG1xqb0DM/2dj5b42P4MAOeWEXDdOZq/LZXyM9Y HqZ3BvTg0Nq/eXwRNeGBXPwMQoK8QswI7U8DccddySdeOewkPTmtV3/vBPRv07CnZcSu +1mA== X-Gm-Message-State: AOAM5331xo54iZFCOHPuiHORph9XZ5R/Z7XPXTilwDgVplu6YfCa5CxH MOI6L9FLs22vCMHaPseau/WmWKxq2xN/e4uuRL7S25yB48SyVA== X-Google-Smtp-Source: ABdhPJzqxrkl4g9NqyQAAAhirCPvG5H3kPJBiq6mxKxFgU6APJbwujRN8Zuflz0mEMN51TkKug9yoh5PQwiI2TjLOvE= X-Received: by 2002:a05:651c:207:: with SMTP id y7mr317091ljn.99.1602580440963; Tue, 13 Oct 2020 02:14:00 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: From: Jim Willeke Date: Tue, 13 Oct 2020 05:13:24 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e871a305b189d59a" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 09:14:06 -0000 --000000000000e871a305b189d59a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption -- -jim Jim Willeke On Tue, Oct 13, 2020 at 4:55 AM Andrew Hindle wrote: > +1 for adoption. > > =E2=80=94&e > > On Mon, 12 Oct 2020 at 05:27, Dave Tonge wrote: > >> +1 for adoption >> >> On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer >> wrote: >> >>> Many thanks to Kathleen and the design team for the intensive work that >>> brought us to this point. >>> >>> >>> >>> We would like to issue a short, one week call for adoption for >>> draft-richer-transactional-authz-14 as the basis of the working group= =E2=80=99s >>> GNAP protocol. To clarify, this means that the design team, having achi= eved >>> its goal, is disbanded, and that change control over the document passe= s >>> into the working group. Whether you=E2=80=99re for or against, please s= peak up. >>> >>> >>> >>> Thanks, >>> >>> Leif and Yaron >>> >>> >>> >>> >>> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Andrew Hindle; CIPM , CIPP/E > , CIPT > > Hindle Consulting Limited > +44 7966 136543 > Schedule a meeting > > ------------------------------ > Hindle Consulting Limited is a company registered in England and Wales. = Company > number: 8888564. > Registered office: Claremont House, 1 Market Square, Bicester, Oxfordshir= e > OX26 6AA, UK. > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e871a305b189d59a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption
--
-jim
Jim Willeke


On T= ue, Oct 13, 2020 at 4:55 AM Andrew Hindle <andrew@hindleconsulting.com> wrote:
+1 for adopt= ion.

=E2=80=94&e

On Mon, 12 Oct 2020 at 05:27, Dave Tonge <dave.tonge@moneyhub.com> wrote:
<= /div>
+1 for adoption

On Sat, 10 Oct 2020 at 1= 5:01, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Many thanks to Kathleen and the design team for the intensive work that b= rought us to this point.

=C2= =A0

We would like to issue a short, one we= ek call for adoption for draft-richer-transactional-authz-14 as the basis o= f the working group=E2=80=99s GNAP protocol. To clarify, this means that th= e design team, having achieved its goal, is disbanded, and that change cont= rol over the document passes into the working group. Whether you=E2=80=99re= for or against, please speak up.

<= u>=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron

=C2=A0



Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Andrew Hindle; CIPM, CIPP/E, CIPT
Hindle Consulting Limit= ed
+44 7966 136543

Hindle Consulting Limited is a company registered in England and Wa= les. =C2=A0Company number: 8888564.
Registe= red office: Claremont House, 1 Market Square, Bicester, Oxfordshire OX26 6A= A, UK.
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000e871a305b189d59a-- From nobody Tue Oct 13 03:03:06 2020 Return-Path: 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 1E6673A0F09 for ; Tue, 13 Oct 2020 03:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=udelt-no.20150623.gappssmtp.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 O0zTsYCF-Lkh for ; Tue, 13 Oct 2020 03:03:02 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 ED8983A0F08 for ; Tue, 13 Oct 2020 03:03:01 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id m13so18480355otl.9 for ; Tue, 13 Oct 2020 03:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LbilcJPSA7JL+UBTYfSVKxmFe1iciH8uqSiWVAtAdhs=; b=IlAhTIHV+nV2fWr2RPVdputJx1Fz0dtV0p8EmCs7qDqNjAlLBL+mrQRvtrGM26V3/G smp7AFlhnjnkmAu5nkFcM8TM5gHHkMZPUg30V/M/DPR7C8VcmpAcxod4ZZunrlfI+sCG vdeHS5Q+gVNKi95KRHpU5IxcmBEBLhimxXb3YFgNVIsp6SBUg+QaAusbDmBwrrlEnByZ Rj/ppL6or8IGfzjxPFuD9cdajmwIdISZQ2R7NBK42QBzJh2gcTsuVgkFCebhbM8uvFqB kSP0pjuJXNDycfdWdFSBEI1gfk6xnnVc3Y0AEg7AAhBOBSBrN5Yf6YYizeLghXe0Nqbm e29w== 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=LbilcJPSA7JL+UBTYfSVKxmFe1iciH8uqSiWVAtAdhs=; b=kVAtocV7MCNwNgHCUkmzSfdDbIp6+8P8gsK9xPQNKc4yRqohN5nFD3Hz99uCtZv1t1 zGUr/lLCm4oJKl0JLdWNTG9LWs9U2ougCjLVf8ehDMwWRJi6xfw8qb4g3SBmd6WBjTtr 9ZFcK4ZJD3RuuqTPw3loBiAn8zPDfurvfDgUPiI1OCwAVvk9wJp41mA9xC2oCK08TxKi WqfJt/mtAhRVjJyyJROQVPfrXh8aYcVL29yHXGdFVavAycZMVX130vUIDqE/JFzoK0rw BuU+VNG3b66DQLNVgZkikmNmuwslskkh4khRXnQ8Njn1vThrO8gRNCor5BuVhjBgC4mi MGZA== X-Gm-Message-State: AOAM5325BwXVBHC7J/zAun7DUEdYSEVrtGeAUqaTyEZu6ecMQ7+v4x7u x1wt43CCMIxgaIDvNzyYjtGBoy5nCvU7yI4HcPz8pA== X-Google-Smtp-Source: ABdhPJyAuyCZ/g2KOcoNSwoO3s9Rhf8dV8SNHV3sJ5PxsPBq0e3lqYJ7f4xv6g6/y+Y4XVln6h/otcZtEBEKTfSw8Vw= X-Received: by 2002:a9d:1a2:: with SMTP id e31mr17814256ote.181.1602583380623; Tue, 13 Oct 2020 03:03:00 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> From: Steinar Noem Date: Tue, 13 Oct 2020 12:02:50 +0200 Message-ID: To: Yaron Sheffer , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000201c2405b18a855f" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 10:03:04 -0000 --000000000000201c2405b18a855f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 l=C3=B8r. 10. okt. 2020 kl. 15:01 skrev Yaron Sheffer : > Many thanks to Kathleen and the design team for the intensive work that > brought us to this point. > > > > We would like to issue a short, one week call for adoption for > draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s > GNAP protocol. To clarify, this means that the design team, having achiev= ed > its goal, is disbanded, and that change control over the document passes > into the working group. Whether you=E2=80=99re for or against, please spe= ak up. > > > > Thanks, > > Leif and Yaron > > > > *From: *TXAuth on behalf of Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> > *Date: *Saturday, October 10, 2020 at 01:55 > *To: *GNAP Mailing List > *Subject: *[GNAP] Design team > > > > Greetings! > > > > The design team has now come to a close. While there were too many issue= s > to resolve to all design team member satisfaction, great effort was put i= n > to describe decision points for the WG to ease and hopefully speed the > working group process. As such, I am requesting that the WG adopts this > version (14 of XYZ) and works together to fully develop a single > specification. > > > > https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > > > > A tremendous thank you to each of the design team members for your hard > work and walking the fine line of when to put a stake in the ground (that > the WG can always change once adopted) and listing our options for decisi= on > points to ease the WG process. > > > > Best regards, > > Kathleen > > > > Sent from my mobile device > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --000000000000201c2405b18a855f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1=C2=A0

l=C3=B8r. 10. okt. 2020 kl. 15:01 skrev Yaron= Sheffer <yaronf.ietf@gmail.com= >:

Many thanks to Kathle= en and the design team for the intensive work that brought us to this point= .

=C2=A0

We would like to issue a short, one week call for adoption f= or draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s GNAP protocol. To clarify, this means that the design team, having = achieved its goal, is disbanded, and that change control over the document = passes into the working group. Whether you=E2=80=99re for or against, pleas= e speak up.

=C2=A0

Thanks,

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Leif and Yaron

= =C2=A0

From: TXAuth <txauth-bounces@ietf.org>= ; on behalf of Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>Date: Saturday, October 10, 2020 at 01:55
To: GNAP Mailin= g List <txauth@ietf= .org>
Subject: [GNAP] Design team

=

=C2=A0

Greetings!<= u>

=C2=A0

=

The design team has now come to a close.=C2=A0 = While there were too many issues to resolve to all design team member satis= faction, great effort was put in to describe decision points for the WG to = ease and hopefully speed the working group process.=C2=A0 As such, I am req= uesting that the WG adopts this version (14 of XYZ) and works together to f= ully develop a single specification.

=C2=A0

https://datatracker.ietf.org/doc/draft-richer-transacti= onal-authz/

= =C2=A0

A tremendous thank you t= o each of the design team members for your hard work and walking the fine l= ine of when to put a stake in the ground (that the WG can always change onc= e adopted) and listing our options for decision points to ease the WG proce= ss.

=C2=A0=

Best regards,

=

Kathleen=C2=A0

=C2=A0

Sent fro= m my mobile device

-- TXAuth = mailing list TXAuth@ie= tf.org https://www.ietf.org/mailman/listinfo/txauth =

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--000000000000201c2405b18a855f-- From nobody Tue Oct 13 06:02:06 2020 Return-Path: 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 BDD4A3A0FB6 for ; Tue, 13 Oct 2020 06:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=securekeytechnologies.onmicrosoft.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 1kk3ZBo6RUcm for ; Tue, 13 Oct 2020 06:02:01 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670126.outbound.protection.outlook.com [40.107.67.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B773A0FB9 for ; Tue, 13 Oct 2020 06:02:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NwumYfPPNIbQTek7SZXYUhPhaDsRuez3+FBXavXJZl5mZFAhZ6HNbjQp/clRcgPmQ7oa3eKEn6xot4SnRzZKz5533pCLubrCBCzaMKVLZp8n5X1eV+z2nPDzMsd3gU18C4AHLVxrdEhXgWDiTUjRirXxKKl+G/Q+CFjSndS7kx86PG8SYaiBqtLldquJFYiqbyo/HtHStUS6k0M28ZCOk0ayqQnWCEztJ+OwYzRCK5B8E1C/62qqfClAlmpGjgcyie9z0hh/HOXZ89XQqg0U0ZtPRJ7+1nhCVNGfgVG+3cLO7SaG58gNcKA5TJSXIWuI/BEzSOTzWtkUCKrhFzZLNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rRHqAt4LzrJwD/wXp0h4USFktAF6Fu978TyZtxas65U=; b=LLG5qt9wwiGJwaYM8ldNPVDlQ+77sfyo/ImDDfJeOP2ZapjoqYMIUVOCiY8boOdRiQNrr2TQmI5WcqvTP40vRFBA+/QymLtr3Q+1DtZntmTZ2mXtLMYMidLzOBLUv2BoV7+b4w4OqL0uL1JL5TQmhKAt8QrobkyJk3oyNdopbbqNMvqoeU+NOZwIoXBObXwCKNvU95Lq33K5MEO3Hv1AAOV0n4b/uI5bsrid/WvdB+vfgDEriZuJ4b9WPhUxRnX4ysrWP7WTy+lEPIU0D+PpdxtBYzl/s2nEoIoXL82V65AjwaqBBqv6kLBPo35e9u1N9sFNrtr9OxSk6tkIRTpRaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rRHqAt4LzrJwD/wXp0h4USFktAF6Fu978TyZtxas65U=; b=PlZntUiLXRHVoLjZ01lectobBuCm83KiY7HC0j1jhuQNLzWVvaNnMK44HeqQEa9lab8m5u8Xjb5lfGhhZilri6cQbHV9l6Lc5BW6xm7fLDD6Fvti+3RWgYszKX53WPE6fu8rgry7OnYwC3GMdC9KJaIN0sHIp/hMkMzDd6GZpLQ= Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8::32) by YTXPR0101MB1470.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:9::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.24; Tue, 13 Oct 2020 13:01:54 +0000 Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::a44c:19a7:5aad:5121]) by YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::a44c:19a7:5aad:5121%7]) with mapi id 15.20.3455.031; Tue, 13 Oct 2020 13:01:54 +0000 From: Mike Varley To: Yaron Sheffer , "txauth@ietf.org" Thread-Topic: [GNAP] Call for adoption: draft-richer-transactional-auth-14 Thread-Index: AQHWoWEFOxL5QHg1KEKaxTFdSNz/ng== Date: Tue, 13 Oct 2020 13:01:54 +0000 Message-ID: <3AD83017-4C05-46E7-BD59-805EC4A6DC0F@securekey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=securekey.com; x-originating-ip: [50.101.239.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a0f63a5-c951-4623-5ec0-08d86f7828c3 x-ms-traffictypediagnostic: YTXPR0101MB1470: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q72fzwDsbhAQee4udgYg4o+yMl1iV9FVa2o7qS8f7/Vd188MMedE59s9YxzDXkwu/O/dmR6VMAJqMukz3fIW7P0Y94o+/tGxFXqESV218Qppk1Qtv4ZHLvPphUgvHRJa4GkGAA0LoHuKlGfoPuq1ZEVBW3s4MrPJKAIUkuLqfgVLjWl4XsDFVhf6A3gIOpG9I9yIfJzn0IaPHXlokOR1yp4A2PKhQDX8TbhpDIhCWb5/986wKpPEG8Ba1hVF7e55tMJvxerOkxfv/PqsEyuW7nhYCxGZJ+ElnZcUbHPftdKa2h7yF4V7/AagT/WnOPLxnSy6VW5rgC3zO9NibbKyLlYCmlNzox3FbsVvoMuHxuEujJFWEoL0JwA49nMxHmTXKfKwM3O+hFFOZ7FsqDqzhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39840400004)(396003)(376002)(366004)(6486002)(6506007)(53546011)(83080400001)(966005)(83380400001)(166002)(86362001)(186003)(83730400002)(26005)(478600001)(2616005)(8936002)(36756003)(2906002)(8676002)(316002)(6512007)(71200400001)(66946007)(44832011)(76116006)(66476007)(64756008)(5660300002)(66446008)(66556008)(33656002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 9O9+IsQg3PK3kq9hCKm4WZ8cHCjVma/5OWflhxNA4sA/BXToOj3KzPDxH2FGNmdR49OZLYSDlcsmeG4NVKyzyXMJBEUN/vF2oP/Y2eQbOF7tO7j4QSHv4bCtWJKuX/lKmCBbq2cJL7XrqvEu1LyMFOwbPKLXYj0i9MJu6wWQn8nbPeG8GRmI0sFcn9NQUHoG9oeIVwdqIRrMoECnch5+okI9BOZhw+t3D5UkjlvCj8x4tcY8U5EK3NWLnncH9+TXnHLOoYpKFFiYrpLuMJnM5QlbcpyarR8Du3rAAZzr5TSP10luj3Z6c5OCgr8tQZaNeSHBn8cbiOIQM+OWwbav8JViFU78AEyJu5QSvD5fmcYl8rZ8aDafCSwJiHuKHmlNu3863eBMzEpvixCjCBFsSpuQQ7fRNwOZwVmD5XuLSxwDnK+6eQ00BL/FXNIMVEXy2NdhbX5mI+bPgPmOrI78h5l2AzbWm+nLKUeCmu9zotwPW821xJnjoUoQ23lE6sT2K8b8F1Y3D4L/QMr61jad3ZpoTrQs2m6xVAm/6cXLbpzrX7HT79bf4bF7R+W55piV01RnOfTOEATZYu//7M7rHtjBKVp5p2rD0hPmwPxyRaRFPPs5az8loXeDDuXRRo/utKfORNfHxTWimr5JAeJnhQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3AD830174C0546E7BD59805EC4A6DC0Fsecurekeycom_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6a0f63a5-c951-4623-5ec0-08d86f7828c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 13:01:54.2796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AkoYWapOhXLNuoPggtNejOBdQSa7ucJWiMwaTBFPHxetHEVJh1ZQPNHtFTJYM7IljcSVQYyDcPjbVWaY1YP3WKMwH0Pgc3wihw1odYhT9Vc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1470 Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:02:05 -0000 --_000_3AD830174C0546E7BD59805EC4A6DC0Fsecurekeycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGFkb3B0aW9uDQoNCk1WDQoNCkZyb206IFRYQXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+ DQpEYXRlOiBTYXR1cmRheSwgT2N0b2JlciAxMCwgMjAyMCBhdCA5OjAxIEFNDQpUbzogS2F0aGxl ZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiwgInR4YXV0aEBp ZXRmLm9yZyIgPHR4YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtHTkFQXSBDYWxsIGZvciBhZG9w dGlvbjogZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aC0xNA0KDQpNYW55IHRoYW5rcyB0 byBLYXRobGVlbiBhbmQgdGhlIGRlc2lnbiB0ZWFtIGZvciB0aGUgaW50ZW5zaXZlIHdvcmsgdGhh dCBicm91Z2h0IHVzIHRvIHRoaXMgcG9pbnQuDQoNCldlIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSBz aG9ydCwgb25lIHdlZWsgY2FsbCBmb3IgYWRvcHRpb24gZm9yIGRyYWZ0LXJpY2hlci10cmFuc2Fj dGlvbmFsLWF1dGh6LTE0IGFzIHRoZSBiYXNpcyBvZiB0aGUgd29ya2luZyBncm91cOKAmXMgR05B UCBwcm90b2NvbC4gVG8gY2xhcmlmeSwgdGhpcyBtZWFucyB0aGF0IHRoZSBkZXNpZ24gdGVhbSwg aGF2aW5nIGFjaGlldmVkIGl0cyBnb2FsLCBpcyBkaXNiYW5kZWQsIGFuZCB0aGF0IGNoYW5nZSBj b250cm9sIG92ZXIgdGhlIGRvY3VtZW50IHBhc3NlcyBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLiBX aGV0aGVyIHlvdeKAmXJlIGZvciBvciBhZ2FpbnN0LCBwbGVhc2Ugc3BlYWsgdXAuDQoNClRoYW5r cywNCiAgICAgICAgICAgICAgICBMZWlmIGFuZCBZYXJvbg0KDQpGcm9tOiBUWEF1dGggPHR4YXV0 aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPg0KRGF0ZTogU2F0dXJkYXksIE9jdG9iZXIgMTAs IDIwMjAgYXQgMDE6NTUNClRvOiBHTkFQIE1haWxpbmcgTGlzdCA8dHhhdXRoQGlldGYub3JnPg0K U3ViamVjdDogW0dOQVBdIERlc2lnbiB0ZWFtDQoNCkdyZWV0aW5ncyENCg0KVGhlIGRlc2lnbiB0 ZWFtIGhhcyBub3cgY29tZSB0byBhIGNsb3NlLiAgV2hpbGUgdGhlcmUgd2VyZSB0b28gbWFueSBp c3N1ZXMgdG8gcmVzb2x2ZSB0byBhbGwgZGVzaWduIHRlYW0gbWVtYmVyIHNhdGlzZmFjdGlvbiwg Z3JlYXQgZWZmb3J0IHdhcyBwdXQgaW4gdG8gZGVzY3JpYmUgZGVjaXNpb24gcG9pbnRzIGZvciB0 aGUgV0cgdG8gZWFzZSBhbmQgaG9wZWZ1bGx5IHNwZWVkIHRoZSB3b3JraW5nIGdyb3VwIHByb2Nl c3MuICBBcyBzdWNoLCBJIGFtIHJlcXVlc3RpbmcgdGhhdCB0aGUgV0cgYWRvcHRzIHRoaXMgdmVy c2lvbiAoMTQgb2YgWFlaKSBhbmQgd29ya3MgdG9nZXRoZXIgdG8gZnVsbHkgZGV2ZWxvcCBhIHNp bmdsZSBzcGVjaWZpY2F0aW9uLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei8NCg0KQSB0cmVtZW5kb3VzIHRoYW5rIHlv dSB0byBlYWNoIG9mIHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIGZvciB5b3VyIGhhcmQgd29yayBh bmQgd2Fsa2luZyB0aGUgZmluZSBsaW5lIG9mIHdoZW4gdG8gcHV0IGEgc3Rha2UgaW4gdGhlIGdy b3VuZCAodGhhdCB0aGUgV0cgY2FuIGFsd2F5cyBjaGFuZ2Ugb25jZSBhZG9wdGVkKSBhbmQgbGlz dGluZyBvdXIgb3B0aW9ucyBmb3IgZGVjaXNpb24gcG9pbnRzIHRvIGVhc2UgdGhlIFdHIHByb2Nl c3MuDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2 aWNlDQotLSBUWEF1dGggbWFpbGluZyBsaXN0IFRYQXV0aEBpZXRmLm9yZyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudHMg YW5kIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBm cm9tIGRpc2Nsb3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBv dGhlciB1c2UgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhp cyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K --_000_3AD830174C0546E7BD59805EC4A6DC0Fsecurekeycom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4rMSBmb3IgYWRvcHRpb248bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TVY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UWEF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgT2N0b2JlciAxMCwgMjAyMCBhdCA5 OjAxIEFNPGJyPg0KPGI+VG86IDwvYj5LYXRobGVlbiBNb3JpYXJ0eSAmbHQ7a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb20mZ3Q7LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0 O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0dOQVBdIENhbGwgZm9y IGFkb3B0aW9uOiBkcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoLTE0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1hbnkgdGhhbmtzIHRvIEth dGhsZWVuIGFuZCB0aGUgZGVzaWduIHRlYW0gZm9yIHRoZSBpbnRlbnNpdmUgd29yayB0aGF0IGJy b3VnaHQgdXMgdG8gdGhpcyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+V2Ugd291bGQgbGlr ZSB0byBpc3N1ZSBhIHNob3J0LCBvbmUgd2VlayBjYWxsIGZvciBhZG9wdGlvbiBmb3IgZHJhZnQt cmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMTQgYXMgdGhlIGJhc2lzIG9mIHRoZSB3b3JraW5n IGdyb3Vw4oCZcyBHTkFQIHByb3RvY29sLiBUbyBjbGFyaWZ5LCB0aGlzIG1lYW5zIHRoYXQgdGhl IGRlc2lnbiB0ZWFtLCBoYXZpbmcgYWNoaWV2ZWQNCiBpdHMgZ29hbCwgaXMgZGlzYmFuZGVkLCBh bmQgdGhhdCBjaGFuZ2UgY29udHJvbCBvdmVyIHRoZSBkb2N1bWVudCBwYXNzZXMgaW50byB0aGUg d29ya2luZyBncm91cC4gV2hldGhlciB5b3XigJlyZSBmb3Igb3IgYWdhaW5zdCwgcGxlYXNlIHNw ZWFrIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTGVpZiBhbmQgWWFyb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5UWEF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgS2F0aGxlZW4gTW9yaWFydHkgJmx0O2thdGhsZWVuLm1vcmlhcnR5Lmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgT2N0b2JlciAxMCwg MjAyMCBhdCAwMTo1NTxicj4NCjxiPlRvOiA8L2I+R05BUCBNYWlsaW5nIExpc3QgJmx0O3R4YXV0 aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0dOQVBdIERlc2lnbiB0ZWFtPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5HcmVldGluZ3MhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIGRlc2lnbiB0ZWFtIGhh cyBub3cgY29tZSB0byBhIGNsb3NlLiAmbmJzcDtXaGlsZSB0aGVyZSB3ZXJlIHRvbyBtYW55IGlz c3VlcyB0byByZXNvbHZlIHRvIGFsbCBkZXNpZ24gdGVhbSBtZW1iZXIgc2F0aXNmYWN0aW9uLCBn cmVhdCBlZmZvcnQgd2FzIHB1dCBpbiB0byBkZXNjcmliZSBkZWNpc2lvbiBwb2ludHMgZm9yIHRo ZSBXRyB0byBlYXNlIGFuZCBob3BlZnVsbHkNCiBzcGVlZCB0aGUgd29ya2luZyBncm91cCBwcm9j ZXNzLiAmbmJzcDtBcyBzdWNoLCBJIGFtIHJlcXVlc3RpbmcgdGhhdCB0aGUgV0cgYWRvcHRzIHRo aXMgdmVyc2lvbiAoMTQgb2YgWFlaKSBhbmQgd29ya3MgdG9nZXRoZXIgdG8gZnVsbHkgZGV2ZWxv cCBhIHNpbmdsZSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QSB0cmVtZW5k b3VzIHRoYW5rIHlvdSB0byBlYWNoIG9mIHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIGZvciB5b3Vy IGhhcmQgd29yayBhbmQgd2Fsa2luZyB0aGUgZmluZSBsaW5lIG9mIHdoZW4gdG8gcHV0IGEgc3Rh a2UgaW4gdGhlIGdyb3VuZCAodGhhdCB0aGUgV0cgY2FuIGFsd2F5cyBjaGFuZ2Ugb25jZSBhZG9w dGVkKSBhbmQgbGlzdGluZyBvdXIgb3B0aW9ucw0KIGZvciBkZWNpc2lvbiBwb2ludHMgdG8gZWFz ZSB0aGUgV0cgcHJvY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+S2F0aGxlZW4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2VudCBmcm9tIG15IG1v YmlsZSBkZXZpY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0gVFhBdXRoIG1haWxpbmcgbGlzdCBUWEF1dGhA aWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgaWQ9ImJvZHkiIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7IGNvbG9yOmRhcmtncmF5OyBsaW5lLWhlaWdodDoxMHB0OyBmb250LWZhbWlseTog J0FyaWFsJywndGltZXMgcm9tYW4nLHNlcmlmOyI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudHMgYW5k IG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBmcm9t IGRpc2Nsb3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBvdGhl ciB1c2UgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9o aWJpdGVkLg0KIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGlz IGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMuPC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_3AD830174C0546E7BD59805EC4A6DC0Fsecurekeycom_-- From nobody Tue Oct 13 06:19:31 2020 Return-Path: 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 50FA43A0FD5 for ; Tue, 13 Oct 2020 06:19:29 -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=ham 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 6XfpPqAo0-fM for ; Tue, 13 Oct 2020 06:19:26 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 2FCD03A0FC2 for ; Tue, 13 Oct 2020 06:18:36 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id a72so10294838wme.5 for ; Tue, 13 Oct 2020 06:18:36 -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; bh=1T8Siypy2MgW44VMUkOOdS1FQJy8ZgsI9bJ3ab6Jxek=; b=h7KjDbq5IwGWOp3RTpuvalmE8mu0BEoIX1HQGAnLq4rPXVTXt+UoVHyDgdX0ly7mOv mgOcZFECmET8UMyrDaT3o96v1n5cNvaK4eBN1LC/Qe7xr9IS0bVODFcHE2qh4GbkIWIY mPLqaXe8SQBc+66MAu67LRy2ZoZwD78qrdXh/0Ym4l5Zm95bSgiDE0nteWXB6eJX/ckt FjVdR8lDoCXrIxWF1pcW+PemeLjBhCNOPGkfB08Pkesk6FKRqa0oyCVPT8E04IfU7iyx syAp8XbeqBKSLoUGC915L7J38QsLfy3JO7QNoPjPzBMC6vFZSvx0bi03D6i9HXNFNvYt Pg7w== 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=1T8Siypy2MgW44VMUkOOdS1FQJy8ZgsI9bJ3ab6Jxek=; b=IfG8pHF27DaB3xp463GnXn63Ph1CQw0udHSr3KXCyqNhw8ubpEAEZc66NZakE+335h 9/E1G03M+enihFnasQf0poCS/J+fX6vrz8MulLXVhlFAYdkD6iLwwJRbQ5Bv75NOJcA1 N2tkO2vWmrEVdaquOpObg8YIQTGnaInWnAipIGgzXB46hKm8uKK5C2FT5y7awfBrNlBJ Ypkv4YVG0aTLbp1VcFv2BT6NGNDWdOfBsjqhhhStzXHDTjhzF7T3NxnfxAlVQXZbt0xl wEgtE6KJDfXqKVm+H/jh/sEo4mfLJlapryiEfkPVadf6DXLnZJkyKYMAQ8EDrcUGxDJ4 09LQ== X-Gm-Message-State: AOAM533oZ37hpdhaPhxlDgUozYtzTHLuWEYYQo3aSODfvo5cU9q9OhkH GKpnTB2mxHrbfQM1a2DOqu2xsNspkQf0qPEnCNZueA5ROFyybw== X-Google-Smtp-Source: ABdhPJxUTvemR7q1A+pGGRwJ90VGP3jYXliISf2R2d//mN359gmjCtEmSkypBykkfDjzqQagmm0GYLqq2mYxhewCQzE= X-Received: by 2002:a1c:9a4b:: with SMTP id c72mr15190752wme.157.1602595114040; Tue, 13 Oct 2020 06:18:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hankins Parichabutr Date: Tue, 13 Oct 2020 09:17:57 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007dbff105b18d4094" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 13:19:30 -0000 --0000000000007dbff105b18d4094 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption . . . . . . . . . . . . . . . . . . . . . Hankins Parichabutr . . . . . . . . . . . . . . . . . . . . . On Tue, Oct 13, 2020 at 6:03 AM wrote: > Send TXAuth mailing list submissions to > txauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/txauth > or, via email, send a message with subject or body 'help' to > txauth-request@ietf.org > > You can reach the person managing the list at > txauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TXAuth digest..." > Today's Topics: > > 1. Re: Call for adoption: draft-richer-transactional-auth-14 > (Andrew Hindle) > 2. Re: Call for adoption: draft-richer-transactional-auth-14 > (Jim Willeke) > 3. Re: Call for adoption: draft-richer-transactional-auth-14 > (Steinar Noem) > > > > ---------- Forwarded message ---------- > From: Andrew Hindle > To: Dave Tonge > Cc: Kathleen Moriarty , Yaron Sheffer < > yaronf.ietf@gmail.com>, txauth@ietf.org > Bcc: > Date: Tue, 13 Oct 2020 09:54:40 +0100 > Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 > +1 for adoption. > > =E2=80=94&e > > On Mon, 12 Oct 2020 at 05:27, Dave Tonge wrote: > >> +1 for adoption >> >> On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer >> wrote: >> >>> Many thanks to Kathleen and the design team for the intensive work that >>> brought us to this point. >>> >>> >>> >>> We would like to issue a short, one week call for adoption for >>> draft-richer-transactional-authz-14 as the basis of the working group= =E2=80=99s >>> GNAP protocol. To clarify, this means that the design team, having achi= eved >>> its goal, is disbanded, and that change control over the document passe= s >>> into the working group. Whether you=E2=80=99re for or against, please s= peak up. >>> >>> >>> >>> Thanks, >>> >>> Leif and Yaron >>> >>> >>> >>> >>> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Andrew Hindle; CIPM , CIPP/E > , CIPT > > Hindle Consulting Limited > +44 7966 136543 > Schedule a meeting > > ------------------------------ > Hindle Consulting Limited is a company registered in England and Wales. = Company > number: 8888564. > Registered office: Claremont House, 1 Market Square, Bicester, Oxfordshir= e > OX26 6AA, UK. > > > > ---------- Forwarded message ---------- > From: Jim Willeke > To: txauth@ietf.org > Cc: > Bcc: > Date: Tue, 13 Oct 2020 05:13:24 -0400 > Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 > +1 for adoption > -- > -jim > Jim Willeke > > > On Tue, Oct 13, 2020 at 4:55 AM Andrew Hindle > wrote: > >> +1 for adoption. >> >> =E2=80=94&e >> >> On Mon, 12 Oct 2020 at 05:27, Dave Tonge wrote= : >> >>> +1 for adoption >>> >>> On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer >>> wrote: >>> >>>> Many thanks to Kathleen and the design team for the intensive work tha= t >>>> brought us to this point. >>>> >>>> >>>> >>>> We would like to issue a short, one week call for adoption for >>>> draft-richer-transactional-authz-14 as the basis of the working group= =E2=80=99s >>>> GNAP protocol. To clarify, this means that the design team, having ach= ieved >>>> its goal, is disbanded, and that change control over the document pass= es >>>> into the working group. Whether you=E2=80=99re for or against, please = speak up. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Leif and Yaron >>>> >>>> >>>> >>>> >>>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS= 1 >>> 6EA. >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> Andrew Hindle; CIPM , CIPP/E >> , CIPT >> >> Hindle Consulting Limited >> +44 7966 136543 >> Schedule a meeting >> >> >> ------------------------------ >> Hindle Consulting Limited is a company registered in England and Wales. = Company >> number: 8888564. >> Registered office: Claremont House, 1 Market Square, Bicester, >> Oxfordshire OX26 6AA, UK. >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > > ---------- Forwarded message ---------- > From: Steinar Noem > To: Yaron Sheffer , txauth@ietf.org > Cc: > Bcc: > Date: Tue, 13 Oct 2020 12:02:50 +0200 > Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 > +1 > > l=C3=B8r. 10. okt. 2020 kl. 15:01 skrev Yaron Sheffer : > >> Many thanks to Kathleen and the design team for the intensive work that >> brought us to this point. >> >> >> >> We would like to issue a short, one week call for adoption for >> draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s >> GNAP protocol. To clarify, this means that the design team, having achie= ved >> its goal, is disbanded, and that change control over the document passes >> into the working group. Whether you=E2=80=99re for or against, please sp= eak up. >> >> >> >> Thanks, >> >> Leif and Yaron >> >> >> >> *From: *TXAuth on behalf of Kathleen Moriarty = < >> kathleen.moriarty.ietf@gmail.com> >> *Date: *Saturday, October 10, 2020 at 01:55 >> *To: *GNAP Mailing List >> *Subject: *[GNAP] Design team >> >> >> >> Greetings! >> >> >> >> The design team has now come to a close. While there were too many >> issues to resolve to all design team member satisfaction, great effort w= as >> put in to describe decision points for the WG to ease and hopefully spee= d >> the working group process. As such, I am requesting that the WG adopts >> this version (14 of XYZ) and works together to fully develop a single >> specification. >> >> >> >> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >> >> >> >> A tremendous thank you to each of the design team members for your hard >> work and walking the fine line of when to put a stake in the ground (tha= t >> the WG can always change once adopted) and listing our options for decis= ion >> points to ease the WG process. >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> Sent from my mobile device >> >> -- TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007dbff105b18d4094 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption
. . . . . . . . . = . . . . . . . . . . . .
Hankins Parichabutr
. . . . . . . . . . . . = . . . . . . . . .


On Tue, Oct 13, 2020= at 6:03 AM <txauth-request@i= etf.org> wrote:
Send TXAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/txauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TXAuth digest..."
Today's Topics:

=C2=A0 =C2=A01. Re: Call for adoption: draft-richer-transactional-auth-14 =C2=A0 =C2=A0 =C2=A0 (Andrew Hindle)
=C2=A0 =C2=A02. Re: Call for adoption: draft-richer-transactional-auth-14 =C2=A0 =C2=A0 =C2=A0 (Jim Willeke)
=C2=A0 =C2=A03. Re: Call for adoption: draft-richer-transactional-auth-14 =C2=A0 =C2=A0 =C2=A0 (Steinar Noem)



---------- Forwarded message ----------
From:=C2=A0Andrew Hi= ndle <a= ndrew@hindleconsulting.com>
To:=C2=A0Dave Tonge <dave.tonge@moneyhub.com= >
Cc:=C2=A0Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>,= Yaron Sheffer <yaronf.ietf@gmail.com>, txauth@ietf.org
Bcc:=C2=A0
Date:=C2=A0Tue, 13 Oct 202= 0 09:54:40 +0100
Subject:=C2=A0Re: [GNAP] Call for adoption: draft-riche= r-transactional-auth-14
+1 for adoption.

=E2=80=94&e

On Mon, 12 Oct 20= 20 at 05:27, Dave Tonge <dave.tonge@moneyhub.com> wrote:
+1 for adoption<= br>

On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer <yaronf.ietf@gmail.com> wrot= e:

Many thanks to Kathleen and the design t= eam for the intensive work that brought us to this point.

=

=C2=A0

We wo= uld like to issue a short, one week call for adoption for draft-richer-tran= sactional-authz-14 as the basis of the working group=E2=80=99s GNAP protoco= l. To clarify, this means that the design team, having achieved its goal, i= s disbanded, and that change control over the document passes into the work= ing group. Whether you=E2=80=99re for or against, please speak up.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif = and Yaron

=C2=A0

<= div style=3D"border-right:none;border-bottom:none;border-left:none;border-t= op:1pt solid rgb(181,196,223);padding:3pt 0in 0in">

<= br>


Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Andrew Hindle; CIPM, CIPP/E, CIPT
Hindle Consulting Limit= ed
+44 7966 136543

Hindle Consulting Limited is a company registered in England and Wa= les. =C2=A0Company number: 8888564.
Registe= red office: Claremont House, 1 Market Square, Bicester, Oxfordshire OX26 6A= A, UK.



---------- Forwarded message ----------
F= rom:=C2=A0Jim Willeke <jim@willeke.com>
To:=C2=A0txauth@ietf.org
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 13 Oct 2020 05:13:24 -0400
Subject:=C2=A0Re: [GNAP] Call for = adoption: draft-richer-transactional-auth-14
+1 for ado= ption
--
-jim
Jim Willeke


On Tue, Oct 13, 20= 20 at 4:55 AM Andrew Hindle <andrew@hindleconsulting.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
+1 for a= doption.

=E2=80=94&e=

On Mon, 12 Oct 2020 at 05:27, Dave Tonge <dave.tonge@moneyhub.com> wrote:<= br>
+1 for adoption

On Sat, 10 Oct 2020 at 15:01, Yaron Sheffer = <yaronf.ietf@= gmail.com> wrote:

Many thanks to K= athleen and the design team for the intensive work that brought us to this = point.

=C2=A0

We would like to issue a short, one week call for adopti= on for draft-richer-transactional-authz-14 as the basis of the working grou= p=E2=80=99s GNAP protocol. To clarify, this means that the design team, hav= ing achieved its goal, is disbanded, and that change control over the docum= ent passes into the working group. Whether you=E2=80=99re for or against, p= lease speak up.

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Leif and Yaron

<= u>=C2=A0

=



Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Andrew Hindle; CIPM, CIPP/E, CIPT
Hindle Consulting Limit= ed
+44 7966 136543

Hindle Consulting Limited is a company registered in England and Wa= les. =C2=A0Company number: 8888564.
Registe= red office: Claremont House, 1 Market Square, Bicester, Oxfordshire OX26 6A= A, UK.
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth



---------- Forwarded message ----------
From:=C2=A0Steinar N= oem <steinar@udelt= .no>
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>, txauth@ietf.org
Cc:=C2=A0
Bcc:= =C2=A0
Date:=C2=A0Tue, 13 Oct 2020 12:02:50 +0200
Subject:=C2=A0Re: [= GNAP] Call for adoption: draft-richer-transactional-auth-14
+1=C2=A0

l=C3=B8r. 10. okt. 2020 kl. 15:01 skrev Yaron Sheffer <= yaronf.ietf@gmai= l.com>:
<= div lang=3D"EN-US">

Many thanks to Kathleen and = the design team for the intensive work that brought us to this point.

=C2=A0

We would like to issue a short, one week call for adoption for draft= -richer-transactional-authz-14 as the basis of the working group=E2=80=99s = GNAP protocol. To clarify, this means that the design team, having achieved= its goal, is disbanded, and that change control over the document passes i= nto the working group. Whether you=E2=80=99re for or against, please speak = up.

=C2=A0

Thanks,

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Leif and Yaron

=C2=A0=

From: <= span style=3D"font-size:12pt;color:black">TXAuth <txauth-bounces@ietf.org> on b= ehalf of Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Da= te: Saturday, October 10, 2020 at 01:55
To: GNAP Mailing List= <txauth@ietf.org>
Subject: [GNAP] Design team

=

=C2=A0

Greetings!=

=C2=A0

<= p class=3D"MsoNormal">The design team has now come to a close.=C2=A0 While = there were too many issues to resolve to all design team member satisfactio= n, great effort was put in to describe decision points for the WG to ease a= nd hopefully speed the working group process.=C2=A0 As such, I am requestin= g that the WG adopts this version (14 of XYZ) and works together to fully d= evelop a single specification.

=C2=A0

=C2=A0=

A tremendous thank you to each of= the design team members for your hard work and walking the fine line of wh= en to put a stake in the ground (that the WG can always change once adopted= ) and listing our options for decision points to ease the WG process.

=C2=A0

Best regards,

Kathleen=C2=A0

=C2=A0

Sent from my mobil= e device

-- TXAuth mailing li= st TXAuth@ietf.org= https://www.ietf.org/mailman/listinfo/txauth

<= /div> --
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
<= span style=3D"color:rgb(34,34,34)">Vennlig hilsen

Ste= inar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
|=C2=A0steinar@= udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
<= /div>
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007dbff105b18d4094-- From nobody Tue Oct 13 17:10:21 2020 Return-Path: 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 3FC793A1269 for ; Tue, 13 Oct 2020 17:10:20 -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 ebbPnhmSkERG for ; Tue, 13 Oct 2020 17:10:18 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 7A4D93A1268 for ; Tue, 13 Oct 2020 17:10:13 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id b127so685253wmb.3 for ; Tue, 13 Oct 2020 17:10:13 -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 :cc; bh=hG2h9xGyf8Y2kHNmn7OAU7PAeokRmequkXOSvhT5z7k=; b=GLH76yrmn+B1gztN1iQuwveJQm0gZ3TdAh5iHNTlHJPRpmELi8NRiXBcU8B6n80RQ3 6ysQUKYSSLBv9W7DV/Q7mhpCQt36WCa22u83M2IxZOrQns5zQrcGim/DeBETUsSLd5AS 8gcwS4MwHyTG69/f3wH40pMnzf/Qgk5aZtB48= 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=hG2h9xGyf8Y2kHNmn7OAU7PAeokRmequkXOSvhT5z7k=; b=q50u3O0pwvJIlcQEzioDMe2jkfAJm6dnwrB/s5iXsJGCqcTOXPSN3+S4sAcsBvsNC2 kkH1GeX0Teqyu0zr7cB+U5hzhJxhLLXRBB0FokOMwSgtdRPizssb99EvYfk52oVVGxdK HQeQgxWd/OuZq1bu7a5Vm2+rPsO2pgHr5/T2qgItXiXkFuQ2ufXWSDSPfMG8SE+t5qIY S406drKcO4XFRy1IFAtkb72HUlBBJtU/7wYRbezAExaOP7RPJoysLTEED5CwCiwOZtH6 EHjYkA78UTPMHQSRwBvoMhq0+Fv+Rld8Ls3u13pJKR8QTZpHGmgvrw8i694YtAG7KO5f u8aw== X-Gm-Message-State: AOAM531YQnnPeIdUwcdKA0PLlxjJFHOQk+2yJn+WwLPdDC88f2gGdFl9 kPMY9tQ8LxQGg2WmUUTZTxv+CAvPu/uvTKqpvvjr5w== X-Google-Smtp-Source: ABdhPJzKQxsQhHs4VBJKOGMeB1P8r3yiYqUMHu+zbcSl9KGhkoLjjIbWILT26eN2ZrY/sQZIygH8ZkK1CHyMYOc5MO8= X-Received: by 2002:a1c:9910:: with SMTP id b16mr661876wme.64.1602634211655; Tue, 13 Oct 2020 17:10:11 -0700 (PDT) MIME-Version: 1.0 References: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> In-Reply-To: <5F7A57FD-B73D-4BC5-9E11-3CC2B28962C3@gmail.com> From: Francis Pouatcha Date: Tue, 13 Oct 2020 20:10:00 -0400 Message-ID: To: Yaron Sheffer Cc: Kathleen Moriarty , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e41c1205b1965aec" Archived-At: Subject: Re: [GNAP] Call for adoption: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 00:10:20 -0000 --000000000000e41c1205b1965aec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption of the document. Best regards, /Francis On Sat, Oct 10, 2020 at 9:01 AM Yaron Sheffer wrote= : > Many thanks to Kathleen and the design team for the intensive work that > brought us to this point. > > > > We would like to issue a short, one week call for adoption for > draft-richer-transactional-authz-14 as the basis of the working group=E2= =80=99s > GNAP protocol. To clarify, this means that the design team, having achiev= ed > its goal, is disbanded, and that change control over the document passes > into the working group. Whether you=E2=80=99re for or against, please spe= ak up. > > > > Thanks, > > Leif and Yaron > > > > *From: *TXAuth on behalf of Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> > *Date: *Saturday, October 10, 2020 at 01:55 > *To: *GNAP Mailing List > *Subject: *[GNAP] Design team > > > > Greetings! > > > > The design team has now come to a close. While there were too many issue= s > to resolve to all design team member satisfaction, great effort was put i= n > to describe decision points for the WG to ease and hopefully speed the > working group process. As such, I am requesting that the WG adopts this > version (14 of XYZ) and works together to fully develop a single > specification. > > > > https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > > > > A tremendous thank you to each of the design team members for your hard > work and walking the fine line of when to put a stake in the ground (that > the WG can always change once adopted) and listing our options for decisi= on > points to ease the WG process. > > > > Best regards, > > Kathleen > > > > Sent from my mobile device > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Francis Pouatcha Technical Lead adorsys GmbH & Co. KG https:// www.adorsys.com --000000000000e41c1205b1965aec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption of the document.

Best regards,
/Francis

=
On Sat, Oc= t 10, 2020 at 9:01 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Many thanks to Kathleen and the design team for the intensive w= ork that brought us to this point.

= =C2=A0

We would like to issue a sho= rt, one week call for adoption for draft-richer-transactional-authz-14 as t= he basis of the working group=E2=80=99s GNAP protocol. To clarify, this mea= ns that the design team, having achieved its goal, is disbanded, and that c= hange control over the document passes into the working group. Whether you= =E2=80=99re for or against, please speak up.

=C2=A0

Thanks,<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leif and Yaron<= /p>

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on behalf of Kathleen Moriarty <kathleen.m= oriarty.ietf@gmail.com>
Date: Saturday, October 10, 2020 a= t 01:55
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] Des= ign team

= =C2=A0

Greetings!

=C2=A0

The design te= am has now come to a close.=C2=A0 While there were too many issues to resol= ve to all design team member satisfaction, great effort was put in to descr= ibe decision points for the WG to ease and hopefully speed the working grou= p process.=C2=A0 As such, I am requesting that the WG adopts this version (= 14 of XYZ) and works together to fully develop a single specification.

A tremendous thank you to each of the design team members for your h= ard work and walking the fine line of when to put a stake in the ground (th= at the WG can always change once adopted) and listing our options for decis= ion points to ease the WG process.

=C2=A0

Best r= egards,

Kathleen=C2=A0

=C2=A0

<= p class=3D"MsoNormal">Sent from my mobile device

-- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Francis Pouatcha
Tec= hnical Lead
adorsys GmbH & Co. KG
--000000000000e41c1205b1965aec-- From nobody Sat Oct 17 05:27:04 2020 Return-Path: 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 B1C5A3A0AD9 for ; Sat, 17 Oct 2020 05:27:02 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 UP6Gb6dWziuy for ; Sat, 17 Oct 2020 05:27:01 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 438183A0AD7 for ; Sat, 17 Oct 2020 05:27:01 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id p15so5970001wmi.4 for ; Sat, 17 Oct 2020 05:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=2TXjTW6iINypOYwT07oZIL5GFAhFydgO8K2gLdqLsA8=; b=JW/Q52CoIFgU+tGxryjseouxTgzxGmtqe74Ik4BcPAhwpXTbb8ubOicIOo1ACT6P96 1PPBvluFIDzWDkFXxl07KNdbAeOa+F4wM4voKMQF1m/RYRKI7atMYkhkV5u1VdZdhCUC +mo8fXQ90hPNBrUFtooEpKQB/W8xYQjzQIJTTXKZs+wJ0qLDp8fx9Zt9r3N++ieEGJAc YuVNjXysMVHeysSnVs/Hx1ACvfJxk39HhHMXctv+oikSMch3Sr32Eua9mbZGXfR80m3Q Qk3Sln77g3Yyf7lq7rN/d0dVLoGOt7Z1vgw5/GGJgKLWAQiA4e9ehtvO/NC/3giElcLC FpIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=2TXjTW6iINypOYwT07oZIL5GFAhFydgO8K2gLdqLsA8=; b=Ze5onQbosGhGh+Q7Bwe+zktM2/Yg8/JOzaILOSS5noaa7tgpEVYMR55b88Z9UJZvDu xMunC5U7Tj+lPChHDHbyyDSuRDEkgT7SoyLLyJNVdnjkT+a+xqLnmI9BvpqjieCJV/rg 29SY2YHNp/SxuONykqDLTpWo+NB17+d7insF7PV9RmxrCAS0HakWk6ZSHTdUCK62R940 wvilmrRfv3oG7YxzoPskLhJnZTQHIGdwNaaWK+qCsdMLzXjHpd7uAYjykmoVaIiDUnz8 YUCWV03BqsfHYWqAd79QaQXDFlDPkHkoi+XugbyWF5l63n1FEsMXsb9DCDBmKXBCo8Cj spQA== X-Gm-Message-State: AOAM532X8JYRoXLl/wikhjyhliZ8DZBvoJvp22wsgivEL5lYa17T+aXU 7EFiVF9WjV4jdWWfhEYL+CfDsT2DPwYkBA== X-Google-Smtp-Source: ABdhPJwQ8MSLv+S+xsuLl+VMvwbbKl5Zn5TI2c8IHVJ2GllhV54WZSL7O5SNLNSYIXIV6xIJXZJ6Xg== X-Received: by 2002:a7b:c4c3:: with SMTP id g3mr1846221wmk.127.1602937618462; Sat, 17 Oct 2020 05:26:58 -0700 (PDT) Received: from [192.168.68.104] (bzq-79-178-56-132.red.bezeqint.net. [79.178.56.132]) by smtp.gmail.com with ESMTPSA id p67sm7377021wmp.11.2020.10.17.05.26.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2020 05:26:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sat, 17 Oct 2020 15:18:27 +0300 From: Yaron Sheffer To: Message-ID: <9CC252F5-F88F-4068-8AB8-D9E4B8A48B2D@gmail.com> Thread-Topic: Adopted: draft-richer-transactional-auth-14 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685793217_1804303021" Archived-At: Subject: [GNAP] Adopted: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 12:27:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685793217_1804303021 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We have clear WG consensus to adopt the draft, thank you all for your suppo= rt. =20 Justin, can you please resubmit the draft as-is (no textual changes) as a w= orking group draft. I would suggest the name draft-ietf-gnap-core-protocol. = We will ask that the document source will be managed on GitHub [1]. =20 The chairs will shortly announce additional draft editor(s). If you are int= erested, please drop us a note. Note that this is a serious commitment: this= is a large and complex document and will take some time and likely quite a = few revisions before it is published. =20 This is a good time to review the document and submit comments to the maili= ng list! =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://github.com/ietf-wg-gnap =20 --B_3685793217_1804303021 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We have clear WG cons= ensus to adopt the draft, thank you all for your support.

 

Justin, can you pleas= e resubmit the draft as-is (no textual changes) as a working group draft. I = would suggest the name draft-ietf-gnap-core-protocol. We will ask that the d= ocument source will be managed on GitHub [1].

 

The chairs will shortly announce = additional draft editor(s). If you are interested, please drop us a note. No= te that this is a serious commitment: this is a large and complex document a= nd will take some time and likely quite a few revisions before it is publish= ed.

 

This is a good time to review the document and submit comments to the maili= ng list!

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Yaron

 

[1] https://github.com/ietf-wg-gnap

<= o:p>

--B_3685793217_1804303021-- From nobody Sat Oct 17 07:46:44 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D543A011D; Sat, 17 Oct 2020 07:46:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: txauth@ietf.org Message-ID: <160294599277.27126.4949816992987431112@ietfa.amsl.com> Date: Sat, 17 Oct 2020 07:46:32 -0700 Archived-At: Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-00.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 14:46:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF. Title : Grant Negotiation and Authorization Protocol Author : Justin Richer Filename : draft-ietf-gnap-core-protocol-00.txt Pages : 119 Date : 2020-10-17 Abstract: This document defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software. This document has been prepared by the GNAP working group design team of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and Justin Richer. This document is intended as a starting point for the working group and includes decision points for discussion and agreement. Many of the features in this proposed protocol can be accomplished in a number of ways. Where possible, the editor has included notes and discussion from the design team regarding the options as understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 12:44:14 2020 Return-Path: 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 F067D3A0B30 for ; Sun, 18 Oct 2020 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 zFxC40kUxXQJ for ; Sun, 18 Oct 2020 12:44:11 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 A2A963A0B36 for ; Sun, 18 Oct 2020 12:44:10 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id i1so9080580wro.1 for ; Sun, 18 Oct 2020 12:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=S5YcBPIVY8+QkweIS8duPKayv3ZoHztvjyyCcFzGqH0=; b=RIWJL6O8jGUDvbPixolcrKts+LSd4r9DKNc2J59AoWW2XYZ9F1ryZH5QCawteV9f8Y qGtxrRdMUeb4WKZ+LuxIF87nnAbOMX5e1xuQDMOEBqj/lAonUifH/jiZsG9y1HAWidMI Rc3VvmKPmhQi0hTNOF/cuWo6SfabNnZoLqolivYs4ndMvngwx0na6kAcLwuxyvn9H4uM FFOokX8PRs3X/YczHEzK8P5hO1HnwcuKPHBIC/siSSJlnEtyEDmrFF3yKnu5+A0JicZK gZebHEwAj+Hk8LrX9q4viD5g3/2ZIPcAQpiu0a6QKrablGMxLt8g/az4LTp+9k3BtAAv mMrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=S5YcBPIVY8+QkweIS8duPKayv3ZoHztvjyyCcFzGqH0=; b=exsuUrR74XwsatVFbXyUUFBErmn9bAsWc/BYpxGpvFJ7vjMT+1vCf8TJzaETN3ySrX ngEt3XH9LiqixUguz7oOg+guUM4+fRoc8mfbjpqhHKQnr0z4Bzzf5qqjDZ9l4bl1e5BJ JUz0TU0zJJEP0xrNRXJml+dEQlneCqC5nbIK44QHa9KCjc+opYqDM4Zuf4x+7ooBykxS uFmS6jJFziVOGf6LIiL4k4LY1IgesSxKgCD1eTiDeMf/E6VteEeuwkm8c8hGT5k9jopC caodE5K/OUUg6c+TujEv5xA47B8VxhUSt1/du0/rl4SUe/oO+CN0DSbnYplGaCH4/tIE 7IwA== X-Gm-Message-State: AOAM533NslNpgdWWH6jEbng0wuc+74bIT1R8JJiwMKGHlUmTX4lDHUJI VbSk2WVYSpFIlPwQVR2PvNUM/cejPfQ= X-Google-Smtp-Source: ABdhPJxAH1+aTZ2H1z1xixP+ZT5p2OwoexsgPgpjjgn92ydiBePsyz4Hg7TL/ash34yShKz/xAqb0Q== X-Received: by 2002:adf:92e4:: with SMTP id 91mr11107540wrn.230.1603050248467; Sun, 18 Oct 2020 12:44:08 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id u6sm13165358wmj.40.2020.10.18.12.44.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2020 12:44:07 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 18 Oct 2020 22:44:06 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: Thread-Topic: Review of draft-ietf-gnap-core-protocol-00 (first half) Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685905847_1730332037" Archived-At: Subject: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 19:44:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685905847_1730332037 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi Justin, all, The draft has undergone major changes since we started the design team, so I spent some time reviewing it. I only got as far as Sec. 3, and I fully intend to review the remainder of the document. But I figured since I have so many comments, I might as well send out what I have. * General comment: we have dozens, maybe hundreds of variants/options here. I think we need to define a must-implement subset, or we will never reach interoperability. * Abstract: the boilerplate text (MUST etc.) usually goes to the Introduction, not the Abstract. * 1. "The requesting party operating the software" - I think these actions are typically performed by the resource owner, who is not necessarily the requesting party. * RS, aka API: we are using the word "API" several times in a more generic sense (management API, identity API), so maybe replace with "RS, typically a protected API". * 1.2, "key" is a too generic term in the context of a security protocol. Can we call it something more specific, maybe "holder identity key"? * 1.3.1. "augmented with a hash of the security information" - this is too implementation-specific, suggest "is cryptographically bound to the security information". In general, step (7) is way too detailed, and verges on the normative. * 1.3.2: it is unclear to me what the goal of the user-code interaction is, in other words what is the threat model. If it's just "second factor, something you have", then an OTP MFA device would be simpler and offer the same security. * 1.3.5 (4): Typically the access token would not be sent once it is expired, right? Let's make the example more realistic. * 2: "OpenID Connect claims request" - why not "identity claims request" (which just happens to be similar to the OpenID request)? * Never liked the "dolphin" here... If this is listed under "actions", it should be a verb, e.g. "swim". * 2.1: an array for a single AT vs. an object for multiple ATs? This is extremely non-intuitive and probably ugly to code. Also, why should (multiple) tokens be named if a single token doesn't have to, why not list them in an array instead? * 2.1.1, "locations": are these really URIs or just URLs? On the other hand, if these are URIs, why do we need a separate "identifier"? There's too much semantic overlap between "type", "location" and "identifier" - specifying just "type" may be sufficient. * 2.1.1: it's implied but should be spelled out that the semantics of this example is the cross product of permissions: I am requesting to read and write and "dolphin" both "metadata" and "images", and that applies to both "locations" - 12 different possible actions. * 2.1.2: I don't see the value of the notion of "expansion". It is sufficient that the string is understood by the AS. * 2.1.2, "in some situations the value is intended to be seen and understood be the RC developer" - shouldn't we require this value to be always fully documented by the AS owner, so that the RC knows what it is requesting? * 2.1.4: why are flags represented as resources? The answer, "this is how OAuth 2 does it" is not great. * "the each access tokens" -> each access token. * I suggest to extend the editor's note to clarify what is the use case, so that the group can decide whether split tokens are indeed necessary. * Why is key binding of the access token even optional? * 2.2, "Subject identifiers requested by the RC serve only to identify the RO in the context of the AS and can't be used as communication channels by the RC" - this sounds a bit naive, people will do that anyway. So why is this a useful statement? (And similarly in 3.4) * 2.3: what's the benefit of including a URI (URL really) in "display"? Do we really want the user (RO) to click links provided by the RC? * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that the cert contains the same public key as the cert? * 2.3, " the AS MUST ensure that the key used to sign the request... is associated with the instance identifier" - can we be much more specific here, e.g. the instance_id MUST be byte-identical to the Common Name of the cert? This "association" is never clarified, either here or in Sec. 8. * 2.3.2: allowing to send the key in multiple formats virtually invites security vulnerabilities. Why is this a good thing? * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it here? Note that in Sec. 8.3 you are using the full certificate rather than the fingerprint. * 2.3.2: why are we using raw PEM certificates instead of the JOSE representation? * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose to avoid displaying an arbitrary URI. RC developers must only assume that the "name" field will be displayed. * 2.3.4, "created just for this request" -> created just for this series of requests. * 2.3.4: I suggest referring to RCs that present unknown keys as "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any assertions from an anonymous RC. * 2.4: IMO assertion validation is a MUST, and we should specify what we require for every assertion type we allow. * 2.4: moreover, when possible, the AS MUST match the assertions to the presented sub_id. It may be a hint, but you're not allowed to lie. * 2.4, "If the identified RQ does not match the RO present at the AS" - I thought there are cases where the RQ is different from the RO. Also, I am wondering why this is a SHOULD, not a MUST. * 2.4.1 (but probably applicable to any references): what is the lifetime of the reference? As an RC, how long can I assume the user reference is still valid? * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is it bundled here? * 2.5: the way "callback" is described here is as a capability, not an interaction mode. The example only strengthens this view, "callback" is a modifier of the "redirect" mode. * 2.5: "use code" -> user code. * 2.5.1: this unnecessary polymorphism IMO just complicates implementations and prevents extensibility. Instead, I would suggest: redirect: {} redirect:{max_length: 255} redirect:{max_length: 255, callback: {...}} * 2.5.2: the "app" option is problematic, as you already note. The RC may not even know if a given URL will result in an application launching. * 2.5.2: and shouldn't the RC include a list of supported applications? (Which would have lovely privacy implications.) * 2.5.3: there's a parenthetical discussion on whether the URL is unique. But the nonce parameter implies that the "hash" parameter is unique per request, making this discussion moot. * 2.5.3: even if we need a different kind of post-interaction "redirect", where the RC is not involved, there must be a way to ensure that the RC receives positive (cryptographically protected) confirmation that the authorization was successful. In other words, what we're discussing here is not an RC interaction mode, it is something else, and should probably have a separate protocol element to describe it. * 2.5.3: In the example for "interact" as an array (which I support), the second "redirect" and "user_code" should be independent elements of the array, not members of an object. This assumes they are truly independent interaction modes. * 2.5.3.1: what does "RQ is present on the request" mean? * 2.5.3.2: typo: HTTP the request. * 2.7: this seems to assume a short access token (which implies a bearer token). What if we want to use longer self-contained access tokens containing full keys? Should we have a separate "grant_id" value instead? * 2.8: another problem with this stanza is that the RC needs to know a priority that the AS supports it. What happens if the AS doesn't? * 2.8: I suggest to move this section into a separate I-D, or at least a separate appendix. * 2.9: it makes sense to bundle extensions and the "capabilities" section into one. * 2.9: The AS MUST ignore any unknown extension. * 3: it's confusing that we're using access_token for two different things. Maybe we could change the RC/AS one to "as_access_token"? * 3.1: MAY vary *by* request. * 3.1: how is the client behavior "deterministic in all cases" - how does the RC know whether the AS allows continuation or only allows one request at a time? * 3.2.1: the "value" of the access token is opaque in some cases (bearer token) but not in others. * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be printable ASCII, 0x20

Hi Justin, all,

 

= The draft has undergone major changes since w= e started the design team, so I spent some time reviewing it. I only got as = far as Sec. 3, and I fully intend to review the remainder of the document. B= ut I figured since I have so many comments, I might as well send out what I = have.

 

* General comment: we have dozens, maybe hundreds of variants/options her= e. I think we need to define a must-implement subset, or we will never reach= interoperability.

* Abstract: the boilerplate text (MUST etc.) usually goes to t= he Introduction, not the Abstract.

<= span style=3D'font-size:11.0pt'>* 1. "The requesting party operating the = software" - I think these actions are typically performed by the resour= ce owner, who is not necessarily the requesting party.

=

* RS, aka API: we are usin= g the word "API" several times in a more generic sense (management= API, identity API), so maybe replace with "RS, typically a protected A= PI".

* 1.2, "key" is a too generic term in the context of a securi= ty protocol. Can we call it something more specific, maybe "holder iden= tity key"?

* 1.3.1. "augmented with a hash of the security information&= quot; - this is too implementation-specific, suggest "is cryptographica= lly bound to the security information". In general, step (7) is way too= detailed, and verges on the normative.

* 1.3.2: it is unclear to me what the goa= l of the user-code interaction is, in other words what is the threat model. = If it's just "second factor, something you have", then an OTP MFA = device would be simpler and offer the same security.

* 1.3.5 (4): Typically the a= ccess token would not be sent once it is expired, right? Let's make the exam= ple more realistic.

* 2: "OpenID Connect claims request" - why not &quo= t;identity claims request" (which just happens to be similar to the Ope= nID request)?

* Never liked the "dolphin" here... If this is listed und= er "actions", it should be a verb, e.g. "swim".

* 2.1: an arr= ay for a single AT vs. an object for multiple ATs? This is extremely non-int= uitive and probably ugly to code. Also, why should (multiple) tokens be name= d if a single token doesn't have to, why not list them in an array instead?<= o:p>

* 2.1= .1, "locations": are these really URIs or just URLs? On the other = hand, if these are URIs, why do we need a separate "identifier"? T= here's too much semantic overlap between "type", "location&qu= ot; and "identifier" - specifying just "type" may be suf= ficient.

* 2.1.1: it's implied but should be spelled out that the semantics of th= is example is the cross product of permissions: I am requesting to read and = write and "dolphin" both "metadata" and "images&quo= t;, and that applies to both "locations" - 12 different possible a= ctions.

* 2.1.2: I don't see the value of the notion of "expansion". It= is sufficient that the string is understood by the AS.

* 2.1.2, "in some si= tuations the value is intended to be seen and understood be the RC developer= " - shouldn't we require this value to be always fully documented by th= e AS owner, so that the RC knows what it is requesting?

* 2.1.4: why are flags re= presented as resources? The answer, "this is how OAuth 2 does it" = is not great.

* "the each access tokens" -> each access token.<= /o:p>

* I sugges= t to extend the editor's note to clarify what is the use case, so that the g= roup can decide whether split tokens are indeed necessary.=

* Why is key binding o= f the access token even optional?

* 2.2, "Subject identifiers requested by t= he RC serve only to identify the RO in the context of the AS and can't be us= ed as communication channels by the RC" - this sounds a bit naive, peop= le will do that anyway. So why is this a useful statement? (And similarly in= 3.4)

* 2.3: what's the benefit of including a URI (URL really) in "display&= quot;? Do we really want the user (RO) to click links provided by the RC?

* 2.3: = why are we sending a JWK *as well as* a cert? Are we checking that the cert = contains the same public key as the cert?

* 2.3, " the AS MUST ensure that t= he key used to sign the request... is associated with the instance identifie= r" - can we be much more specific here, e.g. the instance_id MUST be by= te-identical to the Common Name of the cert? This "association" is= never clarified, either here or in Sec. 8.

* 2.3.2: allowing to send the key in = multiple formats virtually invites security vulnerabilities. Why is this a g= ood thing?

* 2.3.2: cert#256 is not a key, it's an identifier. Why do we include = it here? Note that in Sec. 8.3 you are using the full certificate rather tha= n the fingerprint.

* 2.3.2: why are we using raw PEM certificates instead of the = JOSE representation?

* 2.3.3: For obvious security reasons, I suggest adding: The= AS MAY choose to avoid displaying an arbitrary URI. RC developers must only= assume that the "name" field will be displayed.=

* 2.3.4, "created= just for this request" -> created just for this series of requests.=

* 2.= 3.4: I suggest referring to RCs that present unknown keys as "anonymous= RC", and then in 2.4, say that the AS MUST NOT accept any assertions f= rom an anonymous RC.

* 2.4: IMO assertion validation is a MUST, and we should spe= cify what we require for every assertion type we allow.

* 2.4: moreover, when pos= sible, the AS MUST match the assertions to the presented sub_id. It may be a= hint, but you're not allowed to lie.

* 2.4, "If the identified RQ does not = match the RO present at the AS" - I thought there are cases where the R= Q is different from the RO. Also, I am wondering why this is a SHOULD, not a= MUST.

* 2.4.1 (but probably applicable to any references): what is the lifetime = of the reference? As an RC, how long can I assume the user reference is stil= l valid?

* 2.5: "preferred_locales" is obviously not a mode of interact= ion. Why is it bundled here?

* 2.5: the way "callback" is described her= e is as a capability, not an interaction mode. The example only strengthens = this view, "callback" is a modifier of the "redirect" mo= de.

*= 2.5: "use code" -> user code.

* 2.5.1: this unnecessary polymorphis= m IMO just complicates implementations and prevents extensibility. Instead, = I would suggest:

redirect: {}

redirect:{max_length: 255}

redirect:{max_length: 255, callbac= k: {...}}

* 2.5.2: the "app" option is problematic, as you already note= . The RC may not even know if a given URL will result in an application laun= ching.

* 2.5.2: and shouldn't the RC include a list of supported applications? (W= hich would have lovely privacy implications.)

* 2.5.3: there's a parenthetical di= scussion on whether the URL is unique. But the nonce parameter implies that = the "hash" parameter is unique per request, making this discussion= moot.

* 2.5.3: even if we need a different kind of post-interaction "redire= ct", where the RC is not involved, there must be a way to ensure that t= he RC receives positive (cryptographically protected) confirmation that the = authorization was successful. In other words, what we're discussing here is = not an RC interaction mode, it is something else, and should probably have a= separate protocol element to describe it.

* 2.5.3: In the example for "inte= ract" as an array (which I support), the second "redirect" an= d "user_code" should be independent elements of the array, not mem= bers of an object. This assumes they are truly independent interaction modes= .

* 2= .5.3.1: what does "RQ is present on the request" mean?<= /span>

* 2.5.3.2: typo:= HTTP the request.

* 2.7: this seems to assume a short access token (which implie= s a bearer token). What if we want to use longer self-contained access token= s containing full keys? Should we have a separate "grant_id" value= instead?

* 2.8: another problem with this stanza is that the RC needs to know a = priority that the AS supports it. What happens if the AS doesn't?=

* 2.8: I sugges= t to move this section into a separate I-D, or at least a separate appendix.=

* 2.= 9: it makes sense to bundle extensions and the "capabilities" sect= ion into one.

* 2.9: The AS MUST ignore any unknown extension.<= /p>

* 3: it's confusing tha= t we're using access_token for two different things. Maybe we could change t= he RC/AS one to "as_access_token"?

* 3.1: MAY vary *by* request.

* 3.1: how = is the client behavior "deterministic in all cases" - how does the= RC know whether the AS allows continuation or only allows one request at a = time?

* 3.2.1: the "value" of the access token is opaque in some cases = (bearer token) but not in others.

* 3.2.1: The ASCII restriction on "value&q= uot; is insufficient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I= 'm not sure if this doesn't leave some characters that still need to be esca= ped.

= * 3.2.1: why is "expires_in" optional? Typically access tokens are= not revoked, and the RC needs a way to manage their lifetime.

* 3.2.1: "res= ources" refers to this same section. Did you mean 2.1.2, or are we miss= ing a subsection describing resources/rights?

* 3.2.1: "key": another p= olymorphism alert!

* 3.2.1: the example at the bottom of the section talks about = a way to present the token, I believe this discussion is out of context here= .

* 3= .3: the AS knows now which interaction modes are available. Why not pick jus= t one for its response, to simplify the protocol? As one example, the AS can= then more easily decide on timeout behavior.

* 3.3.3: Suggest to add to the last= paragraph: If the RC does not receive a callback until an RC-determined tim= eout occurs, the RC MUST act as if the entire request failed.

* 3.4: "update= d_at": Unix time is nice, but for absolute time it's common to use ISO = 8601 format.

* 3.6: YES, the "error" element is exclusive!

* 3.6: in SecEven= t we tried to use RFC 7807 "problem details", I think it could wor= k nicely here.

* 10.4: "indicating that GNAP" - sentence is broken.

* This &= quot;speculative" access is not useful if the response is only a MAY. W= hy would the RC try it if it is unlikely to provide useful information?=

* 15: the= BCP195 ref is broken - the author names are missing (yes I am one of them..= .).

*= Appendix D: can we name the first scenario, maybe "Simple API Access&q= uot;?

--B_3685905847_1730332037-- From nobody Sun Oct 18 12:48:01 2020 Return-Path: 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 526263A07DB for ; Sun, 18 Oct 2020 12:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=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 (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 1bZOskYeu5kk for ; Sun, 18 Oct 2020 12:47:57 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 770E13A0B3B for ; Sun, 18 Oct 2020 12:47:57 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id q136so10053800oic.8 for ; Sun, 18 Oct 2020 12:47:57 -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=/SfXTCckILCOjBHP4GPxjMjvRM6zvcXqmq4vSWUnP+o=; b=dxWmq5bXaBP7ueWgQk2CTn8eJF601ZZ+SR4cbvte+4MESqAv1eEMedZgRFk8u2NMND yH2vJZwZ9NwqNOI1Tw01NZOKDH2uQsddOWZUxiwsqOWpukhaJ2QLZXdjK6N/fb8+imN9 C/zaEfKUOuwUx3hO+bIm0DXyFzlzzB7dM8Ql3YKXQzGJvWivc9zHOBjXqJDmsesF0Uye uzQFHIPvn0ziN1lwvqJWXQnaZYGATLWq1rWCJTssrv5ajzrVktX9JBptgKr+pvv9dXCh Z6KfDE01DuGfPBVav8uyvaVPQiKdj1OiB8WSvw3p6PdeWI3vlGILaqixyRqbe4fDtbKA hXsw== 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=/SfXTCckILCOjBHP4GPxjMjvRM6zvcXqmq4vSWUnP+o=; b=FJffTQD/T9JGYeV3Hmm5Oi25vgkkn5RG53MccjCLx+Z7UaawYcEsjoGnVMDLYphC4N 2BTXB0oubOMSl/dEj+H6Y47RlRf7Qa1fgELjbKbzjSNWX0COmosXXQ395VPw7yezeoQs 02gtbUuURFKTG3FfdvSKbZFshP2oSdWyZ3dioRgWgXrJWzZCHXcAH/UJiYBqHfeJZixZ bJf2HBNiW8D4B7SjrmheschrjJZFqpaLUEfWeU2/41vYIlrv7u2vWsu4Q6BxmjPtXuR4 C9+q6vnNl8BkYUL4sEoycxkYBBuwKybDRb0BRf5YmUAjCtY4An/2eQIFlTUqBtAKZO0f I+Ag== X-Gm-Message-State: AOAM531yB9HTvLVLXhYn0+nkJ9DAo/+FqH2mJ8ePb9ADOJbIodLt++ob FdiCmDqk2nHbPV3D5bVuH2s+VE18ZJ4LK3IoY7o= X-Google-Smtp-Source: ABdhPJw7nxP8Pr3S7Xx0YH78zu7VrG1c/ZjNhXcZVDocCItuy46kuJqa8WTQpguJ6Dhs0RA00oheCwV/BzqE2U9qObM= X-Received: by 2002:a05:6808:57c:: with SMTP id j28mr8846524oig.63.1603050476615; Sun, 18 Oct 2020 12:47:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Sun, 18 Oct 2020 12:47:44 -0700 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000373c5405b1f74660" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 19:47:59 -0000 --000000000000373c5405b1f74660 Content-Type: text/plain; charset="UTF-8" why are you doing this? Should these be issues now? Peace ..tom On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer wrote: > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, so > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I have > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these actions > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generic > sense (management API, identity API), so maybe replace with "RS, typically > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is too > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verges > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer the > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not list > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of this > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to both > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify the > RO in the context of the AS and can't be used as communication channels by > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? Do > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of the > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather than > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here is > not an RC interaction mode, it is something else, and should probably have > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if the > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000373c5405b1f74660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
why are you doing this? Should these be issues now?
Peace ..tom


On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin, all= ,

=C2=A0

The draft has undergone major changes since we started the d= esign team, so I spent some time reviewing it. I only got as far as Sec. 3,= and I fully intend to review the remainder of the document. But I figured = since I have so many comments, I might as well send out what I have.=

= =C2=A0

* General comment: we have dozens, maybe hundreds of variants/option= s here. I think we need to define a must-implement subset, or we will never= reach interoperability.

* Abstract: the boilerplate text (MUST etc.) us= ually goes to the Introduction, not the Abstract.

<= p class=3D"MsoNormal">* 1. "The request= ing party operating the software" - I think these actions are typicall= y performed by the resource owner, who is not necessarily the requesting pa= rty.

* RS, aka API: we are using the word "API" several times = in a more generic sense (management API, identity API), so maybe replace wi= th "RS, typically a protected API".

* 1.2, "key" is = a too generic term in the context of a security protocol. Can we call it so= mething more specific, maybe "holder identity key"?=

* 1.3.1. &= quot;augmented with a hash of the security information" - this is too = implementation-specific, suggest "is cryptographically bound to the se= curity information". In general, step (7) is way too detailed, and ver= ges on the normative.

* 1.3.2: it is unclear to me what the goal of the = user-code interaction is, in other words what is the threat model. If it= 9;s just "second factor, something you have", then an OTP MFA dev= ice would be simpler and offer the same security.

<= p class=3D"MsoNormal">* 1.3.5 (4): Typically= the access token would not be sent once it is expired, right? Let's ma= ke the example more realistic.

* 2: "OpenID Connect claims request&= quot; - why not "identity claims request" (which just happens to = be similar to the OpenID request)?

* Never liked the "dolphin"= here... If this is listed under "actions", it should be a verb, = e.g. "swim".

* 2.1: an array for a single AT vs. an object for= multiple ATs? This is extremely non-intuitive and probably ugly to code. A= lso, why should (multiple) tokens be named if a single token doesn't ha= ve to, why not list them in an array instead?

* 2.1.1, "locations&q= uot;: are these really URIs or just URLs? On the other hand, if these are U= RIs, why do we need a separate "identifier"? There's too much= semantic overlap between "type", "location" and "= identifier" - specifying just "type" may be sufficient.

*= 2.1.1: it's implied but should be spelled out that the semantics of th= is example is the cross product of permissions: I am requesting to read and= write and "dolphin" both "metadata" and "images&q= uot;, and that applies to both "locations" - 12 different possibl= e actions.

* 2.1.2: I don't see the value of the notion of "exp= ansion". It is sufficient that the string is understood by the AS.<= /u>

= * 2.1.2, "in some situations the value is intended to be seen and unde= rstood be the RC developer" - shouldn't we require this value to b= e always fully documented by the AS owner, so that the RC knows what it is = requesting?

* 2.1.4: why are flags represented as resources? The answer,= "this is how OAuth 2 does it" is not great.=

* "the each = access tokens" -> each access token.

* I suggest to extend the e= ditor's note to clarify what is the use case, so that the group can dec= ide whether split tokens are indeed necessary.

* Why is key binding of t= he access token even optional?

* 2.2, "Subject identifiers requeste= d by the RC serve only to identify the RO in the context of the AS and can&= #39;t be used as communication channels by the RC" - this sounds a bit= naive, people will do that anyway. So why is this a useful statement? (And= similarly in 3.4)

* 2.3: what's the benefit of including a URI (URL= really) in "display"? Do we really want the user (RO) to click l= inks provided by the RC?

* 2.3: why are we sending a JWK *as well as* a = cert? Are we checking that the cert contains the same public key as the cer= t?

* 2.3, " the AS MUST ensure that the key used to sign the reques= t... is associated with the instance identifier" - can we be much more= specific here, e.g. the instance_id MUST be byte-identical to the Common N= ame of the cert? This "association" is never clarified, either he= re or in Sec. 8.

* 2.3.2: allowing to send the key in multiple formats v= irtually invites security vulnerabilities. Why is this a good thing?=

* 2= .3.2: cert#256 is not a key, it's an identifier. Why do we include it h= ere? Note that in Sec. 8.3 you are using the full certificate rather than t= he fingerprint.

* 2.3.2: why are we using raw PEM certificates instead = of the JOSE representation?

= * 2.3.3: For obvious security reasons, I sug= gest adding: The AS MAY choose to avoid displaying an arbitrary URI. RC dev= elopers must only assume that the "name" field will be displayed.=

* 2.3.4, "created just for this request" -> created just f= or this series of requests.

= * 2.3.4: I suggest referring to RCs that pre= sent unknown keys as "anonymous RC", and then in 2.4, say that th= e AS MUST NOT accept any assertions from an anonymous RC.

* 2.4: IMO ass= ertion validation is a MUST, and we should specify what we require for ever= y assertion type we allow.

<= span style=3D"font-size:11pt">* 2.4: moreover, when possible, the AS MUST m= atch the assertions to the presented sub_id. It may be a hint, but you'= re not allowed to lie.

* 2.4, "If the identified RQ does not match = the RO present at the AS" - I thought there are cases where the RQ is = different from the RO. Also, I am wondering why this is a SHOULD, not a MUS= T.

* 2.4.1 (but probably applicable to any references): what is the life= time of the reference? As an RC, how long can I assume the user reference i= s still valid?

* 2.5: "preferred_locales" is obviously not a= mode of interaction. Why is it bundled here?

* 2.5: the way "callb= ack" is described here is as a capability, not an interaction mode. Th= e example only strengthens this view, "callback" is a modifier of= the "redirect" mode.

* 2.5: "use code" -> user c= ode.

* 2.5.1: this unnecessary polymorphism IMO just complicates impleme= ntations and prevents extensibility. Instead, I would suggest:

redirect:= {}

redirect:{max_length: 255}

redirect:{max_length: 255, callback: {= ...}}

* 2.5.2: the "app" option is problematic, as you already= note. The RC may not even know if a given URL will result in an applicatio= n launching.

* 2.5.2: and shouldn't the RC include a list of support= ed applications? (Which would have lovely privacy implications.)<= /u>

* 2.5.3= : there's a parenthetical discussion on whether the URL is unique. But = the nonce parameter implies that the "hash" parameter is unique p= er request, making this discussion moot.

* 2.5.3: even if we need a di= fferent kind of post-interaction "redirect", where the RC is not = involved, there must be a way to ensure that the RC receives positive (cryp= tographically protected) confirmation that the authorization was successful= . In other words, what we're discussing here is not an RC interaction m= ode, it is something else, and should probably have a separate protocol ele= ment to describe it.

* 2.5.3: In the example for "interact" as= an array (which I support), the second "redirect" and "user= _code" should be independent elements of the array, not members of an = object. This assumes they are truly independent interaction modes.

* 2.5.3.1: what does "RQ i= s present on the request" mean?

* 2.5.3.2: typo: HTTP the request.

* 2.7: this seems to as= sume a short access token (which implies a bearer token). What if we want t= o use longer self-contained access tokens containing full keys? Should we h= ave a separate "grant_id" value instead?

=

* 2.8: another proble= m with this stanza is that the RC needs to know a priority that the AS supp= orts it. What happens if the AS doesn't?

* 2.8: I suggest to move th= is section into a separate I-D, or at least a separate appendix.<= /u>

* 2.9: = it makes sense to bundle extensions and the "capabilities" sectio= n into one.

* 2.9: The AS MUST ignore any unknown extension.

* 3: it&= #39;s confusing that we're using access_token for two different things.= Maybe we could change the RC/AS one to "as_access_token"?=

* 3= .1: MAY vary *by* request.

<= span style=3D"font-size:11pt">* 3.1: how is the client behavior "deter= ministic in all cases" - how does the RC know whether the AS allows co= ntinuation or only allows one request at a time?

* 3.2.1: the "valu= e" of the access token is opaque in some cases (bearer token) but not = in others.

* 3.2.1: The ASCII restriction on "value" is insuff= icient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I'm not = sure if this doesn't leave some characters that still need to be escape= d.

* 3.2.1: why is "expires_in" optional? Typically access tok= ens are not revoked, and the RC needs a way to manage their lifetime.

* = 3.2.1: "resources" refers to this same section. Did you mean 2.1.= 2, or are we missing a subsection describing resources/rights?

* 3.2.1: = "key": another polymorphism alert!

* 3.2.1: the example at the= bottom of the section talks about a way to present the token, I believe th= is discussion is out of context here.

* 3.3: the AS knows now which inte= raction modes are available. Why not pick just one for its response, to sim= plify the protocol? As one example, the AS can then more easily decide on t= imeout behavior.

* 3.3.3: Suggest to add to the last paragraph: If the R= C does not receive a callback until an RC-determined timeout occurs, the RC= MUST act as if the entire request failed.

* 3.4: "updated_at"= : Unix time is nice, but for absolute time it's common to use ISO 8601 = format.

* 3.6: YES, the "error" element is exclusive!

* 3.6= : in SecEvent we tried to use RFC 7807 "problem details", I think= it could work nicely here.

= * 10.4: "indicating that GNAP" - s= entence is broken.

* This "speculative" access is not useful i= f the response is only a MAY. Why would the RC try it if it is unlikely to = provide useful information?

= * 15: the BCP195 ref is broken - the author = names are missing (yes I am one of them...).

* Appendix D: can we name t= he first scenario, maybe "Simple API Access"?

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000373c5405b1f74660-- From nobody Sun Oct 18 13:00:30 2020 Return-Path: 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 8A3623A0B5F for ; Sun, 18 Oct 2020 13:00:29 -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=[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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WAwCMB0V068q for ; Sun, 18 Oct 2020 13:00:27 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 96D663A0B5E for ; Sun, 18 Oct 2020 13:00:26 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id d3so10637595wma.4 for ; Sun, 18 Oct 2020 13:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=LLtwt3YsELKpfZixO0s6UWzze5MeyvQKosC8JTfE8P4=; b=PIpIJW+XvjNzWUNY0EWfsssMfhz/EnAlQre6IzXuYa1NFN7UagDMvslNgBJD1/zU8h iSz8x8JHM+Qxe8+6N185biXBspDhy86joNSl7OMkGqesgttMipfGIhg3uGJ62BHv1pdZ vnjovgmHK1YUwIXPjer/eKbYyI3d+gNLR0wkl1hX42ZlzcNhGe+t/udczpjpDfipoYLw vRXpJ6S/qvUJAWTe3dsPXkqOq5mYhZx4zKM2ZU+UUilhIUor28R3B2oFN3NyvilS6VBO zje2J5BIcZDGmkDqQ1IXEvE4ajhk91UuPPGJocZWQM6R1aPeXXeC+GqUESrFSpC0ZrHe 29Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=LLtwt3YsELKpfZixO0s6UWzze5MeyvQKosC8JTfE8P4=; b=GTTafynwlFlgDYYe3Es46PeSAu8aJm8AvIVPxEptNGCOJZF7dqH/05LJMOGdeZi9c4 hdbFVRd4ItYjRXM20ANO3pSl1VLM8X6ksSBbfA4oGau7Dg4XwIjNTKNPifiPaO9o2kJH mFtWMpksn9lT05LaCnL7X1NsZMUVrpIrRP10G9WVfmaYw9cLzDsMySquteD3/10ZmIgO DwNuhfWMfX8wwcMIyU82PQ+SEw8i6WPnp+lrwiiYIpZc5BcmvMY2yAzVyvbvOoqb68w5 XaUwWNFeOvhAYryZ7lRNlbYNXRANMJAy7hH9iG7gd5jp3YLMRrYgJSJq8VhmJXcVrAiX FyMA== X-Gm-Message-State: AOAM533FwGrdW4w5cxP7PaUcNPOmY+PRP29mXx4BYwEUM+yEv8adayeZ OjU6pwn5aQ1IvuPQ9M/MYZM= X-Google-Smtp-Source: ABdhPJyMLfcSWe8yb20LEzWoK8KAljKZNLAXwi1wbC0Lfpgxj4tzqv+0nbqV8GnTbi0g7QCBCDMTqg== X-Received: by 2002:a1c:bb06:: with SMTP id l6mr14654443wmf.40.1603051224926; Sun, 18 Oct 2020 13:00:24 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id s1sm12885541wmh.22.2020.10.18.13.00.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2020 13:00:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 18 Oct 2020 23:00:22 +0300 From: Yaron Sheffer To: Tom Jones CC: GNAP Mailing List Message-ID: <7B79DA52-C4CE-4033-961A-AB4E81248D83@gmail.com> Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685906823_1894089213" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 20:00:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685906823_1894089213 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We haven=E2=80=99t discussed this process yet, and the default IETF process is, e= verything goes through the mailing list. =20 IMO small things can be quickly cleaned up (fixed or rejected), and we can = open GH issues for bigger things. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Tom Jones Date: Sunday, October 18, 2020 at 22:47 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) =20 why are you doing this? Should these be issues now? Peace ..tom =20 =20 On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer wrot= e: Hi Justin, all, =20 The draft has undergone major changes since we started the design team, so = I spent some time reviewing it. I only got as far as Sec. 3, and I fully int= end to review the remainder of the document. But I figured since I have so m= any comments, I might as well send out what I have. =20 * General comment: we have dozens, maybe hundreds of variants/options here.= I think we need to define a must-implement subset, or we will never reach i= nteroperability. * Abstract: the boilerplate text (MUST etc.) usually goes to the Introducti= on, not the Abstract. * 1. "The requesting party operating the software" - I think these actions = are typically performed by the resource owner, who is not necessarily the re= questing party. * RS, aka API: we are using the word "API" several times in a more generic = sense (management API, identity API), so maybe replace with "RS, typically a= protected API". * 1.2, "key" is a too generic term in the context of a security protocol. C= an we call it something more specific, maybe "holder identity key"? * 1.3.1. "augmented with a hash of the security information" - this is too = implementation-specific, suggest "is cryptographically bound to the security= information". In general, step (7) is way too detailed, and verges on the n= ormative. * 1.3.2: it is unclear to me what the goal of the user-code interaction is,= in other words what is the threat model. If it's just "second factor, somet= hing you have", then an OTP MFA device would be simpler and offer the same s= ecurity. * 1.3.5 (4): Typically the access token would not be sent once it is expire= d, right? Let's make the example more realistic. * 2: "OpenID Connect claims request" - why not "identity claims request" (w= hich just happens to be similar to the OpenID request)? * Never liked the "dolphin" here... If this is listed under "actions", it s= hould be a verb, e.g. "swim". * 2.1: an array for a single AT vs. an object for multiple ATs? This is ext= remely non-intuitive and probably ugly to code. Also, why should (multiple) = tokens be named if a single token doesn't have to, why not list them in an a= rray instead? * 2.1.1, "locations": are these really URIs or just URLs? On the other hand= , if these are URIs, why do we need a separate "identifier"? There's too muc= h semantic overlap between "type", "location" and "identifier" - specifying = just "type" may be sufficient. * 2.1.1: it's implied but should be spelled out that the semantics of this = example is the cross product of permissions: I am requesting to read and wri= te and "dolphin" both "metadata" and "images", and that applies to both "loc= ations" - 12 different possible actions. * 2.1.2: I don't see the value of the notion of "expansion". It is sufficie= nt that the string is understood by the AS. * 2.1.2, "in some situations the value is intended to be seen and understoo= d be the RC developer" - shouldn't we require this value to be always fully = documented by the AS owner, so that the RC knows what it is requesting? * 2.1.4: why are flags represented as resources? The answer, "this is how O= Auth 2 does it" is not great. * "the each access tokens" -> each access token. * I suggest to extend the editor's note to clarify what is the use case, so= that the group can decide whether split tokens are indeed necessary. * Why is key binding of the access token even optional? * 2.2, "Subject identifiers requested by the RC serve only to identify the = RO in the context of the AS and can't be used as communication channels by t= he RC" - this sounds a bit naive, people will do that anyway. So why is this= a useful statement? (And similarly in 3.4) * 2.3: what's the benefit of including a URI (URL really) in "display"? Do = we really want the user (RO) to click links provided by the RC? * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that t= he cert contains the same public key as the cert? * 2.3, " the AS MUST ensure that the key used to sign the request... is ass= ociated with the instance identifier" - can we be much more specific here, e= .g. the instance_id MUST be byte-identical to the Common Name of the cert? T= his "association" is never clarified, either here or in Sec. 8. * 2.3.2: allowing to send the key in multiple formats virtually invites sec= urity vulnerabilities. Why is this a good thing? * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it he= re? Note that in Sec. 8.3 you are using the full certificate rather than the= fingerprint. * 2.3.2: why are we using raw PEM certificates instead of the JOSE represen= tation? * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose = to avoid displaying an arbitrary URI. RC developers must only assume that th= e "name" field will be displayed. * 2.3.4, "created just for this request" -> created just for this series of= requests. * 2.3.4: I suggest referring to RCs that present unknown keys as "anonymous= RC", and then in 2.4, say that the AS MUST NOT accept any assertions from a= n anonymous RC. * 2.4: IMO assertion validation is a MUST, and we should specify what we re= quire for every assertion type we allow. * 2.4: moreover, when possible, the AS MUST match the assertions to the pre= sented sub_id. It may be a hint, but you're not allowed to lie. * 2.4, "If the identified RQ does not match the RO present at the AS" - I t= hought there are cases where the RQ is different from the RO. Also, I am won= dering why this is a SHOULD, not a MUST. * 2.4.1 (but probably applicable to any references): what is the lifetime o= f the reference? As an RC, how long can I assume the user reference is still= valid? * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is i= t bundled here? * 2.5: the way "callback" is described here is as a capability, not an inte= raction mode. The example only strengthens this view, "callback" is a modifi= er of the "redirect" mode. * 2.5: "use code" -> user code. * 2.5.1: this unnecessary polymorphism IMO just complicates implementations= and prevents extensibility. Instead, I would suggest: redirect: {} redirect:{max_length: 255} redirect:{max_length: 255, callback: {...}} * 2.5.2: the "app" option is problematic, as you already note. The RC may n= ot even know if a given URL will result in an application launching. * 2.5.2: and shouldn't the RC include a list of supported applications? (Wh= ich would have lovely privacy implications.) * 2.5.3: there's a parenthetical discussion on whether the URL is unique. B= ut the nonce parameter implies that the "hash" parameter is unique per reque= st, making this discussion moot. * 2.5.3: even if we need a different kind of post-interaction "redirect", w= here the RC is not involved, there must be a way to ensure that the RC recei= ves positive (cryptographically protected) confirmation that the authorizati= on was successful. In other words, what we're discussing here is not an RC i= nteraction mode, it is something else, and should probably have a separate p= rotocol element to describe it. * 2.5.3: In the example for "interact" as an array (which I support), the s= econd "redirect" and "user_code" should be independent elements of the array= , not members of an object. This assumes they are truly independent interact= ion modes. * 2.5.3.1: what does "RQ is present on the request" mean? * 2.5.3.2: typo: HTTP the request. * 2.7: this seems to assume a short access token (which implies a bearer to= ken). What if we want to use longer self-contained access tokens containing = full keys? Should we have a separate "grant_id" value instead? * 2.8: another problem with this stanza is that the RC needs to know a prio= rity that the AS supports it. What happens if the AS doesn't? * 2.8: I suggest to move this section into a separate I-D, or at least a se= parate appendix. * 2.9: it makes sense to bundle extensions and the "capabilities" section i= nto one. * 2.9: The AS MUST ignore any unknown extension. * 3: it's confusing that we're using access_token for two different things.= Maybe we could change the RC/AS one to "as_access_token"? * 3.1: MAY vary *by* request. * 3.1: how is the client behavior "deterministic in all cases" - how does t= he RC know whether the AS allows continuation or only allows one request at = a time? * 3.2.1: the "value" of the access token is opaque in some cases (bearer to= ken) but not in others. * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be prin= table ASCII, 0x20

We haven=E2=80=99t discusse= d this process yet, and the default IETF process is, everything goes through= the mailing list.

 

IMO small things can be quickly cleaned up (fixed or rejecte= d), and we can open GH issues for bigger things.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Tom Jones <thomasclinganjones@gmail.com>
Date: Sunday, = October 18, 2020 at 22:47
To: Yaron Sheffer <yaronf.ietf@gmail.= com>
Cc: GNAP Mailing List <txauth@ietf.org>
Subjec= t: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half)

 

=

why are you doing this? Should these be issues now?<= br clear=3Dall>

Peace ..t= om

 

 

On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

<= blockquote style=3D'border:none;border-right:solid #CCCCCC 1.0pt;padding:0in 0= in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>

Hi Justin, all,=

 

The draft has undergone major change= s since we started the design team, so I spent some time reviewing it. I onl= y got as far as Sec. 3, and I fully intend to review the remainder of the do= cument. But I figured since I have so many comments, I might as well send ou= t what I have.

 

* General comment: we = have dozens, maybe hundreds of variants/options here. I think we need to def= ine a must-implement subset, or we will never reach interoperability.

* Abstract: the boilerplate text (MUST etc.) usually goes to the I= ntroduction, not the Abstract.

* 1. "The requesting par= ty operating the software" - I think these actions are typically perfor= med by the resource owner, who is not necessarily the requesting party.=

* RS, aka API: we are using the word "API" several tim= es in a more generic sense (management API, identity API), so maybe replace = with "RS, typically a protected API".

* 1.2, "= ;key" is a too generic term in the context of a security protocol. Can = we call it something more specific, maybe "holder identity key"?

* 1.3.1. "augmented with a hash of the security informat= ion" - this is too implementation-specific, suggest "is cryptograp= hically bound to the security information". In general, step (7) is way= too detailed, and verges on the normative.

* 1.3.2: it is u= nclear to me what the goal of the user-code interaction is, in other words w= hat is the threat model. If it's just "second factor, something you hav= e", then an OTP MFA device would be simpler and offer the same security= .

* 1.3.5 (4): Typically the access token would not be sent = once it is expired, right? Let's make the example more realistic.=

* 2: "OpenID Connect claims request" - why not "identit= y claims request" (which just happens to be similar to the OpenID reque= st)?

* Never liked the "dolphin" here... If this i= s listed under "actions", it should be a verb, e.g. "swim&quo= t;.

* 2.1: an array for a single AT vs. an object for multip= le ATs? This is extremely non-intuitive and probably ugly to code. Also, why= should (multiple) tokens be named if a single token doesn't have to, why no= t list them in an array instead?

* 2.1.1, "locations&qu= ot;: are these really URIs or just URLs? On the other hand, if these are URI= s, why do we need a separate "identifier"? There's too much semant= ic overlap between "type", "location" and "identifi= er" - specifying just "type" may be sufficient.

* 2.1.1: it's implied but should be spelled out that the semantics of thi= s example is the cross product of permissions: I am requesting to read and w= rite and "dolphin" both "metadata" and "images"= ;, and that applies to both "locations" - 12 different possible ac= tions.

* 2.1.2: I don't see the value of the notion of "= ;expansion". It is sufficient that the string is understood by the AS.<= o:p>

* 2.1.2, "in some situations the value is intended to b= e seen and understood be the RC developer" - shouldn't we require this = value to be always fully documented by the AS owner, so that the RC knows wh= at it is requesting?

* 2.1.4: why are flags represented as r= esources? The answer, "this is how OAuth 2 does it" is not great.<= o:p>

* "the each access tokens" -> each access token= .

* I suggest to extend the editor's note to clarify what is= the use case, so that the group can decide whether split tokens are indeed = necessary.

* Why is key binding of the access token even opt= ional?

* 2.2, "Subject identifiers requested by the RC = serve only to identify the RO in the context of the AS and can't be used as = communication channels by the RC" - this sounds a bit naive, people wil= l do that anyway. So why is this a useful statement? (And similarly in 3.4)<= o:p>

* 2.3: what's the benefit of including a URI (URL really) in= "display"? Do we really want the user (RO) to click links provide= d by the RC?

* 2.3: why are we sending a JWK *as well as* a = cert? Are we checking that the cert contains the same public key as the cert= ?

* 2.3, " the AS MUST ensure that the key used to sign= the request... is associated with the instance identifier" - can we be= much more specific here, e.g. the instance_id MUST be byte-identical to the= Common Name of the cert? This "association" is never clarified, e= ither here or in Sec. 8.

* 2.3.2: allowing to send the key i= n multiple formats virtually invites security vulnerabilities. Why is this a= good thing?

* 2.3.2: cert#256 is not a key, it's an identif= ier. Why do we include it here? Note that in Sec. 8.3 you are using the full= certificate rather than the fingerprint.

* 2.3.2: why are w= e using raw PEM certificates instead of the JOSE representation?<= /p>

* 2.3.3: For obvious security reasons, I suggest adding: The AS MAY cho= ose to avoid displaying an arbitrary URI. RC developers must only assume tha= t the "name" field will be displayed.

* 2.3.4, &qu= ot;created just for this request" -> created just for this series of= requests.

* 2.3.4: I suggest referring to RCs that present = unknown keys as "anonymous RC", and then in 2.4, say that the AS M= UST NOT accept any assertions from an anonymous RC.

* 2.4: I= MO assertion validation is a MUST, and we should specify what we require for= every assertion type we allow.

* 2.4: moreover, when possib= le, the AS MUST match the assertions to the presented sub_id. It may be a hi= nt, but you're not allowed to lie.

* 2.4, "If the ident= ified RQ does not match the RO present at the AS" - I thought there are= cases where the RQ is different from the RO. Also, I am wondering why this = is a SHOULD, not a MUST.

* 2.4.1 (but probably applicable to= any references): what is the lifetime of the reference? As an RC, how long = can I assume the user reference is still valid?

* 2.5: "= ;preferred_locales" is obviously not a mode of interaction. Why is it b= undled here?

* 2.5: the way "callback" is describe= d here is as a capability, not an interaction mode. The example only strengt= hens this view, "callback" is a modifier of the "redirect&quo= t; mode.

* 2.5: "use code" -> user code.

* 2.5.1: this unnecessary polymorphism IMO just complicates implem= entations and prevents extensibility. Instead, I would suggest:

redirect: {}

redirect:{max_length: 255}

= redirect:{max_length: 255, callback: {...}}

* 2.5.2: the &qu= ot;app" option is problematic, as you already note. The RC may not even= know if a given URL will result in an application launching.

=

* 2.5.2: and shouldn't the RC include a list of supported applications? (W= hich would have lovely privacy implications.)

* 2.5.3: there= 's a parenthetical discussion on whether the URL is unique. But the nonce pa= rameter implies that the "hash" parameter is unique per request, m= aking this discussion moot.

* 2.5.3: even if we need a diffe= rent kind of post-interaction "redirect", where the RC is not invo= lved, there must be a way to ensure that the RC receives positive (cryptogra= phically protected) confirmation that the authorization was successful. In o= ther words, what we're discussing here is not an RC interaction mode, it is = something else, and should probably have a separate protocol element to desc= ribe it.

* 2.5.3: In the example for "interact" as= an array (which I support), the second "redirect" and "user_= code" should be independent elements of the array, not members of an ob= ject. This assumes they are truly independent interaction modes.<= /p>

* 2.5.3.1: what does "= ;RQ is present on the request" mean?

* 2.5.3.2: typo: HTTP the request.

=

* 2.7: this seems to assume a short access token (which implies a bearer t= oken). What if we want to use longer self-contained access tokens containing= full keys? Should we have a separate "grant_id" value instead?

* 2.8: another problem with this stanza is that the RC needs t= o know a priority that the AS supports it. What happens if the AS doesn't?

* 2.8: I suggest to move this section into a separate I-D, or= at least a separate appendix.

* 2.9: it makes sense to bund= le extensions and the "capabilities" section into one.<= /p>

* 2.9: The AS MUST ignore any unknown extension.

* 3: i= t's confusing that we're using access_token for two different things. Maybe = we could change the RC/AS one to "as_access_token"?

=

* 3.1: MAY vary *by* request.

* 3.1: how is the client beh= avior "deterministic in all cases" - how does the RC know whether = the AS allows continuation or only allows one request at a time?<= /p>

* 3.2.1: the "value" of the access token is opaque in some ca= ses (bearer token) but not in others.

* 3.2.1: The ASCII res= triction on "value" is insufficient. Needs to be printable ASCII, = 0x20<v<=3D0x7f. And I'm not sure if this doesn't leave some characters t= hat still need to be escaped.

* 3.2.1: why is "expires_= in" optional? Typically access tokens are not revoked, and the RC needs= a way to manage their lifetime.

* 3.2.1: "resources&qu= ot; refers to this same section. Did you mean 2.1.2, or are we missing a sub= section describing resources/rights?

* 3.2.1: "key"= ;: another polymorphism alert!

* 3.2.1: the example at the b= ottom of the section talks about a way to present the token, I believe this = discussion is out of context here.

* 3.3: the AS knows now w= hich interaction modes are available. Why not pick just one for its response= , to simplify the protocol? As one example, the AS can then more easily deci= de on timeout behavior.

* 3.3.3: Suggest to add to the last = paragraph: If the RC does not receive a callback until an RC-determined time= out occurs, the RC MUST act as if the entire request failed.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >* 3.4: "updated_at": Unix time is nice, but for absolute time it'= s common to use ISO 8601 format.

* 3.6: YES, the "error= " element is exclusive!

* 3.6: in SecEvent we tried to = use RFC 7807 "problem details", I think it could work nicely here.=

* 10.4: "indicating that GNAP" - sentence is brok= en.

* This "speculative" access is not useful if t= he response is only a MAY. Why would the RC try it if it is unlikely to prov= ide useful information?

* 15: the BCP195 ref is broken - the= author names are missing (yes I am one of them...).

* Appen= dix D: can we name the first scenario, maybe "Simple API Access"?<= o:p>

--
TXAuth mailing list
<= a href=3D"mailto:TXAuth@ietf.org" target=3D"_blank">TXAuth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/txauth

--B_3685906823_1894089213-- From nobody Sun Oct 18 14:38:11 2020 Return-Path: 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 56F113A0DBD for ; Sun, 18 Oct 2020 14:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=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 (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 sx9kkFSfVvmQ for ; Sun, 18 Oct 2020 14:38:07 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 D151C3A0D9C for ; Sun, 18 Oct 2020 14:38:06 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id l4so8600938ota.7 for ; Sun, 18 Oct 2020 14:38:06 -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=GwJIFLWCF8Ny58fravNA+9db7+DHJS3UIJW7q1aNSzw=; b=f9i0DDbaCDwoZ0Vc7vdtqDT1AQ9gTG1P01eb3Vz55qKePue63fzhUGKVEhknHmgiUO MqNNvNgw6St8ii/9muJOnP4jgbLW/nfO2OcwW/C28uxRSFbzZNrOLyt2BzRH2zxkYx6i 3wXT7xfrYlJ4ChcmRYTuWW6hZ6g3dMsUJImx+1KtQL8hwXswd/WLoEhzEPh2RZkZ9zJA a2ZuVLFDda6q+BonEofagONfDgvUJeFbNrV29UuMSsZ4tIE/EwW/ReMuwqJJBe5YkkeN X747/r2E+ZIYunTOZt/1pHIjIuYLe8XmHin5FM7PJutsi45/4b9AaaIGDIRm9VPW9aZK 6qZA== 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=GwJIFLWCF8Ny58fravNA+9db7+DHJS3UIJW7q1aNSzw=; b=OKEpxl88Dds3vk6dJbDnyKC9kk4PUNwgB4FJ8KzLSdEyl44R8EuOkF05jBOMNfwE/c cl+Zwag9uc3p5gs6rXQ3zGS1ZkLI6CkL/Nu2F7ePmJqbBseVr6ShCF4bqU8N+7knSci/ nDl3T+kvh1Lbh+rLMvlNdrxjudMTGUI0HkJQpNMvdiGQBV18BwjEDjtVvQR8ZZrTI0Jb DInbsLlOKb/ub4duGtTDws5wyLFWC8RrY2gf/gF7aW0C8SJnyxyfUhq14HZRRFPX48Iy 1f6JPM1OBRkUCEscNJh49ip9jaJqEe2Off+bNpne1l8RpfPoiBhA7t1EFRxC9M6vsIjo 0KbA== X-Gm-Message-State: AOAM5311oJUkUWdW8M49cs5UKVYNKWHXcnRRIZP7J3XXh0Twl9TS8uVn canm+U6Y5fZ3TcA3+w2ac89Zr94WtuQKbIA5YeM= X-Google-Smtp-Source: ABdhPJyELqsU77Q/0vo3qx9OAoGMCngveM8DwmmWDXAEXI7OgPXpZC9Yi8AfRdReHIUrN1z42XxhLUAQdnJrE4v7Wv8= X-Received: by 2002:a9d:6005:: with SMTP id h5mr9417241otj.87.1603057085793; Sun, 18 Oct 2020 14:38:05 -0700 (PDT) MIME-Version: 1.0 References: <7B79DA52-C4CE-4033-961A-AB4E81248D83@gmail.com> In-Reply-To: <7B79DA52-C4CE-4033-961A-AB4E81248D83@gmail.com> From: Tom Jones Date: Sun, 18 Oct 2020 14:37:54 -0700 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000002749ab05b1f8d018" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 21:38:10 -0000 --0000000000002749ab05b1f8d018 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable then i guess we must address the entire email, which is not helpful. Here are at least a few of my thoughts. 1.2, "key" is a too generic term in the context of a security protocol. Can we call it something more specific, maybe "holder identity key"? >> that is not more specific. if you want to understand the source of the key then perhaps the entire jwk element needs to be augmented. 1.3.2: it is unclear to me what the goal of the user-code interaction is, in other words what is the threat model. If it's just "second factor, something you have", then an OTP MFA device would be simpler and offer the same security. >> first of all, you are wrong in your assessment, second that is not all that the user-code interaction supplies. 2.1.2: I don't see the value of the notion of "expansion". It is sufficient that the string is understood by the AS. >> I am already running into this as a problem with strings in OIDC. I believe we need a better way to expand strings into structures. I proposed the use of 3part jose structures as a solution. * 2.3: what's the benefit of including a URI (URL really) in "display"? Do we really want the user (RO) to click links provided by the RC? >> I hope you are not proposing that users actually see any of this? That would be grotesque. * 2.4: IMO assertion validation is a MUST, and we should specify what we require for every assertion type we allow. >> I plan on including assertions that do not need to be validated. I believe it is not up to the sender whether the receiver validates the assertion. In general I find that many of your comments are not trivial and need deeper analysis. Peace ..tom On Sun, Oct 18, 2020 at 1:00 PM Yaron Sheffer wrote= : > We haven=E2=80=99t discussed this process yet, and the default IETF proce= ss is, > everything goes through the mailing list. > > > > IMO small things can be quickly cleaned up (fixed or rejected), and we ca= n > open GH issues for bigger things. > > > > Thanks, > > Yaron > > > > *From: *Tom Jones > *Date: *Sunday, October 18, 2020 at 22:47 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > why are you doing this? Should these be issues now? > > Peace ..tom > > > > > > On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer > wrote: > > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, s= o > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I hav= e > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these action= s > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generi= c > sense (management API, identity API), so maybe replace with "RS, typicall= y > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is to= o > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verg= es > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not lis= t > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of thi= s > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to bot= h > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify th= e > RO in the context of the AS and can't be used as communication channels b= y > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather tha= n > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choos= e > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here = is > not an RC interaction mode, it is something else, and should probably hav= e > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if t= he > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000002749ab05b1f8d018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
then i guess we must address the=C2=A0entire email, which = is not helpful.=C2=A0 Here are at=C2=A0least a few of my thoughts.
1.2, "key" is a too generic term = in the context of a security protocol. Can we call it something more specif= ic, maybe "holder identity key"?
>> that is not more specific. if you want to und= erstand the source of the key then perhaps the entire jwk element needs to = be augmented.

1.3.2: it is unclear to me what the goal of the user-code interac= tion is, in other words what is the threat model. If it's just "se= cond factor, something you have", then an OTP MFA device would be simp= ler and offer the same security.

>> first of all, you are wro= ng in your assessment, second that is not all that the user-code interactio= n supplies.

2.1.2: I don't see the value of the notion of "expansion&quo= t;. It is sufficient that the string is understood by the AS.

>> I am already running into this as a problem with s= trings in OIDC. I believe we need a better way to expand strings into struc= tures.=C2=A0 I proposed the use of 3part jose structures=C2=A0as a solution= .
* 2.3: what's th= e benefit of including a URI (URL really) in "display"? Do we rea= lly want the user (RO) to click links provided by the RC?
= >> I hope you are not proposing t= hat users actually see any of this?=C2=A0 That would be grotesque.
* 2.4: IMO assertion validatio= n is a MUST, and we should specify what we require for every assertion type= we allow.
>> I = plan on including assertions that do not need to be validated. I believe it= is not up to the sender whether the receiver validates the assertion.

In general I find that many of your comment= s are not trivial and need deeper analysis.
Peace ..tom

<= br>
On Sun,= Oct 18, 2020 at 1:00 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

We haven=E2=80=99t discussed this process yet, and the defa= ult IETF process is, everything goes through the mailing list.

=C2=A0

= IMO small things can be quickly cleaned up (fixed or rejected), and we can = open GH issues for bigger things.

<= u>=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Tom Jones &l= t;thomasc= linganjones@gmail.com>
Date: Sunday, October 18, 2020 at 2= 2:47
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: GNAP Maili= ng List <txauth@iet= f.org>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-= protocol-00 (first half)

=C2=A0

why are y= ou doing this? Should these be issues now?
<= /p>

Peace ..tom

=

=C2=A0

=C2=A0

On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wro= te:

Hi Justin, all,

=C2=A0

The draft has undergone major changes s= ince we started the design team, so I spent some time reviewing it. I only = got as far as Sec. 3, and I fully intend to review the remainder of the doc= ument. But I figured since I have so many comments, I might as well send ou= t what I have.

=C2=A0=

* General comment: we have dozens, maybe hundred= s of variants/options here. I think we need to define a must-implement subs= et, or we will never reach interoperability.

* Abstract: the boilerplate text (MUST etc.) usually goes to the = Introduction, not the Abstract.

* 1= . "The requesting party operating the software" - I think these a= ctions are typically performed by the resource owner, who is not necessaril= y the requesting party.

* RS, aka A= PI: we are using the word "API" several times in a more generic s= ense (management API, identity API), so maybe replace with "RS, typica= lly a protected API".

* 1.2, &= quot;key" is a too generic term in the context of a security protocol.= Can we call it something more specific, maybe "holder identity key&qu= ot;?

* 1.3.1. "augmented with = a hash of the security information" - this is too implementation-speci= fic, suggest "is cryptographically bound to the security information&q= uot;. In general, step (7) is way too detailed, and verges on the normative= .

* 1.3.2: it is unclear to me what= the goal of the user-code interaction is, in other words what is the threa= t model. If it's just "second factor, something you have", th= en an OTP MFA device would be simpler and offer the same security.

* 1.3.5 (4): Typically the access token wou= ld not be sent once it is expired, right? Let's make the example more r= ealistic.

* 2: "OpenID Connect= claims request" - why not "identity claims request" (which = just happens to be similar to the OpenID request)?

* Never liked the "dolphin" here... If this is li= sted under "actions", it should be a verb, e.g. "swim".=

* 2.1: an array for a single AT vs= . an object for multiple ATs? This is extremely non-intuitive and probably = ugly to code. Also, why should (multiple) tokens be named if a single token= doesn't have to, why not list them in an array instead?<= /p>

* 2.1.1, "locations": are these really = URIs or just URLs? On the other hand, if these are URIs, why do we need a s= eparate "identifier"? There's too much semantic overlap betwe= en "type", "location" and "identifier" - spec= ifying just "type" may be sufficient.

* 2.1.1: it's implied but should be spelled out that the= semantics of this example is the cross product of permissions: I am reques= ting to read and write and "dolphin" both "metadata" an= d "images", and that applies to both "locations" - 12 d= ifferent possible actions.

* 2.1.2:= I don't see the value of the notion of "expansion". It is su= fficient that the string is understood by the AS.

* 2.1.2, "in some situations the value is intended to b= e seen and understood be the RC developer" - shouldn't we require = this value to be always fully documented by the AS owner, so that the RC kn= ows what it is requesting?

* 2.1.4:= why are flags represented as resources? The answer, "this is how OAut= h 2 does it" is not great.

* &= quot;the each access tokens" -> each access token.

* I suggest to extend the editor's note to clar= ify what is the use case, so that the group can decide whether split tokens= are indeed necessary.

* Why is key= binding of the access token even optional?

* 2.2, "Subject identifiers requested by the RC serve only to= identify the RO in the context of the AS and can't be used as communic= ation channels by the RC" - this sounds a bit naive, people will do th= at anyway. So why is this a useful statement? (And similarly in 3.4)=

* 2.3: what's the benefit of includin= g a URI (URL really) in "display"? Do we really want the user (RO= ) to click links provided by the RC?

* 2.3: why are we sending a JWK *as well as* a cert? Are we checking that= the cert contains the same public key as the cert?

* 2.3, " the AS MUST ensure that the key used to sign= the request... is associated with the instance identifier" - can we b= e much more specific here, e.g. the instance_id MUST be byte-identical to t= he Common Name of the cert? This "association" is never clarified= , either here or in Sec. 8.

* 2.3.2= : allowing to send the key in multiple formats virtually invites security v= ulnerabilities. Why is this a good thing?

* 2.3.2: cert#256 is not a key, it's an identifier. Why do we in= clude it here? Note that in Sec. 8.3 you are using the full certificate rat= her than the fingerprint.

* 2.3.2: = why are we using raw PEM certificates instead of the JOSE representation?

* 2.3.3: For obvious security reason= s, I suggest adding: The AS MAY choose to avoid displaying an arbitrary URI= . RC developers must only assume that the "name" field will be di= splayed.

* 2.3.4, "created jus= t for this request" -> created just for this series of requests.=

* 2.3.4: I suggest referring to RCs t= hat present unknown keys as "anonymous RC", and then in 2.4, say = that the AS MUST NOT accept any assertions from an anonymous RC.<= /u>

* 2.4: IMO assertion validation is a MUST, an= d we should specify what we require for every assertion type we allow.

* 2.4: moreover, when possible, the AS = MUST match the assertions to the presented sub_id. It may be a hint, but yo= u're not allowed to lie.

* 2.4,= "If the identified RQ does not match the RO present at the AS" -= I thought there are cases where the RQ is different from the RO. Also, I a= m wondering why this is a SHOULD, not a MUST.

* 2.4.1 (but probably applicable to any references): what is the= lifetime of the reference? As an RC, how long can I assume the user refere= nce is still valid?

* 2.5: "pr= eferred_locales" is obviously not a mode of interaction. Why is it bun= dled here?

* 2.5: the way "cal= lback" is described here is as a capability, not an interaction mode. = The example only strengthens this view, "callback" is a modifier = of the "redirect" mode.

*= 2.5: "use code" -> user code.

* 2.5.1: this unnecessary polymorphism IMO just complicates implem= entations and prevents extensibility. Instead, I would suggest:

redirect: {}

redirect:{max_length: 255}

r= edirect:{max_length: 255, callback: {...}}

* 2.5.2: the "app" option is problematic, as you already = note. The RC may not even know if a given URL will result in an application= launching.

* 2.5.2: and shouldn= 9;t the RC include a list of supported applications? (Which would have love= ly privacy implications.)

* 2.5.3: = there's a parenthetical discussion on whether the URL is unique. But th= e nonce parameter implies that the "hash" parameter is unique per= request, making this discussion moot.

* 2.5.3: even if we need a different kind of post-interaction "red= irect", where the RC is not involved, there must be a way to ensure th= at the RC receives positive (cryptographically protected) confirmation that= the authorization was successful. In other words, what we're discussin= g here is not an RC interaction mode, it is something else, and should prob= ably have a separate protocol element to describe it.

* 2.5.3: In the example for "interact" as an a= rray (which I support), the second "redirect" and "user_code= " should be independent elements of the array, not members of an objec= t. This assumes they are truly independent interaction modes.=

* 2= .5.3.1: what does "RQ is present on the request" mean?=

* 2.5.3.2: typo: HTTP the request.

* 2.7: this seems to assume a short access token (which implies a b= earer token). What if we want to use longer self-contained access tokens co= ntaining full keys? Should we have a separate "grant_id" value in= stead?

* 2.8: another problem with = this stanza is that the RC needs to know a priority that the AS supports it= . What happens if the AS doesn't?

* 2.8: I suggest to move this section into a separate I-D, or at least a= separate appendix.

* 2.9: it makes= sense to bundle extensions and the "capabilities" section into o= ne.

* 2.9: The AS MUST ignore any u= nknown extension.

* 3: it's con= fusing that we're using access_token for two different things. Maybe we= could change the RC/AS one to "as_access_token"?

* 3.1: MAY vary *by* request.

* 3.1: how is the client behavior "deterministic i= n all cases" - how does the RC know whether the AS allows continuation= or only allows one request at a time?

* 3.2.1: the "value" of the access token is opaque in some ca= ses (bearer token) but not in others.

* 3.2.1: The ASCII restriction on "value" is insufficient. Nee= ds to be printable ASCII, 0x20<v<=3D0x7f. And I'm not sure if thi= s doesn't leave some characters that still need to be escaped.

* 3.2.1: why is "expires_in" opti= onal? Typically access tokens are not revoked, and the RC needs a way to ma= nage their lifetime.

* 3.2.1: "= ;resources" refers to this same section. Did you mean 2.1.2, or are we= missing a subsection describing resources/rights?

* 3.2.1: "key": another polymorphism alert!

* 3.2.1: the example at the bottom of th= e section talks about a way to present the token, I believe this discussion= is out of context here.

* 3.3: the= AS knows now which interaction modes are available. Why not pick just one = for its response, to simplify the protocol? As one example, the AS can then= more easily decide on timeout behavior.

* 3.3.3: Suggest to add to the last paragraph: If the RC does not rec= eive a callback until an RC-determined timeout occurs, the RC MUST act as i= f the entire request failed.

* 3.4:= "updated_at": Unix time is nice, but for absolute time it's = common to use ISO 8601 format.

* 3.= 6: YES, the "error" element is exclusive!

* 3.6: in SecEvent we tried to use RFC 7807 "problem = details", I think it could work nicely here.

* 10.4: "indicating that GNAP" - sentence is broke= n.

* This "speculative" a= ccess is not useful if the response is only a MAY. Why would the RC try it = if it is unlikely to provide useful information?

* 15: the BCP195 ref is broken - the author names are missin= g (yes I am one of them...).

* Appe= ndix D: can we name the first scenario, maybe "Simple API Access"= ?

--
TXAuth mailing= list
TXAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/txauth<= /p>

--0000000000002749ab05b1f8d018-- From nobody Mon Oct 19 00:08:06 2020 Return-Path: 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 54AD23A1439 for ; Mon, 19 Oct 2020 00:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=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 (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 37J2aN0gmVko for ; Mon, 19 Oct 2020 00:08:01 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 71AC33A13A8 for ; Mon, 19 Oct 2020 00:08:01 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id y20so11790058iod.5 for ; Mon, 19 Oct 2020 00:08:01 -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=k60UjyHaAfiMdkDD30TcGEC+XbnpGgV2JuYfS4dV6vA=; b=TDTWEww+rAuseJV2Xj+wBlrauI3GKkSDSflhah7FIHbNeHyngShdTyRH9WSMaKoeOc wGEunm5/uSa+o6Z3QappvYpQDrdEDBYEKmshG5FxJ9zARDbksyRUVdzuDZR80e0KoNol qLJd2dZlULInp9TVJKvNe6MBlV9Rp5Glr8/CebwHdT23tKS4dxPzee/89BOIO8gA6wiL +hwL86+zGnUTFfaSIgmHcDhjOfWYTWCU2GzZDMnS+LCwWpb+0AOHkuHhL1PMQAZcHTDQ BHTPd5gj4myNT0ldkmAM/jLsPQ2iXvISX1/XZty2GJU4ZHReZQPabGXv+nhkHEDNGlDf dTdw== 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=k60UjyHaAfiMdkDD30TcGEC+XbnpGgV2JuYfS4dV6vA=; b=fIqfTWyOrwkoxnounAB52Z1arndPUpSv890qH6rlhYCSU4lwV3iDamWhqZ2uWurLx0 Doq37IW5ECrLaHcJc92t9ll9e0ezywcuePPi9WGRBAroY/BJRYPkjcLWLTpq5iySYW8l T+jQLL3eSial0HqNrh44D2c12C74gWi0T8rf9X5MAdBD5J7/AQ8IrqZIX2OM0RiXXzQ9 s3jSJOjbILRzDpTILLrd+no4qYbqWn20f4JDEN8FeGOHNe2EvfTk1AhcpeeOAfosBitG 2kyLNPK3N3aRp8Y3RVwPSRQtQRvLGXn44Ycn9dFaIX2oxtIh8I414qOTUg6joySktUR/ 0ZFQ== X-Gm-Message-State: AOAM531qdChNzpW8837lZ+iSAiLXwFWpgvWVhXSIP1r9paSgzcMpOoHh yvFjxJqfzaAzQJVUZjiDxnMuRnjs76Ub2R/61ik= X-Google-Smtp-Source: ABdhPJySRJX4wp4nMMjCeTelFhJXClqYEymNaSxXN+xQSeHc+9cS+YzwxSpDWdcyP6PFYR8tEP2mpqIQgkrq9e2RpNc= X-Received: by 2002:a6b:dc15:: with SMTP id s21mr9474227ioc.162.1603091280679; Mon, 19 Oct 2020 00:08:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 19 Oct 2020 09:07:49 +0200 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000053d76505b200c6bd" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:08:04 -0000 --00000000000053d76505b200c6bd Content-Type: text/plain; charset="UTF-8" Hi, These are very useful feedback. We do need to take the time to read again the entire document, as it was patched up to the last minute. There are many places where several options are considered (some of which might need further explanation, from some of the questions I read). The objective was to openly expose some design choices for the group to consider, especially when it was new to the spec or when there was no consensus. And then decide what to keep with the group. It will be worth investigating every comment. Considering their number, I'm just wondering if the mailing list is the best place to follow up the details. Wouldn't issues on github be better suited for that task? (as the document source will be on github anyway). Cheers Fabien On Sun, Oct 18, 2020 at 9:44 PM Yaron Sheffer wrote: > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, so > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I have > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these actions > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generic > sense (management API, identity API), so maybe replace with "RS, typically > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is too > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verges > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer the > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not list > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of this > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to both > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify the > RO in the context of the AS and can't be used as communication channels by > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? Do > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of the > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather than > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here is > not an RC interaction mode, it is something else, and should probably have > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if the > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000053d76505b200c6bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

These are ve= ry useful feedback. We do need to take the time to read again the entire do= cument, as it was patched up to the last minute.

T= here are many places where several options are considered (some of which mi= ght need further explanation, from some of the questions I read). The objec= tive was to openly expose some design choices for the group to consider, es= pecially when it was new to the spec or when there was no consensus. And th= en decide what to keep with the=C2=A0group.=C2=A0

= It will be worth investigating every comment. Considering their=C2=A0number= , I'm just wondering if the mailing list is the best place to follow up= the details. Wouldn't issues on github be better suited for that task?= (as the document source will be on github anyway).=C2=A0

Cheers
Fabien

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 18, 2020 at 9:44 PM Yaron = Sheffer <yaronf.ietf@gmail.com<= /a>> wrote:
<= div lang=3D"EN-US" style=3D"overflow-wrap: break-word;">

Hi Justin, all,

=C2=A0

The draft has undergone major= changes since we started the design team, so I spent some time reviewing i= t. I only got as far as Sec. 3, and I fully intend to review the remainder = of the document. But I figured since I have so many comments, I might as we= ll send out what I have.

=C2=A0

* General comment: we have dozens, ma= ybe hundreds of variants/options here. I think we need to define a must-imp= lement subset, or we will never reach interoperability.

* Abstract: the = boilerplate text (MUST etc.) usually goes to the Introduction, not the Abst= ract.

* 1. "The requesting party operating the software" - I t= hink these actions are typically performed by the resource owner, who is no= t necessarily the requesting party.

* RS, aka API: we are using the word= "API" several times in a more generic sense (management API, ide= ntity API), so maybe replace with "RS, typically a protected API"= .

* 1.2, "key" is a too generic term in the context of a secur= ity protocol. Can we call it something more specific, maybe "holder id= entity key"?

* 1.3.1. "augmented with a hash of the security i= nformation" - this is too implementation-specific, suggest "is cr= yptographically bound to the security information". In general, step (= 7) is way too detailed, and verges on the normative.

* 1.3.2: it is uncl= ear to me what the goal of the user-code interaction is, in other words wha= t is the threat model. If it's just "second factor, something you = have", then an OTP MFA device would be simpler and offer the same secu= rity.

* 1.3.5 (4): Typically the access token would not be sent once it = is expired, right? Let's make the example more realistic.=

* 2: "= ;OpenID Connect claims request" - why not "identity claims reques= t" (which just happens to be similar to the OpenID request)?=

* Neve= r liked the "dolphin" here... If this is listed under "actio= ns", it should be a verb, e.g. "swim".<= /p>

* 2.1: an array fo= r a single AT vs. an object for multiple ATs? This is extremely non-intuiti= ve and probably ugly to code. Also, why should (multiple) tokens be named i= f a single token doesn't have to, why not list them in an array instead= ?

* 2.1.1, "locations": are these really URIs or just URLs? On= the other hand, if these are URIs, why do we need a separate "identif= ier"? There's too much semantic overlap between "type", = "location" and "identifier" - specifying just "typ= e" may be sufficient.

<= span style=3D"font-size:11pt">* 2.1.1: it's implied but should be spell= ed out that the semantics of this example is the cross product of permissio= ns: I am requesting to read and write and "dolphin" both "me= tadata" and "images", and that applies to both "locatio= ns" - 12 different possible actions.

* 2.1.2: I don't see the = value of the notion of "expansion". It is sufficient that the str= ing is understood by the AS.

* 2.1.2, "in some situations the value= is intended to be seen and understood be the RC developer" - shouldn&= #39;t we require this value to be always fully documented by the AS owner, = so that the RC knows what it is requesting?

* 2.1.4: why are flags repre= sented as resources? The answer, "this is how OAuth 2 does it" is= not great.

* "the each access tokens" -> each access token= .

* I suggest to extend the editor's note to clarify what is the use= case, so that the group can decide whether split tokens are indeed necessa= ry.

* Why is key binding of the access token even optional?

* 2.2, &q= uot;Subject identifiers requested by the RC serve only to identify the RO i= n the context of the AS and can't be used as communication channels by = the RC" - this sounds a bit naive, people will do that anyway. So why = is this a useful statement? (And similarly in 3.4)

=

* 2.3: what's the= benefit of including a URI (URL really) in "display"? Do we real= ly want the user (RO) to click links provided by the RC?

* 2.3: why are = we sending a JWK *as well as* a cert? Are we checking that the cert contain= s the same public key as the cert?

* 2.3, " the AS MUST ensure that= the key used to sign the request... is associated with the instance identi= fier" - can we be much more specific here, e.g. the instance_id MUST b= e byte-identical to the Common Name of the cert? This "association&quo= t; is never clarified, either here or in Sec. 8.

* 2.3.2: allowing to se= nd the key in multiple formats virtually invites security vulnerabilities. = Why is this a good thing?

* 2.3.2: cert#256 is not a key, it's an id= entifier. Why do we include it here? Note that in Sec. 8.3 you are using th= e full certificate rather than the fingerprint.

* 2.3.2: why are we usin= g raw PEM certificates instead of the JOSE representation?

* 2.3.3: For = obvious security reasons, I suggest adding: The AS MAY choose to avoid disp= laying an arbitrary URI. RC developers must only assume that the "name= " field will be displayed.

* 2.3.4, "created just for this req= uest" -> created just for this series of requests.

* 2.3.4: I su= ggest referring to RCs that present unknown keys as "anonymous RC"= ;, and then in 2.4, say that the AS MUST NOT accept any assertions from an = anonymous RC.

* 2.4: IMO assertion validation is a MUST, and we should s= pecify what we require for every assertion type we allow.

* 2.4: moreove= r, when possible, the AS MUST match the assertions to the presented sub_id.= It may be a hint, but you're not allowed to lie.<= /p>

* 2.4, "If th= e identified RQ does not match the RO present at the AS" - I thought t= here are cases where the RQ is different from the RO. Also, I am wondering = why this is a SHOULD, not a MUST.

* 2.4.1 (but probably applicable to an= y references): what is the lifetime of the reference? As an RC, how long ca= n I assume the user reference is still valid?

* 2.5: "preferred_loc= ales" is obviously not a mode of interaction. Why is it bundled here?<= u>

* 2.5: the way "callback" is described here is as a capability= , not an interaction mode. The example only strengthens this view, "ca= llback" is a modifier of the "redirect" mode.<= /span>

* 2.5: &quo= t;use code" -> user code.

* 2.5.1: this unnecessary polymorphism= IMO just complicates implementations and prevents extensibility. Instead, = I would suggest:

redirect: {}

redirect:{max_length: 255}

redirect:= {max_length: 255, callback: {...}}

* 2.5.2: the "app" option i= s problematic, as you already note. The RC may not even know if a given URL= will result in an application launching.

* 2.5.2: and shouldn't th= e RC include a list of supported applications? (Which would have lovely pri= vacy implications.)

* 2.5.3: there's a parenthetical discussion on w= hether the URL is unique. But the nonce parameter implies that the "ha= sh" parameter is unique per request, making this discussion moot.

*= 2.5.3: even if we need a different kind of post-interaction "redirect= ", where the RC is not involved, there must be a way to ensure that th= e RC receives positive (cryptographically protected) confirmation that the = authorization was successful. In other words, what we're discussing her= e is not an RC interaction mode, it is something else, and should probably = have a separate protocol element to describe it.

* 2.5.3: In the example= for "interact" as an array (which I support), the second "r= edirect" and "user_code" should be independent elements of t= he array, not members of an object. This assumes they are truly independent= interaction modes.

* 2.5.3= .1: what does "RQ is present on the request" mean?<= /u>

* 2.5.3.2: typo: HTTP the request= .

* 2.7: this seems to assume a short access token (which implies a bear= er token). What if we want to use longer self-contained access tokens conta= ining full keys? Should we have a separate "grant_id" value inste= ad?

* 2.8: another problem with this stanza is that the RC needs to know= a priority that the AS supports it. What happens if the AS doesn't?=

* 2.8: I suggest to move this section into a separate I-D, or at least a s= eparate appendix.

* 2.9: it makes sense to bundle extensions and the &qu= ot;capabilities" section into one.

* 2.9: The AS MUST ignore any un= known extension.

* 3: it's confusing that we're using access_tok= en for two different things. Maybe we could change the RC/AS one to "a= s_access_token"?

* 3.1: MAY vary *by* request.=

* 3.1: how is the= client behavior "deterministic in all cases" - how does the RC k= now whether the AS allows continuation or only allows one request at a time= ?

* 3.2.1: the "value" of the access token is opaque in some c= ases (bearer token) but not in others.

* 3.2.1: The ASCII restriction on= "value" is insufficient. Needs to be printable ASCII, 0x20<v&= lt;=3D0x7f. And I'm not sure if this doesn't leave some characters = that still need to be escaped.

* 3.2.1: why is "expires_in" op= tional? Typically access tokens are not revoked, and the RC needs a way to = manage their lifetime.

* 3.2.1: "resources" refers to this sam= e section. Did you mean 2.1.2, or are we missing a subsection describing re= sources/rights?

* 3.2.1: "key": another polymorphism alert!

* 3.2.1: the example at the bottom of the section talks about a way to pr= esent the token, I believe this discussion is out of context here.

* 3.3= : the AS knows now which interaction modes are available. Why not pick just= one for its response, to simplify the protocol? As one example, the AS can= then more easily decide on timeout behavior.

* 3.3.3: Suggest to add to= the last paragraph: If the RC does not receive a callback until an RC-dete= rmined timeout occurs, the RC MUST act as if the entire request failed.<= /u>

= * 3.4: "updated_at": Unix time is nice, but for absolute time it&= #39;s common to use ISO 8601 format.

* 3.6: YES, the "error" e= lement is exclusive!

* 3.6: in SecEvent we tried to use RFC 7807 "p= roblem details", I think it could work nicely here.

* 10.4: "i= ndicating that GNAP" - sentence is broken.

* This "speculative= " access is not useful if the response is only a MAY. Why would the RC= try it if it is unlikely to provide useful information?

* 15: the BCP19= 5 ref is broken - the author names are missing (yes I am one of them...).

* Appendix D: can we name the first scenario, maybe "Simple API Acce= ss"?

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000053d76505b200c6bd-- From nobody Mon Oct 19 02:47:22 2020 Return-Path: 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 EE3053A098B for ; Mon, 19 Oct 2020 02:47:20 -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=[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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 udKffUKSTJMz for ; Mon, 19 Oct 2020 02:47:18 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 BD6273A097E for ; Mon, 19 Oct 2020 02:47:17 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id h7so10653708wre.4 for ; Mon, 19 Oct 2020 02:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=cKsL+B8rFv55aT8Kk+W5jEqfmVASWOtea0E6cKrdV6U=; b=HsjoZGVyjFDcXbXR0l1aS29CQZfi3mHWy0bBg3+fapYxR4UOuewyuWB88pO7vXVx80 jbh1A4jzBT2Do+7ONU8bUF821yNKqVMWNKYHafV3R88zMPjqKFvJbt8UGfkYHMQNT/wT 0grbJybN7gAF24mwKuo/AXI1QCbIujtuRxM4QP6A9jhXJb0OrNs2890Nfwti8/fA23x2 Edu/2s4gV8nvC6WSX0rb37WDQXGi0XotRLezkVTgeIDfQOxxNK3AWGf5QQ6S2QrLvg6v qoFdpn4eYl91yEqgl8Ef9b6o3kxlRfSqktyLnR0q0ZCazK6yXEQSMgZWOZo18CemyJKu eXCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=cKsL+B8rFv55aT8Kk+W5jEqfmVASWOtea0E6cKrdV6U=; b=sFEE1CFGsLalGu+v1BXpc2/eVdYKqEs6wzzo5AypS8Id3F3ahpqDnU/tDIa/Gpv9VV ReuRShay2FrSNhbMoNymc+5ycbvklyLz73qu/Mfg8u4i7aFtXqcUTpy3iSzJuTgWftBr zbYphKfxaBWsDR4Um46akJ/5XDiB73Y1tmSSMJgkO5oDLrkXm+Kyu1VoC6kY6qOiVQ3L bN2GIKGAuvHF8G7VNzZCpaiQlsZ4RY3zDBBeSDD3NY7RMKVveMAEckljuDxjauM9wBWk cq1gmEvJ3K4hBaVP0wfrU9XfsjtFhx6kOaVxX+8TZap6tQwEVc5A3yTfuEfqg23T7Cc6 /qig== X-Gm-Message-State: AOAM533noYa3v77cQftOPIuuoPvCfvwWzeh7V3xVLAtl2RwKJDcnZWpu cDn0aTdofuqeLQTab8wmRJw= X-Google-Smtp-Source: ABdhPJwyawFzte6GJgB3yS6nYA/Jnf99BLFMkFF4nZu13CwNwwc6IXDY4D5Ph1oK7y9BEeOilNO6fw== X-Received: by 2002:adf:8562:: with SMTP id 89mr18386747wrh.214.1603100836170; Mon, 19 Oct 2020 02:47:16 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id v11sm14723483wml.26.2020.10.19.02.47.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 02:47:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Mon, 19 Oct 2020 12:47:13 +0300 From: Yaron Sheffer To: Fabien Imbault CC: GNAP Mailing List Message-ID: <36B6ACBF-1FBD-4A77-8875-B080242FED67@gmail.com> Thread-Topic: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685956434_621808930" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:47:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685956434_621808930 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 I think we all have a bad experience with huge issue backlogs, which is one= reason why creating issues for all these comments would be a pain. =20 I would suggest that the editor(s) should address all the simple issues (th= ose where the text can be easily fixed or clarified, or those where I clearl= y don=E2=80=99t know what I=E2=80=99m talking about). Then I will open issues for the re= maining ones. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Fabien Imbault Date: Monday, October 19, 2020 at 10:08 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) =20 Hi,=20 =20 These are very useful feedback. We do need to take the time to read again t= he entire document, as it was patched up to the last minute. =20 There are many places where several options are considered (some of which m= ight need further explanation, from some of the questions I read). The objec= tive was to openly expose some design choices for the group to consider, esp= ecially when it was new to the spec or when there was no consensus. And then= decide what to keep with the group.=20 =20 It will be worth investigating every comment. Considering their number, I'm= just wondering if the mailing list is the best place to follow up the detai= ls. Wouldn't issues on github be better suited for that task? (as the docume= nt source will be on github anyway).=20 =20 Cheers Fabien =20 On Sun, Oct 18, 2020 at 9:44 PM Yaron Sheffer wrote= : Hi Justin, all, =20 The draft has undergone major changes since we started the design team, so = I spent some time reviewing it. I only got as far as Sec. 3, and I fully int= end to review the remainder of the document. But I figured since I have so m= any comments, I might as well send out what I have. =20 * General comment: we have dozens, maybe hundreds of variants/options here.= I think we need to define a must-implement subset, or we will never reach i= nteroperability. * Abstract: the boilerplate text (MUST etc.) usually goes to the Introducti= on, not the Abstract. * 1. "The requesting party operating the software" - I think these actions = are typically performed by the resource owner, who is not necessarily the re= questing party. * RS, aka API: we are using the word "API" several times in a more generic = sense (management API, identity API), so maybe replace with "RS, typically a= protected API". * 1.2, "key" is a too generic term in the context of a security protocol. C= an we call it something more specific, maybe "holder identity key"? * 1.3.1. "augmented with a hash of the security information" - this is too = implementation-specific, suggest "is cryptographically bound to the security= information". In general, step (7) is way too detailed, and verges on the n= ormative. * 1.3.2: it is unclear to me what the goal of the user-code interaction is,= in other words what is the threat model. If it's just "second factor, somet= hing you have", then an OTP MFA device would be simpler and offer the same s= ecurity. * 1.3.5 (4): Typically the access token would not be sent once it is expire= d, right? Let's make the example more realistic. * 2: "OpenID Connect claims request" - why not "identity claims request" (w= hich just happens to be similar to the OpenID request)? * Never liked the "dolphin" here... If this is listed under "actions", it s= hould be a verb, e.g. "swim". * 2.1: an array for a single AT vs. an object for multiple ATs? This is ext= remely non-intuitive and probably ugly to code. Also, why should (multiple) = tokens be named if a single token doesn't have to, why not list them in an a= rray instead? * 2.1.1, "locations": are these really URIs or just URLs? On the other hand= , if these are URIs, why do we need a separate "identifier"? There's too muc= h semantic overlap between "type", "location" and "identifier" - specifying = just "type" may be sufficient. * 2.1.1: it's implied but should be spelled out that the semantics of this = example is the cross product of permissions: I am requesting to read and wri= te and "dolphin" both "metadata" and "images", and that applies to both "loc= ations" - 12 different possible actions. * 2.1.2: I don't see the value of the notion of "expansion". It is sufficie= nt that the string is understood by the AS. * 2.1.2, "in some situations the value is intended to be seen and understoo= d be the RC developer" - shouldn't we require this value to be always fully = documented by the AS owner, so that the RC knows what it is requesting? * 2.1.4: why are flags represented as resources? The answer, "this is how O= Auth 2 does it" is not great. * "the each access tokens" -> each access token. * I suggest to extend the editor's note to clarify what is the use case, so= that the group can decide whether split tokens are indeed necessary. * Why is key binding of the access token even optional? * 2.2, "Subject identifiers requested by the RC serve only to identify the = RO in the context of the AS and can't be used as communication channels by t= he RC" - this sounds a bit naive, people will do that anyway. So why is this= a useful statement? (And similarly in 3.4) * 2.3: what's the benefit of including a URI (URL really) in "display"? Do = we really want the user (RO) to click links provided by the RC? * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that t= he cert contains the same public key as the cert? * 2.3, " the AS MUST ensure that the key used to sign the request... is ass= ociated with the instance identifier" - can we be much more specific here, e= .g. the instance_id MUST be byte-identical to the Common Name of the cert? T= his "association" is never clarified, either here or in Sec. 8. * 2.3.2: allowing to send the key in multiple formats virtually invites sec= urity vulnerabilities. Why is this a good thing? * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it he= re? Note that in Sec. 8.3 you are using the full certificate rather than the= fingerprint. * 2.3.2: why are we using raw PEM certificates instead of the JOSE represen= tation? * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose = to avoid displaying an arbitrary URI. RC developers must only assume that th= e "name" field will be displayed. * 2.3.4, "created just for this request" -> created just for this series of= requests. * 2.3.4: I suggest referring to RCs that present unknown keys as "anonymous= RC", and then in 2.4, say that the AS MUST NOT accept any assertions from a= n anonymous RC. * 2.4: IMO assertion validation is a MUST, and we should specify what we re= quire for every assertion type we allow. * 2.4: moreover, when possible, the AS MUST match the assertions to the pre= sented sub_id. It may be a hint, but you're not allowed to lie. * 2.4, "If the identified RQ does not match the RO present at the AS" - I t= hought there are cases where the RQ is different from the RO. Also, I am won= dering why this is a SHOULD, not a MUST. * 2.4.1 (but probably applicable to any references): what is the lifetime o= f the reference? As an RC, how long can I assume the user reference is still= valid? * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is i= t bundled here? * 2.5: the way "callback" is described here is as a capability, not an inte= raction mode. The example only strengthens this view, "callback" is a modifi= er of the "redirect" mode. * 2.5: "use code" -> user code. * 2.5.1: this unnecessary polymorphism IMO just complicates implementations= and prevents extensibility. Instead, I would suggest: redirect: {} redirect:{max_length: 255} redirect:{max_length: 255, callback: {...}} * 2.5.2: the "app" option is problematic, as you already note. The RC may n= ot even know if a given URL will result in an application launching. * 2.5.2: and shouldn't the RC include a list of supported applications? (Wh= ich would have lovely privacy implications.) * 2.5.3: there's a parenthetical discussion on whether the URL is unique. B= ut the nonce parameter implies that the "hash" parameter is unique per reque= st, making this discussion moot. * 2.5.3: even if we need a different kind of post-interaction "redirect", w= here the RC is not involved, there must be a way to ensure that the RC recei= ves positive (cryptographically protected) confirmation that the authorizati= on was successful. In other words, what we're discussing here is not an RC i= nteraction mode, it is something else, and should probably have a separate p= rotocol element to describe it. * 2.5.3: In the example for "interact" as an array (which I support), the s= econd "redirect" and "user_code" should be independent elements of the array= , not members of an object. This assumes they are truly independent interact= ion modes. * 2.5.3.1: what does "RQ is present on the request" mean? * 2.5.3.2: typo: HTTP the request. * 2.7: this seems to assume a short access token (which implies a bearer to= ken). What if we want to use longer self-contained access tokens containing = full keys? Should we have a separate "grant_id" value instead? * 2.8: another problem with this stanza is that the RC needs to know a prio= rity that the AS supports it. What happens if the AS doesn't? * 2.8: I suggest to move this section into a separate I-D, or at least a se= parate appendix. * 2.9: it makes sense to bundle extensions and the "capabilities" section i= nto one. * 2.9: The AS MUST ignore any unknown extension. * 3: it's confusing that we're using access_token for two different things.= Maybe we could change the RC/AS one to "as_access_token"? * 3.1: MAY vary *by* request. * 3.1: how is the client behavior "deterministic in all cases" - how does t= he RC know whether the AS allows continuation or only allows one request at = a time? * 3.2.1: the "value" of the access token is opaque in some cases (bearer to= ken) but not in others. * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be prin= table ASCII, 0x20

Hi Fabien,=

 

I think we al= l have a bad experience with huge issue backlogs, which is one reason why cr= eating issues for all these comments would be a pain.

 

I would suggest that the = editor(s) should address all the simple issues (those where the text can be = easily fixed or clarified, or those where I clearly don=E2=80=99t know what I=E2=80=99m = talking about). Then I will open issues for the remaining ones.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Fabien Imbault <fabien.imbault@gmail.com>
Da= te: Monday, October 19, 2020 at 10:08
To: Yaron Sheffer <ya= ronf.ietf@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org&= gt;
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00= (first half)

 =

Hi, 

 

These ar= e very useful feedback. We do need to take the time to read again the entire= document, as it was patched up to the last minute.

 

There= are many places where several options are considered (some of which might n= eed further explanation, from some of the questions I read). The objective w= as to openly expose some design choices for the group to consider, especiall= y when it was new to the spec or when there was no consensus. And then decid= e what to keep with the group. 

 

It will be wort= h investigating every comment. Considering their number, I'm just wonde= ring if the mailing list is the best place to follow up the details. Wouldn'= t issues on github be better suited for that task? (as the document source w= ill be on github anyway). 

=  

Cheers

Fabien

 

On Sun, Oct 18, 2020 at = 9:44 PM Yaron Sheffer <yaronf.ietf= @gmail.com> wrote:

Hi Justin, all,

 

The draft has undergone major changes since we started the design = team, so I spent some time reviewing it. I only got as far as Sec. 3, and I = fully intend to review the remainder of the document. But I figured since I = have so many comments, I might as well send out what I have.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= > 

* General comment: we have dozens, maybe hundreds of= variants/options here. I think we need to define a must-implement subset, o= r we will never reach interoperability.

* Abstract: the boil= erplate text (MUST etc.) usually goes to the Introduction, not the Abstract.=

* 1. "The requesting party operating the software"= ; - I think these actions are typically performed by the resource owner, who= is not necessarily the requesting party.

* RS, aka API: we = are using the word "API" several times in a more generic sense (ma= nagement API, identity API), so maybe replace with "RS, typically a pro= tected API".

* 1.2, "key" is a too generic te= rm in the context of a security protocol. Can we call it something more spec= ific, maybe "holder identity key"?

* 1.3.1. "= augmented with a hash of the security information" - this is too implem= entation-specific, suggest "is cryptographically bound to the security = information". In general, step (7) is way too detailed, and verges on t= he normative.

* 1.3.2: it is unclear to me what the goal of = the user-code interaction is, in other words what is the threat model. If it= 's just "second factor, something you have", then an OTP MFA devic= e would be simpler and offer the same security.

* 1.3.5 (4):= Typically the access token would not be sent once it is expired, right? Let= 's make the example more realistic.

* 2: "OpenID Connec= t claims request" - why not "identity claims request" (which = just happens to be similar to the OpenID request)?

* Never l= iked the "dolphin" here... If this is listed under "actions&q= uot;, it should be a verb, e.g. "swim".

* 2.1: an = array for a single AT vs. an object for multiple ATs? This is extremely non-= intuitive and probably ugly to code. Also, why should (multiple) tokens be n= amed if a single token doesn't have to, why not list them in an array instea= d?

* 2.1.1, "locations": are these really URIs or = just URLs? On the other hand, if these are URIs, why do we need a separate &= quot;identifier"? There's too much semantic overlap between "type&= quot;, "location" and "identifier" - specifying just &qu= ot;type" may be sufficient.

* 2.1.1: it's implied but s= hould be spelled out that the semantics of this example is the cross product= of permissions: I am requesting to read and write and "dolphin" b= oth "metadata" and "images", and that applies to both &q= uot;locations" - 12 different possible actions.

* 2.1.2= : I don't see the value of the notion of "expansion". It is suffic= ient that the string is understood by the AS.

* 2.1.2, "= ;in some situations the value is intended to be seen and understood be the R= C developer" - shouldn't we require this value to be always fully docum= ented by the AS owner, so that the RC knows what it is requesting?

* 2.1.4: why are flags represented as resources? The answer, "th= is is how OAuth 2 does it" is not great.

* "the ea= ch access tokens" -> each access token.

* I suggest = to extend the editor's note to clarify what is the use case, so that the gro= up can decide whether split tokens are indeed necessary.

* W= hy is key binding of the access token even optional?

* 2.2, = "Subject identifiers requested by the RC serve only to identify the RO = in the context of the AS and can't be used as communication channels by the = RC" - this sounds a bit naive, people will do that anyway. So why is th= is a useful statement? (And similarly in 3.4)

* 2.3: what's = the benefit of including a URI (URL really) in "display"? Do we re= ally want the user (RO) to click links provided by the RC?

*= 2.3: why are we sending a JWK *as well as* a cert? Are we checking that the= cert contains the same public key as the cert?

* 2.3, "= ; the AS MUST ensure that the key used to sign the request... is associated = with the instance identifier" - can we be much more specific here, e.g.= the instance_id MUST be byte-identical to the Common Name of the cert? This= "association" is never clarified, either here or in Sec. 8.<= /o:p>

* 2.3.2: allowing to send the key in multiple formats virtually i= nvites security vulnerabilities. Why is this a good thing?

*= 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it here= ? Note that in Sec. 8.3 you are using the full certificate rather than the f= ingerprint.

* 2.3.2: why are we using raw PEM certificates i= nstead of the JOSE representation?

* 2.3.3: For obvious secu= rity reasons, I suggest adding: The AS MAY choose to avoid displaying an arb= itrary URI. RC developers must only assume that the "name" field w= ill be displayed.

* 2.3.4, "created just for this reque= st" -> created just for this series of requests.

* 2= .3.4: I suggest referring to RCs that present unknown keys as "anonymou= s RC", and then in 2.4, say that the AS MUST NOT accept any assertions = from an anonymous RC.

* 2.4: IMO assertion validation is a M= UST, and we should specify what we require for every assertion type we allow= .

* 2.4: moreover, when possible, the AS MUST match the asse= rtions to the presented sub_id. It may be a hint, but you're not allowed to = lie.

* 2.4, "If the identified RQ does not match the RO= present at the AS" - I thought there are cases where the RQ is differe= nt from the RO. Also, I am wondering why this is a SHOULD, not a MUST.<= /o:p>

* 2.4.1 (but probably applicable to any references): what is the = lifetime of the reference? As an RC, how long can I assume the user referenc= e is still valid?

* 2.5: "preferred_locales" is ob= viously not a mode of interaction. Why is it bundled here?

*= 2.5: the way "callback" is described here is as a capability, not= an interaction mode. The example only strengthens this view, "callback= " is a modifier of the "redirect" mode.

* 2.5= : "use code" -> user code.

* 2.5.1: this unnece= ssary polymorphism IMO just complicates implementations and prevents extensi= bility. Instead, I would suggest:

redirect: {}

redirect:{max_length: 255}

redirect:{max_length: 255, cal= lback: {...}}

* 2.5.2: the "app" option is problem= atic, as you already note. The RC may not even know if a given URL will resu= lt in an application launching.

* 2.5.2: and shouldn't the R= C include a list of supported applications? (Which would have lovely privacy= implications.)

* 2.5.3: there's a parenthetical discussion = on whether the URL is unique. But the nonce parameter implies that the "= ;hash" parameter is unique per request, making this discussion moot.

* 2.5.3: even if we need a different kind of post-interaction = "redirect", where the RC is not involved, there must be a way to e= nsure that the RC receives positive (cryptographically protected) confirmati= on that the authorization was successful. In other words, what we're discuss= ing here is not an RC interaction mode, it is something else, and should pro= bably have a separate protocol element to describe it.

* 2.5= .3: In the example for "interact" as an array (which I support), t= he second "redirect" and "user_code" should be independe= nt elements of the array, not members of an object. This assumes they are tr= uly independent interaction modes.

* 2.5.3.1: what does "RQ is present on the request&= quot; mean?

* 2.5.3= .2: typo: HTTP the request.

* 2.7: this seems to assume = a short access token (which implies a bearer token). What if we want to use = longer self-contained access tokens containing full keys? Should we have a s= eparate "grant_id" value instead?

* 2.8: another p= roblem with this stanza is that the RC needs to know a priority that the AS = supports it. What happens if the AS doesn't?

* 2.8: I sugges= t to move this section into a separate I-D, or at least a separate appendix.=

* 2.9: it makes sense to bundle extensions and the "ca= pabilities" section into one.

* 2.9: The AS MUST ignore= any unknown extension.

* 3: it's confusing that we're using= access_token for two different things. Maybe we could change the RC/AS one = to "as_access_token"?

* 3.1: MAY vary *by* request= .

* 3.1: how is the client behavior "deterministic in a= ll cases" - how does the RC know whether the AS allows continuation or = only allows one request at a time?

* 3.2.1: the "value&= quot; of the access token is opaque in some cases (bearer token) but not in = others.

* 3.2.1: The ASCII restriction on "value" = is insufficient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I'm no= t sure if this doesn't leave some characters that still need to be escaped.<= o:p>

* 3.2.1: why is "expires_in" optional? Typically a= ccess tokens are not revoked, and the RC needs a way to manage their lifetim= e.

* 3.2.1: "resources" refers to this same sectio= n. Did you mean 2.1.2, or are we missing a subsection describing resources/r= ights?

* 3.2.1: "key": another polymorphism alert!=

* 3.2.1: the example at the bottom of the section talks abo= ut a way to present the token, I believe this discussion is out of context h= ere.

* 3.3: the AS knows now which interaction modes are ava= ilable. Why not pick just one for its response, to simplify the protocol? As= one example, the AS can then more easily decide on timeout behavior.

* 3.3.3: Suggest to add to the last paragraph: If the RC does not = receive a callback until an RC-determined timeout occurs, the RC MUST act as= if the entire request failed.

* 3.4: "updated_at"= : Unix time is nice, but for absolute time it's common to use ISO 8601 forma= t.

* 3.6: YES, the "error" element is exclusive!

* 3.6: in SecEvent we tried to use RFC 7807 "problem det= ails", I think it could work nicely here.

* 10.4: "= ;indicating that GNAP" - sentence is broken.

* This &qu= ot;speculative" access is not useful if the response is only a MAY. Why= would the RC try it if it is unlikely to provide useful information?

* 15: the BCP195 ref is broken - the author names are missing (yes= I am one of them...).

* Appendix D: can we name the first s= cenario, maybe "Simple API Access"?

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/tx= auth

--B_3685956434_621808930-- From nobody Mon Oct 19 02:48:55 2020 Return-Path: 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 E76373A098E for ; Mon, 19 Oct 2020 02:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.813 X-Spam-Level: X-Spam-Status: No, score=0.813 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, SHORTENED_URL_HREF=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch 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 X19boCX8nfkQ for ; Mon, 19 Oct 2020 02:48:51 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 C5CDF3A098B for ; Mon, 19 Oct 2020 02:48:49 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id m9so5656661qth.7 for ; Mon, 19 Oct 2020 02:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NvjLpXjkF8wrwsBy51kyNaCovdHwszD+/lVnpjsBPMg=; b=FCBxh4ASl8fw1zYMZv7ZLKAREBa6DaX8DyL2UdN/zrl1flsi+tfTOZkGpBqLAPVRCL 8tVsah31L9V9w7D60vzG4snYpdtvlIZAMUIi1WW1nuN+eb2c5w/RD+27YCp4akobTpWS T2HBSCjenWgAPuxuCTMg0V1YxsGyzNVXJDegY= 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=NvjLpXjkF8wrwsBy51kyNaCovdHwszD+/lVnpjsBPMg=; b=mBMBITCaSCHiHfw9cVgRKmpL74bX/nSQRwxjutN65/ePpCXROe3QDoc07ccuRg1zhd 5Ugha+iGExTxV6a2m37Y9Tn6/+1Hn0gqWptiVlhWZ1G26ouWS5Wo7gw4U/o74m3W/jMn iLyzGahRHoJ53eqbK3gtc44YBqbQ35Ih0xgzNCSRUY6lOFxHbrz8k9JbHF9IvDeMLnXE aUD/L4V+2arYT1WHPMLShFU1T27iOEESFBfTTjAbBJGOvueRlIWr/wyxvh54XV637oea MQd+oSAGcDx4L1I1JhsT41mQNJ8pKlz0upa03H7anCfq1LifW0Yd5ZlzvDFwmm6vpNvt /t9g== X-Gm-Message-State: AOAM532ZB6V9Vk03XN+TajiXIUtDYI43jj7GE5kte2eXkuU2gJXDAG72 L2pTIHXOu0PmV5lQG1ArtfrqtUVGn19oCfOnKXio X-Google-Smtp-Source: ABdhPJxrOwiWGKWCwARZtfynbm7pFzjnVlZb/Fq1zBVV2SynS0R/DMNr0aw33BYtpq7LU/P8ARD6XReCHjl5hhduzm8= X-Received: by 2002:ac8:14c:: with SMTP id f12mr13930230qtg.171.1603100928557; Mon, 19 Oct 2020 02:48:48 -0700 (PDT) MIME-Version: 1.0 References: <36B6ACBF-1FBD-4A77-8875-B080242FED67@gmail.com> In-Reply-To: <36B6ACBF-1FBD-4A77-8875-B080242FED67@gmail.com> From: Warren Parad Date: Mon, 19 Oct 2020 11:48:37 +0200 Message-ID: To: Yaron Sheffer Cc: Fabien Imbault , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000062f6f605b203053f" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:48:54 -0000 --00000000000062f6f605b203053f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for using github issues for tracking and not the email DL. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Mon, Oct 19, 2020 at 11:47 AM Yaron Sheffer wrote: > Hi Fabien, > > > > I think we all have a bad experience with huge issue backlogs, which is > one reason why creating issues for all these comments would be a pain. > > > > I would suggest that the editor(s) should address all the simple issues > (those where the text can be easily fixed or clarified, or those where I > clearly don=E2=80=99t know what I=E2=80=99m talking about). Then I will o= pen issues for the > remaining ones. > > > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Monday, October 19, 2020 at 10:08 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > Hi, > > > > These are very useful feedback. We do need to take the time to read again > the entire document, as it was patched up to the last minute. > > > > There are many places where several options are considered (some of which > might need further explanation, from some of the questions I read). The > objective was to openly expose some design choices for the group to > consider, especially when it was new to the spec or when there was no > consensus. And then decide what to keep with the group. > > > > It will be worth investigating every comment. Considering their number, > I'm just wondering if the mailing list is the best place to follow up the > details. Wouldn't issues on github be better suited for that task? (as th= e > document source will be on github anyway). > > > > Cheers > > Fabien > > > > On Sun, Oct 18, 2020 at 9:44 PM Yaron Sheffer > wrote: > > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, s= o > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I hav= e > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these action= s > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generi= c > sense (management API, identity API), so maybe replace with "RS, typicall= y > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is to= o > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verg= es > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not lis= t > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of thi= s > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to bot= h > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify th= e > RO in the context of the AS and can't be used as communication channels b= y > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather tha= n > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choos= e > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here = is > not an RC interaction mode, it is something else, and should probably hav= e > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if t= he > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000062f6f605b203053f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for using github issues for tracking and not the email = DL.

Warren Parad

Founder, CTO

Secure your user data and complete your authorization a= rchitecture. Implement=C2=A0Authress.


On Mon, Oct 19, 2020 at= 11:47 AM Yaron Sheffer <yaronf= .ietf@gmail.com> wrote:

= Hi Fabien,

=C2=A0

=

I think we all have a bad experience with huge issue= backlogs, which is one reason why creating issues for all these comments w= ould be a pain.

=C2=A0

I would suggest that the editor(s) should addre= ss all the simple issues (those where the text can be easily fixed or clari= fied, or those where I clearly don=E2=80=99t know what I=E2=80=99m talking = about). Then I will open issues for the remaining ones.

=C2=A0

Thanks,=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Monday, Oct= ober 19, 2020 at 10:08
To: Yaron Sheffer <yaronf.ietf@gmail.com>
= Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [GNAP] Review of dra= ft-ietf-gnap-core-protocol-00 (first half)

=C2=A0

Hi,=C2=A0

=C2=A0

These are very useful = feedback. We do need to take the time to read again the entire document, as= it was patched up to the last minute.

=C2=A0

Th= ere are many places where several options are considered (some of which mig= ht need further explanation, from some of the questions I read). The object= ive was to openly expose some design choices for the group to consider, esp= ecially when it was new to the spec or when there was no consensus. And the= n decide what to keep with the=C2=A0group.=C2=A0

=C2=A0

It will be worth investigating every comment. Considering their=C2= =A0number, I'm just wondering if the mailing list is the best place to = follow up the details. Wouldn't issues on github be better suited for t= hat task? (as the document source will be on github anyway).=C2=A0

=C2=A0

Cheers

Fabien

= =C2=A0

On Sun, Oct 18, 2020 at 9= :44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin, all,=

=C2=A0

The draft has undergone major changes since we started the design team, = so I spent some time reviewing it. I only got as far as Sec. 3, and I fully= intend to review the remainder of the document. But I figured since I have= so many comments, I might as well send out what I have.

<= p class=3D"MsoNormal">=C2=A0

* Gene= ral comment: we have dozens, maybe hundreds of variants/options here. I thi= nk we need to define a must-implement subset, or we will never reach intero= perability.

* Abstract: the boilerp= late text (MUST etc.) usually goes to the Introduction, not the Abstract.

* 1. "The requesting party oper= ating the software" - I think these actions are typically performed by= the resource owner, who is not necessarily the requesting party.=

* RS, aka API: we are using the word "A= PI" several times in a more generic sense (management API, identity AP= I), so maybe replace with "RS, typically a protected API".=

* 1.2, "key" is a too generic t= erm in the context of a security protocol. Can we call it something more sp= ecific, maybe "holder identity key"?

* 1.3.1. "augmented with a hash of the security informatio= n" - this is too implementation-specific, suggest "is cryptograph= ically bound to the security information". In general, step (7) is way= too detailed, and verges on the normative.

* 1.3.2: it is unclear to me what the goal of the user-code intera= ction is, in other words what is the threat model. If it's just "s= econd factor, something you have", then an OTP MFA device would be sim= pler and offer the same security.

*= 1.3.5 (4): Typically the access token would not be sent once it is expired= , right? Let's make the example more realistic.

* 2: "OpenID Connect claims request" - why not &= quot;identity claims request" (which just happens to be similar to the= OpenID request)?

* Never liked the= "dolphin" here... If this is listed under "actions", i= t should be a verb, e.g. "swim".

* 2.1: an array for a single AT vs. an object for multiple ATs? Thi= s is extremely non-intuitive and probably ugly to code. Also, why should (m= ultiple) tokens be named if a single token doesn't have to, why not lis= t them in an array instead?

* 2.1.1= , "locations": are these really URIs or just URLs? On the other h= and, if these are URIs, why do we need a separate "identifier"? T= here's too much semantic overlap between "type", "locati= on" and "identifier" - specifying just "type" may = be sufficient.

* 2.1.1: it's im= plied but should be spelled out that the semantics of this example is the c= ross product of permissions: I am requesting to read and write and "do= lphin" both "metadata" and "images", and that appl= ies to both "locations" - 12 different possible actions.

* 2.1.2: I don't see the value of the n= otion of "expansion". It is sufficient that the string is underst= ood by the AS.

* 2.1.2, "in so= me situations the value is intended to be seen and understood be the RC dev= eloper" - shouldn't we require this value to be always fully docum= ented by the AS owner, so that the RC knows what it is requesting?

* 2.1.4: why are flags represented as resou= rces? The answer, "this is how OAuth 2 does it" is not great.<= /u>

* "the each access tokens" -= > each access token.

* I suggest= to extend the editor's note to clarify what is the use case, so that t= he group can decide whether split tokens are indeed necessary.

* Why is key binding of the access token even o= ptional?

* 2.2, "Subject ident= ifiers requested by the RC serve only to identify the RO in the context of = the AS and can't be used as communication channels by the RC" - th= is sounds a bit naive, people will do that anyway. So why is this a useful = statement? (And similarly in 3.4)

*= 2.3: what's the benefit of including a URI (URL really) in "displ= ay"? Do we really want the user (RO) to click links provided by the RC= ?

* 2.3: why are we sending a JWK *= as well as* a cert? Are we checking that the cert contains the same public = key as the cert?

* 2.3, " the = AS MUST ensure that the key used to sign the request... is associated with = the instance identifier" - can we be much more specific here, e.g. the= instance_id MUST be byte-identical to the Common Name of the cert? This &q= uot;association" is never clarified, either here or in Sec. 8.<= u>

* 2.3.2: allowing to send the key in multi= ple formats virtually invites security vulnerabilities. Why is this a good = thing?

* 2.3.2: cert#256 is not a k= ey, it's an identifier. Why do we include it here? Note that in Sec. 8.= 3 you are using the full certificate rather than the fingerprint.=

* 2.3.2: why are we using raw PEM certificat= es instead of the JOSE representation?

* 2.3.3: For obvious security reasons, I suggest adding: The AS MAY cho= ose to avoid displaying an arbitrary URI. RC developers must only assume th= at the "name" field will be displayed.

* 2.3.4, "created just for this request" -> cre= ated just for this series of requests.

* 2.3.4: I suggest referring to RCs that present unknown keys as "= anonymous RC", and then in 2.4, say that the AS MUST NOT accept any as= sertions from an anonymous RC.

* 2.= 4: IMO assertion validation is a MUST, and we should specify what we requir= e for every assertion type we allow.

* 2.4: moreover, when possible, the AS MUST match the assertions to the p= resented sub_id. It may be a hint, but you're not allowed to lie.

* 2.4, "If the identified RQ does n= ot match the RO present at the AS" - I thought there are cases where t= he RQ is different from the RO. Also, I am wondering why this is a SHOULD, = not a MUST.

* 2.4.1 (but probably a= pplicable to any references): what is the lifetime of the reference? As an = RC, how long can I assume the user reference is still valid?<= /p>

* 2.5: "preferred_locales" is obviously= not a mode of interaction. Why is it bundled here?

* 2.5: the way "callback" is described here is a= s a capability, not an interaction mode. The example only strengthens this = view, "callback" is a modifier of the "redirect" mode.<= u>

* 2.5: "use code" -> u= ser code.

* 2.5.1: this unnecessary= polymorphism IMO just complicates implementations and prevents extensibili= ty. Instead, I would suggest:

redir= ect: {}

redirect:{max_length: 255}<= u>

redirect:{max_length: 255, callback= : {...}}

* 2.5.2: the "app&quo= t; option is problematic, as you already note. The RC may not even know if = a given URL will result in an application launching.

* 2.5.2: and shouldn't the RC include a list of suppo= rted applications? (Which would have lovely privacy implications.)

* 2.5.3: there's a parenthetical discus= sion on whether the URL is unique. But the nonce parameter implies that the= "hash" parameter is unique per request, making this discussion m= oot.

* 2.5.3: even if we need a dif= ferent kind of post-interaction "redirect", where the RC is not i= nvolved, there must be a way to ensure that the RC receives positive (crypt= ographically protected) confirmation that the authorization was successful.= In other words, what we're discussing here is not an RC interaction mo= de, it is something else, and should probably have a separate protocol elem= ent to describe it.

* 2.5.3: In the= example for "interact" as an array (which I support), the second= "redirect" and "user_code" should be independent eleme= nts of the array, not members of an object. This assumes they are truly ind= ependent interaction modes.

* 2.5.3.1: what does "RQ is = present on the request" mean?

= * 2.5.3.2: typo: HTTP the = request.

* 2.7: this seems to assum= e a short access token (which implies a bearer token). What if we want to u= se longer self-contained access tokens containing full keys? Should we have= a separate "grant_id" value instead?

* 2.8: another problem with this stanza is that the RC needs= to know a priority that the AS supports it. What happens if the AS doesn&#= 39;t?

* 2.8: I suggest to move this= section into a separate I-D, or at least a separate appendix.

* 2.9: it makes sense to bundle extensions and = the "capabilities" section into one.

* 2.9: The AS MUST ignore any unknown extension.<= /p>

* 3: it's confusing that we're using acce= ss_token for two different things. Maybe we could change the RC/AS one to &= quot;as_access_token"?

* 3.1: = MAY vary *by* request.

* 3.1: how i= s the client behavior "deterministic in all cases" - how does the= RC know whether the AS allows continuation or only allows one request at a= time?

* 3.2.1: the "value&quo= t; of the access token is opaque in some cases (bearer token) but not in ot= hers.

* 3.2.1: The ASCII restrictio= n on "value" is insufficient. Needs to be printable ASCII, 0x20&l= t;v<=3D0x7f. And I'm not sure if this doesn't leave some charact= ers that still need to be escaped.

= * 3.2.1: why is "expires_in" optional? Typically access tokens ar= e not revoked, and the RC needs a way to manage their lifetime.

* 3.2.1: "resources" refers to this = same section. Did you mean 2.1.2, or are we missing a subsection describing= resources/rights?

* 3.2.1: "k= ey": another polymorphism alert!

* 3.2.1: the example at the bottom of the section talks about a way to p= resent the token, I believe this discussion is out of context here.<= u>

* 3.3: the AS knows now which interaction = modes are available. Why not pick just one for its response, to simplify th= e protocol? As one example, the AS can then more easily decide on timeout b= ehavior.

* 3.3.3: Suggest to add to= the last paragraph: If the RC does not receive a callback until an RC-dete= rmined timeout occurs, the RC MUST act as if the entire request failed.<= /u>

* 3.4: "updated_at": Unix ti= me is nice, but for absolute time it's common to use ISO 8601 format.

* 3.6: YES, the "error" el= ement is exclusive!

* 3.6: in SecEv= ent we tried to use RFC 7807 "problem details", I think it could = work nicely here.

* 10.4: "ind= icating that GNAP" - sentence is broken.

* This "speculative" access is not useful if the respo= nse is only a MAY. Why would the RC try it if it is unlikely to provide use= ful information?

* 15: the BCP195 r= ef is broken - the author names are missing (yes I am one of them...).

* Appendix D: can we name the first sce= nario, maybe "Simple API Access"?

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth

<= /div> --
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000062f6f605b203053f-- From nobody Mon Oct 19 02:52:12 2020 Return-Path: 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 E90573A098E for ; Mon, 19 Oct 2020 02:52:10 -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=[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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 llfVLUj_1piZ for ; Mon, 19 Oct 2020 02:52:08 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 C07D83A098B for ; Mon, 19 Oct 2020 02:52:07 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id q5so12123091wmq.0 for ; Mon, 19 Oct 2020 02:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=foXUqxzycTnKCW/Ib+Ve8ZnkVoZBwkJwd/HIuy4Vylg=; b=kRB5aW9Y9ZK1vBMFwYwTymrQCnV2/qM4vPbCLY13pJ5YCLNx8GWulZmbPtPPrqsXfM +Ygw5QjJvDkTWrVCV4MhGoRVq+V2YFESJc214DSX0zmg7iMQWy/Xh9boyfPR7lX1rUej MlS5LKsie57VJpRRlPoBU5kKxyDsD1n4aRkET7xmN0e0M4WonRQVaYBxhpa6m9AcfMGa DrPHYWjIrRZ8/GiIRLhfnckRCF8AvhU+a1smdyRNOLUPlj8uIC3JIAH350oJIWCYkPCu Q87/SERV/Gj7P22UEO1JEC7ms2jfI4XoqoFhSk/ohkTK6JDpKaWmp26c4s/GfUkPduUn Qwtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=foXUqxzycTnKCW/Ib+Ve8ZnkVoZBwkJwd/HIuy4Vylg=; b=XY08RC+gDeT8/UEm4k6Tt8BlCggSTsWh2DW8w0sWxobAQhwDTgd9S3j6gxYd2kZKUL IiljZ9xky33fM/UF+mznJrhOq3BFgbgBoYbe0eWGGhcVRjZ20UrR/+GoXSg9oMX7UI3G sk1VUz29fdP3ZKhCbu7DtQ9KrV45wPNtQRW2oD4iUqGCwtjmdFxUiUgfjgq87rRyQ4fJ KWHzWnMSNs1+xP+77pO6D6ho3Rg9UV1TZsr2iHXwO4C/dyNig7eH77sc5IA84+vRJxFt XXsQ1n+U0XyF1wN8wV8CY/I/KVuEHP+TALlWeNE0nu/rRcsfzM8a5dLc2pG1TMxmMMVb qL1Q== X-Gm-Message-State: AOAM530F7RHQGWLiI0rrGZLsU0lWv4wvinpcLIqRp2Z8kHNrIUsQFBV/ bdNDAUoQws+GPI9Ff2JlZH8= X-Google-Smtp-Source: ABdhPJw2BkeWdxMVUTr55ejLiSAXfj1mJeqN0MquNPxU5zeqrL+j+L31KLZUI/Wykx4KyPPtEVNsxw== X-Received: by 2002:a1c:9a10:: with SMTP id c16mr15771241wme.96.1603101126194; Mon, 19 Oct 2020 02:52:06 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id b63sm16341756wme.9.2020.10.19.02.52.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 02:52:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Mon, 19 Oct 2020 12:52:04 +0300 From: Yaron Sheffer To: Tom Jones CC: GNAP Mailing List Message-ID: <95C5E06D-C017-4BD1-8CA1-0AF07E3DB3AE@gmail.com> Thread-Topic: User code, was Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3685956725_1532013119" Archived-At: Subject: [GNAP] User code, was Re: Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:52:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3685956725_1532013119 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Tom, =20 Thanks for your response. I would like to focus on one point. =20 The document does not explain what the user code solution tries to achieve,= and I honestly don=E2=80=99t understand the exact use case(s) myself. If you coul= d write up a paragraph, we could include it in the document for my own and o= thers=E2=80=99 edification. =20 Regards, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Tom Jones Date: Monday, October 19, 2020 at 00:38 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) =20 then i guess we must address the entire email, which is not helpful. Here = are at least a few of my thoughts. 1.2, "key" is a too generic term in the context of a security protocol. Can= we call it something more specific, maybe "holder identity key"? >> that is not more specific. if you want to understand the source of the k= ey then perhaps the entire jwk element needs to be augmented. 1.3.2: it is unclear to me what the goal of the user-code interaction is, i= n other words what is the threat model. If it's just "second factor, somethi= ng you have", then an OTP MFA device would be simpler and offer the same sec= urity. >> first of all, you are wrong in your assessment, second that is not all t= hat the user-code interaction supplies. 2.1.2: I don't see the value of the notion of "expansion". It is sufficient= that the string is understood by the AS. >> I am already running into this as a problem with strings in OIDC. I beli= eve we need a better way to expand strings into structures. I proposed the = use of 3part jose structures as a solution. * 2.3: what's the benefit of including a URI (URL really) in "display"? Do = we really want the user (RO) to click links provided by the RC? >> I hope you are not proposing that users actually see any of this? That = would be grotesque. * 2.4: IMO assertion validation is a MUST, and we should specify what we re= quire for every assertion type we allow. >> I plan on including assertions that do not need to be validated. I belie= ve it is not up to the sender whether the receiver validates the assertion. =20 In general I find that many of your comments are not trivial and need deepe= r analysis. Peace ..tom =20 =20 On Sun, Oct 18, 2020 at 1:00 PM Yaron Sheffer wrote= : We haven=E2=80=99t discussed this process yet, and the default IETF process is, e= verything goes through the mailing list. =20 IMO small things can be quickly cleaned up (fixed or rejected), and we can = open GH issues for bigger things. =20 Thanks, Yaron =20 From: Tom Jones Date: Sunday, October 18, 2020 at 22:47 To: Yaron Sheffer Cc: GNAP Mailing List Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) =20 why are you doing this? Should these be issues now? Peace ..tom =20 =20 On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer wrot= e: Hi Justin, all, =20 The draft has undergone major changes since we started the design team, so = I spent some time reviewing it. I only got as far as Sec. 3, and I fully int= end to review the remainder of the document. But I figured since I have so m= any comments, I might as well send out what I have. =20 * General comment: we have dozens, maybe hundreds of variants/options here.= I think we need to define a must-implement subset, or we will never reach i= nteroperability. * Abstract: the boilerplate text (MUST etc.) usually goes to the Introducti= on, not the Abstract. * 1. "The requesting party operating the software" - I think these actions = are typically performed by the resource owner, who is not necessarily the re= questing party. * RS, aka API: we are using the word "API" several times in a more generic = sense (management API, identity API), so maybe replace with "RS, typically a= protected API". * 1.2, "key" is a too generic term in the context of a security protocol. C= an we call it something more specific, maybe "holder identity key"? * 1.3.1. "augmented with a hash of the security information" - this is too = implementation-specific, suggest "is cryptographically bound to the security= information". In general, step (7) is way too detailed, and verges on the n= ormative. * 1.3.2: it is unclear to me what the goal of the user-code interaction is,= in other words what is the threat model. If it's just "second factor, somet= hing you have", then an OTP MFA device would be simpler and offer the same s= ecurity. * 1.3.5 (4): Typically the access token would not be sent once it is expire= d, right? Let's make the example more realistic. * 2: "OpenID Connect claims request" - why not "identity claims request" (w= hich just happens to be similar to the OpenID request)? * Never liked the "dolphin" here... If this is listed under "actions", it s= hould be a verb, e.g. "swim". * 2.1: an array for a single AT vs. an object for multiple ATs? This is ext= remely non-intuitive and probably ugly to code. Also, why should (multiple) = tokens be named if a single token doesn't have to, why not list them in an a= rray instead? * 2.1.1, "locations": are these really URIs or just URLs? On the other hand= , if these are URIs, why do we need a separate "identifier"? There's too muc= h semantic overlap between "type", "location" and "identifier" - specifying = just "type" may be sufficient. * 2.1.1: it's implied but should be spelled out that the semantics of this = example is the cross product of permissions: I am requesting to read and wri= te and "dolphin" both "metadata" and "images", and that applies to both "loc= ations" - 12 different possible actions. * 2.1.2: I don't see the value of the notion of "expansion". It is sufficie= nt that the string is understood by the AS. * 2.1.2, "in some situations the value is intended to be seen and understoo= d be the RC developer" - shouldn't we require this value to be always fully = documented by the AS owner, so that the RC knows what it is requesting? * 2.1.4: why are flags represented as resources? The answer, "this is how O= Auth 2 does it" is not great. * "the each access tokens" -> each access token. * I suggest to extend the editor's note to clarify what is the use case, so= that the group can decide whether split tokens are indeed necessary. * Why is key binding of the access token even optional? * 2.2, "Subject identifiers requested by the RC serve only to identify the = RO in the context of the AS and can't be used as communication channels by t= he RC" - this sounds a bit naive, people will do that anyway. So why is this= a useful statement? (And similarly in 3.4) * 2.3: what's the benefit of including a URI (URL really) in "display"? Do = we really want the user (RO) to click links provided by the RC? * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that t= he cert contains the same public key as the cert? * 2.3, " the AS MUST ensure that the key used to sign the request... is ass= ociated with the instance identifier" - can we be much more specific here, e= .g. the instance_id MUST be byte-identical to the Common Name of the cert? T= his "association" is never clarified, either here or in Sec. 8. * 2.3.2: allowing to send the key in multiple formats virtually invites sec= urity vulnerabilities. Why is this a good thing? * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it he= re? Note that in Sec. 8.3 you are using the full certificate rather than the= fingerprint. * 2.3.2: why are we using raw PEM certificates instead of the JOSE represen= tation? * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choose = to avoid displaying an arbitrary URI. RC developers must only assume that th= e "name" field will be displayed. * 2.3.4, "created just for this request" -> created just for this series of= requests. * 2.3.4: I suggest referring to RCs that present unknown keys as "anonymous= RC", and then in 2.4, say that the AS MUST NOT accept any assertions from a= n anonymous RC. * 2.4: IMO assertion validation is a MUST, and we should specify what we re= quire for every assertion type we allow. * 2.4: moreover, when possible, the AS MUST match the assertions to the pre= sented sub_id. It may be a hint, but you're not allowed to lie. * 2.4, "If the identified RQ does not match the RO present at the AS" - I t= hought there are cases where the RQ is different from the RO. Also, I am won= dering why this is a SHOULD, not a MUST. * 2.4.1 (but probably applicable to any references): what is the lifetime o= f the reference? As an RC, how long can I assume the user reference is still= valid? * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is i= t bundled here? * 2.5: the way "callback" is described here is as a capability, not an inte= raction mode. The example only strengthens this view, "callback" is a modifi= er of the "redirect" mode. * 2.5: "use code" -> user code. * 2.5.1: this unnecessary polymorphism IMO just complicates implementations= and prevents extensibility. Instead, I would suggest: redirect: {} redirect:{max_length: 255} redirect:{max_length: 255, callback: {...}} * 2.5.2: the "app" option is problematic, as you already note. The RC may n= ot even know if a given URL will result in an application launching. * 2.5.2: and shouldn't the RC include a list of supported applications? (Wh= ich would have lovely privacy implications.) * 2.5.3: there's a parenthetical discussion on whether the URL is unique. B= ut the nonce parameter implies that the "hash" parameter is unique per reque= st, making this discussion moot. * 2.5.3: even if we need a different kind of post-interaction "redirect", w= here the RC is not involved, there must be a way to ensure that the RC recei= ves positive (cryptographically protected) confirmation that the authorizati= on was successful. In other words, what we're discussing here is not an RC i= nteraction mode, it is something else, and should probably have a separate p= rotocol element to describe it. * 2.5.3: In the example for "interact" as an array (which I support), the s= econd "redirect" and "user_code" should be independent elements of the array= , not members of an object. This assumes they are truly independent interact= ion modes. * 2.5.3.1: what does "RQ is present on the request" mean? * 2.5.3.2: typo: HTTP the request. * 2.7: this seems to assume a short access token (which implies a bearer to= ken). What if we want to use longer self-contained access tokens containing = full keys? Should we have a separate "grant_id" value instead? * 2.8: another problem with this stanza is that the RC needs to know a prio= rity that the AS supports it. What happens if the AS doesn't? * 2.8: I suggest to move this section into a separate I-D, or at least a se= parate appendix. * 2.9: it makes sense to bundle extensions and the "capabilities" section i= nto one. * 2.9: The AS MUST ignore any unknown extension. * 3: it's confusing that we're using access_token for two different things.= Maybe we could change the RC/AS one to "as_access_token"? * 3.1: MAY vary *by* request. * 3.1: how is the client behavior "deterministic in all cases" - how does t= he RC know whether the AS allows continuation or only allows one request at = a time? * 3.2.1: the "value" of the access token is opaque in some cases (bearer to= ken) but not in others. * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be prin= table ASCII, 0x20

Hi Tom,

 

Thanks for your = response. I would like to focus on one point.

 

The document does not explain wha= t the user code solution tries to achieve, and I honestly don=E2=80=99t understand= the exact use case(s) myself. If you could write up a paragraph, we could i= nclude it in the document for my own and others=E2=80=99 edification.

 

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Tom Jones <thomasclinganjones@gmail.com>
Da= te: Monday, October 19, 2020 at 00:38
To: Yaron Sheffer <ya= ronf.ietf@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org&= gt;
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00= (first half)

 =

then i guess we must address the&nbs= p;entire email, which is not helpful.  Here are at least a few of = my thoughts.

1.2, "key" is a= too generic term in the context of a security protocol. Can we call it some= thing more specific, maybe "holder identity key"?

>> that is not more specific. if you want = to understand the source of the key then perhaps the entire jwk element need= s to be augmented.

1.3.2: it is unclear to me wha= t the goal of the user-code interaction is, in other words what is the threa= t model. If it's just "second factor, something you have", then an= OTP MFA device would be simpler and offer the same security.

=

>> first of all, you are wrong in your assessment, second that is no= t all that the user-code interaction supplies.

2.1.2: I don'= t see the value of the notion of "expansion". It is sufficient tha= t the string is understood by the AS.

>> I am already running into this as a problem with strings in O= IDC. I believe we need a better way to expand strings into structures. = I proposed the use of 3part jose structures as a solution.<= /p>

* 2.3: what's the benefit of including a UR= I (URL really) in "display"? Do we really want the user (RO) to cl= ick links provided by the RC?

&g= t;> I hope you are not proposing that users actually see any of this?&nbs= p; That would be grotesque.

* 2.= 4: IMO assertion validation is a MUST, and we should specify what we require= for every assertion type we allow.

>> I plan on including assertions that do not need to be validated= . I believe it is not up to the sender whether the receiver validates the as= sertion.

 

In general I find that many of your comments are= not trivial and need deeper analysis.

Peace ..tom

 

<= o:p> 

On Sun, Oct 18, 2020 at 1:0= 0 PM Yaron Sheffer <yaronf.ietf@gm= ail.com> wrote:

We haven=E2=80=99t discussed this process yet, and the= default IETF process is, everything goes through the mailing list.

 

IMO small things can be quickly cleaned up (f= ixed or rejected), and we can open GH issues for bigger things.

 

Thanks,

    &= nbsp;           Yaron=

 

From: Tom J= ones <thoma= sclinganjones@gmail.com>
Date: Sunday, October 18, 2020 at = 22:47
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: GNAP Mailing Li= st <txauth@ietf.org&= gt;
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00= (first half)

 

<= div>

why are you doing this? Should these be issues now?
=

Peace ..tom

=

 

 

On Sun= , Oct 18, 2020 at 12:44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

<= /div>

Hi Justin, all,

 <= /p>

The draft has undergone major changes since we started the design team,= so I spent some time reviewing it. I only got as far as Sec. 3, and I fully= intend to review the remainder of the document. But I figured since I have = so many comments, I might as well send out what I have.

&nbs= p;

* General comment: we have dozens, maybe hundreds of vari= ants/options here. I think we need to define a must-implement subset, or we = will never reach interoperability.

* Abstract: the boilerpla= te text (MUST etc.) usually goes to the Introduction, not the Abstract.=

* 1. "The requesting party operating the software" - I= think these actions are typically performed by the resource owner, who is n= ot necessarily the requesting party.

* RS, aka API: we are u= sing the word "API" several times in a more generic sense (managem= ent API, identity API), so maybe replace with "RS, typically a protecte= d API".

* 1.2, "key" is a too generic term in= the context of a security protocol. Can we call it something more specific,= maybe "holder identity key"?

* 1.3.1. "augme= nted with a hash of the security information" - this is too implementat= ion-specific, suggest "is cryptographically bound to the security infor= mation". In general, step (7) is way too detailed, and verges on the no= rmative.

* 1.3.2: it is unclear to me what the goal of the u= ser-code interaction is, in other words what is the threat model. If it's ju= st "second factor, something you have", then an OTP MFA device wou= ld be simpler and offer the same security.

* 1.3.5 (4): Typi= cally the access token would not be sent once it is expired, right? Let's ma= ke the example more realistic.

* 2: "OpenID Connect cla= ims request" - why not "identity claims request" (which just = happens to be similar to the OpenID request)?

* Never liked = the "dolphin" here... If this is listed under "actions",= it should be a verb, e.g. "swim".

* 2.1: an array= for a single AT vs. an object for multiple ATs? This is extremely non-intui= tive and probably ugly to code. Also, why should (multiple) tokens be named = if a single token doesn't have to, why not list them in an array instead?

* 2.1.1, "locations": are these really URIs or just = URLs? On the other hand, if these are URIs, why do we need a separate "= identifier"? There's too much semantic overlap between "type"= , "location" and "identifier" - specifying just "ty= pe" may be sufficient.

* 2.1.1: it's implied but should= be spelled out that the semantics of this example is the cross product of p= ermissions: I am requesting to read and write and "dolphin" both &= quot;metadata" and "images", and that applies to both "l= ocations" - 12 different possible actions.

* 2.1.2: I d= on't see the value of the notion of "expansion". It is sufficient = that the string is understood by the AS.

* 2.1.2, "in s= ome situations the value is intended to be seen and understood be the RC dev= eloper" - shouldn't we require this value to be always fully documented= by the AS owner, so that the RC knows what it is requesting?

=

* 2.1.4: why are flags represented as resources? The answer, "this is= how OAuth 2 does it" is not great.

* "the each ac= cess tokens" -> each access token.

* I suggest to ex= tend the editor's note to clarify what is the use case, so that the group ca= n decide whether split tokens are indeed necessary.

* Why is= key binding of the access token even optional?

* 2.2, "= ;Subject identifiers requested by the RC serve only to identify the RO in th= e context of the AS and can't be used as communication channels by the RC&qu= ot; - this sounds a bit naive, people will do that anyway. So why is this a = useful statement? (And similarly in 3.4)

* 2.3: what's the b= enefit of including a URI (URL really) in "display"? Do we really = want the user (RO) to click links provided by the RC?

* 2.3:= why are we sending a JWK *as well as* a cert? Are we checking that the cert= contains the same public key as the cert?

* 2.3, " the= AS MUST ensure that the key used to sign the request... is associated with = the instance identifier" - can we be much more specific here, e.g. the = instance_id MUST be byte-identical to the Common Name of the cert? This &quo= t;association" is never clarified, either here or in Sec. 8.=

* 2.3.2: allowing to send the key in multiple formats virtually invite= s security vulnerabilities. Why is this a good thing?

* 2.3.= 2: cert#256 is not a key, it's an identifier. Why do we include it here? Not= e that in Sec. 8.3 you are using the full certificate rather than the finger= print.

* 2.3.2: why are we using raw PEM certificates instea= d of the JOSE representation?

* 2.3.3: For obvious security = reasons, I suggest adding: The AS MAY choose to avoid displaying an arbitrar= y URI. RC developers must only assume that the "name" field will b= e displayed.

* 2.3.4, "created just for this request&qu= ot; -> created just for this series of requests.

* 2.3.4:= I suggest referring to RCs that present unknown keys as "anonymous RC&= quot;, and then in 2.4, say that the AS MUST NOT accept any assertions from = an anonymous RC.

* 2.4: IMO assertion validation is a MUST, = and we should specify what we require for every assertion type we allow.

* 2.4: moreover, when possible, the AS MUST match the assertion= s to the presented sub_id. It may be a hint, but you're not allowed to lie.<= o:p>

* 2.4, "If the identified RQ does not match the RO pres= ent at the AS" - I thought there are cases where the RQ is different fr= om the RO. Also, I am wondering why this is a SHOULD, not a MUST.=

* 2.4.1 (but probably applicable to any references): what is the lifet= ime of the reference? As an RC, how long can I assume the user reference is = still valid?

* 2.5: "preferred_locales" is obvious= ly not a mode of interaction. Why is it bundled here?

* 2.5:= the way "callback" is described here is as a capability, not an i= nteraction mode. The example only strengthens this view, "callback"= ; is a modifier of the "redirect" mode.

* 2.5: &qu= ot;use code" -> user code.

* 2.5.1: this unnecessary= polymorphism IMO just complicates implementations and prevents extensibilit= y. Instead, I would suggest:

redirect: {}

re= direct:{max_length: 255}

redirect:{max_length: 255, callback= : {...}}

* 2.5.2: the "app" option is problematic,= as you already note. The RC may not even know if a given URL will result in= an application launching.

* 2.5.2: and shouldn't the RC inc= lude a list of supported applications? (Which would have lovely privacy impl= ications.)

* 2.5.3: there's a parenthetical discussion on wh= ether the URL is unique. But the nonce parameter implies that the "hash= " parameter is unique per request, making this discussion moot.

* 2.5.3: even if we need a different kind of post-interaction "= ;redirect", where the RC is not involved, there must be a way to ensure= that the RC receives positive (cryptographically protected) confirmation th= at the authorization was successful. In other words, what we're discussing h= ere is not an RC interaction mode, it is something else, and should probably= have a separate protocol element to describe it.

* 2.5.3: I= n the example for "interact" as an array (which I support), the se= cond "redirect" and "user_code" should be independent el= ements of the array, not members of an object. This assumes they are truly i= ndependent interaction modes.

* 2.5.3.1: what does "RQ is present on the request"= mean?

* 2.5.3.2: typo: HTTP the request.

* 2.7: this seems to assume a sho= rt access token (which implies a bearer token). What if we want to use longe= r self-contained access tokens containing full keys? Should we have a separa= te "grant_id" value instead?

* 2.8: another proble= m with this stanza is that the RC needs to know a priority that the AS suppo= rts it. What happens if the AS doesn't?

* 2.8: I suggest to = move this section into a separate I-D, or at least a separate appendix.=

* 2.9: it makes sense to bundle extensions and the "capabil= ities" section into one.

* 2.9: The AS MUST ignore any = unknown extension.

* 3: it's confusing that we're using acce= ss_token for two different things. Maybe we could change the RC/AS one to &q= uot;as_access_token"?

* 3.1: MAY vary *by* request.

* 3.1: how is the client behavior "deterministic in all ca= ses" - how does the RC know whether the AS allows continuation or only = allows one request at a time?

* 3.2.1: the "value"= of the access token is opaque in some cases (bearer token) but not in other= s.

* 3.2.1: The ASCII restriction on "value" is in= sufficient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I'm not sur= e if this doesn't leave some characters that still need to be escaped.<= /o:p>

* 3.2.1: why is "expires_in" optional? Typically access= tokens are not revoked, and the RC needs a way to manage their lifetime.

* 3.2.1: "resources" refers to this same section. Di= d you mean 2.1.2, or are we missing a subsection describing resources/rights= ?

* 3.2.1: "key": another polymorphism alert!=

* 3.2.1: the example at the bottom of the section talks about a = way to present the token, I believe this discussion is out of context here.<= o:p>

* 3.3: the AS knows now which interaction modes are availabl= e. Why not pick just one for its response, to simplify the protocol? As one = example, the AS can then more easily decide on timeout behavior.<= /p>

* 3.3.3: Suggest to add to the last paragraph: If the RC does not recei= ve a callback until an RC-determined timeout occurs, the RC MUST act as if t= he entire request failed.

* 3.4: "updated_at": Uni= x time is nice, but for absolute time it's common to use ISO 8601 format.

* 3.6: YES, the "error" element is exclusive!

* 3.6: in SecEvent we tried to use RFC 7807 "problem details&= quot;, I think it could work nicely here.

* 10.4: "indi= cating that GNAP" - sentence is broken.

* This "sp= eculative" access is not useful if the response is only a MAY. Why woul= d the RC try it if it is unlikely to provide useful information?<= /p>

* 15: the BCP195 ref is broken - the author names are missing (yes I am= one of them...).

* Appendix D: can we name the first scenar= io, maybe "Simple API Access"?

--
= TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--B_3685956725_1532013119-- From nobody Mon Oct 19 02:54:16 2020 Return-Path: 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 83B7A3A09A4 for ; Mon, 19 Oct 2020 02:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=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 (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 3pQiiU_FJgLt for ; Mon, 19 Oct 2020 02:54:12 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 78D7B3A0991 for ; Mon, 19 Oct 2020 02:54:07 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id p16so9814851ilq.5 for ; Mon, 19 Oct 2020 02:54:07 -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=WVhsJTOhfjAt6ukBRDAvOcWGXpIlSd5gpC0B70t7yXU=; b=kKYveR3jQAiYfC779Y74myxOQnojlEuZp3UhzLMTILboGzpuDCRuPGvAt539l/jb3/ kSOP0B57ZO3w420XKFwpB1sZ06raD3PXLFAsAhb207QGD/VMeDUdJydhAld7haoAVCE2 95Q7vWZoTcp4fs0gIbLTFF9spx/hwtQCctrdWX4jzf0TtQsdxgv/rBPVewz1Br2CXV0B jVngGoHUYixMmzyADANPpLovF4jAcyTsDiZVyNjCmdLEF3H8BfTz/PRbQlVVdtk1Mzd/ Tno/c4+axdStMyoZ8HLfvY4+i/KEdv5EfFFLlqfzljkHc4umm2oG8NFRoZUpTc2GXwek hSRw== 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=WVhsJTOhfjAt6ukBRDAvOcWGXpIlSd5gpC0B70t7yXU=; b=okJBYaHRrnxGKRfSohsdH3uzrLrhyO3EdBQTz4JeWJaSKzabshJY8k5NkJfDzdbUlF 3PC1ZFG08tw6vkzObPntKGKpxjiYoVtxXb07xS7gYwzIKNiyAfT8BlWNoo1RshOLjBWb RsbTSjMroC8wKMKQWr++C/sw6lW57gvNF++0gEgBCHkUSvQkdG7w//o46aV6VDAqKZeg PA09YfOY6NdUZnsHMdS4Oy1j5329lyfMYB6H3TVd3/afpJUeNv38pzHkPCXJdn8RZjhY mI4s49eKpkuhFq6G4g90dTVwQJZGFjISkfCKqufiiJI5kBaYVa1kBqCqPDgplLoNf4BW hdvA== X-Gm-Message-State: AOAM533fS1GtuDRZuK8mR5ubYiWAsVkUVN3whHaTaa5Txk8fyQ4El4YS TE7kxqjx2uZjyWWQXuZoX1R8s77/JSAwH43CMKrM4ljCztc= X-Google-Smtp-Source: ABdhPJwbi8oTkj29YrC/zWDgboFN6sn3mm98JszdvDnPqQsEUZRmwNtwAymcTsuUL4oproUHI9dlp41/lOigItSVcf8= X-Received: by 2002:a92:ccc5:: with SMTP id u5mr10645077ilq.178.1603101246671; Mon, 19 Oct 2020 02:54:06 -0700 (PDT) MIME-Version: 1.0 References: <36B6ACBF-1FBD-4A77-8875-B080242FED67@gmail.com> In-Reply-To: <36B6ACBF-1FBD-4A77-8875-B080242FED67@gmail.com> From: Fabien Imbault Date: Mon, 19 Oct 2020 11:53:55 +0200 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000058d04605b203184d" Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:54:16 -0000 --00000000000058d04605b203184d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Fair enough ;-) Cheers Fabien On Mon, Oct 19, 2020 at 11:47 AM Yaron Sheffer wrote: > Hi Fabien, > > > > I think we all have a bad experience with huge issue backlogs, which is > one reason why creating issues for all these comments would be a pain. > > > > I would suggest that the editor(s) should address all the simple issues > (those where the text can be easily fixed or clarified, or those where I > clearly don=E2=80=99t know what I=E2=80=99m talking about). Then I will o= pen issues for the > remaining ones. > > > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Monday, October 19, 2020 at 10:08 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > Hi, > > > > These are very useful feedback. We do need to take the time to read again > the entire document, as it was patched up to the last minute. > > > > There are many places where several options are considered (some of which > might need further explanation, from some of the questions I read). The > objective was to openly expose some design choices for the group to > consider, especially when it was new to the spec or when there was no > consensus. And then decide what to keep with the group. > > > > It will be worth investigating every comment. Considering their number, > I'm just wondering if the mailing list is the best place to follow up the > details. Wouldn't issues on github be better suited for that task? (as th= e > document source will be on github anyway). > > > > Cheers > > Fabien > > > > On Sun, Oct 18, 2020 at 9:44 PM Yaron Sheffer > wrote: > > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, s= o > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I hav= e > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these action= s > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generi= c > sense (management API, identity API), so maybe replace with "RS, typicall= y > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is to= o > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verg= es > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not lis= t > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of thi= s > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to bot= h > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify th= e > RO in the context of the AS and can't be used as communication channels b= y > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather tha= n > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choos= e > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here = is > not an RC interaction mode, it is something else, and should probably hav= e > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if t= he > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --00000000000058d04605b203184d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

Fair e= nough ;-)

Cheers
Fabien

<= div class=3D"gmail_quote">
On Mon, Oct= 19, 2020 at 11:47 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Fabien,

= =C2=A0

I think we all have a bad experienc= e with huge issue backlogs, which is one reason why creating issues for all= these comments would be a pain.

=C2=A0

I would suggest that the edito= r(s) should address all the simple issues (those where the text can be easi= ly fixed or clarified, or those where I clearly don=E2=80=99t know what I= =E2=80=99m talking about). Then I will open issues for the remaining ones.<= u>

=C2=A0

Thanks,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Yaron

=C2=A0

<= span style=3D"font-size:12pt;color:black">From: Fabien Imbault <fabien.imbault@gmail.com>
Dat= e: Monday, October 19, 2020 at 10:08
To: Yaron Sheffer <yaronf.ietf@gmail.= com>
Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [G= NAP] Review of draft-ietf-gnap-core-protocol-00 (first half)<= /span>

=C2=A0

<= div>

Hi,=C2=A0

=C2=A0

These= are very useful feedback. We do need to take the time to read again the en= tire document, as it was patched up to the last minute.

=C2=A0

There are many places where several options are considered (= some of which might need further explanation, from some of the questions I = read). The objective was to openly expose some design choices for the group= to consider, especially when it was new to the spec or when there was no c= onsensus. And then decide what to keep with the=C2=A0group.=C2=A0=

=C2=A0

It will be worth investigating every comment. Cons= idering their=C2=A0number, I'm just wondering if the mailing list is th= e best place to follow up the details. Wouldn't issues on github be bet= ter suited for that task? (as the document source will be on github anyway)= .=C2=A0

=C2=A0=

Cheers

Fabien

=C2=A0

On Sun, O= ct 18, 2020 at 9:44 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:=

Hi Justin= , all,

=C2=A0

The draft has undergone major changes since we started t= he design team, so I spent some time reviewing it. I only got as far as Sec= . 3, and I fully intend to review the remainder of the document. But I figu= red since I have so many comments, I might as well send out what I have.=

=C2=A0

* General comment: we have dozens, maybe hundreds of variants/opt= ions here. I think we need to define a must-implement subset, or we will ne= ver reach interoperability.

* Abstr= act: the boilerplate text (MUST etc.) usually goes to the Introduction, not= the Abstract.

* 1. "The reque= sting party operating the software" - I think these actions are typica= lly performed by the resource owner, who is not necessarily the requesting = party.

* RS, aka API: we are using = the word "API" several times in a more generic sense (management = API, identity API), so maybe replace with "RS, typically a protected A= PI".

* 1.2, "key" is= a too generic term in the context of a security protocol. Can we call it s= omething more specific, maybe "holder identity key"?

* 1.3.1. "augmented with a hash of the sec= urity information" - this is too implementation-specific, suggest &quo= t;is cryptographically bound to the security information". In general,= step (7) is way too detailed, and verges on the normative.

* 1.3.2: it is unclear to me what the goal of the = user-code interaction is, in other words what is the threat model. If it= 9;s just "second factor, something you have", then an OTP MFA dev= ice would be simpler and offer the same security.

* 1.3.5 (4): Typically the access token would not be sent on= ce it is expired, right? Let's make the example more realistic.<= u>

* 2: "OpenID Connect claims request&q= uot; - why not "identity claims request" (which just happens to b= e similar to the OpenID request)?

*= Never liked the "dolphin" here... If this is listed under "= actions", it should be a verb, e.g. "swim".

* 2.1: an array for a single AT vs. an object for m= ultiple ATs? This is extremely non-intuitive and probably ugly to code. Als= o, why should (multiple) tokens be named if a single token doesn't have= to, why not list them in an array instead?

* 2.1.1, "locations": are these really URIs or just URLs= ? On the other hand, if these are URIs, why do we need a separate "ide= ntifier"? There's too much semantic overlap between "type&quo= t;, "location" and "identifier" - specifying just "= ;type" may be sufficient.

* 2.= 1.1: it's implied but should be spelled out that the semantics of this = example is the cross product of permissions: I am requesting to read and wr= ite and "dolphin" both "metadata" and "images"= ;, and that applies to both "locations" - 12 different possible a= ctions.

* 2.1.2: I don't see th= e value of the notion of "expansion". It is sufficient that the s= tring is understood by the AS.

* 2.= 1.2, "in some situations the value is intended to be seen and understo= od be the RC developer" - shouldn't we require this value to be al= ways fully documented by the AS owner, so that the RC knows what it is requ= esting?

* 2.1.4: why are flags repr= esented as resources? The answer, "this is how OAuth 2 does it" i= s not great.

* "the each acces= s tokens" -> each access token.

* I suggest to extend the editor's note to clarify what is the use= case, so that the group can decide whether split tokens are indeed necessa= ry.

* Why is key binding of the acc= ess token even optional?

* 2.2, &qu= ot;Subject identifiers requested by the RC serve only to identify the RO in= the context of the AS and can't be used as communication channels by t= he RC" - this sounds a bit naive, people will do that anyway. So why i= s this a useful statement? (And similarly in 3.4)

* 2.3: what's the benefit of including a URI (URL really= ) in "display"? Do we really want the user (RO) to click links pr= ovided by the RC?

* 2.3: why are we= sending a JWK *as well as* a cert? Are we checking that the cert contains = the same public key as the cert?

* = 2.3, " the AS MUST ensure that the key used to sign the request... is = associated with the instance identifier" - can we be much more specifi= c here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he cert? This "association" is never clarified, either here or in= Sec. 8.

* 2.3.2: allowing to send = the key in multiple formats virtually invites security vulnerabilities. Why= is this a good thing?

* 2.3.2: cer= t#256 is not a key, it's an identifier. Why do we include it here? Note= that in Sec. 8.3 you are using the full certificate rather than the finger= print.

* 2.3.2: why are we using ra= w PEM certificates instead of the JOSE representation?

* 2.3.3: For obvious security reasons, I suggest adding= : The AS MAY choose to avoid displaying an arbitrary URI. RC developers mus= t only assume that the "name" field will be displayed.<= /u>

* 2.3.4, "created just for this request&= quot; -> created just for this series of requests.

* 2.3.4: I suggest referring to RCs that present unknown= keys as "anonymous RC", and then in 2.4, say that the AS MUST NO= T accept any assertions from an anonymous RC.

* 2.4: IMO assertion validation is a MUST, and we should specify= what we require for every assertion type we allow.

* 2.4: moreover, when possible, the AS MUST match the asse= rtions to the presented sub_id. It may be a hint, but you're not allowe= d to lie.

* 2.4, "If the ident= ified RQ does not match the RO present at the AS" - I thought there ar= e cases where the RQ is different from the RO. Also, I am wondering why thi= s is a SHOULD, not a MUST.

* 2.4.1 = (but probably applicable to any references): what is the lifetime of the re= ference? As an RC, how long can I assume the user reference is still valid?=

* 2.5: "preferred_locales&quo= t; is obviously not a mode of interaction. Why is it bundled here?

* 2.5: the way "callback" is desc= ribed here is as a capability, not an interaction mode. The example only st= rengthens this view, "callback" is a modifier of the "redire= ct" mode.

* 2.5: "use cod= e" -> user code.

* 2.5.1: t= his unnecessary polymorphism IMO just complicates implementations and preve= nts extensibility. Instead, I would suggest:

redirect: {}

redirect:{ma= x_length: 255}

redirect:{max_length= : 255, callback: {...}}

* 2.5.2: th= e "app" option is problematic, as you already note. The RC may no= t even know if a given URL will result in an application launching.<= u>

* 2.5.2: and shouldn't the RC include = a list of supported applications? (Which would have lovely privacy implicat= ions.)

* 2.5.3: there's a paren= thetical discussion on whether the URL is unique. But the nonce parameter i= mplies that the "hash" parameter is unique per request, making th= is discussion moot.

* 2.5.3: even i= f we need a different kind of post-interaction "redirect", where = the RC is not involved, there must be a way to ensure that the RC receives = positive (cryptographically protected) confirmation that the authorization = was successful. In other words, what we're discussing here is not an RC= interaction mode, it is something else, and should probably have a separat= e protocol element to describe it.

= * 2.5.3: In the example for "interact" as an array (which I suppo= rt), the second "redirect" and "user_code" should be in= dependent elements of the array, not members of an object. This assumes the= y are truly independent interaction modes.

* 2.5.3.1: what do= es "RQ is present on the request" mean?

* 2.5.3.2: = typo: HTTP the request.

* 2.7: this= seems to assume a short access token (which implies a bearer token). What = if we want to use longer self-contained access tokens containing full keys?= Should we have a separate "grant_id" value instead?

* 2.8: another problem with this stanza is that= the RC needs to know a priority that the AS supports it. What happens if t= he AS doesn't?

* 2.8: I suggest= to move this section into a separate I-D, or at least a separate appendix.=

* 2.9: it makes sense to bundle ex= tensions and the "capabilities" section into one.

* 2.9: The AS MUST ignore any unknown extension.

* 3: it's confusing that we'= re using access_token for two different things. Maybe we could change the R= C/AS one to "as_access_token"?

* 3.1: MAY vary *by* request.

* 3.1: how is the client behavior "deterministic in all cases" -= how does the RC know whether the AS allows continuation or only allows one= request at a time?

* 3.2.1: the &q= uot;value" of the access token is opaque in some cases (bearer token) = but not in others.

* 3.2.1: The ASC= II restriction on "value" is insufficient. Needs to be printable = ASCII, 0x20<v<=3D0x7f. And I'm not sure if this doesn't leave= some characters that still need to be escaped.

* 3.2.1: why is "expires_in" optional? Typically a= ccess tokens are not revoked, and the RC needs a way to manage their lifeti= me.

* 3.2.1: "resources" = refers to this same section. Did you mean 2.1.2, or are we missing a subsec= tion describing resources/rights?

*= 3.2.1: "key": another polymorphism alert!

* 3.2.1: the example at the bottom of the section talks a= bout a way to present the token, I believe this discussion is out of contex= t here.

* 3.3: the AS knows now whi= ch interaction modes are available. Why not pick just one for its response,= to simplify the protocol? As one example, the AS can then more easily deci= de on timeout behavior.

* 3.3.3: Su= ggest to add to the last paragraph: If the RC does not receive a callback u= ntil an RC-determined timeout occurs, the RC MUST act as if the entire requ= est failed.

* 3.4: "updated_at= ": Unix time is nice, but for absolute time it's common to use ISO= 8601 format.

* 3.6: YES, the "= ;error" element is exclusive!

= * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I = think it could work nicely here.

* = 10.4: "indicating that GNAP" - sentence is broken.<= /p>

* This "speculative" access is not usef= ul if the response is only a MAY. Why would the RC try it if it is unlikely= to provide useful information?

* 1= 5: the BCP195 ref is broken - the author names are missing (yes I am one of= them...).

* Appendix D: can we nam= e the first scenario, maybe "Simple API Access"?

--
TXAuth mailing list
TXAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/txauth

--00000000000058d04605b203184d-- From nobody Mon Oct 19 06:39:33 2020 Return-Path: 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 835393A09EA for ; Mon, 19 Oct 2020 06:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6TLlsH8iOS8L for ; Mon, 19 Oct 2020 06:39:30 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42573A09D4 for ; Mon, 19 Oct 2020 06:39:29 -0700 (PDT) Received: from [192.168.1.4] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09JDdQLd029795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 09:39:27 -0400 From: Justin Richer Message-Id: <251BDA6B-AE15-4AD3-8D1E-94D1487D2715@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_59B2D6A2-2775-49BB-97E6-B8CB567FB140" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 19 Oct 2020 09:39:26 -0400 In-Reply-To: <9CC252F5-F88F-4068-8AB8-D9E4B8A48B2D@gmail.com> Cc: txauth@ietf.org To: Yaron Sheffer References: <9CC252F5-F88F-4068-8AB8-D9E4B8A48B2D@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Adopted: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 13:39:32 -0000 --Apple-Mail=_59B2D6A2-2775-49BB-97E6-B8CB567FB140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, chairs. As you all probably saw over the weekend, I have = published the design team draft as draft-ietf-gnap-core-protocol-00: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html = This is the same text as the document that was adopted by the WG: = https://www.ietf.org/rfcdiff?url1=3Ddraft-richer-transactional-authz-14&ur= l2=3Ddraft-ietf-gnap-core-protocol-00 = I have pushed the source markdown file and a basic README to the = group=E2=80=99s GitHub repository: https://github.com/ietf-wg-gnap/core-protocol = =E2=80=94 Justin > On Oct 17, 2020, at 8:18 AM, Yaron Sheffer = wrote: >=20 > We have clear WG consensus to adopt the draft, thank you all for your = support. > =20 > Justin, can you please resubmit the draft as-is (no textual changes) = as a working group draft. I would suggest the name = draft-ietf-gnap-core-protocol. We will ask that the document source will = be managed on GitHub [1]. > =20 > The chairs will shortly announce additional draft editor(s). If you = are interested, please drop us a note. Note that this is a serious = commitment: this is a large and complex document and will take some time = and likely quite a few revisions before it is published. > =20 > This is a good time to review the document and submit comments to the = mailing list! > =20 > Thanks, > Yaron > =20 > [1] https://github.com/ietf-wg-gnap > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_59B2D6A2-2775-49BB-97E6-B8CB567FB140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, chairs. As you all probably saw over the weekend, I = have published the design team draft as = draft-ietf-gnap-core-protocol-00:

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html

This = is the same text as the document that was adopted by the WG:

https://www.ietf.org/rfcdiff?url1=3Ddraft-richer-transactional-= authz-14&url2=3Ddraft-ietf-gnap-core-protocol-00

I have pushed the source = markdown file and a basic README to the group=E2=80=99s GitHub = repository:

https://github.com/ietf-wg-gnap/core-protocol

 =E2=80=94 = Justin

On Oct 17, 2020, at 8:18 AM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

We have clear WG consensus = to adopt the draft, thank you all for your support.
 
Justin, can you please = resubmit the draft as-is (no textual changes) as a working group draft. = I would suggest the name draft-ietf-gnap-core-protocol. We will ask that = the document source will be managed on GitHub [1].
 
The chairs will shortly = announce additional draft editor(s). If you are interested, please drop = us a note. Note that this is a serious commitment: this is a large and = complex document and will take some time and likely quite a few = revisions before it is published.
 
This is a good time to review the document and = submit comments to the mailing list!
 
Thanks,
          &nb= sp;     Yaron
 
[1] https://github.com/ietf-wg-gnap
-- TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_59B2D6A2-2775-49BB-97E6-B8CB567FB140-- From nobody Mon Oct 19 07:58:38 2020 Return-Path: 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 954473A005E for ; Mon, 19 Oct 2020 07:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 w5lx3gb7J7L2 for ; Mon, 19 Oct 2020 07:58:34 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 478373A00D2 for ; Mon, 19 Oct 2020 07:58:34 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id l16so368073ilj.9 for ; Mon, 19 Oct 2020 07:58:34 -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=j34Jx6E0qMJhdAPTEDBxt1Tsv506QX+SlSE+PzLXgXA=; b=OStwB5X/5U6Foq5/cbsm7q1zvw2pasT1p7+SlHylsVvg5EvPgI6hrRko3BGB43iH9w XlL1PcRXT0oK59oKannjGdpZVJDyviiJf5aR1/OT/ab35ds4MMHOhL6CzMVMMB4Ln+Dn IYUfEJkKsCfOwexFyydF1VRXNNzicgUIX9MP62QnNHhwVw1FOYSEki18JCoLfX24GK92 6T+JIfXKp5jfbChipT/A7CsND5YvDIZM9YB/pUbZxLY2Pb5do/XB5lQ0ZJ4nhqeRW74+ 2lscQT1vCP4f5aCkXh7JGU8o8nAWfXGamabxeVCEg426aA68Augwjipke+P6Zc9rdPMT JIAQ== 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=j34Jx6E0qMJhdAPTEDBxt1Tsv506QX+SlSE+PzLXgXA=; b=Rjs0kY4IP1aJbd9Eu1CSz1Hkp9RP1KysqZriHpbJlOPsQ2PX8pz3YVSTxuIvyedtFl oHCvpPyOnzVP66Rsn7606toGox4wgrwxZdo/Y+C07bzNmSRTE4yyxcNF3ADYUQxWPC7D Gxq4/qgj+MY5AwsszBsz0/xARYAs2NjDRqDvEKiBay07zwj2cE9+TVi6iaeMwhSZQ9e9 W8ZLpHFkuoQoWfz7YrLLF+6gmg8NyFMKqvGvFR+Z4qMMTnZvjonnyZR8xQt0Bp1flxIJ rGdzAikKn5l/WXYLP45qzyWJ5mCkD/zoO4unwWcmPpORjwXw4eIHxsFPCy00HtATxJau AlyA== X-Gm-Message-State: AOAM5322FJ2EbtVr1V72goc7ivoVREndw9AyW0OT7DtwCdVKVpIKC22x eKFOlj4OSqmEODlje3RFZFtN+8+FPPep+VyuSUE= X-Google-Smtp-Source: ABdhPJzWY1Ol3l6Y8ni70pbGosi8VC54NxcnZRJai9cwxr/ZoInvSNI1IBCtaOHVTdT3XNziIePwjGSEVhNxH5thnNc= X-Received: by 2002:a92:ae0a:: with SMTP id s10mr245262ilh.289.1603119513361; Mon, 19 Oct 2020 07:58:33 -0700 (PDT) MIME-Version: 1.0 References: <95C5E06D-C017-4BD1-8CA1-0AF07E3DB3AE@gmail.com> In-Reply-To: <95C5E06D-C017-4BD1-8CA1-0AF07E3DB3AE@gmail.com> From: Fabien Imbault Date: Mon, 19 Oct 2020 16:58:22 +0200 Message-ID: To: Yaron Sheffer Cc: Tom Jones , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000020632505b20759be" Archived-At: Subject: Re: [GNAP] User code, was Re: Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:58:36 -0000 --00000000000020632505b20759be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User code is an interaction mode that you use when an interaction via a browser is not possible. For instance, a small device that can display a code, so that the end-user can easily enter that code through a predetermined endpoint (typically through a mobile phone). On Mon, Oct 19, 2020 at 11:52 AM Yaron Sheffer wrote: > Hi Tom, > > > > Thanks for your response. I would like to focus on one point. > > > > The document does not explain what the user code solution tries to > achieve, and I honestly don=E2=80=99t understand the exact use case(s) my= self. If > you could write up a paragraph, we could include it in the document for m= y > own and others=E2=80=99 edification. > > > > Regards, > > Yaron > > > > *From: *Tom Jones > *Date: *Monday, October 19, 2020 at 00:38 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > then i guess we must address the entire email, which is not helpful. Her= e > are at least a few of my thoughts. > > 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > >> that is not more specific. if you want to understand the source of the > key then perhaps the entire jwk element needs to be augmented. > > 1.3.2: it is unclear to me what the goal of the user-code interaction is, > in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > >> first of all, you are wrong in your assessment, second that is not all > that the user-code interaction supplies. > > 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > >> I am already running into this as a problem with strings in OIDC. I > believe we need a better way to expand strings into structures. I propos= ed > the use of 3part jose structures as a solution. > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > >> I hope you are not proposing that users actually see any of this? Tha= t > would be grotesque. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > >> I plan on including assertions that do not need to be validated. I > believe it is not up to the sender whether the receiver validates the > assertion. > > > > In general I find that many of your comments are not trivial and need > deeper analysis. > > Peace ..tom > > > > > > On Sun, Oct 18, 2020 at 1:00 PM Yaron Sheffer > wrote: > > We haven=E2=80=99t discussed this process yet, and the default IETF proce= ss is, > everything goes through the mailing list. > > > > IMO small things can be quickly cleaned up (fixed or rejected), and we ca= n > open GH issues for bigger things. > > > > Thanks, > > Yaron > > > > *From: *Tom Jones > *Date: *Sunday, October 18, 2020 at 22:47 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > why are you doing this? Should these be issues now? > > Peace ..tom > > > > > > On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer > wrote: > > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, s= o > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I hav= e > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these action= s > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generi= c > sense (management API, identity API), so maybe replace with "RS, typicall= y > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is to= o > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verg= es > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not lis= t > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of thi= s > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to bot= h > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify th= e > RO in the context of the AS and can't be used as communication channels b= y > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather tha= n > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choos= e > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here = is > not an RC interaction mode, it is something else, and should probably hav= e > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if t= he > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000020632505b20759be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
User code is an interaction mode that you= use when an interaction via a browser is not possible. For instance, a sma= ll device that can display a code, so that the end-user can easily enter th= at code through a predetermined endpoint (typically through a mobile phone)= .=C2=A0

On Mon, Oct 19, 2020 at 11:52 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Tom,

=C2=A0

Thanks for your response= . I would like to focus on one point.

=C2=A0

The document does not exp= lain what the user code solution tries to achieve, and I honestly don=E2=80= =99t understand the exact use case(s) myself. If you could write up a parag= raph, we could include it in the document for my own and others=E2=80=99 ed= ification.

=C2=A0

=

Regards,

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Yaron

=C2=A0=

From: Tom Jones <thomasclinganjones@gmail.com>
Date: Monday, October 19, 2020 at 00:38
To: Yaron= Sheffer <yar= onf.ietf@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org>
Subj= ect: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half)=

=C2=A0=

then i guess we must address the= =C2=A0entire email, which is not helpful.=C2=A0 Here are at=C2=A0least a fe= w of my thoughts.

1.2, "k= ey" is a too generic term in the context of a security protocol. Can w= e call it something more specific, maybe "holder identity key"?

>> that is not more= specific. if you want to understand the source of the key then perhaps the= entire jwk element needs to be augmented.

1.3.2: it is unclear to me what the goal of the user-cod= e interaction is, in other words what is the threat model. If it's just= "second factor, something you have", then an OTP MFA device woul= d be simpler and offer the same security.

>> first of all, you are wrong in your assessment, second that= is not all that the user-code interaction supplies.

2.1.2: I don't see the value of the notion of "e= xpansion". It is sufficient that the string is understood by the AS.

>> I am already run= ning into this as a problem with strings in OIDC. I believe we need a bette= r way to expand strings into structures.=C2=A0 I proposed the use of 3part = jose structures=C2=A0as a solution.

* 2.3: what's the benefit of including a URI (URL really) i= n "display"? Do we really want the user (RO) to click links provi= ded by the RC?

>> = I hope you are not proposing that users actually see any of this?=C2=A0 Tha= t would be grotesque.

* = 2.4: IMO assertion validation is a MUST, and we should specify what we requ= ire for every assertion type we allow.

>> I plan on including assertions that do not need to = be validated. I believe it is not up to the sender whether the receiver val= idates the assertion.

=C2=A0

In general I find t= hat many of your comments are not trivial and need deeper analysis.

Peac= e ..tom

= =C2=A0

=C2=A0

On Sun, Oct 18, 2020 at 1:00 PM Yaron= Sheffer <yar= onf.ietf@gmail.com> wrote:

We haven=E2=80=99t discussed this pr= ocess yet, and the default IETF process is, everything goes through the mai= ling list.

=C2=A0

=

IMO small things can be quickly cleaned up (fixed or= rejected), and we can open GH issues for bigger things.

<= p class=3D"MsoNormal">=C2=A0

Thanks= ,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Tom Jones <thomasclinganjones@gmail.com>
Date: Sunday, = October 18, 2020 at 22:47
To: Yaron Sheffer <yaronf.ietf@gmail.com>
= Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [GNAP] Review of= draft-ietf-gnap-core-protocol-00 (first half)

=C2=A0

why are you doing this? Should these be issues now?

Peace= ..tom

=C2= =A0

=C2=A0

<= div>

On Sun, Oct 18, 2020 at 12:44 PM Yaron Shef= fer <yaronf.i= etf@gmail.com> wrote:

Hi Justin, all,

=C2=A0

The draft has undergone major change= s since we started the design team, so I spent some time reviewing it. I on= ly got as far as Sec. 3, and I fully intend to review the remainder of the = document. But I figured since I have so many comments, I might as well send= out what I have.

=C2=A0<= /u>

* General comment: we have dozens, maybe hund= reds of variants/options here. I think we need to define a must-implement s= ubset, or we will never reach interoperability.

* Abstract: the boilerplate text (MUST etc.) usually goes to= the Introduction, not the Abstract.

* 1. "The requesting party operating the software" - I think th= ese actions are typically performed by the resource owner, who is not neces= sarily the requesting party.

* RS, = aka API: we are using the word "API" several times in a more gene= ric sense (management API, identity API), so maybe replace with "RS, t= ypically a protected API".

* 1= .2, "key" is a too generic term in the context of a security prot= ocol. Can we call it something more specific, maybe "holder identity k= ey"?

* 1.3.1. "augmented = with a hash of the security information" - this is too implementation-= specific, suggest "is cryptographically bound to the security informat= ion". In general, step (7) is way too detailed, and verges on the norm= ative.

* 1.3.2: it is unclear to me= what the goal of the user-code interaction is, in other words what is the = threat model. If it's just "second factor, something you have"= ;, then an OTP MFA device would be simpler and offer the same security.<= /u>

* 1.3.5 (4): Typically the access toke= n would not be sent once it is expired, right? Let's make the example m= ore realistic.

* 2: "OpenID Co= nnect claims request" - why not "identity claims request" (w= hich just happens to be similar to the OpenID request)?

* Never liked the "dolphin" here... If this = is listed under "actions", it should be a verb, e.g. "swim&q= uot;.

* 2.1: an array for a single = AT vs. an object for multiple ATs? This is extremely non-intuitive and prob= ably ugly to code. Also, why should (multiple) tokens be named if a single = token doesn't have to, why not list them in an array instead?=

* 2.1.1, "locations": are these re= ally URIs or just URLs? On the other hand, if these are URIs, why do we nee= d a separate "identifier"? There's too much semantic overlap = between "type", "location" and "identifier" -= specifying just "type" may be sufficient.

* 2.1.1: it's implied but should be spelled out that = the semantics of this example is the cross product of permissions: I am req= uesting to read and write and "dolphin" both "metadata"= and "images", and that applies to both "locations" - 1= 2 different possible actions.

* 2.1= .2: I don't see the value of the notion of "expansion". It is= sufficient that the string is understood by the AS.

* 2.1.2, "in some situations the value is intended t= o be seen and understood be the RC developer" - shouldn't we requi= re this value to be always fully documented by the AS owner, so that the RC= knows what it is requesting?

* 2.1= .4: why are flags represented as resources? The answer, "this is how O= Auth 2 does it" is not great.

= * "the each access tokens" -> each access token.=

* I suggest to extend the editor's note to c= larify what is the use case, so that the group can decide whether split tok= ens are indeed necessary.

* Why is = key binding of the access token even optional?

* 2.2, "Subject identifiers requested by the RC serve only= to identify the RO in the context of the AS and can't be used as commu= nication channels by the RC" - this sounds a bit naive, people will do= that anyway. So why is this a useful statement? (And similarly in 3.4)<= /u>

* 2.3: what's the benefit of inclu= ding a URI (URL really) in "display"? Do we really want the user = (RO) to click links provided by the RC?

* 2.3: why are we sending a JWK *as well as* a cert? Are we checking t= hat the cert contains the same public key as the cert?

* 2.3, " the AS MUST ensure that the key used to s= ign the request... is associated with the instance identifier" - can w= e be much more specific here, e.g. the instance_id MUST be byte-identical t= o the Common Name of the cert? This "association" is never clarif= ied, either here or in Sec. 8.

* 2.= 3.2: allowing to send the key in multiple formats virtually invites securit= y vulnerabilities. Why is this a good thing?

* 2.3.2: cert#256 is not a key, it's an identifier. Why do we= include it here? Note that in Sec. 8.3 you are using the full certificate = rather than the fingerprint.

* 2.3.= 2: why are we using raw PEM certificates instead of the JOSE representation= ?

* 2.3.3: For obvious security rea= sons, I suggest adding: The AS MAY choose to avoid displaying an arbitrary = URI. RC developers must only assume that the "name" field will be= displayed.

* 2.3.4, "created = just for this request" -> created just for this series of requests.=

* 2.3.4: I suggest referring to RC= s that present unknown keys as "anonymous RC", and then in 2.4, s= ay that the AS MUST NOT accept any assertions from an anonymous RC.<= u>

* 2.4: IMO assertion validation is a MUST,= and we should specify what we require for every assertion type we allow.

* 2.4: moreover, when possible, the = AS MUST match the assertions to the presented sub_id. It may be a hint, but= you're not allowed to lie.

* 2= .4, "If the identified RQ does not match the RO present at the AS"= ; - I thought there are cases where the RQ is different from the RO. Also, = I am wondering why this is a SHOULD, not a MUST.

* 2.4.1 (but probably applicable to any references): what is= the lifetime of the reference? As an RC, how long can I assume the user re= ference is still valid?

* 2.5: &quo= t;preferred_locales" is obviously not a mode of interaction. Why is it= bundled here?

* 2.5: the way "= ;callback" is described here is as a capability, not an interaction mo= de. The example only strengthens this view, "callback" is a modif= ier of the "redirect" mode.

* 2.5: "use code" -> user code.

* 2.5.1: this unnecessary polymorphism IMO just complicates = implementations and prevents extensibility. Instead, I would suggest:

redirect: {}

redirect:{max_length: 255}

redirect:{max_length: 255, callback: {...}}

* 2.5.2: the "app" option is problematic, as you = already note. The RC may not even know if a given URL will result in an app= lication launching.

* 2.5.2: and sh= ouldn't the RC include a list of supported applications? (Which would h= ave lovely privacy implications.)

*= 2.5.3: there's a parenthetical discussion on whether the URL is unique= . But the nonce parameter implies that the "hash" parameter is un= ique per request, making this discussion moot.

* 2.5.3: even if we need a different kind of post-interaction &= quot;redirect", where the RC is not involved, there must be a way to e= nsure that the RC receives positive (cryptographically protected) confirmat= ion that the authorization was successful. In other words, what we're d= iscussing here is not an RC interaction mode, it is something else, and sho= uld probably have a separate protocol element to describe it.=

* 2.5.3: In the example for "interact"= as an array (which I support), the second "redirect" and "u= ser_code" should be independent elements of the array, not members of = an object. This assumes they are truly independent interaction modes.

* 2.5.3.1: what does "RQ is present on the request" mean= ?

* 2.5.3.2: typo: HTTP the request.

* 2.7: this seems to assume a short access token (which imp= lies a bearer token). What if we want to use longer self-contained access t= okens containing full keys? Should we have a separate "grant_id" = value instead?

* 2.8: another probl= em with this stanza is that the RC needs to know a priority that the AS sup= ports it. What happens if the AS doesn't?

* 2.8: I suggest to move this section into a separate I-D, or at= least a separate appendix.

* 2.9: = it makes sense to bundle extensions and the "capabilities" sectio= n into one.

* 2.9: The AS MUST igno= re any unknown extension.

* 3: it&#= 39;s confusing that we're using access_token for two different things. = Maybe we could change the RC/AS one to "as_access_token"?<= u>

* 3.1: MAY vary *by* request.

* 3.1: how is the client behavior "determi= nistic in all cases" - how does the RC know whether the AS allows cont= inuation or only allows one request at a time?

* 3.2.1: the "value" of the access token is opaque in= some cases (bearer token) but not in others.

* 3.2.1: The ASCII restriction on "value" is insuffici= ent. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I'm not sur= e if this doesn't leave some characters that still need to be escaped.<= u>

* 3.2.1: why is "expires_in&qu= ot; optional? Typically access tokens are not revoked, and the RC needs a w= ay to manage their lifetime.

* 3.2.= 1: "resources" refers to this same section. Did you mean 2.1.2, o= r are we missing a subsection describing resources/rights?

* 3.2.1: "key": another polymorphism aler= t!

* 3.2.1: the example at the bott= om of the section talks about a way to present the token, I believe this di= scussion is out of context here.

* = 3.3: the AS knows now which interaction modes are available. Why not pick j= ust one for its response, to simplify the protocol? As one example, the AS = can then more easily decide on timeout behavior.

* 3.3.3: Suggest to add to the last paragraph: If the RC doe= s not receive a callback until an RC-determined timeout occurs, the RC MUST= act as if the entire request failed.

* 3.4: "updated_at": Unix time is nice, but for absolute time = it's common to use ISO 8601 format.

* 3.6: YES, the "error" element is exclusive!<= /p>

* 3.6: in SecEvent we tried to use RFC 7807 "= ;problem details", I think it could work nicely here.

* 10.4: "indicating that GNAP" - sentence= is broken.

* This "speculativ= e" access is not useful if the response is only a MAY. Why would the R= C try it if it is unlikely to provide useful information?

=

* 15: the BCP195 ref is broken - the author names ar= e missing (yes I am one of them...).

* Appendix D: can we name the first scenario, maybe "Simple API Acce= ss"?

--
TXAuth= mailing list
TXAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000020632505b20759be-- From nobody Mon Oct 19 10:46:18 2020 Return-Path: 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 6F2CA3A0EC5 for ; Mon, 19 Oct 2020 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=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 (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 R1XgMrzLqkTp for ; Mon, 19 Oct 2020 10:46:14 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 973D13A0EC3 for ; Mon, 19 Oct 2020 10:46:14 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id h10so821254oie.5 for ; Mon, 19 Oct 2020 10:46:14 -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=OIsmh0o+bfVq+zjJo/cojriFFG1T3kX9EJhAmfaO7H8=; b=OlcjNw3W3wmCfEfrndLn1ijnF5+YvEofsiAzV9uvW9c0ZwAvL+ailfHsjQAbP4L9Rm WUdKOGUItmnJ0V001bgRsbFczBRO/UiE89ue0xQ8EaCClGD+DHdWVCTXck1shwZTSE6D Te3AvwXfK/UXROG783qHdz3FnQNSauPrSly9/0WSmEM4GtCItPjuaWItCalooMn1x7dX tCEac/1IYr1j6wqMsQCYst9SF7yPBQ3MKUipxnVftOAVRa/1jWvtaYIH/NrGlqlBJCZK XUseDdX4xo1GVYi4wOqYwZUDI9hBOrn45P73nQa+9hty4SRdlZYyxFuuvRkZpWgPjzW0 j7Uw== 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=OIsmh0o+bfVq+zjJo/cojriFFG1T3kX9EJhAmfaO7H8=; b=RGGroRX69b6P7HPjAoTVZQ09PASIgR20hcMzJweYHGt1nhBDwZNhumORZ+gC20W+Cm oFXJhR3h6aRTx4i/0B0KlzBHqoCK8WrnKo5yItpY7FdircgddeuD5mpYDY6Ug3alRAxg WOFuL6uKvkPqy7KeugtlIgKRFA/V3g4aAiMkmFgLH1Zk/FDaoLxXSme2oU/Md1Y/OqSD rXpvybIxKcanksSL4uAHDlUzCAdNxtqmP118PRM1/7Hg3MTM2N9yDNiPjoLZF0aHbDIO BtxBur7s319NRjdWDR7gYifuYr1uhhmCy/gZe22YvY9vvVEwDUOu6xHyGaenc0S2vzir +eBA== X-Gm-Message-State: AOAM533Ys0C30PAMrKZX6/iQS8bO6JFEVYB2GtayJfqBebCVP136qVuS o5dLgo+nzFwa8I4ninsj0P/dXyK6QAhW2nYo6nhmQSzB5z1yAg== X-Google-Smtp-Source: ABdhPJzhSviQDUZzpeLFuBT+GFepdQuqlE/Kwo9XV3QrAL1zM8Qh/LEnbcroJxhoxy7K/omoUW8qeE7bVQPdJ3WpTSM= X-Received: by 2002:aca:cc0e:: with SMTP id c14mr370060oig.131.1603129573696; Mon, 19 Oct 2020 10:46:13 -0700 (PDT) MIME-Version: 1.0 References: <95C5E06D-C017-4BD1-8CA1-0AF07E3DB3AE@gmail.com> In-Reply-To: <95C5E06D-C017-4BD1-8CA1-0AF07E3DB3AE@gmail.com> From: Tom Jones Date: Mon, 19 Oct 2020 10:46:02 -0700 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000c4ea8605b209b0e7" Archived-At: Subject: Re: [GNAP] User code, was Re: Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:46:17 -0000 --000000000000c4ea8605b209b0e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok - several others have been asking as well. I wrote up this page https://tcwiki.azurewebsites.net/index.php?title=3DApps_on_User_Devices basically there are assertions from the programmer of the app, and from the app itself that are passed in the id token (whatever) from the user device. Note that this means that not all assertions are signed by the same key in this case! Nor are all the attributes about the subject. Some are just in support of the level of assurance. The big difference with FIDO U2F and II is that the keys are bound to the user in the device, not in the RP. Peace ..tom On Mon, Oct 19, 2020 at 2:52 AM Yaron Sheffer wrote= : > Hi Tom, > > > > Thanks for your response. I would like to focus on one point. > > > > The document does not explain what the user code solution tries to > achieve, and I honestly don=E2=80=99t understand the exact use case(s) my= self. If > you could write up a paragraph, we could include it in the document for m= y > own and others=E2=80=99 edification. > > > > Regards, > > Yaron > > > > *From: *Tom Jones > *Date: *Monday, October 19, 2020 at 00:38 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > then i guess we must address the entire email, which is not helpful. Her= e > are at least a few of my thoughts. > > 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > >> that is not more specific. if you want to understand the source of the > key then perhaps the entire jwk element needs to be augmented. > > 1.3.2: it is unclear to me what the goal of the user-code interaction is, > in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > >> first of all, you are wrong in your assessment, second that is not all > that the user-code interaction supplies. > > 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > >> I am already running into this as a problem with strings in OIDC. I > believe we need a better way to expand strings into structures. I propos= ed > the use of 3part jose structures as a solution. > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > >> I hope you are not proposing that users actually see any of this? Tha= t > would be grotesque. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > >> I plan on including assertions that do not need to be validated. I > believe it is not up to the sender whether the receiver validates the > assertion. > > > > In general I find that many of your comments are not trivial and need > deeper analysis. > > Peace ..tom > > > > > > On Sun, Oct 18, 2020 at 1:00 PM Yaron Sheffer > wrote: > > We haven=E2=80=99t discussed this process yet, and the default IETF proce= ss is, > everything goes through the mailing list. > > > > IMO small things can be quickly cleaned up (fixed or rejected), and we ca= n > open GH issues for bigger things. > > > > Thanks, > > Yaron > > > > *From: *Tom Jones > *Date: *Sunday, October 18, 2020 at 22:47 > *To: *Yaron Sheffer > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first > half) > > > > why are you doing this? Should these be issues now? > > Peace ..tom > > > > > > On Sun, Oct 18, 2020 at 12:44 PM Yaron Sheffer > wrote: > > Hi Justin, all, > > > > The draft has undergone major changes since we started the design team, s= o > I spent some time reviewing it. I only got as far as Sec. 3, and I fully > intend to review the remainder of the document. But I figured since I hav= e > so many comments, I might as well send out what I have. > > > > * General comment: we have dozens, maybe hundreds of variants/options > here. I think we need to define a must-implement subset, or we will never > reach interoperability. > > * Abstract: the boilerplate text (MUST etc.) usually goes to the > Introduction, not the Abstract. > > * 1. "The requesting party operating the software" - I think these action= s > are typically performed by the resource owner, who is not necessarily the > requesting party. > > * RS, aka API: we are using the word "API" several times in a more generi= c > sense (management API, identity API), so maybe replace with "RS, typicall= y > a protected API". > > * 1.2, "key" is a too generic term in the context of a security protocol. > Can we call it something more specific, maybe "holder identity key"? > > * 1.3.1. "augmented with a hash of the security information" - this is to= o > implementation-specific, suggest "is cryptographically bound to the > security information". In general, step (7) is way too detailed, and verg= es > on the normative. > > * 1.3.2: it is unclear to me what the goal of the user-code interaction > is, in other words what is the threat model. If it's just "second factor, > something you have", then an OTP MFA device would be simpler and offer th= e > same security. > > * 1.3.5 (4): Typically the access token would not be sent once it is > expired, right? Let's make the example more realistic. > > * 2: "OpenID Connect claims request" - why not "identity claims request" > (which just happens to be similar to the OpenID request)? > > * Never liked the "dolphin" here... If this is listed under "actions", it > should be a verb, e.g. "swim". > > * 2.1: an array for a single AT vs. an object for multiple ATs? This is > extremely non-intuitive and probably ugly to code. Also, why should > (multiple) tokens be named if a single token doesn't have to, why not lis= t > them in an array instead? > > * 2.1.1, "locations": are these really URIs or just URLs? On the other > hand, if these are URIs, why do we need a separate "identifier"? There's > too much semantic overlap between "type", "location" and "identifier" - > specifying just "type" may be sufficient. > > * 2.1.1: it's implied but should be spelled out that the semantics of thi= s > example is the cross product of permissions: I am requesting to read and > write and "dolphin" both "metadata" and "images", and that applies to bot= h > "locations" - 12 different possible actions. > > * 2.1.2: I don't see the value of the notion of "expansion". It is > sufficient that the string is understood by the AS. > > * 2.1.2, "in some situations the value is intended to be seen and > understood be the RC developer" - shouldn't we require this value to be > always fully documented by the AS owner, so that the RC knows what it is > requesting? > > * 2.1.4: why are flags represented as resources? The answer, "this is how > OAuth 2 does it" is not great. > > * "the each access tokens" -> each access token. > > * I suggest to extend the editor's note to clarify what is the use case, > so that the group can decide whether split tokens are indeed necessary. > > * Why is key binding of the access token even optional? > > * 2.2, "Subject identifiers requested by the RC serve only to identify th= e > RO in the context of the AS and can't be used as communication channels b= y > the RC" - this sounds a bit naive, people will do that anyway. So why is > this a useful statement? (And similarly in 3.4) > > * 2.3: what's the benefit of including a URI (URL really) in "display"? D= o > we really want the user (RO) to click links provided by the RC? > > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking that > the cert contains the same public key as the cert? > > * 2.3, " the AS MUST ensure that the key used to sign the request... is > associated with the instance identifier" - can we be much more specific > here, e.g. the instance_id MUST be byte-identical to the Common Name of t= he > cert? This "association" is never clarified, either here or in Sec. 8. > > * 2.3.2: allowing to send the key in multiple formats virtually invites > security vulnerabilities. Why is this a good thing? > > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include it > here? Note that in Sec. 8.3 you are using the full certificate rather tha= n > the fingerprint. > > * 2.3.2: why are we using raw PEM certificates instead of the JOSE > representation? > > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY choos= e > to avoid displaying an arbitrary URI. RC developers must only assume that > the "name" field will be displayed. > > * 2.3.4, "created just for this request" -> created just for this series > of requests. > > * 2.3.4: I suggest referring to RCs that present unknown keys as > "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any > assertions from an anonymous RC. > > * 2.4: IMO assertion validation is a MUST, and we should specify what we > require for every assertion type we allow. > > * 2.4: moreover, when possible, the AS MUST match the assertions to the > presented sub_id. It may be a hint, but you're not allowed to lie. > > * 2.4, "If the identified RQ does not match the RO present at the AS" - I > thought there are cases where the RQ is different from the RO. Also, I am > wondering why this is a SHOULD, not a MUST. > > * 2.4.1 (but probably applicable to any references): what is the lifetime > of the reference? As an RC, how long can I assume the user reference is > still valid? > > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why is > it bundled here? > > * 2.5: the way "callback" is described here is as a capability, not an > interaction mode. The example only strengthens this view, "callback" is a > modifier of the "redirect" mode. > > * 2.5: "use code" -> user code. > > * 2.5.1: this unnecessary polymorphism IMO just complicates > implementations and prevents extensibility. Instead, I would suggest: > > redirect: {} > > redirect:{max_length: 255} > > redirect:{max_length: 255, callback: {...}} > > * 2.5.2: the "app" option is problematic, as you already note. The RC may > not even know if a given URL will result in an application launching. > > * 2.5.2: and shouldn't the RC include a list of supported applications? > (Which would have lovely privacy implications.) > > * 2.5.3: there's a parenthetical discussion on whether the URL is unique. > But the nonce parameter implies that the "hash" parameter is unique per > request, making this discussion moot. > > * 2.5.3: even if we need a different kind of post-interaction "redirect", > where the RC is not involved, there must be a way to ensure that the RC > receives positive (cryptographically protected) confirmation that the > authorization was successful. In other words, what we're discussing here = is > not an RC interaction mode, it is something else, and should probably hav= e > a separate protocol element to describe it. > > * 2.5.3: In the example for "interact" as an array (which I support), the > second "redirect" and "user_code" should be independent elements of the > array, not members of an object. This assumes they are truly independent > interaction modes. > > * 2.5.3.1: what does "RQ is present on the request" mean? > > * 2.5.3.2: typo: HTTP the request. > > * 2.7: this seems to assume a short access token (which implies a bearer > token). What if we want to use longer self-contained access tokens > containing full keys? Should we have a separate "grant_id" value instead? > > * 2.8: another problem with this stanza is that the RC needs to know a > priority that the AS supports it. What happens if the AS doesn't? > > * 2.8: I suggest to move this section into a separate I-D, or at least a > separate appendix. > > * 2.9: it makes sense to bundle extensions and the "capabilities" section > into one. > > * 2.9: The AS MUST ignore any unknown extension. > > * 3: it's confusing that we're using access_token for two different > things. Maybe we could change the RC/AS one to "as_access_token"? > > * 3.1: MAY vary *by* request. > > * 3.1: how is the client behavior "deterministic in all cases" - how does > the RC know whether the AS allows continuation or only allows one request > at a time? > > * 3.2.1: the "value" of the access token is opaque in some cases (bearer > token) but not in others. > > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be > printable ASCII, 0x20 characters that still need to be escaped. > > * 3.2.1: why is "expires_in" optional? Typically access tokens are not > revoked, and the RC needs a way to manage their lifetime. > > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, or > are we missing a subsection describing resources/rights? > > * 3.2.1: "key": another polymorphism alert! > > * 3.2.1: the example at the bottom of the section talks about a way to > present the token, I believe this discussion is out of context here. > > * 3.3: the AS knows now which interaction modes are available. Why not > pick just one for its response, to simplify the protocol? As one example, > the AS can then more easily decide on timeout behavior. > > * 3.3.3: Suggest to add to the last paragraph: If the RC does not receive > a callback until an RC-determined timeout occurs, the RC MUST act as if t= he > entire request failed. > > * 3.4: "updated_at": Unix time is nice, but for absolute time it's common > to use ISO 8601 format. > > * 3.6: YES, the "error" element is exclusive! > > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think it > could work nicely here. > > * 10.4: "indicating that GNAP" - sentence is broken. > > * This "speculative" access is not useful if the response is only a MAY. > Why would the RC try it if it is unlikely to provide useful information? > > * 15: the BCP195 ref is broken - the author names are missing (yes I am > one of them...). > > * Appendix D: can we name the first scenario, maybe "Simple API Access"? > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c4ea8605b209b0e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok - several others have been asking as well.=C2=A0 I wrot= e up this page=C2=A0https://tcwiki.azurewebsites.net/index.php?tit= le=3DApps_on_User_Devices

basically there are assert= ions from the programmer of the app, and from the app itself that are passe= d in the id token (whatever) from the user device.
Note that this= means that not all assertions are signed by the same key in this case!
Nor are all the attributes about the subject. Some are just in suppo= rt of the level of assurance.
The big difference with FIDO U2F an= d II is that the keys are bound to the user in the device, not in the RP.
Peace ..tom
=


On Mon, Oct 19, 2020 at 2:52 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= /div>

Hi Tom,

=C2=A0

Thanks for yo= ur response. I would like to focus on one point.

=C2=A0

The document = does not explain what the user code solution tries to achieve, and I honest= ly don=E2=80=99t understand the exact use case(s) myself. If you could writ= e up a paragraph, we could include it in the document for my own and others= =E2=80=99 edification.

=C2= =A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

<= u>=C2=A0

=

From: = Tom Jones <thomasclinganjon= es@gmail.com>
Date: Monday, October 19, 2020 at 00:38
<= b>To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: GNAP Mailing List &= lt;txauth@ietf.org= >
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-= 00 (first half)

<= u>=C2=A0

then i guess we mu= st address the=C2=A0entire email, which is not helpful.=C2=A0 Here are at= =C2=A0least a few of my thoughts.

1.2, "key" is a too generic term in the context of a security= protocol. Can we call it something more specific, maybe "holder ident= ity key"?

>> = that is not more specific. if you want to understand the source of the key = then perhaps the entire jwk element needs to be augmented.

1.3.2: it is unclear to me what the goal= of the user-code interaction is, in other words what is the threat model. = If it's just "second factor, something you have", then an OTP= MFA device would be simpler and offer the same security.

=

>> first of all, you are wrong in your assessm= ent, second that is not all that the user-code interaction supplies.=

2.1.2: I don't see the value of the n= otion of "expansion". It is sufficient that the string is underst= ood by the AS.

>> = I am already running into this as a problem with strings in OIDC. I believe= we need a better way to expand strings into structures.=C2=A0 I proposed t= he use of 3part jose structures=C2=A0as a solution.

=

* 2.3: what's the benefit of including a UR= I (URL really) in "display"? Do we really want the user (RO) to c= lick links provided by the RC?

>> I hope you are not proposing that users actually see any of= this?=C2=A0 That would be grotesque.

* 2.4: IMO assertion validation is a MUST, and we should spe= cify what we require for every assertion type we allow.

>> I plan on including assertions tha= t do not need to be validated. I believe it is not up to the sender whether= the receiver validates the assertion.

=C2=A0

In= general I find that many of your comments are not trivial and need deeper = analysis.

Peace ..tom

=C2=A0

= =C2=A0

On Sun, Oct 18, 20= 20 at 1:00 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

We haven=E2=80=99t= discussed this process yet, and the default IETF process is, everything go= es through the mailing list.

=C2=A0=

IMO small things can be quickly cl= eaned up (fixed or rejected), and we can open GH issues for bigger things.<= u>

=C2=A0

Thanks,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Yaron

=C2=A0

<= span style=3D"font-size:12pt;color:black">From: Tom Jones <thomasclinganjones@gmail.com>
= Date: Sunday, October 18, 2020 at 22:47
To: Yaron Sheffer <= ;yaronf.ietf@gma= il.com>
Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re:= [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half)

=C2=A0

why are you doing this? Should these be issue= s now?

Peace ..tom

=C2=A0

=C2=A0

On Sun, Oct 18, 2020 at 12:44= PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin, all,

=C2=A0

The draft has undergon= e major changes since we started the design team, so I spent some time revi= ewing it. I only got as far as Sec. 3, and I fully intend to review the rem= ainder of the document. But I figured since I have so many comments, I migh= t as well send out what I have.

=C2= =A0

* General comment: we have doze= ns, maybe hundreds of variants/options here. I think we need to define a mu= st-implement subset, or we will never reach interoperability.=

* Abstract: the boilerplate text (MUST etc.) usu= ally goes to the Introduction, not the Abstract.

* 1. "The requesting party operating the software"= - I think these actions are typically performed by the resource owner, who= is not necessarily the requesting party.

* RS, aka API: we are using the word "API" several times i= n a more generic sense (management API, identity API), so maybe replace wit= h "RS, typically a protected API".

* 1.2, "key" is a too generic term in the context of a = security protocol. Can we call it something more specific, maybe "hold= er identity key"?

* 1.3.1. &qu= ot;augmented with a hash of the security information" - this is too im= plementation-specific, suggest "is cryptographically bound to the secu= rity information". In general, step (7) is way too detailed, and verge= s on the normative.

* 1.3.2: it is = unclear to me what the goal of the user-code interaction is, in other words= what is the threat model. If it's just "second factor, something = you have", then an OTP MFA device would be simpler and offer the same = security.

* 1.3.5 (4): Typically th= e access token would not be sent once it is expired, right? Let's make = the example more realistic.

* 2: &q= uot;OpenID Connect claims request" - why not "identity claims req= uest" (which just happens to be similar to the OpenID request)?=

* Never liked the "dolphin" her= e... If this is listed under "actions", it should be a verb, e.g.= "swim".

* 2.1: an array = for a single AT vs. an object for multiple ATs? This is extremely non-intui= tive and probably ugly to code. Also, why should (multiple) tokens be named= if a single token doesn't have to, why not list them in an array inste= ad?

* 2.1.1, "locations":= are these really URIs or just URLs? On the other hand, if these are URIs, = why do we need a separate "identifier"? There's too much sema= ntic overlap between "type", "location" and "ident= ifier" - specifying just "type" may be sufficient.=

* 2.1.1: it's implied but should be spel= led out that the semantics of this example is the cross product of permissi= ons: I am requesting to read and write and "dolphin" both "m= etadata" and "images", and that applies to both "locati= ons" - 12 different possible actions.

* 2.1.2: I don't see the value of the notion of "expansion= ". It is sufficient that the string is understood by the AS.=

* 2.1.2, "in some situations the value = is intended to be seen and understood be the RC developer" - shouldn&#= 39;t we require this value to be always fully documented by the AS owner, s= o that the RC knows what it is requesting?

* 2.1.4: why are flags represented as resources? The answer, "= this is how OAuth 2 does it" is not great.

* "the each access tokens" -> each access token= .

* I suggest to extend the editor&= #39;s note to clarify what is the use case, so that the group can decide wh= ether split tokens are indeed necessary.

* Why is key binding of the access token even optional?=

* 2.2, "Subject identifiers requested by th= e RC serve only to identify the RO in the context of the AS and can't b= e used as communication channels by the RC" - this sounds a bit naive,= people will do that anyway. So why is this a useful statement? (And simila= rly in 3.4)

* 2.3: what's the b= enefit of including a URI (URL really) in "display"? Do we really= want the user (RO) to click links provided by the RC?

* 2.3: why are we sending a JWK *as well as* a cert? Ar= e we checking that the cert contains the same public key as the cert?

* 2.3, " the AS MUST ensure that th= e key used to sign the request... is associated with the instance identifie= r" - can we be much more specific here, e.g. the instance_id MUST be b= yte-identical to the Common Name of the cert? This "association" = is never clarified, either here or in Sec. 8.

* 2.3.2: allowing to send the key in multiple formats virtually = invites security vulnerabilities. Why is this a good thing?

* 2.3.2: cert#256 is not a key, it's an identi= fier. Why do we include it here? Note that in Sec. 8.3 you are using the fu= ll certificate rather than the fingerprint.

* 2.3.2: why are we using raw PEM certificates instead of the JOSE= representation?

* 2.3.3: For obvio= us security reasons, I suggest adding: The AS MAY choose to avoid displayin= g an arbitrary URI. RC developers must only assume that the "name"= ; field will be displayed.

* 2.3.4,= "created just for this request" -> created just for this seri= es of requests.

* 2.3.4: I suggest = referring to RCs that present unknown keys as "anonymous RC", and= then in 2.4, say that the AS MUST NOT accept any assertions from an anonym= ous RC.

* 2.4: IMO assertion valida= tion is a MUST, and we should specify what we require for every assertion t= ype we allow.

* 2.4: moreover, when= possible, the AS MUST match the assertions to the presented sub_id. It may= be a hint, but you're not allowed to lie.

* 2.4, "If the identified RQ does not match the RO present= at the AS" - I thought there are cases where the RQ is different from= the RO. Also, I am wondering why this is a SHOULD, not a MUST.

* 2.4.1 (but probably applicable to any refere= nces): what is the lifetime of the reference? As an RC, how long can I assu= me the user reference is still valid?

* 2.5: "preferred_locales" is obviously not a mode of interact= ion. Why is it bundled here?

* 2.5:= the way "callback" is described here is as a capability, not an = interaction mode. The example only strengthens this view, "callback&qu= ot; is a modifier of the "redirect" mode.

* 2.5: "use code" -> user code.=

* 2.5.1: this unnecessary polymorphism IMO just = complicates implementations and prevents extensibility. Instead, I would su= ggest:

redirect: {}

redirect:{max_length: 255}

redirect:{max_length: 255, callback: {...}}<= /p>

* 2.5.2: the "app" option is problemati= c, as you already note. The RC may not even know if a given URL will result= in an application launching.

* 2.5= .2: and shouldn't the RC include a list of supported applications? (Whi= ch would have lovely privacy implications.)

* 2.5.3: there's a parenthetical discussion on whether the URL= is unique. But the nonce parameter implies that the "hash" param= eter is unique per request, making this discussion moot.

<= p class=3D"MsoNormal">* 2.5.3: even if we need a different kind of post-int= eraction "redirect", where the RC is not involved, there must be = a way to ensure that the RC receives positive (cryptographically protected)= confirmation that the authorization was successful. In other words, what w= e're discussing here is not an RC interaction mode, it is something els= e, and should probably have a separate protocol element to describe it.<= /u>

* 2.5.3: In the example for "inte= ract" as an array (which I support), the second "redirect" a= nd "user_code" should be independent elements of the array, not m= embers of an object. This assumes they are truly independent interaction mo= des.

* 2.5.3.1: what does "RQ is present on the request&= quot; mean?

* 2.5.3.2: typo: HTTP the request.<= /p>

* 2.7: this seems to assume a short access token = (which implies a bearer token). What if we want to use longer self-containe= d access tokens containing full keys? Should we have a separate "grant= _id" value instead?

* 2.8: ano= ther problem with this stanza is that the RC needs to know a priority that = the AS supports it. What happens if the AS doesn't?

* 2.8: I suggest to move this section into a separate = I-D, or at least a separate appendix.

* 2.9: it makes sense to bundle extensions and the "capabilities&qu= ot; section into one.

* 2.9: The AS= MUST ignore any unknown extension.

* 3: it's confusing that we're using access_token for two differen= t things. Maybe we could change the RC/AS one to "as_access_token"= ;?

* 3.1: MAY vary *by* request.=

* 3.1: how is the client behavior &qu= ot;deterministic in all cases" - how does the RC know whether the AS a= llows continuation or only allows one request at a time?

<= p class=3D"MsoNormal">* 3.2.1: the "value" of the access token is= opaque in some cases (bearer token) but not in others.

* 3.2.1: The ASCII restriction on "value" is= insufficient. Needs to be printable ASCII, 0x20<v<=3D0x7f. And I'= ;m not sure if this doesn't leave some characters that still need to be= escaped.

* 3.2.1: why is "exp= ires_in" optional? Typically access tokens are not revoked, and the RC= needs a way to manage their lifetime.

* 3.2.1: "resources" refers to this same section. Did you mea= n 2.1.2, or are we missing a subsection describing resources/rights?=

* 3.2.1: "key": another polymor= phism alert!

* 3.2.1: the example a= t the bottom of the section talks about a way to present the token, I belie= ve this discussion is out of context here.

* 3.3: the AS knows now which interaction modes are available. Why = not pick just one for its response, to simplify the protocol? As one exampl= e, the AS can then more easily decide on timeout behavior.

* 3.3.3: Suggest to add to the last paragraph: If t= he RC does not receive a callback until an RC-determined timeout occurs, th= e RC MUST act as if the entire request failed.

* 3.4: "updated_at": Unix time is nice, but for absol= ute time it's common to use ISO 8601 format.

* 3.6: YES, the "error" element is exclusive!

* 3.6: in SecEvent we tried to use RFC = 7807 "problem details", I think it could work nicely here.=

* 10.4: "indicating that GNAP" = - sentence is broken.

* This "= speculative" access is not useful if the response is only a MAY. Why w= ould the RC try it if it is unlikely to provide useful information?<= u>

* 15: the BCP195 ref is broken - the autho= r names are missing (yes I am one of them...).

* Appendix D: can we name the first scenario, maybe "Simpl= e API Access"?

-- =
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

=
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c4ea8605b209b0e7-- From nobody Mon Oct 19 13:42:30 2020 Return-Path: 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 7DDC53A098E for ; Mon, 19 Oct 2020 13:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 ryQQPW1smI_z for ; Mon, 19 Oct 2020 13:42:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6627E3A0995 for ; Mon, 19 Oct 2020 13:42:21 -0700 (PDT) Received: from [192.168.1.4] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09JKgGkH012782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 16:42:17 -0400 From: Justin Richer Message-Id: <228126C9-2DCD-47D7-8499-EDC5BAD0CD66@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_0DF47B37-0192-4C3A-B3A1-2F51A8112774" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 19 Oct 2020 16:42:16 -0400 In-Reply-To: Cc: GNAP Mailing List To: Yaron Sheffer References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 (first half) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 20:42:30 -0000 --Apple-Mail=_0DF47B37-0192-4C3A-B3A1-2F51A8112774 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, Thanks for the thorough reading. I agree with the other commenters that = GitHub issues are a better way to track many of these items. There=E2=80=99= s a natural threading and separation of discussions, which can get = really unwieldy in a mailing list thread, but you can also explicitly = cross-link things. Also, when changes are made to the document in = response to a specific issue, the change set can be linked to the issue = that caused them. It also lets people engage on the specific topics that = they want.=20 With that in mind, now is the best time for the group to decide on the = best practices for disposition and addressing feedback, and agreeing on = when and how to bring discussion to the list. We have a lot of work = ahead of us, and now is when we need to decide how we=E2=80=99re going = to do that work. In the mean time, I=E2=80=99ve commented on each of these inline below. = It=E2=80=99s a lot of writing, and I apologize ahead of time to everyone = for that. I also apologize in advance if there are cut off sentences or = things that don=E2=80=99t make sense =E2=80=94 there was a lot to = discuss here in one go, and I=E2=80=99ve tried not to leave anything = out. I=E2=80=99m hoping that the responses below will offer some = background and clarity into how we got to what=E2=80=99s there now, so = that we can find what the right way is forward, even (or especially) = where things need to change. Absolutely everything in the 00 draft is up = for discussion to drive consensus within the working group going = forward. And there is a LOT of discussion for this working group to have = still, and I look forward to continuing that discussion in a productive = manner. Thanks, =E2=80=94 Justin > On Oct 18, 2020, at 3:44 PM, Yaron Sheffer = wrote: >=20 > Hi Justin, all, > =20 > The draft has undergone major changes since we started the design = team, so I spent some time reviewing it. I only got as far as Sec. 3, = and I fully intend to review the remainder of the document. But I = figured since I have so many comments, I might as well send out what I = have. > =20 > * General comment: we have dozens, maybe hundreds of variants/options = here. I think we need to define a must-implement subset, or we will = never reach interoperability. Completely agree, but please understand that many of these options are = presented by the design team as explicit discussion points. In = particular, there are MANY things that are in =E2=80=9CEditor=E2=80=99s = Note=E2=80=9D blocks throughout the document, where the design team saw = multiple ways to approach something that we believed the wider working = group should weigh in on. In other words, many of what are presented as = =E2=80=9Coptions=E2=80=9D aren=E2=80=99t integrated as options within = the protocol itself, but options FOR the protocol to be considered for = integration and decision.=20 I=E2=80=99ll also note that the back-and-forth =E2=80=9Cnegotiation=E2=80=9D= nature of the protocol allows the different parties to present options = to each other at runtime (or before) and settle on an overlapping set of = functions to enable interop. So the RC can ask for a feature, and the AS = can reject it because it isn=E2=80=99t allowed for a specific request or = because the AS doesn=E2=80=99t support it at all =E2=80=94 in either = case, the client doesn=E2=80=99t get what it wants. Even so, I agree = that we will need to have a notion of mandatory to implement within the = protocol in order to facilitate a base level of interoperability, and = this is currently lacking in the document because I don=E2=80=99t have a = good idea of what the MTI portions really need to be. As you know, a = security protocol needs to be especially careful not to mandate = implementation of an insecure option for MTI purposes, and that=E2=80=99s = a delicate balance the WG is going to need to settle on. Would you = suggest an MTI section be added? OIDC has this, with several profiles = within that section. > * Abstract: the boilerplate text (MUST etc.) usually goes to the = Introduction, not the Abstract. Thanks, I was led astray by the template I used when I converted to = Markdown from XML. :) We should move it into a more proper = =E2=80=9CIntroduction" section, which will encompass what=E2=80=99s now = labeled =E2=80=9Cprotocol=E2=80=9D in section 1.=20 > * 1. "The requesting party operating the software" - I think these = actions are typically performed by the resource owner, who is not = necessarily the requesting party. You=E2=80=99re right, that is not at all clear from the text as written, = we can fix that. The funny thing is, this is exactly why we separated the requesting = party from the resource owner =E2=80=94 they are defined by the actions = they take. The requesting party interacts with the client while the = resource owner does the approval. You=E2=80=99re right that in many = cases the RO and RQ are the same person, as this is the core OAuth 2 use = case set =E2=80=94 and this is what the text in question was actually = trying to point out.=20 > * RS, aka API: we are using the word "API" several times in a more = generic sense (management API, identity API), so maybe replace with "RS, = typically a protected API". Good catch, this is an artifact from a previous version where non-RS = items weren=E2=80=99t described as an API so it was a more safe = comparison.=20 (Even so, things like the token management API and request = continuation/management now have parity with RS APIs by using access = tokens for protection, so we do need to be more clear/precise about what = an =E2=80=9CRS=E2=80=9D exactly is.) > * 1.2, "key" is a too generic term in the context of a security = protocol. Can we call it something more specific, maybe "holder identity = key"? This isn=E2=80=99t just about a user=E2=80=99s key =E2=80=94 this is = primarily a key for the requesting client software, but it gets used in = a number of ways. Keys can be bound to client instances and to access = tokens, and they can be used to identify various parties in the system = (including users).=20 It was brought up in the design team meetings that we might not even = need to define this term, since it=E2=80=99s understood in the wider = security space, and so I=E2=80=99m happy to either take it out or expand = it as required. > * 1.3.1. "augmented with a hash of the security information" - this is = too implementation-specific, suggest "is cryptographically bound to the = security information". In general, step (7) is way too detailed, and = verges on the normative. I=E2=80=99m fine with this suggested rewording. Note though: this is not = a generic flow, but this sequence is intended to be specific to use of = the =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback (with redirect)=E2=80= =9D interaction modes in combination with each other, and thus is = specific to the functioning of those elements. > * 1.3.2: it is unclear to me what the goal of the user-code = interaction is, in other words what is the threat model. If it's just = "second factor, something you have", then an OTP MFA device would be = simpler and offer the same security. This is an equivalent function of the OAuth Device Flow: = https://tools.ietf.org/html/rfc8628 = It=E2=80=99s not about a second factor for authenticating the user, = really, it=E2=80=99s about facilitating authorization on a secondary = device through the use of a user-typed code to tie the back end and = front end together. > * 1.3.5 (4): Typically the access token would not be sent once it is = expired, right? Let's make the example more realistic. The intent is that time has passed between (2) and (4) to allow the = token to expire =E2=80=94 not that the token is already expired. I = initially had a =E2=80=9Csuccessful request=E2=80=9D in the middle, but = I cut it out as it wasn=E2=80=99t interesting to the topic of refreshing = a token. I=E2=80=99ll add it back in for clarity.=20 > * 2: "OpenID Connect claims request" - why not "identity claims = request" (which just happens to be similar to the OpenID request)? Because this is specific to the OpenID Connect Claims query language, = which has inherent limitations on its use. More comments in response to = your note on section 2.8, below. > * Never liked the "dolphin" here... If this is listed under "actions", = it should be a verb, e.g. "swim". So there=E2=80=99s a (fairly silly) story on why =E2=80=9Cdolphin=E2=80=9D= is an example here and has been an example in several RFC=E2=80=99s = I=E2=80=99ve edited, but it=E2=80=99s more appropriately shared over = beers when that=E2=80=99s an option again. :) I agree that =E2=80=9Cswim=E2= =80=9D is probably less confusing in this specific context though. > * 2.1: an array for a single AT vs. an object for multiple ATs? This = is extremely non-intuitive and probably ugly to code. Also, why should = (multiple) tokens be named if a single token doesn't have to, why not = list them in an array instead? I agree that it looks a little odd at first glance, but I=E2=80=99ve = coded this in a few languages now and on the request side (this section) = it is really clear what you=E2=80=99re doing. I think it might be = helpful to build up from the parts of this section of the request, which = will show the history and decision process that got us to the syntax = that=E2=80=99s there today. Obviously, this isn=E2=80=99t a statement = that it needs to stay this way, but I hope that this will help bring to = light the reasoning behind what=E2=80=99s there now so that it can be = explained, refined, or updated as needed. At the lowest level, we=E2=80=99ve got the dimensions for access. OAuth = 2 showed us that =E2=80=9Cscope=E2=80=9D was a useful way for a client = to indicate what it wants, but we=E2=80=99ve found that API designers = have used scope to talk about many different dimensions of access, all = rolled into different scope values. We are now being explicit about = those dimensions, and trying to make those dimensions orthogonal to each = other. There is some small amount of fuzziness and potential overlap of = interpretation, and ultimately these are all up to the AS/RS (and the = API designer, really) to define: - type: =E2=80=9Cthe kind of API I want to call=E2=80=9D, like OIDC = UserInfo or FHIR Medical Record - datatypes: =E2=80=9Cthe kind of data I want to use at the API=E2=80=9D,= like email addresses or office visits - actions: =E2=80=9Cthe kind of actions I want to do on the API=E2=80=9D,= like read, or write, or make the robot move - locations: =E2=80=9Cthe RSs I want to call the API on=E2=80=9D, like = the URL of the UserInfo Endpoint or a URI for a specific document server = cluster - identifier: =E2=80=9Cthe entity I want to do these actions on=E2=80=9D,= like the medical record ID or bank account number These are all strings or arrays of strings, and they=E2=80=99re meant to = be very specific to the requested access to the API. Specific APIs are = likely to add their own dimensions as well, which can be pretty much = anything so long as the RS can interpret the token that it represents. = This is why we have the =E2=80=9Ctype=E2=80=9D field, which gives us a = way to namespace the dimensions.=20 But these dimensions don=E2=80=99t live alone: I=E2=80=99m not going to = just ask for =E2=80=9Cread=E2=80=9D or just =E2=80=9Cmedical record=E2=80=9D= , I probably want to ask for =E2=80=9Cread the medical record=E2=80=9D. = With scopes, we were forced to just put them all in a bucket and define = awkward semantics for combining them, and then watch things go awry as = an AS protected different APIs with different interpretations of, for = example, =E2=80=9Cemail=E2=80=9D as a scope. So with GNAP, we=E2=80=99ve = got a way to combine them into single objects. That lets us create = combinations like =E2=80=9Cread the medical record=E2=80=9D by combining = the =E2=80=9Ctype=E2=80=9D and =E2=80=9Cactions=E2=80=9D fields into a = single object. The =E2=80=9Cpass by reference=E2=80=9D feature allows us = to send a simple string value that is interpreted as if it were one of = the objects. So maybe there=E2=80=99s a =E2=80=9Cfhir-read=E2=80=9D = value that means =E2=80=9Cread all available sections of the fhir = medical record of the current user=E2=80=9D. You can think of it like a = pre-computed object where the client doesn=E2=80=99t have to specify all = the details =E2=80=94 and in that way it works almost just like a scope = value would.=20 But what if I want read access to the medical history record but ALSO = want update access to the demographic information? We can=E2=80=99t just = throw it all onto the same object because there are two very distinct = requests, but one access token can reasonably encompass both. So in GNAP = we=E2=80=99ve got an array of objects that allows us to combine these = multidimensional requests and have them all apply to a single access = token. Since any of these objects could potentially be replaced by a = string, this array could have a combination of strings or objects, but = each item in the array represents the same kind of multi-dimensional = request. The =E2=80=9Cscope=E2=80=9D field in OAuth 2 is semantically an = array (even though it=E2=80=99s formatted as a space-separated list of = space-free ascii strings) for exactly this reason: I should be able to = ask for multiple scopes at the same time.=20 The resulting access token is for the total of everything in the array = (that=E2=80=99s granted =E2=80=94 of course any of this can be changed = by the AS and RO). So an access token always represents an array of = requested access rights, each access right is an object that describes = what=E2=80=99s being requested across several dimensions which are = properties of that object in their own syntax. An access token is a = combined collection of access rights, so requesting an access token = requires the structure of an array. And so far, this is inline (by = design) with what=E2=80=99s in OAuth 2 RAR: = https://tools.ietf.org/id/draft-ietf-oauth-rar-03.html = And that brings us to multiple access tokens: Multiple access tokens are = requested by sending an object which uses labels to mark individual = single access token requests, which as we just saw is an array =E2=80=94 = so it=E2=80=99s an object whose values are all arrays, but specifically = arrays that are defined to ask for a single access token. Why put the labels on these requests? Multiple access tokens need to = have names (or labels) so that the client can tell :which: of its access = requests each token maps to. Otherwise, how can a client know which set = of resources it=E2=80=99s supposed to use each token with? The = =E2=80=9Clocations=E2=80=9D field (discussed more below) is for = identifying sets of resources, and so that field is not likely to be the = exact set of URLs that the client can use the token at. And it=E2=80=99s = also not guaranteed that all APIs will use =E2=80=9Clocations=E2=80=9D = in a way that=E2=80=99s meaningful to a client =E2=80=94 what if the = client wants =E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D access = at the same API with different tokens? The =E2=80=9Cread=E2=80=9D token = could be long-lived but the =E2=80=9Cwrite=E2=80=9D token short lived, = for security purposes, but the =E2=80=9Clocations=E2=80=9D would be the = same. Additionally, the =E2=80=9Cread=E2=80=9D could be limited to GET = requests and the =E2=80=9Cwrite=E2=80=9D limited to =E2=80=9CPOST=E2=80=9D= requests, neither of which is really expressed in =E2=80=9Clocations=E2=80= =9D. If the RC is going to ask for different tokens in a single request, = it needs to have a way to differentiate the portions of the response = from each other.=20 There are some different syntaxes we could use to make parts of this = work, but these choices tend to have other follow-on effects. Here are a = few that I=E2=80=99ve cycled through in the design of the current = proposal: We could ask for multiple access tokens this by having a =E2=80=9Clabel=E2= =80=9D field inside the request for a single access token and then = sending an array of single access token request (so an array of arrays), = but then you need to answer the question of where in the request to put = the label. Should it go in the array like the proposed =E2=80=9Ctoken = flags=E2=80=9D? Should it go inside one of the objects in the array? But = if it does, what would it mean for multiple objects in the array to have = a =E2=80=9Clabel=E2=80=9D value? Additionally, we=E2=80=99d need to = detect at the top level whether we had an array of arrays or an array of = objects and strings =E2=80=94 doable, but more prone to weird error = cases. (What if an RC sends an array with one array and one object? We = need to detect that now and might end up down the wrong code path before = we do, with a naive parser anyway.) We could simply require all tokens to be labeled at all times, but I = would argue that the overwhelmingly common use case of a single access = token doesn=E2=80=99t need that kind of overhead because there=E2=80=99s = only one set of requested items that the RC is asking for.=20 We could define single access tokens as an object, with multiple = aspects. This would potentially let us hang additional fields off of the = access token request alongside the resource list, but it would also mean = that we=E2=80=99d have a degenerate case where you=E2=80=99re defining = an object with one member, whose value is always an array. In other = words, this is exactly what the JSON Web Key Set format does, which = I=E2=80=99ve always found clunky. The top level object doesn=E2=80=99t = add anything in the JWKS case, and I=E2=80=99m not seeing how it would = add anything here. On the other hand, this would let us use an object = for a single access token and potentially an array for multiple access = tokens, but at some cost to the complexity at the layers below that. None of those ideas lead to a better syntax across the different uses = cases, or that optimize for simplicity in the common use cases. All that is to say that I currently think that what we have is the = simplest and cleanest approach that I=E2=80=99ve seen so far, and I = would really love to see if there are any alternatives that offer this = same kind of power and clarity when exercised the same. I would love to = see some fresh ideas on different ways to approach this. > * 2.1.1, "locations": are these really URIs or just URLs? On the other = hand, if these are URIs, why do we need a separate "identifier"? There's = too much semantic overlap between "type", "location" and "identifier" - = specifying just "type" may be sufficient. In my implementation, =E2=80=9Clocations=E2=80=9D are actually just = Strings that the AS and RS can dereference to figure out the intended = target of the RS. In practice I think these will be URIs that identify = the RS (or really, the APIs hosted at each RS) in a way that the RC can = communicate to the AS and back. It=E2=80=99s not meant to be an = exhaustive list of URLs that the RS will use the token at, since an = =E2=80=9CRS=E2=80=9D could have a nearly infinite set of URLs that it = protects, depending on the nature of the API. GNAP shouldn=E2=80=99t = take a stance on the structure of the APIs it protects, much like OAuth = didn=E2=80=99t. =E2=80=9Cidentifier" is for an object identifier of some type within the = API =E2=80=94 so while =E2=80=9Clocation=E2=80=9D is more to identify = the RS itself, =E2=80=9Cidentifier=E2=80=9D is to indicate the item at = the RS which might not be exposed through any kind of URL.=20 =E2=80=9Ctype=E2=80=9D tells you what=E2=80=99s in the rest of the = object. The semantics are shared with OAuth RAR, as mentioned in the = note: https://tools.ietf.org/id/draft-ietf-oauth-rar-03.html = Though, as = mentioned in the note, we can=E2=80=99t cleanly normatively reference = RAR directly as RAR needs to exist in an OAuth 2 world, which has = =E2=80=9Cscope=E2=80=9D and =E2=80=9Cresource=E2=80=9D parameters, as = well as some extensions/profiles that use an =E2=80=9Caud=E2=80=9D = parameter and other items. We don=E2=80=99t have those restrictions in = GNAP and so the semantics are slightly different here. In an ideal = world, we=E2=80=99d define these in GNAP and RAR would be a clean = back-port of this function to OAuth 2. For a concrete strawman example using OpenID Connect=E2=80=99s userinfo = endpoint with the subject ID 248289761001, we might have something like = this: { type: http://openid.net/specs/connect/1.0/userinfo, locations: [ https://server.example.com/userinfo ], identifier: 248289761001 } A more realistic example would be asking for a specific bank account = (identifier) at a specific bank (locations) for a specific accounting = API (type).=20 Any advice to clarify this intent would be greatly appreciated! > * 2.1.1: it's implied but should be spelled out that the semantics of = this example is the cross product of permissions: I am requesting to = read and write and "dolphin" both "metadata" and "images", and that = applies to both "locations" - 12 different possible actions. OK, that can be expounded upon here, as that is the intent. Each object = is meant to encompass one fully realized combination of options, which = is why they=E2=80=99re presented in an array overall (as talked about = above). > * 2.1.2: I don't see the value of the notion of "expansion". It is = sufficient that the string is understood by the AS. While I personally agree with your stance, this was from a discussion on = the list about the nature of the string value that we wanted to capture = here.=20 > * 2.1.2, "in some situations the value is intended to be seen and = understood be the RC developer" - shouldn't we require this value to be = always fully documented by the AS owner, so that the RC knows what it is = requesting? For cases when the developer sees it and configures it into the RC code, = I agree. But there are cases (like section 10.3) where things happen = more dynamically that are also enabled by this functionality.=20 > * 2.1.4: why are flags represented as resources? The answer, "this is = how OAuth 2 does it" is not great. The idea is that these are items that alter what the access token = that=E2=80=99s being requested in the =E2=80=9Cresources=E2=80=9D = section. It is a sensible way to hang things together since everything = in the array ties to a specific access token. This was a proposed design = compromise, and if these flags can fit elsewhere then we can do that. > * "the each access tokens" -> each access token. Thanks, got it! > * I suggest to extend the editor's note to clarify what is the use = case, so that the group can decide whether split tokens are indeed = necessary. I think we should have a more detailed conversation about this potential = feature than an editor=E2=80=99s note could reasonably get into. There = are a number of large items (splitting access tokens, directing access = tokens to specific portions of API or RS=E2=80=99s, among others) that I = think will be big conversations for the WG, and all the context of these = don=E2=80=99t necessarily need to be documented inside the notes in the = document itself.=20 But for discussion and context, this feature was proposed to deal with = cases where the AS might decide to issue several access tokens in any = case where the client requested one, because the AS wants to have = restricted audiences for individual access tokens but the client = doesn=E2=80=99t know about the audiences ahead of time. I agree that = it=E2=80=99s a compelling use case, and it puts security of the = protected domains in the hands of the AS where it belongs, but it would = require a client to be smart enough to know what to do with these tokens = downstream, and if OAuth has taught us anything it=E2=80=99s that we = can=E2=80=99t rely on client software to be smart about most anything. = :) > * Why is key binding of the access token even optional? Because people still want to use bearer tokens as an option. I think we = can make bound tokens first class citizens in GNAP, and that=E2=80=99s a = large reason behind having consistent key binding approaches instead of = having them separated out (section 8). I think we can even make the = =E2=80=9Cdefault=E2=80=9D having the token bound to the RC=E2=80=99s = presented key (and therefore make =E2=80=9Cunbound token=E2=80=9D a flag = instead), but I don=E2=80=99t think there would be support in the = community for removing bearer tokens entirely. > * 2.2, "Subject identifiers requested by the RC serve only to identify = the RO in the context of the AS and can't be used as communication = channels by the RC" - this sounds a bit naive, people will do that = anyway. So why is this a useful statement? (And similarly in 3.4) This inclusion is based roughly off of a similar constraint in OIDC = around subject identifiers: = https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability = I agree that people will do dumb things anyway, but that=E2=80=99s why = we ned to spell out why it=E2=80=99s dumb here. > * 2.3: what's the benefit of including a URI (URL really) in = "display"? Do we really want the user (RO) to click links provided by = the RC? I think we want to give them the option of doing so, yes. It=E2=80=99s = up to the AS to help protect the RO, and that will need to be written up = in the security considerations.=20 This is analogous to =E2=80=9Cclient_uri=E2=80=9D in OAuth Dynamic = Registration: https://tools.ietf.org/html/rfc7591#section-2 > * 2.3: why are we sending a JWK *as well as* a cert? Are we checking = that the cert contains the same public key as the cert? I would be ok with the different formats being mutually exclusive = somehow. The AS would need to check that they=E2=80=99re the same and = throw an error if not. But this would also let the RC send over whatever = it=E2=80=99s got for its own keys every time. > * 2.3, " the AS MUST ensure that the key used to sign the request... = is associated with the instance identifier" - can we be much more = specific here, e.g. the instance_id MUST be byte-identical to the Common = Name of the cert? This "association" is never clarified, either here or = in Sec. 8. No, I don=E2=80=99t think we should be so prescriptive =E2=80=94 for = one, it won=E2=80=99t always be a certificate or a JWK (where you might = use the Key ID). And for another, you might want to rotate the key = without changing the instance identifier. And finally, I don=E2=80=99t = think the CN would even be enough since there will be plenty of cases = where you=E2=80=99d be accepting client-supplied keys.=20 The =E2=80=9Cinstance_id=E2=80=9D is an AS-assigned value that it can = use to look up information about the instance of RC software making the = call. Part of that includes whatever key information is associated with = that instance. The =E2=80=9Cassociation=E2=80=9D for this kind of thing = is up to the AS, and in OAuth we called this =E2=80=9Cstatic client = registration=E2=80=9D or =E2=80=9Cdynamic client registration=E2=80=9D, = depending on how it happened. Here, we=E2=80=99re taking a step back = from saying that =E2=80=9Ca client must be registered=E2=80=9D and = instead simply saying that =E2=80=9Cif you see an instance_id, you need = to know what key goes along with that and prove that that key is = used=E2=80=9D. For many clients, it=E2=80=99s the same net effect as = having a client_id and registering their public key against that = client_id in OAuth 2, but for large swaths of clients that currently = fall outside of the OAuth world, this is a more flexible overall model. I=E2=80=99d like to understand more about what you=E2=80=99re seeing = here with regard to the keys, though, especially since this section was = restructured several times during the design team discussions and it = could be more consistent and clear.=20 > * 2.3.2: allowing to send the key in multiple formats virtually = invites security vulnerabilities. Why is this a good thing? See above, I think this is something we need to talk about more in the = group and I=E2=80=99m very open to having better ways present this = information. I didn=E2=80=99t see a harm in having the same key in = multiple formats, and JWK itself already allows that with the =E2=80=9Cx5c= =E2=80=9D field and related. > * 2.3.2: cert#256 is not a key, it's an identifier. Why do we include = it here? Note that in Sec. 8.3 you are using the full certificate rather = than the fingerprint. It=E2=80=99s more than an identifier, since an identifier could be an = arbitrary value =E2=80=94 this is cryptographically derived from a = specific certificate. If you=E2=80=99re doing MTLS, the client is still = sending the full certificate in the TLS layer, but this would be a way = to call out that certificate in a way that=E2=80=99s tied to the = request, without replicating it entirely within the request body. So = it=E2=80=99s a way to send the certificate in a more compact fashion = that you can verify, more than it is a way to identify a certificate = whose value you=E2=80=99d need to go look up. > * 2.3.2: why are we using raw PEM certificates instead of the JOSE = representation? The idea was to make it dead simple for developers. Not everything runs = on JOSE, but JWK is there if you want to use it (including JWK = certificate representations).=20 > * 2.3.3: For obvious security reasons, I suggest adding: The AS MAY = choose to avoid displaying an arbitrary URI. RC developers must only = assume that the "name" field will be displayed. I would actually go farther in the security considerations and say that = not even the name is necessarily trusted for display. An RC could claim = =E2=80=9CGoogle Docs=E2=80=9D as its display name, and without other = information being displayed (like callback URIs or home pages), the = RO=E2=80=99s got nothing to go on to figure out if it=E2=80=99s really = Google Docs or not.=20 > * 2.3.4, "created just for this request" -> created just for this = series of requests. Got it, thanks.=20 > * 2.3.4: I suggest referring to RCs that present unknown keys as = "anonymous RC", and then in 2.4, say that the AS MUST NOT accept any = assertions from an anonymous RC. I disagree with this =E2=80=94 there are a lot of cases out there where = the RC isn=E2=80=99t =E2=80=9Canonymous=E2=80=9D at all but is still = presenting a key that the AS doesn=E2=80=99t know. And in fact, the RC = might be presenting some assertions as to its own identity that the AS = can verify. > * 2.4: IMO assertion validation is a MUST, and we should specify what = we require for every assertion type we allow. I hear that point, but I=E2=80=99m just not sure we can or even should = get into that level of detail.=20 > * 2.4: moreover, when possible, the AS MUST match the assertions to = the presented sub_id. It may be a hint, but you're not allowed to lie. The reason that they=E2=80=99re a hint is that the client doesn=E2=80=99t = really know who the user is yet. So I agree the AS needs to process = them, but that doesn=E2=80=99t mean it has to trust them.=20 > * 2.4, "If the identified RQ does not match the RO present at the AS" = - I thought there are cases where the RQ is different from the RO. Also, = I am wondering why this is a SHOULD, not a MUST. The SHOULD is exactly for that use case where they aren=E2=80=99t the = same person. :) The idea is that the AS would at least be able to detect = that the user that the RC thinks is there is different from the one the = AS sees. This might be fine for the AS for multi-person delegation use = cases, and the AS can prompt the RO during authorization if that=E2=80=99s= the case. I can see that this needs to be a lot clearer, and we can work on that = text. > * 2.4.1 (but probably applicable to any references): what is the = lifetime of the reference? As an RC, how long can I assume the user = reference is still valid? That=E2=80=99s up to the AS ultimately. Previous editions of the XYZ = Protocol had lifetimes and other things tied to the reference handles = (defined in section 3.5), but it didn=E2=80=99t seem like anyone = actually cared about those parts in practice. A reference is either = going to work, or it won=E2=80=99t, and it could fail for reasons that = have nothing to do with a timeout that the RC can=E2=80=99t control or = have input into. > * 2.5: "preferred_locales" is obviously not a mode of interaction. Why = is it bundled here? It controls an aspect of how interaction could happen, which is what all = of the fields in this section do.=20 Even though it might look similar, these interaction modes aren=E2=80=99t = setting up things like the OAuth 2 =E2=80=9Cgrant type=E2=80=9D where = the combinations of parts are pre-defined and you=E2=80=99re signaling = which combination you=E2=80=99re after right at the start. Instead, the = RC is saying what it can handle throughout the interaction process. Some = of these are things that get the user over to the AS (redirect, = user_code, app), some are for getting the user back after interaction = (callback), and some are about how interaction can be presented before = the RO is known (preferred_locales). All of these are aspects of the = interaction process, and it=E2=80=99s the combination of all of these = together that say what the client can do. In this model, each of these = elements is independently defined, but they are all taken together as a = single set of parameters that can control the means of interaction with = the user. So in one way of looking at it, you=E2=80=99re creating the = =E2=80=9Cinteraction mode=E2=80=9D by defining all of the aspects of = that mode at once, including any potential parallel alternatives (ie: = redirect and app together).=20 The discussion on bundles of interaction elements in the editor=E2=80=99s = comment at the end of 2.5.3 provides an alternative model that would = allow the RC to define multiple sets of these interactions, so that you = could say, for instance, =E2=80=9CI can get you to an arbitrary URL or = type a user code but I can=E2=80=99t do a callback on those =E2=80=94 OR = I could get you to an arbitrary URL and also do a callback on that = one=E2=80=9D. This kind of thing would let the AS decide to give out two = different interaction URLs with different expectations on what to do = afterward, as opposed to right now where there is a single expectation = of what to do afterward no matter which URL the user followed to get = there.=20 I=E2=80=99ll also note that we removed the term =E2=80=9Ccapability=E2=80=9D= from this section as members of the design team found it confusing as = used here since it=E2=80=99s also used elsewhere in the document. I = replaced it with =E2=80=9Cmode=E2=80=9D, but that might have the wrong = connotations. I=E2=80=99m happy for suggestions of a better name than = =E2=80=9Cmode=E2=80=9D, but I=E2=80=99m starting to wonder if everything = should just be called =E2=80=9Ca thing=E2=80=9D everywhere. :) > * 2.5: the way "callback" is described here is as a capability, not an = interaction mode. The example only strengthens this view, "callback" is = a modifier of the "redirect" mode. The =E2=80=9Ccallback=E2=80=9D field defines =E2=80=9Cwhat to do after = interaction is done=E2=80=9D. Therefore, =E2=80=9Ccallback=E2=80=9D does = not just modify =E2=80=9Credirect=E2=80=9D, it also potentially modifies = other any other methods of getting the user in front of the AS. When the = AS figures out that it=E2=80=99s done with the RO, it follows whatever = steps the =E2=80=9Ccallback=E2=80=9D defines, regardless of how the user = gets there. So for example, you could have the user present a user code, = and then follow a callback to push information back into the RC. Or you = could have some kind of in-app interaction and still have a callback. Inversely, you could have a redirect :without: a callback, like if the = user scans a QR code on a secondary device but doesn=E2=80=99t come = back.=20 > * 2.5: "use code" -> user code. Got it, thanks. > * 2.5.1: this unnecessary polymorphism IMO just complicates = implementations and prevents extensibility. Instead, I would suggest: > redirect: {} > redirect:{max_length: 255} I find the pattern of sending an empty object problematic, and we need = to ask if there are other parameters that would really be sent here.=20 > redirect:{max_length: 255, callback: {...}} Again, the =E2=80=9Ccallback=E2=80=9D could be applied to multiple = outing options, but this would be an alternative of including it as = noted in the editor=E2=80=99s note in 2.5.3 about re-using the = =E2=80=9Ccallback=E2=80=9D field.=20 > * 2.5.2: the "app" option is problematic, as you already note. The RC = may not even know if a given URL will result in an application = launching. It depends on the nature of app =E2=80=94 it could be a single URL like = it is in many mobile platforms today but it could also be a bundle of = other information that can be used to launch the app. I don=E2=80=99t = think we=E2=80=99ll be doing any good by assuming things will continue = to be single URLs. > * 2.5.2: and shouldn't the RC include a list of supported = applications? (Which would have lovely privacy implications.) I think that=E2=80=99s a reasonable dimension and one of the reasons = =E2=80=9Capp=E2=80=9D launch should be separate from the =E2=80=9Cnormal=E2= =80=9D redirect. I brought this up with some implementors in the = financial sector a while ago, and with that group at least there = wasn=E2=80=99t a lot of desire for that kind of functionality.=20 I agree that there are some significant privacy implications driving = this as well.=20 > * 2.5.3: there's a parenthetical discussion on whether the URL is = unique. But the nonce parameter implies that the "hash" parameter is = unique per request, making this discussion moot. I agree with you, if we have a =E2=80=9Cnonce=E2=80=9D then you don=E2=80=99= t necessarily need a unique URL, at least not for security purposes. The = editor=E2=80=99s note is to point out the inverse that came up in design = team discussions, that the =E2=80=9Cnonce=E2=80=9D is not needed to = protect against some of the attacks if you require a unique URL. I would = like to see some formal analysis against this feature set as we build = this out.=20 > * 2.5.3: even if we need a different kind of post-interaction = "redirect", where the RC is not involved, there must be a way to ensure = that the RC receives positive (cryptographically protected) confirmation = that the authorization was successful. In other words, what we're = discussing here is not an RC interaction mode, it is something else, and = should probably have a separate protocol element to describe it. I=E2=80=99m on the fence about it being something outside the = interaction element, since it=E2=80=99s a kind of post-interaction = method just like =E2=80=9Ccallback=E2=80=9D already defines. I don=E2=80=99= t think it makes sense to allow a client to ask for more than one of = these at a time, and it could lead to some weird race conditions (do I = poll if I might get a callback?) and potential security issues (I polled = but then got a callback, is that an injection attack?).=20 > * 2.5.3: In the example for "interact" as an array (which I support), = the second "redirect" and "user_code" should be independent elements of = the array, not members of an object. This assumes they are truly = independent interaction modes. No, they are bundled together as the same element in the array on = purpose. This is the client saying =E2=80=9CI can send the user to a = short URI or I can display a user code, but I can=E2=80=99t get a = callback=E2=80=9D. This is equivalent to the OAuth 2 device mode of = displaying a QR code for the user to scan and giving them a code to type = into a static URL. The QR code is already an arbitrary URL and so it can = use the same mechanism as =E2=80=9Credirect=E2=80=9D. To do what = you=E2=80=99re asking you=E2=80=99d want a three element array.=20 > * 2.5.3.1: what does "RQ is present on the request" mean? This is most clear for web server based RC=E2=80=99s: the session that = was used to send the user outbound needs to be the same that is used = when the return comes in. It makes less sense with other interaction = methods and other client types, but wherever possible the RC needs to = make sure that the user who started the request is =E2=80=9Cstill = there=E2=80=9D when the response comes back in the front channel.=20 Is there a better way to say this without making it overly prescriptive? > * 2.5.3.2: typo: HTTP the request. Got it, thanks! > * 2.7: this seems to assume a short access token (which implies a = bearer token). What if we want to use longer self-contained access = tokens containing full keys? Should we have a separate "grant_id" value = instead? I don=E2=80=99t see how this implies a short access token, can you = expand on what you mean by that? The access token value will always be a = string, opaque to the client, so if it=E2=80=99s self contained and has = its own keys wrapped inside of it in some way, that=E2=80=99s fine and = would still be enough for the AS to figure out what it means.=20 There previously was the equivalent of a =E2=80=9Cgrant_id=E2=80=9D for = exactly this purpose =E2=80=94 it was the =E2=80=9Ctransaction handle=E2=80= =9D in previous revisions, and it was also used for continuation and a = number of other functions. That feature has been phased out in favor of = using either unique continuation URIs, access tokens, or a combination = of both for managing the ongoing grant request process. Having an = explicit identifier would be helpful for this specific use case, but = it=E2=80=99s not needed for the more common use cases anymore. Would it = be worth bringing it back in? > * 2.8: another problem with this stanza is that the RC needs to know a = priority that the AS supports it. What happens if the AS doesn't? If the AS doesn=E2=80=99t support this, then it gets ignored and has no = effect on the resulting response. At least, that=E2=80=99s how I think = it should go =E2=80=94 we could also allow the AS to return an error for = fields it doesn=E2=80=99t understand, but that=E2=80=99s something that = needs to be consistent across the protocol in my opinion. > * 2.8: I suggest to move this section into a separate I-D, or at least = a separate appendix. As stated in the last note in the section, I agree, and in fact don=E2=80=99= t think we should be defining any use of OIDC within the GNAP working = group. I think a good exercise would be to build out what an actual OIDC = style protocol would be on top of GNAP, and it=E2=80=99s something I=E2=80= =99d like to . The design team included this section as a way to show = how this type of externally-defined query language could be = incorporated, with all of its limitations and assumptions that come with = it.=20 > * 2.9: it makes sense to bundle extensions and the "capabilities" = section into one. While I see the point, the =E2=80=9Ccapabilities=E2=80=9D field is = really meant to signal specific extensions. It=E2=80=99s really loosely = defined right now though, and I think that we need a lot more concrete = applications of the mechanism if we=E2=80=99re going to keep it. > * 2.9: The AS MUST ignore any unknown extension. I=E2=80=99m OK with this stance, but it needs to be consistent = throughout the protocol, not just at this level.=20 > * 3: it's confusing that we're using access_token for two different = things. Maybe we could change the RC/AS one to "as_access_token"? I disagree =E2=80=94 I think we=E2=80=99re using them for the same kind = of thing. They=E2=80=99re both access tokens, and they=E2=80=99re used = by the client in exactly the same way. The resource being accessed is = part of the AS in one case, but the RS in the other case, but you use = the same kind of artifact in both cases to do the same kind of thing. I = think there=E2=80=99s a lot of power in re-using components like this = instead of inventing something special here. > * 3.1: MAY vary *by* request. Got it, thanks! > * 3.1: how is the client behavior "deterministic in all cases" - how = does the RC know whether the AS allows continuation or only allows one = request at a time? If the AS does not include a =E2=80=9Ccontinue=E2=80=9D field in any of = its replies, then the RC can=E2=80=99t continue it again.=20 > * 3.2.1: the "value" of the access token is opaque in some cases = (bearer token) but not in others. In what cases would it not be opaque to the client? In all the current = binding methods, this value would still be opaque and the RC still has = to send the token value. > * 3.2.1: The ASCII restriction on "value" is insufficient. Needs to be = printable ASCII, 0x20 * 3.2.1: why is "expires_in" optional? Typically access tokens are not = revoked, and the RC needs a way to manage their lifetime. Access tokens are revoked outside of the RC=E2=80=99s control in a lot = of different ways, not just timeouts. And there are non-expiring access = tokens out there as well. It=E2=80=99s possible, though in my experience = exceedingly rare, for an RC to preemptively get a new access token = before expiry. > * 3.2.1: "resources" refers to this same section. Did you mean 2.1.2, = or are we missing a subsection describing resources/rights? Good catch, this was in fact meant to point to 2.1.1 (the anchors in = markdown are similarly named since this is the corresponding response to = that request section). > * 3.2.1: "key": another polymorphism alert! Yes, this is intentional use of polymorphism to allow one field to = represent different ways of related things instead of having multiple = mutually-exclusive fields say the same thing. Right now it=E2=80=99s got = four possible values, and each of them answers the question =E2=80=9Cwhich= key is this token bound to=E2=80=9D: Boolean =E2=80=9Ctrue=E2=80=9D: use the RC=E2=80=99s presented key (ie, = =E2=80=9Cthe key you sent=E2=80=9D =E2=80=94 the client doesn=E2=80=99t = need any additional identifying information to determine which key or = method) Boolean =E2=80=9Cfalse=E2=80=9D: bearer token (ie, =E2=80=9Cno key=E2=80=9D= ) Object: A specific key, not the one the client sent, either a public key = for something the RC knows or possibly a full key pair (with private = key) or a symmetric key provided by the AS; I think we need more on this = use case String: A specific key, not the one the client sent, indicated by this = reference that the RC can figure out An RC looking at this field is always looking to answer the question of = how the token is bound, and this allows us to answer that definitively = in a single space. > * 3.2.1: the example at the bottom of the section talks about a way to = present the token, I believe this discussion is out of context here. I=E2=80=99m not sure which example you are referring to here, since I = don=E2=80=99t see anything about a way to present a token. If you mean = the editor=E2=80=99s note at the bottom about directed access tokens, = this is relevant here because the information needed to direct the RC = where it should use the tokens would be included in this response. > * 3.3: the AS knows now which interaction modes are available. Why not = pick just one for its response, to simplify the protocol? As one = example, the AS can then more easily decide on timeout behavior. The AS can do exactly that with the existing construction =E2=80=94 it = can respond to only the parts that it wants to do for that specific = request.=20 For example, if the RC doesn=E2=80=99t include the =E2=80=9Ccallback=E2=80= =9D in its request but the AS decides, for security reasons, that it = won=E2=80=99t serve any requests without a way to return control = directly to the RC post-interaction, then the AS can reject a request = that doesn=E2=80=99t have that.=20 For another example, if an AS decides that a specific resource can only = be authorized through a user code interaction (maybe it=E2=80=99s for a = resource/client format that the AS knows to be a limited device and so = the AS has a specific usage pattern it will allow), then the AS can = respond only to the =E2=80=9Cuser_code=E2=80=9D portion of the = client=E2=80=99s request, even if the client includes a =E2=80=9Ccallback=E2= =80=9D and =E2=80=9Credirect=E2=80=9D parameter as well.=20 Combining these interaction together is key to moving GNAP beyond what = OAuth 2=E2=80=99s extremely limited =E2=80=9Cgrant_type=E2=80=9D model = allows. > * 3.3.3: Suggest to add to the last paragraph: If the RC does not = receive a callback until an RC-determined timeout occurs, the RC MUST = act as if the entire request failed. I=E2=80=99m fine with adding that kind of guidance. It gets fuzzy in = terms of security considerations though because =E2=80=9Can = RC-determined timeout=E2=80=9D without other guidance is so loose as to = be undefined. > * 3.4: "updated_at": Unix time is nice, but for absolute time it's = common to use ISO 8601 format. I stole this field from OIDC, but I=E2=80=99m fine with any format here, = so if there=E2=80=99s no outcry we should change it in the next = revision.=20 > * 3.6: YES, the "error" element is exclusive! I think it should be, but I=E2=80=99d like to see if there=E2=80=99s any = kind of counter argument. For example, returning an error BUT also = allowing continuation to address the error. Is that allowed? If so = we=E2=80=99d need to return the =E2=80=9Ccontinue=E2=80=9D field as = well, which is already defined. But if =E2=80=9Cerror=E2=80=9D means = =E2=80=9Cthis is final, this request is done now and forever=E2=80=9D, = then yes it should be completely exclusive of all others.=20 > * 3.6: in SecEvent we tried to use RFC 7807 "problem details", I think = it could work nicely here. I=E2=80=99m unfamiliar with the details of that spec, but after a quick = skim I think that=E2=80=99s got some possibility. It seems to = incorporate a lot of information from the HTTP message in the response = body though which isn=E2=80=99t really that applicable. > * 10.4: "indicating that GNAP" - sentence is broken. Thanks, that meant to say "indicating that GNAP needs to be used to = access the resource=E2=80=9D, fixed. > * This "speculative" access is not useful if the response is only a = MAY. Why would the RC try it if it is unlikely to provide useful = information? I think the MAY is not quite the right normative application here. = It=E2=80=99s a MUST if you=E2=80=99re doing it to do it in this way, but = it=E2=80=99s not a MUST for all RS=E2=80=99s everywhere to respond in = this fashion. If the RC tries calling an RS that doesn=E2=80=99t respond = with this, the RC simply doesn=E2=80=99t know, from any programmatic or = automated way, what to do to make the request actually work. > * 15: the BCP195 ref is broken - the author names are missing (yes I = am one of them...). Yes, all the references need to be cleaned up! RFCs and IDs get picked = up automatically by the tools, but other documents (including, it seems, = BCPs) don=E2=80=99t have that luxury. I focused on getting a basic = reference in place so that it would compile, and now I need to go back = and make it more correct. No offense intended to any of the BCP or other = document authors. :) > * Appendix D: can we name the first scenario, maybe "Simple API = Access"? I don=E2=80=99t think that is an accurate name for what=E2=80=99s being = shown here, and especially for what=E2=80=99s being highlighted. We are = specifically showing how to get API access through the use of fully = redirect-based interaction =E2=80=94 redirect the user there, and have = them redirected back. It=E2=80=99s analogous to the OAuth 2 = Authorization Code Grant Type. It=E2=80=99s very specific to that = aspect, and not really specific to =E2=80=9CAPI access=E2=80=9D. In = fact, nothing in the scenario really needs API access for it to work =E2=80= =94 the RC could be asking for subject information instead and the rest = of the example would remain the same. This is the same scenario as = discussed and diagrammed in 1.3.1, but with more extensive examples of = protocol messages in use.=20 =E2=80=94 Justin > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_0DF47B37-0192-4C3A-B3A1-2F51A8112774 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Yaron,

Thanks for = the thorough reading. I agree with the other commenters that GitHub = issues are a better way to track many of these items. There=E2=80=99s a = natural threading and separation of discussions, which can get really = unwieldy in a mailing list thread, but you can also explicitly = cross-link things. Also, when changes are made to the document in = response to a specific issue, the change set can be linked to the issue = that caused them. It also lets people engage on the specific topics that = they want. 

With that in mind, now is the best time for the group to = decide on the best practices for disposition and addressing feedback, = and agreeing on when and how to bring discussion to the list. We have a = lot of work ahead of us, and now is when we need to decide how we=E2=80=99= re going to do that work.

In the mean time, I=E2=80=99ve commented on each of these = inline below. It=E2=80=99s a lot of writing, and I apologize ahead of = time to everyone for that. I also apologize in advance if there are cut = off sentences or things that don=E2=80=99t make sense =E2=80=94 there = was a lot to discuss here in one go, and I=E2=80=99ve tried not to leave = anything out. I=E2=80=99m hoping that the responses below will offer = some background and clarity into how we got to what=E2=80=99s there now, = so that we can find what the right way is forward, even (or especially) = where things need to change. Absolutely everything in the 00 draft is up = for discussion to drive consensus within the working group going = forward. And there is a LOT of discussion for this working group to have = still, and I look forward to continuing that discussion in a productive = manner.

Thanks,
 =E2=80=94 Justin

On Oct 18, 2020, at 3:44 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin, all,
 
The draft has undergone major = changes since we started the design team, so I spent some time reviewing = it. I only got as far as Sec. 3, and I fully intend to review the = remainder of the document. But I figured since I have so many comments, = I might as well send out what I have.
 
* General comment: we have dozens, = maybe hundreds of variants/options here. I think we need to define a = must-implement subset, or we will never reach = interoperability.

Completely agree, but please understand that many = of these options are presented by the design team as explicit discussion = points. In particular, there are MANY things that are in =E2=80=9CEditor=E2= =80=99s Note=E2=80=9D blocks throughout the document, where the design = team saw multiple ways to approach something that we believed the wider = working group should weigh in on. In other words, many of what are = presented as =E2=80=9Coptions=E2=80=9D aren=E2=80=99t integrated as = options within the protocol itself, but options FOR the protocol to be = considered for integration and decision. 

I=E2=80=99ll also note that the back-and-forth = =E2=80=9Cnegotiation=E2=80=9D nature of the protocol allows the = different parties to present options to each other at runtime (or = before) and settle on an overlapping set of functions to enable interop. = So the RC can ask for a feature, and the AS can reject it because it = isn=E2=80=99t allowed for a specific request or because the AS doesn=E2=80= =99t support it at all =E2=80=94 in either case, the client doesn=E2=80=99= t get what it wants. Even so, I agree that we will need to have a notion = of mandatory to implement within the protocol in order to facilitate a = base level of interoperability, and this is currently lacking in the = document because I don=E2=80=99t have a good idea of what the MTI = portions really need to be. As you know, a security protocol needs to be = especially careful not to mandate implementation of an insecure option = for MTI purposes, and that=E2=80=99s a delicate balance the WG is going = to need to settle on. Would you suggest an MTI section be added? OIDC = has this, with several profiles within that section.

* Abstract: the boilerplate text = (MUST etc.) usually goes to the Introduction, not the = Abstract.

Thanks, I was led astray by the template I used = when I converted to Markdown from XML. :) We should move it into a more = proper =E2=80=9CIntroduction" section, which will encompass what=E2=80=99s= now labeled =E2=80=9Cprotocol=E2=80=9D in section 1. 

* 1. "The requesting party = operating the software" - I think these actions are typically performed = by the resource owner, who is not necessarily the requesting = party.

You=E2=80=99re right, that is not at all clear = from the text as written, we can fix that.

The funny thing is, this is exactly why we = separated the requesting party from the resource owner =E2=80=94 they = are defined by the actions they take. The requesting party interacts = with the client while the resource owner does the approval. You=E2=80=99re= right that in many cases the RO and RQ are the same person, as this is = the core OAuth 2 use case set =E2=80=94 and this is what the text in = question was actually trying to point out. 

* RS, aka API: we are using the = word "API" several times in a more generic sense (management API, = identity API), so maybe replace with "RS, typically a protected = API".

Good catch, this is an artifact from a previous = version where non-RS items weren=E2=80=99t described as an API so it was = a more safe comparison. 

(Even = so, things like the token management API and request = continuation/management now have parity with RS APIs by using access = tokens for protection, so we do need to be more clear/precise about what = an =E2=80=9CRS=E2=80=9D exactly is.)

* 1.2, "key" is a too generic term = in the context of a security protocol. Can we call it something more = specific, maybe "holder identity = key"?

This isn=E2=80=99t just about a user=E2=80=99s key = =E2=80=94 this is primarily a key for the requesting client software, = but it gets used in a number of ways. Keys can be bound to client = instances and to access tokens, and they can be used to identify various = parties in the system (including users). 

It was brought up in the design team meetings that = we might not even need to define this term, since it=E2=80=99s = understood in the wider security space, and so I=E2=80=99m happy to = either take it out or expand it as required.

* 1.3.1. "augmented with a hash = of the security information" - this is too implementation-specific, = suggest "is cryptographically bound to the security information". In = general, step (7) is way too detailed, and verges on the = normative.

I=E2=80=99m fine with this suggested rewording. = Note though: this is not a generic flow, but this sequence is intended = to be specific to use of the =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallb= ack (with redirect)=E2=80=9D interaction modes in combination with each = other, and thus is specific to the functioning of those = elements.

* 1.3.2: it is unclear to me what = the goal of the user-code interaction is, in other words what is the = threat model. If it's just "second factor, something you have", then an = OTP MFA device would be simpler and offer the same = security.

This is an equivalent function of the OAuth Device = Flow: https://tools.ietf.org/html/rfc8628

It=E2=80=99s not about a second factor for = authenticating the user, really, it=E2=80=99s about facilitating = authorization on a secondary device through the use of a user-typed code = to tie the back end and front end together.

* 1.3.5 (4): Typically the access = token would not be sent once it is expired, right? Let's make the = example more realistic.

The intent is that time has passed between (2) and = (4) to allow the token to expire =E2=80=94 not that the token is already = expired. I initially had a =E2=80=9Csuccessful request=E2=80=9D in the = middle, but I cut it out as it wasn=E2=80=99t interesting to the topic = of refreshing a token. I=E2=80=99ll add it back in for = clarity. 

* 2: "OpenID Connect claims = request" - why not "identity claims request" (which just happens to be = similar to the OpenID = request)?

Because this is specific to the OpenID Connect = Claims query language, which has inherent limitations on its use. More = comments in response to your note on section 2.8, below.

* Never liked the "dolphin" = here... If this is listed under "actions", it should be a verb, e.g. = "swim".

So there=E2=80=99s a (fairly silly) story on why = =E2=80=9Cdolphin=E2=80=9D is an example here and has been an example in = several RFC=E2=80=99s I=E2=80=99ve edited, but it=E2=80=99s more = appropriately shared over beers when that=E2=80=99s an option again. :) = I agree that =E2=80=9Cswim=E2=80=9D is probably less confusing in this = specific context though.

* 2.1: an array for a single AT = vs. an object for multiple ATs? This is extremely non-intuitive and = probably ugly to code. Also, why should (multiple) tokens be named if a = single token doesn't have to, why not list them in an array = instead?

I agree that it looks a little odd at first = glance, but I=E2=80=99ve coded this in a few languages now and on the = request side (this section) it is really clear what you=E2=80=99re = doing. I think it might be helpful to build up from the parts of this = section of the request, which will show the history and decision process = that got us to the syntax that=E2=80=99s there today. Obviously, this = isn=E2=80=99t a statement that it needs to stay this way, but I hope = that this will help bring to light the reasoning behind what=E2=80=99s = there now so that it can be explained, refined, or updated as = needed.

At the lowest level, we=E2=80=99= ve got the dimensions for access. OAuth 2 showed us that =E2=80=9Cscope=E2= =80=9D was a useful way for a client to indicate what it wants, but = we=E2=80=99ve found that API designers have used scope to talk about = many different dimensions of access, all rolled into different scope = values. We are now being explicit about those dimensions, and trying to = make those dimensions orthogonal to each other. There is some small = amount of fuzziness and potential overlap of interpretation, and = ultimately these are all up to the AS/RS (and the API designer, really) = to define:

 - type: =E2=80=9Cthe = kind of API I want to call=E2=80=9D, like OIDC UserInfo or FHIR Medical = Record
 - datatypes: =E2=80=9Cthe kind of data I want to = use at the API=E2=80=9D, like email addresses or office = visits
 - actions: =E2=80=9Cthe kind of actions I want to = do on the API=E2=80=9D, like read, or write, or make the robot = move
 - locations: =E2=80=9Cthe RSs I want to call the = API on=E2=80=9D, like the URL of the UserInfo Endpoint or a URI for a = specific document server cluster
 - identifier: =E2=80=9Cth= e entity I want to do these actions on=E2=80=9D, like the medical record = ID or bank account number

These are = all strings or arrays of strings, = and they=E2=80=99re meant to be very specific to the requested access to = the API. Specific APIs are likely to add their own dimensions as well, = which can be pretty much anything so long as the RS can interpret the = token that it represents. This is why we have the =E2=80=9Ctype=E2=80=9D = field, which gives us a way to namespace the = dimensions. 

But these = dimensions don=E2=80=99t live alone: I=E2=80=99m not going to just ask = for =E2=80=9Cread=E2=80=9D or just =E2=80=9Cmedical record=E2=80=9D, I = probably want to ask for =E2=80=9Cread the medical record=E2=80=9D. With = scopes, we were forced to just put them all in a bucket and define = awkward semantics for combining them, and then watch things go awry as = an AS protected different APIs with different interpretations of, for = example, =E2=80=9Cemail=E2=80=9D as a scope. So with GNAP, we=E2=80=99ve = got a way to combine them into single objects. That = lets us create combinations like =E2=80=9Cread the medical record=E2=80=9D= by combining the =E2=80=9Ctype=E2=80=9D and =E2=80=9Cactions=E2=80=9D = fields into a single object. The =E2=80=9Cpass by reference=E2=80=9D = feature allows us to send a simple string value that = is interpreted as if it were one of the objects. So maybe there=E2=80=99s = a =E2=80=9Cfhir-read=E2=80=9D value that means =E2=80=9Cread all = available sections of the fhir medical record of the current user=E2=80=9D= . You can think of it like a pre-computed object where the client = doesn=E2=80=99t have to specify all the details =E2=80=94 and in that = way it works almost just like a scope value would. 

But what if I want read access to the medical = history record but ALSO want update access to the demographic = information? We can=E2=80=99t just throw it all onto the same object = because there are two very distinct requests, but one access token can = reasonably encompass both. So in GNAP we=E2=80=99ve got an array of objects that allows us to combine these = multidimensional requests and have them all apply to a single access = token. Since any of these objects could potentially be replaced by a = string, this array could have a combination of strings or objects, but = each item in the array represents the same kind of multi-dimensional = request. The =E2=80=9Cscope=E2=80=9D field in OAuth 2 is semantically an = array (even though it=E2=80=99s formatted as a space-separated list of = space-free ascii strings) for exactly this reason: I should be able to = ask for multiple scopes at the same time. 

The resulting access token is for the total of = everything in the array (that=E2=80=99s granted =E2=80=94 of course any = of this can be changed by the AS and RO). So an access token always = represents an array of requested access rights, = each access right is an object that describes = what=E2=80=99s being requested across several dimensions = which are properties of that object in their own syntax. An access = token is a combined collection of access rights, so requesting an access token requires the structure of an array. And so = far, this is inline (by design) with what=E2=80=99s in OAuth 2 RAR: =  https://tools.ietf.org/id/draft-ietf-oauth-rar-03.html

And that brings us to multiple access = tokens: Multiple access tokens are requested by sending an object which uses labels to mark individual single access token requests, which as we just saw = is an array =E2=80=94 so it=E2=80=99s an object whose values are all arrays, but specifically arrays that are defined to ask for a single access = token.

Why put the labels on = these requests? Multiple access tokens need to have names (or labels) so = that the client can tell :which: of its access requests each token maps = to. Otherwise, how can a client know which set of resources it=E2=80=99s = supposed to use each token with? The =E2=80=9Clocations=E2=80=9D field = (discussed more below) is for identifying sets of resources, and so that = field is not likely to be the exact set of URLs that the client can use = the token at. And it=E2=80=99s also not guaranteed that all APIs will = use =E2=80=9Clocations=E2=80=9D in a way that=E2=80=99s meaningful to a = client =E2=80=94 what if the client wants =E2=80=9Cread=E2=80=9D and = =E2=80=9Cwrite=E2=80=9D access at the same API with different tokens? = The =E2=80=9Cread=E2=80=9D token could be long-lived but the =E2=80=9Cwrit= e=E2=80=9D token short lived, for security purposes, but the = =E2=80=9Clocations=E2=80=9D would be the same. Additionally, the = =E2=80=9Cread=E2=80=9D could be limited to GET requests and the = =E2=80=9Cwrite=E2=80=9D limited to =E2=80=9CPOST=E2=80=9D requests, = neither of which is really expressed in =E2=80=9Clocations=E2=80=9D. If = the RC is going to ask for different tokens in a single request, it = needs to have a way to differentiate the portions of the response from = each other. 

There are some = different syntaxes we could use to make parts of this work, but these = choices tend to have other follow-on effects. Here are a few that I=E2=80=99= ve cycled through in the design of the current proposal:

We could ask for multiple access tokens this by = having a =E2=80=9Clabel=E2=80=9D field inside the request for a single = access token and then sending an array of single access token request = (so an array of arrays), but then you need to answer = the question of where in the request to put the label. Should it go in = the array like the proposed =E2=80=9Ctoken flags=E2=80=9D? Should it go = inside one of the objects in the array? But if it does, what would it = mean for multiple objects in the array to have a =E2=80=9Clabel=E2=80=9D = value? Additionally, we=E2=80=99d need to detect at the top level = whether we had an array of arrays or an array of objects and strings =E2=80= =94 doable, but more prone to weird error cases. (What if an RC sends an = array with one array and one object? We need to detect that now and = might end up down the wrong code path before we do, with a naive parser = anyway.)

We could simply require all = tokens to be labeled at all times, but I would argue that the = overwhelmingly common use case of a single access token doesn=E2=80=99t = need that kind of overhead because there=E2=80=99s only one set of = requested items that the RC is asking for. 

We could define single access tokens as an object, = with multiple aspects. This would potentially let us hang additional = fields off of the access token request alongside the resource list, but = it would also mean that we=E2=80=99d have a degenerate case where = you=E2=80=99re defining an object with one member, whose value is always = an array. In other words, this is exactly what the JSON Web Key Set = format does, which I=E2=80=99ve always found clunky. The top level = object doesn=E2=80=99t add anything in the JWKS case, and I=E2=80=99m = not seeing how it would add anything here. On the other hand, this would = let us use an object for a single access token and potentially an array = for multiple access tokens, but at some cost to the complexity at the = layers below that.

None of those = ideas lead to a better syntax across the different uses cases, or that = optimize for simplicity in the common use cases.

All that is to say that I currently think that = what we have is the simplest and cleanest approach that I=E2=80=99ve = seen so far, and I would really love to see if there are any = alternatives that offer this same kind of power and clarity when = exercised the same. I would love to see some fresh ideas on different = ways to approach this.

* 2.1.1, "locations": are these = really URIs or just URLs? On the other hand, if these are URIs, why do = we need a separate "identifier"? There's too much semantic overlap = between "type", "location" and "identifier" - specifying just "type" may = be sufficient.

In my implementation, =E2=80=9Clocations=E2=80=9D = are actually just Strings that the AS and RS can dereference to figure = out the intended target of the RS. In practice I think these will be = URIs that identify the RS (or really, the APIs hosted at each RS) in a = way that the RC can communicate to the AS and back. It=E2=80=99s not = meant to be an exhaustive list of URLs that the RS will use the token = at, since an =E2=80=9CRS=E2=80=9D could have a nearly infinite set of = URLs that it protects, depending on the nature of the API. GNAP = shouldn=E2=80=99t take a stance on the structure of the APIs it = protects, much like OAuth didn=E2=80=99t.

=E2=80=9Cidentifier" is for an object identifier = of some type within the API =E2=80=94 so while =E2=80=9Clocation=E2=80=9D = is more to identify the RS itself, =E2=80=9Cidentifier=E2=80=9D is to = indicate the item at the RS which might not be exposed through any kind = of URL. 

=E2=80=9Ctype=E2=80=9D = tells you what=E2=80=99s in the rest of the object. The semantics are = shared with OAuth RAR, as mentioned in the note: https://tools.ietf.org/id/draft-ietf-oauth-rar-03.html = ;Though, as mentioned in the note, we can=E2=80=99t cleanly normatively = reference RAR directly as RAR needs to exist in an OAuth 2 world, which = has =E2=80=9Cscope=E2=80=9D and =E2=80=9Cresource=E2=80=9D parameters, = as well as some extensions/profiles that use an =E2=80=9Caud=E2=80=9D = parameter and other items. We don=E2=80=99t have those restrictions in = GNAP and so the semantics are slightly different here. In an ideal = world, we=E2=80=99d define these in GNAP and RAR would be a clean = back-port of this function to OAuth 2.

For a concrete strawman example using OpenID = Connect=E2=80=99s userinfo endpoint with the subject ID 248289761001, we = might have something like this:

{
&nb= sp;  locations: [ https://server.example.com/userinfo ],
  =  identifier: 248289761001
}

A more realistic example would be asking for a = specific bank account (identifier) at a specific bank (locations) for a = specific accounting API (type). 

Any advice to clarify this intent would be greatly = appreciated!

* 2.1.1: it's implied but should = be spelled out that the semantics of this example is the cross product = of permissions: I am requesting to read and write and "dolphin" both = "metadata" and "images", and that applies to both "locations" - 12 = different possible = actions.

OK, that can be expounded upon here, as that is = the intent. Each object is meant to encompass one fully realized = combination of options, which is why they=E2=80=99re presented in an = array overall (as talked about above).

* 2.1.2: I don't see the value of = the notion of "expansion". It is sufficient that the string is = understood by the AS.

While I personally agree with your stance, this = was from a discussion on the list about the nature of the string value = that we wanted to capture here. 

* 2.1.2, "in some situations the = value is intended to be seen and understood be the RC developer" - = shouldn't we require this value to be always fully documented by the AS = owner, so that the RC knows what it is = requesting?

For cases when the developer sees it and = configures it into the RC code, I agree. But there are cases (like = section 10.3) where things happen more dynamically that are also enabled = by this functionality. 

* 2.1.4: why are flags represented = as resources? The answer, "this is how OAuth 2 does it" is not = great.

The idea is that these are items that alter what = the access token that=E2=80=99s being requested in the =E2=80=9Cresources=E2= =80=9D section. It is a sensible way to hang things together since = everything in the array ties to a specific access token. This was a = proposed design compromise, and if these flags can fit elsewhere then we = can do that.

* "the each access tokens" -> = each access token.

Thanks, got it!

* I suggest to extend the editor's = note to clarify what is the use case, so that the group can decide = whether split tokens are indeed = necessary.

I think we should have a more detailed = conversation about this potential feature than an editor=E2=80=99s note = could reasonably get into. There are a number of large items (splitting = access tokens, directing access tokens to specific portions of API or = RS=E2=80=99s, among others) that I think will be big conversations for = the WG, and all the context of these don=E2=80=99t necessarily need to = be documented inside the notes in the document = itself. 

But for discussion and = context, this feature was proposed to deal with cases where the AS might = decide to issue several access tokens in any case where the client = requested one, because the AS wants to have restricted audiences for = individual access tokens but the client doesn=E2=80=99t know about the = audiences ahead of time. I agree that it=E2=80=99s a compelling use = case, and it puts security of the protected domains in the hands of the = AS where it belongs, but it would require a client to be smart enough to = know what to do with these tokens downstream, and if OAuth has taught us = anything it=E2=80=99s that we can=E2=80=99t rely on client software to = be smart about most anything. :)

* Why is key binding of the access = token even optional?

Because people still want to use bearer tokens as = an option. I think we can make bound tokens first class citizens in = GNAP, and that=E2=80=99s a large reason behind having consistent key = binding approaches instead of having them separated out (section 8). I = think we can even make the =E2=80=9Cdefault=E2=80=9D having the token = bound to the RC=E2=80=99s presented key (and therefore make =E2=80=9Cunbou= nd token=E2=80=9D a flag instead), but I don=E2=80=99t think there would = be support in the community for removing bearer tokens = entirely.

* 2.2, "Subject identifiers = requested by the RC serve only to identify the RO in the context of the = AS and can't be used as communication channels by the RC" - this sounds = a bit naive, people will do that anyway. So why is this a useful = statement? (And similarly in = 3.4)

This inclusion is based roughly off of a similar = constraint in OIDC around subject identifiers: https://openid.net/specs/openid-connect-core-1_0.html#ClaimStab= ility

I agree that people will = do dumb things anyway, but that=E2=80=99s why we ned to spell out why = it=E2=80=99s dumb here.

* 2.3: what's the benefit of = including a URI (URL really) in "display"? Do we really want the user = (RO) to click links provided by the = RC?

I = think we want to give them the option of doing so, yes. It=E2=80=99s up = to the AS to help protect the RO, and that will need to be written up in = the security considerations. 

This is analogous to =E2=80=9Cclient_uri=E2=80=9D = in OAuth Dynamic Registration: https://tools.ietf.org/html/rfc7591#section-2

* 2.3: why are we sending a JWK = *as well as* a cert? Are we checking that the cert contains the same = public key as the cert?

I would be ok with the different formats being = mutually exclusive somehow. The AS would need to check that they=E2=80=99r= e the same and throw an error if not. But this would also let the RC = send over whatever it=E2=80=99s got for its own keys every = time.

* 2.3, " the AS MUST ensure that = the key used to sign the request... is associated with the instance = identifier" - can we be much more specific here, e.g. the instance_id = MUST be byte-identical to the Common Name of the cert? This = "association" is never clarified, either here or in Sec. = 8.

No,= I don=E2=80=99t think we should be so prescriptive =E2=80=94 for one, = it won=E2=80=99t always be a certificate or a JWK (where you might use = the Key ID). And for another, you might want to rotate the key without = changing the instance identifier. And finally, I don=E2=80=99t think the = CN would even be enough since there will be plenty of cases where = you=E2=80=99d be accepting client-supplied keys. 

The =E2=80=9Cinstance_id=E2=80=9D is an = AS-assigned value that it can use to look up information about the = instance of RC software making the call. Part of that includes whatever = key information is associated with that instance. The =E2=80=9Cassociation= =E2=80=9D for this kind of thing is up to the AS, and in OAuth we called = this =E2=80=9Cstatic client registration=E2=80=9D or =E2=80=9Cdynamic = client registration=E2=80=9D, depending on how it happened. Here, = we=E2=80=99re taking a step back from saying that =E2=80=9Ca client must = be registered=E2=80=9D and instead simply saying that =E2=80=9Cif you = see an instance_id, you need to know what key goes along with that and = prove that that key is used=E2=80=9D. For many clients, it=E2=80=99s the = same net effect as having a client_id and registering their public key = against that client_id in OAuth 2, but for large swaths of clients that = currently fall outside of the OAuth world, this is a more flexible = overall model.

I=E2=80=99d like to = understand more about what you=E2=80=99re seeing here with regard to the = keys, though, especially since this section was restructured several = times during the design team discussions and it could be more consistent = and clear. 

* 2.3.2: allowing to send the key = in multiple formats virtually invites security vulnerabilities. Why is = this a good thing?

See above, I think this is something we need to = talk about more in the group and I=E2=80=99m very open to having better = ways present this information. I didn=E2=80=99t see a harm in having the = same key in multiple formats, and JWK itself already allows that with = the =E2=80=9Cx5c=E2=80=9D field and related.

* 2.3.2: cert#256 is not a key, = it's an identifier. Why do we include it here? Note that in Sec. 8.3 you = are using the full certificate rather than the = fingerprint.

It=E2=80=99s more than an identifier, since an = identifier could be an arbitrary value =E2=80=94 this is = cryptographically derived from a specific certificate. If you=E2=80=99re = doing MTLS, the client is still sending the full certificate in the TLS = layer, but this would be a way to call out that certificate in a way = that=E2=80=99s tied to the request, without replicating it entirely = within the request body. So it=E2=80=99s a way to send the certificate = in a more compact fashion that you can verify, more than it is a way to = identify a certificate whose value you=E2=80=99d need to go look = up.

* 2.3.2: why are we using raw PEM = certificates instead of the JOSE = representation?

The idea was to make it dead simple for = developers. Not everything runs on JOSE, but JWK is there if you want to = use it (including JWK certificate representations). 

* 2.3.3: For obvious security = reasons, I suggest adding: The AS MAY choose to avoid displaying an = arbitrary URI. RC developers must only assume that the "name" field will = be displayed.

I would actually go farther in the security = considerations and say that not even the name is necessarily trusted for = display. An RC could claim =E2=80=9CGoogle Docs=E2=80=9D as its display = name, and without other information being displayed (like callback URIs = or home pages), the RO=E2=80=99s got nothing to go on to figure out if = it=E2=80=99s really Google Docs or not. 

* 2.3.4, "created just for this = request" -> created just for this series of = requests.

Got it, thanks. 

* 2.3.4: I suggest referring to = RCs that present unknown keys as "anonymous RC", and then in 2.4, say = that the AS MUST NOT accept any assertions from an anonymous = RC.

I = disagree with this =E2=80=94 there are a lot of cases out there where = the RC isn=E2=80=99t =E2=80=9Canonymous=E2=80=9D at all but is still = presenting a key that the AS doesn=E2=80=99t know. And in fact, the RC = might be presenting some assertions as to its own identity that the AS = can verify.

* 2.4: IMO assertion validation is = a MUST, and we should specify what we require for every assertion type = we allow.

I hear that point, but I=E2=80=99m just not sure = we can or even should get into that level of detail. 

* 2.4: moreover, when possible, = the AS MUST match the assertions to the presented sub_id. It may be a = hint, but you're not allowed to = lie.

The reason that they=E2=80=99re a hint is that the = client doesn=E2=80=99t really know who the user is yet. So I agree the = AS needs to process them, but that doesn=E2=80=99t mean it has to trust = them. 

* 2.4, "If the identified RQ does = not match the RO present at the AS" - I thought there are cases where = the RQ is different from the RO. Also, I am wondering why this is a = SHOULD, not a MUST.

The SHOULD is exactly for that use case where they = aren=E2=80=99t the same person. :) The idea is that the AS would at = least be able to detect that the user that the RC thinks is there is = different from the one the AS sees. This might be fine for the AS for = multi-person delegation use cases, and the AS can prompt the RO during = authorization if that=E2=80=99s the case.

I can see that this needs to be a lot clearer, and = we can work on that text.

* 2.4.1 (but probably applicable = to any references): what is the lifetime of the reference? As an RC, how = long can I assume the user reference is still = valid?

That=E2=80=99s up to the AS ultimately. Previous = editions of the XYZ Protocol had lifetimes and other things tied to the = reference handles (defined in section 3.5), but it didn=E2=80=99t seem = like anyone actually cared about those parts in practice. A reference is = either going to work, or it won=E2=80=99t, and it could fail for reasons = that have nothing to do with a timeout that the RC can=E2=80=99t control = or have input into.

* 2.5: "preferred_locales" is = obviously not a mode of interaction. Why is it bundled = here?

It controls an aspect of how interaction could = happen, which is what all of the fields in this section = do. 

Even though it might look = similar, these interaction modes aren=E2=80=99t setting up things like = the OAuth 2 =E2=80=9Cgrant type=E2=80=9D where the combinations of parts = are pre-defined and you=E2=80=99re signaling which combination you=E2=80=99= re after right at the start. Instead, the RC is saying what it can = handle throughout the interaction process. Some of these are things that = get the user over to the AS (redirect, user_code, app), some are for = getting the user back after interaction (callback), and some are about = how interaction can be presented before the RO is known = (preferred_locales). All of these are aspects of the interaction = process, and it=E2=80=99s the combination of all of these together that = say what the client can do. In this model, each of these elements is = independently defined, but they are all taken together as a single set = of parameters that can control the means of interaction with the user. = So in one way of looking at it, you=E2=80=99re creating the = =E2=80=9Cinteraction mode=E2=80=9D by defining all of the aspects of = that mode at once, including any potential parallel alternatives (ie: = redirect and app together). 

The = discussion on bundles of interaction elements in the editor=E2=80=99s = comment at the end of 2.5.3 provides an alternative model that would = allow the RC to define multiple sets of these interactions, so that you = could say, for instance, =E2=80=9CI can get you to an arbitrary URL or = type a user code but I can=E2=80=99t do a callback on those =E2=80=94 OR = I could get you to an arbitrary URL and also do a callback on that = one=E2=80=9D. This kind of thing would let the AS decide to give out two = different interaction URLs with different expectations on what to do = afterward, as opposed to right now where there is a single expectation = of what to do afterward no matter which URL the user followed to get = there. 

I=E2=80=99ll also note = that we removed the term =E2=80=9Ccapability=E2=80=9D from this section = as members of the design team found it confusing as used here since = it=E2=80=99s also used elsewhere in the document. I replaced it with = =E2=80=9Cmode=E2=80=9D, but that might have the wrong connotations. = I=E2=80=99m happy for suggestions of a better name than =E2=80=9Cmode=E2=80= =9D, but I=E2=80=99m starting to wonder if everything should just be = called =E2=80=9Ca thing=E2=80=9D everywhere. :)

* 2.5: the way "callback" is described here is as a = capability, not an interaction mode. The example only strengthens this = view, "callback" is a modifier of the "redirect" = mode.

The =E2=80=9Ccallback=E2=80=9D field defines = =E2=80=9Cwhat to do after interaction is done=E2=80=9D. Therefore, = =E2=80=9Ccallback=E2=80=9D does not just modify =E2=80=9Credirect=E2=80=9D= , it also potentially modifies other any other methods of getting the = user in front of the AS. When the AS figures out that it=E2=80=99s done = with the RO, it follows whatever steps the =E2=80=9Ccallback=E2=80=9D = defines, regardless of how the user gets there. So for example, you = could have the user present a user code, and then follow a callback to = push information back into the RC. Or you could have some kind of in-app = interaction and still have a callback.

Inversely, you could have a redirect :without: a = callback, like if the user scans a QR code on a secondary device but = doesn=E2=80=99t come back. 

* 2.5: "use code" -> user = code.

Got it, thanks.

* 2.5.1: this unnecessary = polymorphism IMO just complicates implementations and prevents = extensibility. Instead, I would suggest:
redirect: {}
redirect:{max_length: 255}

I= find the pattern of sending an empty object problematic, and we need to = ask if there are other parameters that would really be sent = here. 

redirect:{max_length: 255, callback: = {...}}

Again, the =E2=80=9Ccallback=E2=80=9D could be = applied to multiple outing options, but this would be an alternative of = including it as noted in the editor=E2=80=99s note in 2.5.3 about = re-using the =E2=80=9Ccallback=E2=80=9D field. 

* 2.5.2: the "app" option is = problematic, as you already note. The RC may not even know if a given = URL will result in an application = launching.

It depends on the nature of app =E2=80=94 it could = be a single URL like it is in many mobile platforms today but it could = also be a bundle of other information that can be used to launch the = app. I don=E2=80=99t think we=E2=80=99ll be doing any good by assuming = things will continue to be single URLs.

* 2.5.2: and shouldn't the RC = include a list of supported applications? (Which would have lovely = privacy implications.)

I think that=E2=80=99s a reasonable dimension and = one of the reasons =E2=80=9Capp=E2=80=9D launch should be separate from = the =E2=80=9Cnormal=E2=80=9D redirect. I brought this up with some = implementors in the financial sector a while ago, and with that group at = least there wasn=E2=80=99t a lot of desire for that kind of = functionality. 

I agree that = there are some significant privacy implications driving this as = well. 

* 2.5.3: there's a parenthetical = discussion on whether the URL is unique. But the nonce parameter implies = that the "hash" parameter is unique per request, making this discussion = moot.

I agree with you, if we have a =E2=80=9Cnonce=E2=80=9D= then you don=E2=80=99t necessarily need a unique URL, at least not for = security purposes. The editor=E2=80=99s note is to point out the inverse = that came up in design team discussions, that the =E2=80=9Cnonce=E2=80=9D = is not needed to protect against some of the attacks if you require a = unique URL. I would like to see some formal analysis against this = feature set as we build this out. 

* 2.5.3: even if we need a = different kind of post-interaction "redirect", where the RC is not = involved, there must be a way to ensure that the RC receives positive = (cryptographically protected) confirmation that the authorization was = successful. In other words, what we're discussing here is not an RC = interaction mode, it is something else, and should probably have a = separate protocol element to describe = it.

I=E2=80=99m on the fence about it being something = outside the interaction element, since it=E2=80=99s a kind of = post-interaction method just like =E2=80=9Ccallback=E2=80=9D already = defines. I don=E2=80=99t think it makes sense to allow a client to ask = for more than one of these at a time, and it could lead to some weird = race conditions (do I poll if I might get a callback?) and potential = security issues (I polled but then got a callback, is that an injection = attack?). 

* 2.5.3: In the example for = "interact" as an array (which I support), the second "redirect" and = "user_code" should be independent elements of the array, not members of = an object. This assumes they are truly independent interaction = modes.

No, they are bundled together as the same element = in the array on purpose. This is the client saying =E2=80=9CI can send = the user to a short URI or I can display a user code, but I can=E2=80=99t = get a callback=E2=80=9D. This is equivalent to the OAuth 2 device mode = of displaying a QR code for the user to scan and giving them a code to = type into a static URL. The QR code is already an arbitrary URL and so = it can use the same mechanism as =E2=80=9Credirect=E2=80=9D. To do what = you=E2=80=99re asking you=E2=80=99d want a three element = array. 

* 2.5.3.1: what does "RQ is = present on the request" = mean?

This is most clear for web server based RC=E2=80=99s= : the session that was used to send the user outbound needs to be the = same that is used when the return comes in. It makes less sense with = other interaction methods and other client types, but wherever possible = the RC needs to make sure that the user who started the request is = =E2=80=9Cstill there=E2=80=9D when the response comes back in the front = channel. 

Is there a better way = to say this without making it overly prescriptive?

* 2.5.3.2: typo: HTTP the = request.

Got it, thanks!

* 2.7: this seems to assume a = short access token (which implies a bearer token). What if we want to = use longer self-contained access tokens containing full keys? Should we = have a separate "grant_id" value = instead?

I don=E2=80=99t see how this implies a short = access token, can you expand on what you mean by that? The access token = value will always be a string, opaque to the client, so if it=E2=80=99s = self contained and has its own keys wrapped inside of it in some way, = that=E2=80=99s fine and would still be enough for the AS to figure out = what it means. 

There = previously was the equivalent of a =E2=80=9Cgrant_id=E2=80=9D for = exactly this purpose =E2=80=94 it was the =E2=80=9Ctransaction handle=E2=80= =9D in previous revisions, and it was also used for continuation and a = number of other functions. That feature has been phased out in favor of = using either unique continuation URIs, access tokens, or a combination = of both for managing the ongoing grant request process.  Having an = explicit identifier would be helpful for this specific use case, but = it=E2=80=99s not needed for the more common use cases anymore. Would it = be worth bringing it back in?

* 2.8: another problem with this = stanza is that the RC needs to know a priority that the AS supports it. = What happens if the AS = doesn't?

If the AS doesn=E2=80=99t support this, then it = gets ignored and has no effect on the resulting response. At least, = that=E2=80=99s how I think it should go =E2=80=94 we could also allow = the AS to return an error for fields it doesn=E2=80=99t understand, but = that=E2=80=99s something that needs to be consistent across the protocol = in my opinion.

* 2.8: I suggest to move this = section into a separate I-D, or at least a separate = appendix.

As stated in the last note in the section, I = agree, and in fact don=E2=80=99t think we should be defining any use of = OIDC within the GNAP working group. I think a good exercise would be to = build out what an actual OIDC style protocol would be on top of GNAP, = and it=E2=80=99s something I=E2=80=99d like to . The design team = included this section as a way to show how this type of = externally-defined query language could be incorporated, with all of its = limitations and assumptions that come with it. 

* 2.9: it makes sense to bundle = extensions and the "capabilities" section into = one.

While I see the point, the =E2=80=9Ccapabilities=E2=80= =9D field is really meant to signal specific extensions. It=E2=80=99s = really loosely defined right now though, and I think that we need a lot = more concrete applications of the mechanism if we=E2=80=99re going to = keep it.

* 2.9: The AS MUST ignore any = unknown extension.

I=E2=80=99m OK with this stance, but it needs to = be consistent throughout the protocol, not just at this = level. 

* 3: it's confusing that we're = using access_token for two different things. Maybe we could change the = RC/AS one to = "as_access_token"?

I disagree =E2=80=94 I think we=E2=80=99re using = them for the same kind of thing. They=E2=80=99re both access tokens, and = they=E2=80=99re used by the client in exactly the same way. The resource = being accessed is part of the AS in one case, but the RS in the other = case, but you use the same kind of artifact in both cases to do the same = kind of thing.  I think there=E2=80=99s a lot of power in re-using = components like this instead of inventing something special = here.

* 3.1: MAY vary *by* = request.

Got it, thanks!

* 3.1: how is the client behavior = "deterministic in all cases" - how does the RC know whether the AS = allows continuation or only allows one request at a = time?

If the AS does not include a =E2=80=9Ccontinue=E2=80= =9D field in any of its replies, then the RC can=E2=80=99t continue it = again. 

* 3.2.1: the "value" of the access = token is opaque in some cases (bearer token) but not in = others.

In what cases would it not be opaque to the = client? In all the current binding methods, this value would still be = opaque and the RC still has to send the token value.

* 3.2.1: The ASCII restriction on = "value" is insufficient. Needs to be printable ASCII, = 0x20<v<=3D0x7f. And I'm not sure if this doesn't leave some = characters that still need to be = escaped.

That=E2=80=99s fair, and it=E2=80=99s currently a = SHOULD anyway so I=E2=80=99m fine with making it more restrictive in = that case. OAuth 2 currently has the range "%x20-7E=E2=80=9D, but I=E2=80=99= m not even sure how strictly that=E2=80=99s enforced in the = wild.

* 3.2.1: why is "expires_in" = optional? Typically access tokens are not revoked, and the RC needs a = way to manage their = lifetime.

Access tokens are revoked outside of the RC=E2=80=99= s control in a lot of different ways, not just timeouts. And there are = non-expiring access tokens out there as well. It=E2=80=99s possible, = though in my experience exceedingly rare, for an RC to preemptively get = a new access token before expiry.

* 3.2.1: "resources" refers to = this same section. Did you mean 2.1.2, or are we missing a subsection = describing = resources/rights?

Good catch, this was in fact meant to point to = 2.1.1 (the anchors in markdown are similarly named since this is the = corresponding response to that request section).

* 3.2.1: "key": another = polymorphism alert!

Yes, this is intentional use of polymorphism to = allow one field to represent different ways of related things instead of = having multiple mutually-exclusive fields say the same thing. Right now = it=E2=80=99s got four possible values, and each of them answers the = question =E2=80=9Cwhich key is this token bound to=E2=80=9D:
Boolean =E2=80=9Ctrue=E2=80=9D: use the RC=E2=80=99= s presented key (ie, =E2=80=9Cthe key you sent=E2=80=9D =E2=80=94 the = client doesn=E2=80=99t need any additional identifying information to = determine which key or method)
Boolean =E2=80=9Cfalse=E2=80=9D: = bearer token (ie, =E2=80=9Cno key=E2=80=9D)
Object: A specific = key, not the one the client sent, either a public key for something the = RC knows or possibly a full key pair (with private key) or a symmetric = key provided by the AS; I think we need more on this use = case
String: A specific key, not the one the client sent, = indicated by this reference that the RC can figure out

An RC looking at this field is always looking to = answer the question of how the token is bound, and this allows us to = answer that definitively in a single space.

* 3.2.1: the example at the bottom of the section = talks about a way to present the token, I believe this discussion is out = of context here.

I=E2=80=99m not sure which example you are = referring to here, since I don=E2=80=99t see anything about a way to = present a token. If you mean the editor=E2=80=99s note at the bottom = about directed access tokens, this is relevant here because the = information needed to direct the RC where it should use the tokens would = be included in this response.

* 3.3: the AS knows now which = interaction modes are available. Why not pick just one for its response, = to simplify the protocol? As one example, the AS can then more easily = decide on timeout = behavior.

The AS can do exactly that with the existing = construction =E2=80=94 it can respond to only the parts that it wants to = do for that specific request. 

For example, if the RC doesn=E2=80=99t include the = =E2=80=9Ccallback=E2=80=9D in its request but the AS decides, for = security reasons, that it won=E2=80=99t serve any requests without a way = to return control directly to the RC post-interaction, then the AS can = reject a request that doesn=E2=80=99t have that. 

For another example, if an AS decides that a = specific resource can only be authorized through a user code interaction = (maybe it=E2=80=99s for a resource/client format that the AS knows to be = a limited device and so the AS has a specific usage pattern it will = allow), then the AS can respond only to the =E2=80=9Cuser_code=E2=80=9D = portion of the client=E2=80=99s request, even if the client includes a = =E2=80=9Ccallback=E2=80=9D and =E2=80=9Credirect=E2=80=9D parameter as = well. 

Combining these = interaction together is key to moving GNAP beyond what OAuth 2=E2=80=99s = extremely limited =E2=80=9Cgrant_type=E2=80=9D model allows.

* 3.3.3: Suggest to add to the = last paragraph: If the RC does not receive a callback until an = RC-determined timeout occurs, the RC MUST act as if the entire request = failed.

I=E2=80=99m fine with adding that kind of = guidance. It gets fuzzy in terms of security considerations though = because =E2=80=9Can RC-determined timeout=E2=80=9D without other = guidance is so loose as to be undefined.

* 3.4: "updated_at": Unix time is = nice, but for absolute time it's common to use ISO 8601 = format.

I stole this field from OIDC, but I=E2=80=99m fine = with any format here, so if there=E2=80=99s no outcry we should change = it in the next revision. 

* 3.6: YES, the "error" element is = exclusive!

I think it should be, but I=E2=80=99d like to see = if there=E2=80=99s any kind of counter argument. For example, returning = an error BUT also allowing continuation to address the error. Is that = allowed? If so we=E2=80=99d need to return the =E2=80=9Ccontinue=E2=80=9D = field as well, which is already defined. But if =E2=80=9Cerror=E2=80=9D = means =E2=80=9Cthis is final, this request is done now and forever=E2=80=9D= , then yes it should be completely exclusive of all = others. 

* 3.6: in SecEvent we tried to use = RFC 7807 "problem details", I think it could work nicely = here.

I=E2=80=99m unfamiliar with the details of that = spec, but after a quick skim I think that=E2=80=99s got some = possibility. It seems to incorporate a lot of information from the HTTP = message in the response body though which isn=E2=80=99t really that = applicable.

* 10.4: "indicating that GNAP" - = sentence is broken.

Thanks, that meant to say "indicating that GNAP = needs to be used to access the resource=E2=80=9D, fixed.

* This "speculative" access is = not useful if the response is only a MAY. Why would the RC try it if it = is unlikely to provide useful = information?

I think the MAY is not quite the right normative = application here. It=E2=80=99s a MUST if you=E2=80=99re doing it to do = it in this way, but it=E2=80=99s not a MUST for all RS=E2=80=99s = everywhere to respond in this fashion. If the RC tries calling an RS = that doesn=E2=80=99t respond with this, the RC simply doesn=E2=80=99t = know, from any programmatic or automated way, what to do to make the = request actually work.

* 15: the BCP195 ref is broken - = the author names are missing (yes I am one of = them...).

Yes, all the references need to be cleaned up! = RFCs and IDs get picked up automatically by the tools, but other = documents (including, it seems, BCPs) don=E2=80=99t have that luxury. I = focused on getting a basic reference in place so that it would compile, = and now I need to go back and make it more correct. No offense intended = to any of the BCP or other document authors. :)

* Appendix D: can we name the = first scenario, maybe "Simple API = Access"?

I don=E2=80=99t think that is an accurate name for = what=E2=80=99s being shown here, and especially for what=E2=80=99s being = highlighted. We are specifically showing how to get API access through the use of fully redirect-based interaction =E2=80=94= redirect the user there, and have them redirected back. It=E2=80=99s = analogous to the OAuth 2 Authorization Code Grant Type. It=E2=80=99s = very specific to that aspect, and not really specific to =E2=80=9CAPI = access=E2=80=9D. In fact, nothing in the scenario really needs API = access for it to work =E2=80=94 the RC could be asking for subject = information instead and the rest of the example would remain the same. = This is the same scenario as discussed and diagrammed in 1.3.1, but with = more extensive examples of protocol messages in use. 

 =E2=80=94 Justin

-- 
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_0DF47B37-0192-4C3A-B3A1-2F51A8112774-- From nobody Mon Oct 19 20:27:00 2020 Return-Path: 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 71D393A1097 for ; Mon, 19 Oct 2020 20:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7aVOi8_Ed0HC for ; Mon, 19 Oct 2020 20:26:56 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 60E863A109D for ; Mon, 19 Oct 2020 20:26:56 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id j30so281092lfp.4 for ; Mon, 19 Oct 2020 20:26:56 -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=3dPfJXdnkxyBtNfgXM11B3tnRlWvXyoBjpz2GaMaVbw=; b=JEFojfz3qD1a9/O3gGkjM80WIzJ2pNZnv4ZumcZ1toQw0+6uOGjYq+YTnerSPiAZRY ecpCcRV3ZBgfgE62GD7QELlJeBcBhQTWaD6uEXSZKCpyeN4YWSLnvVaG0AhccTo6dRST m9yIu7YuSC5gQ8ABS8GZk90feLOGdAJSb3lRIeD/bSBddOpGJ2j4u+Vm3+Sav74+0d6N 8+kS2nspLYso33HDsRKsAMAOJAFPZFjzGpIJ8OPgpD2hjoaAHGO2fYMOHnG3RBC8Re/N ht45jgxLrnZnTURBhL3PiD2bWiaKcSZkzMNpNAkAca98eUolWbe87xlwmiS2fUYHnWvi on4A== 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=3dPfJXdnkxyBtNfgXM11B3tnRlWvXyoBjpz2GaMaVbw=; b=eHIanbslI7570iy7jSi5/8pZPoPll+l6ktCa+AVGFtxv66zynZpyv47dlrxhLPgEiv 96Hbd8V3t5tCgplnbxUbBd1HLjW34+8HvvKpPQr2OqfHl+ws9eB+apN1aFpK85Zpm9ji KCSOdheJxb4HktO7oPYsNnahWyVCAcDc11yU6wX34Y/g+EwIScCiVLoe97MhUdV8BPrv 2dsXH/SsL/8lWs09K25c6/flyOTziATX1lRQoWz2cBMwjTpxSG+9bT5YNNgC1h2kaTO7 hdmukFiEAsdGqUg+qOv1RZYQuqg0yhHSd6nz7cH2RT0mYYp6oxEd57YybsqLUK8qfPyp YcHg== X-Gm-Message-State: AOAM531V5HWye0G6HTIgr4zHmw+gKlXG5gF/3Wc3JsPBHfl0Ir9JYGKr 5+dNSWCk5NU4x+nRMcUJVYZwvi2lhWIOaKvynFo= X-Google-Smtp-Source: ABdhPJwCrdm5DQ/c9tDFQ/6iWVfMOvbrC/0n6xOF/+z0om+EW6ebAyQhqp1QOW2kzsUvC1DAdrGLH9VhlYvMIqfN/EU= X-Received: by 2002:a05:6512:3137:: with SMTP id p23mr251921lfd.316.1603164414167; Mon, 19 Oct 2020 20:26:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 19 Oct 2020 20:26:18 -0700 Message-ID: To: Kathleen Moriarty Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c4f5705b211cd12" Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 03:26:58 -0000 --0000000000006c4f5705b211cd12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't see how your take is different in the process you chose to take, vs the process I had suggested in the WG meeting, and the chairs had set as the goals of the design team. Despite the WG not adopting your recommendation to start with XYZ, you chose to ignore the WG and chairs and start with the XYZ document. wrt. RESTful design patterns, that was a design pattern that XAuth introduced and that XYZ has adopted. The one comment about a suggestion I made that was not RESTful -- I was asking for the parameters in JWS signing to be moved from the JWS header to the JWS payload -- my suggestion was not making it any less RESTful than it already was. Inaccurate representations like this contributed to the tension in the meetings. One of your criticisms of XAuth was the use of "non standard IETF language" such as "sequence" -- a term that is now used numerous times in the draft. I hope you had a RESTful vacation! On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > My take is very different, Dick. I am starting a 2 week vacation and wil= l > not be spending it arguing with you on the list. > > Multiple reviews pointed to Justin=E2=80=99s document as a better startin= g point, > not just mine. Your use case cases can be met and some of what you were > asking for did not follow RESTful design patterns. They really don=E2=80= =99t map > to a future protocol well. You may need to write extension documents, bu= t > your goals can be met. > > Many calls were difficult as displayed in your message. Justin did a > great job handling the weekly tension and ensuring options were included > for WG discussion when agreement was not met. He=E2=80=99s completely am= enable to > following the WG and chairs decisions. His document was also easier to > follow and aligned better with numerous IETF documents. Please do keep > Justin on as an editor. As you can see from the draft, there are many are= as > where WG input on decision points are requested. > > Best regards, > Kathleen > > Sent from my mobile device > > On Oct 9, 2020, at 8:26 PM, Dick Hardt wrote: > > =EF=BB=BF > Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting > -14, but I propose someone other than Justin be the document editor. > > I was on the design team to work on the goals set out by the chairs [1]: > > "We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15" > > Surprisingly, Kathleen convened the design team with her recommendation t= o > start with the XYZ document with Justin as editor, and add in the diagram= s > from XAuth. The rest of the design team had an opportunity to express the= ir > concerns and Justin edited the document. In other words, I had to convinc= e > Justin to change the document, rather than the design team comparing and > contrasting the proposals and selecting the best parts. I expressed my > concerns with our AD, and decided to continue participating in the design > team. We did make some progress on a number of issues thanks to the hard > work of Fabien, Justin, and Mike -- but many issues have been punted to t= he > WG. > > Justin has poured tons of energy into this project, and to his credit he > was a good editor at times, but there are areas where he was unwilling to > deviate from his vision. > > I am concerned about a repeat of what happened in OAuth 2.0: Erin had the > pen and had strong views that often were not aligned with the rest of the > WG. A good example was Erin's distaste for bearer tokens. He factored tha= t > out of the core document, which we are now adding back in with OAuth 2.1. > Anyone that participated in the WG saw the issues this had. > > I'm not suggesting that Justin is Erin, but I think a more neutral editor > of the core document will allow us to make progress more quickly. > > /Dick > > [1] > https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/ > =E1=90=A7 > > On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: > >> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their har= d >> work and discussion as well. This draft contains aspects of XYZ and Xaut= h, >> and introduces some new elements and pieces as well. As you'll see, ther= e >> are many identified issues and decisions to be made, but even then I >> believe it hangs together fairly cohesively already thanks to the good >> engineering effort and discussion that's gone in so far. >> >> Nothing in the document is final, of course. To me, this document >> represents a good starting point for working group discussion and >> decisions, +1 for its adoption. >> >> - Justin >> ________________________________________ >> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ >> kathleen.moriarty.ietf@gmail.com] >> Sent: Friday, October 9, 2020 6:55 PM >> To: txauth@ietf.org >> Subject: [GNAP] Design team >> >> Greetings! >> >> The design team has now come to a close. While there were too many >> issues to resolve to all design team member satisfaction, great effort w= as >> put in to describe decision points for the WG to ease and hopefully spee= d >> the working group process. As such, I am requesting that the WG adopts >> this version (14 of XYZ) and works together to fully develop a single >> specification. >> >> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >> >> A tremendous thank you to each of the design team members for your hard >> work and walking the fine line of when to put a stake in the ground (tha= t >> the WG can always change once adopted) and listing our options for decis= ion >> points to ease the WG process. >> >> Best regards, >> Kathleen >> >> Sent from my mobile device >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006c4f5705b211cd12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see how your take is different in the process = you chose to take, vs the process I had suggested in the WG meeting, and th= e chairs had set as the goals of the design team. Despite the WG not adopti= ng your recommendation to start with XYZ, you chose to ignore the WG and ch= airs and start with the XYZ document.

wrt. RESTful desig= n patterns, that was a design pattern that XAuth introduced and that XYZ ha= s adopted. The one comment about a suggestion I made that was not RESTful -= - I was asking for the parameters in JWS signing to be moved from the JWS h= eader to the JWS payload -- my suggestion was not making it any less RESTfu= l than it already was. Inaccurate representations like this contributed to = the tension in the meetings.

One of your criticisms = of XAuth was the use of "non standard IETF language" such as &quo= t;sequence" -- a term that is now used numerous times in the draft.=C2= =A0

I hope you had a RESTful vacation!
<= br>




<= br>

On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.= com> wrote:

= My take is very different, Dick.=C2=A0 I am starting a 2 week vacation and = will not be spending it arguing with you on the list.

=
Multiple reviews pointed to Justin=E2=80=99s document as a better star= ting point, not just mine.=C2=A0 Your use case cases can be met and some of= what you were asking for did not follow RESTful design patterns.=C2=A0 The= y really don=E2=80=99t map to a future protocol well.=C2=A0 You may need to= write extension documents, but your goals can be met.

=
Many calls were difficult as displayed in your message.=C2=A0 Justin d= id a great job handling the weekly tension and ensuring options were includ= ed for WG discussion when agreement was not met.=C2=A0 He=E2=80=99s complet= ely amenable to following the WG and chairs decisions.=C2=A0 His document w= as also easier to follow and aligned better with numerous IETF documents.= =C2=A0 Please do keep Justin on as an editor. As you can see from the draft= , there are many areas where WG input on decision points are requested.

Best regards,
Kathleen=C2=A0

=
Sent from my mobile device
On Oct 9, 2020, at 8:26 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
Tl;dr: Given where we are in the WG, I a= m not opposed to the WG adopting -14, but I propose someone other than Just= in be the document editor.

I was on the design team to work on the = goals set out by the chairs [1]:

"We expect the design team to= decide on a solution outline that combines the best of both proposals, and= present this outline by Sep. 15"

Surprisingly, Kathleen conven= ed the design team with her recommendation to start with the XYZ document w= ith Justin as editor, and add in the diagrams from XAuth. The rest of the d= esign team had an opportunity to express their concerns and Justin edited t= he document. In other words, I had to convince Justin to change the documen= t, rather than the design team comparing and contrasting the proposals and = selecting the best parts. I expressed my concerns with our AD, and decided = to continue participating in the design team. We did make some progress on = a number of issues thanks to the hard work of Fabien, Justin, and Mike -- b= ut many issues have been punted to the WG.

Justin has poured tons o= f energy into this project, and to his credit he was a good editor at times= , but there are areas where he was unwilling to deviate from his vision.
I am concerned about a repeat of what happened in OAuth 2.0: Erin had= the pen and had strong views that often were not aligned with the rest of = the WG. A good example was Erin's distaste for bearer tokens. He factor= ed that out of the core document, which we are now adding back in with OAut= h 2.1. Anyone that participated in the WG saw the issues this had.

I= 'm not suggesting that Justin is Erin, but I think a more neutral edito= r of the core document will allow us to make progress more quickly.
/Dick

[1] https://mailarchive.ietf.org= /arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM Justin Richer <jricher@mit.edu> wrote= :
Thanks, Kathle= en, and thanks to Dick, Mike, and Fabian for all their hard work and discus= sion as well. This draft contains aspects of XYZ and Xauth, and introduces = some new elements and pieces as well. As you'll see, there are many ide= ntified issues and decisions to be made, but even then I believe it hangs t= ogether fairly cohesively already thanks to the good engineering effort and= discussion that's gone in so far.

Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.

- Justin
________________________________________
From: TXAuth [= txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kathleen.moriarty.i= etf@gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.ietf.org/doc/d= raft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000006c4f5705b211cd12-- From nobody Mon Oct 19 20:27:07 2020 Return-Path: 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 7E4F93A10E6 for ; Mon, 19 Oct 2020 20:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 1CWa9vTsLI7B for ; Mon, 19 Oct 2020 20:27:01 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 1F82F3A10BA for ; Mon, 19 Oct 2020 20:27:01 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id d24so266363lfa.8 for ; Mon, 19 Oct 2020 20:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3ZK0bGFEx8YW6sFXy80zxj2ktVoBZqgElSq6vZFlKUM=; b=I5ZTi30oDxvEHjwtnXoA9ptNQwbKUKKQCZxC8d/BPdX/+lXrHf70n4Oh+NkzzUWPyy AhpXL6QMDh4BLzdKaooVFvdoDL7TrMKFPG6+QXfem0u7jDedXRtS5BOqWeG03uWnJJ6Q vBCnFEzBWnAqP7auk0aKZmaF1cYHdc/i9Nq4UrwcEel/6Gn96RA2RErN34prNDdISDYv RRBQz60ndbuhcxU1A+AGAy77kZslv9vMCMwnr+NuDMQQQTiRTBvdjxP5UG6t4689G1Ro DzyLRKoipDMqmc/E9mZR8dyeO35OhVD22V8RriRB9qFfm1XhrfP8NouXTWPpWBf60Eo7 WD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3ZK0bGFEx8YW6sFXy80zxj2ktVoBZqgElSq6vZFlKUM=; b=gmlAMWWojW2g2T+Ht3Ggrv34MtHyTik5AI3HNkUm2Ug9PN/UlHxpgKBbBy0b/3ENDz LyyOB6MwxKnNIgQuseFplOQ5ruv8LyR5d+GDuJ8bXS0VdECxaP61szv2nMgeHedi+qZL APx8qiF5mrByt7Movo5zItia3LusDtgVrpyaVgGK1sGBrCtHSD4PvcMBjsrMHhJtg60k 7eT5nGARVOtULIv3sKreCE02Wt1crN8uEQo4QxG4UdIj0jIy99sgpy8+FlsHEb1+cDEi Oj7kNYGc3jCukN5wFYLVpzpohsXs5YvMnWwB0vHDoTGbH6KVFloDB4XOa19jSNutNVPU QgKw== X-Gm-Message-State: AOAM5322kyizK33kB9gxx6Db9fT+YtICuxYjQST0m79+bXEBSFjl4NyG C1ffQrThVTNkg0C9Kmy7aZwgajpJuf9kIWn0HINcWcU1AdPA7Q== X-Google-Smtp-Source: ABdhPJyrT2nq/UXgb149SvgzewVapsw7aZY/iWwqLZjuMgbJfQy/eXnqFME62dNk3rBMsYsswQ7DRoYvzhAA4PX/Ix4= X-Received: by 2002:a19:cb14:: with SMTP id b20mr215108lfg.162.1603164418813; Mon, 19 Oct 2020 20:26:58 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 19 Oct 2020 20:26:22 -0700 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b3336205b211cd99" Archived-At: Subject: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 03:27:06 -0000 --000000000000b3336205b211cd99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Previous Feedback* The following items were discussed in the design team, but did not make it into the draft for WG discussion. A concern I have with many of the editor notes (which I point out) is that they are heavily biased by Justin's vision and misrepresent the options. *Abstract:* "information passed directly to the software" can mean pretty much anything. The charter has "user identifiers, and identity assertions." *1. *Same point as in Abstract around "information". *1.1* Roles: Add in roles for operators of AS and RC. Show trust framework between legal entities (user, RO, client operator, AS operator) Differentiate between legal entities having a relationship or HCI and the actual protocol roles (RC, AS, RS) What is the difference between roles and parties? Can we avoid the term parties? RQ is both a party and a role. Alternative names: client for RC user for RQ *1.2* Elements: defined access token without using "credential" Grant as both a noun (what is being requested) and a verb Grant is already is a noun being used as an adjective in "Grant Negotiation ..." and "Grant Response" "Subject Information" is better than just "information" -- but is still extremely broad The subject information should be about the user, not the RO. For example, in an enterprise use case where resource access and identity claims are being requested, the RO is not the user, but could be an administrator. The "subject information" is going to be about the user of the client, not the administrator. *1.3.3* step 7 - what is a refreshed credential? We should refer to the defined terms. *2.* title should be Grant Request to match with Grant Response in (3), and use of "Grant Request" in 2.7, 2.9, 5, 5.4, & 5.5 *2.1.2:* "a RC MAY send a string known to the AS or RS" why "or"? Explain. *2.2* "sub_ids" are sub_ids a good idea, a best practice? despite warnings in the protocol, developers will use an email identifier as a communication identifier, or worse, a verified identifier. GNAP is defining a query language here for subject identifiers. *2.3 *Identifying a client via URL Mobile Apps and SPA can identify themselves with an HTTPS url that only that client can receive redirects to (universal link in iOS, android app link). The client passes the general identifier for the client (class_id?) and the AS ensures the redirect URI belongs to that client. A parameter is passed on the redirect to the client that the client presents to the AS to prove it is an instance of that client. The AS may then release access and claims to the client. The AS may also provide an instance identifier for the client so that instance of the client can uniquely identify itself. The editor note that instance_id is analogous to the client_id prevents an instance of the client in the preceding paragraph from uniquely identifying itself, and the name is misleading. Additionally, pre-registered identifiers (class_id which should be equivalent to client_id for confidential clients) and dynamic identifiers (instance_id) have different operational and infrastructure requirements. pre-registered identifiers should be read only for the AS vs read / write for the AS. There may be millions of dynamic identifier for one pre-registered identifier (mobile app, SPA) *2.3.1 *Do we need to support symmetric keys? Most OAuth clients support a secret, not a key. *2.3.2* what are the supported public key formats? What if the client is able to use different proofing mechanisms? How does it negotiate with the AS? *2.4.1* identifying the user this identifier would be useful if it had properties that other opaque identifiers did not have: being globally unique. A reason developers have used the email in ID Tokens was that it was a globally unique string in contrast to the tuple of "iss" and "sub" in the ID Token which was much more complicated to add and work with in a DB. Otherwise, we are creating yet another user identifier. *2.5* interaction capabilities / modes (section 3.3 as well) While the document has renamed "interaction capabilities" to "interaction modes", but the client is still declaring capabilities, but in 3.3 there are conflicting statements "If the RC has indicated a capability to interact with the RO in its request (Section 2.5)" The AS MUST NOT respond with any interaction mode that the RC did not indicate in its request. using the same 4 interaction modes in the client request would make it easier for the client to say which modes it supports, and the AS to respond with which modes are allowed. It also allows all parameters required for a mode to be in the mode. For example the URL for a double redirection, vs a redirection to an information page after a user_code or decoupled redirect. *2.5* declaring RC capabilities Editor's note on what this is supposed to do, and why it can't be done by just adding the properties to the request. *2.7 *perhaps this could be done by updating an existing Grant Request. This seems overly complicated. *2.8* Perhaps this should be in 2.2 where we are requesting information about the user? Given that solving the use cases solved by OIDC is in conflict with the editor note that OIDF should be doing the integration with GNAP. The current model is confusing as requests are in one object, and responses are in a different object. We don't have to combine the userinfo endpoint request with the id_token request just because that was convenient for OIDC. The editorial comments make thi seem much messier than it is. *3.* The URI can be stable, and the access token is potentially superfluous. As the client is authenticating with the same key in all subsequent requests, rotation of the URI or access token may be superfluous. Having an access token for the AS seems that is used while authenticating vs the typical access token for an RS seems very confusing to a developer. Additionally, putting the access token for calls to the AS in the HTTP Authorization header precludes using the HTTP Authorization header for client authentication in 8. *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in the API between the client and the AS rather than an interaction that involves the user. Also, this functionality provides no protection to session fixation. The interaction reference has no value. *4.4.3 *While it is good to see an editor's note that a unique callback URL could be used, the statement "but it would not prevent an attacker from injecting an unrelated interaction reference into this channel." is misleading. This would only happen if the client did not ensure it is the same user, as that would be linked to the correct URL. Similarly, the interaction reference does not provide protection if the client does not ensure it is the same user. Using a unique callback URL would be much simpler, and appears to provide the same protection as the interaction reference and the hashing. *5. * Continuing a Grant Request (which in (2) is called an Access Request) Is "continuing the right word"? We are either "validating" the request (5.1), polling the request (5.2), modifying the request (5.3), reading the request (5.4), or cancelling the request (5.5). Include editorial discussion of replacing a request, replacing part of a request, and adding to a request, and if we should have semantics for all 3 mechanisms. *8* While some binding mechanisms work the same for the client calling the AS as the RS, the requirements are different. When the client calls the AS, the client is authenticating. When the client is calling the RS, the client is proving it is authorized to access the resource. The RS does not need to know the identity of the client -- just that it is the client that the AS gave the access token to. *8.2 Attached JWS* Why not a JWT? This is the ONLY self contained mechanism. All the other ones require all, or most of the HTTP headers and the body to be kept together. The editor note "Alternatively, we could add all these fields to the body of the request, but then it gets awkward for non-body requests like GET/DELETE." It is not awkward. A mechanism is described later of having the JWS as an HTTP header. Something JWS was designed for. The editor note "A downside to this method is that it requires the content type to be something other than application/json, and it doesn't work against an RS without additional profiling since it takes over the request body - plus we have to specify different delivery locations for a GET vs. a POST, for example." Not being application/json is a feature as the AS can detect the signature mechanism. Per above, the requirements for the AS and RS are different. The client can use the same mechanism of signing with an empty body and placing the JWS in an HTTP header just as it does below for requests with no body. The RS is proving it was given the access token by the AS, and binding that to time, URI, and method. The editor note "Additionally it is potentially fragile like a detached JWS since a multi-tier system could parse the payload and pass the parsed payload downstream with potential transformations. We might want to remove this in favor of general-purpose HTTP signing, or at least provide guidance on its use." is very misleading. The whole point is to pass the JWS between components so that each can independently verify the request. ALL the other mechanisms have the fragility described as different components are going to pass around the JSON -- and even if they pass around the detached signature information and other headers, a component could transform the JSON in parsing and stringifying the request. The straightforward way to use JOSE from a developers point of view would be: - use JWT - include the key in the header - have "iat", the method, and the URI in the payload - put the JWT in the HTTP Authorization header for methods without a body This is how I wrote it in my implementation. It was very straightforward. Only the last point conflicts with GNAP as now written -- all the other aspects could be how it is done for JWT. *Additional feedback* the document name is redundant - protocol is in it twice (gnap =3D Grant Negotiation and Authorization Protocol)-core-protocol "draft-ietf-gnap-core" would be sufficient 1.2 Elements Key - "A cryptographic element binding a request to the holder of the key." It is actually *any* holder of the key. 2.2 Editor's note "you'd need a full identity protocol and not just this" implies that GNAP is not an identity protocol despite it supporting the OpenId Connect use cases. 3.5 Do we need this section? The only thing with "handle" in the name is user_handle. The access token is not really a handle. =E1=90=A7 --000000000000b3336205b211cd99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Previous Feedback
The following items wer= e discussed=C2=A0in the design team, but did not make it into the draft for= WG discussion. A concern I have=C2=A0with many of the editor notes (which = I point out) is that they are heavily biased by Justin's vision and mis= represent the options.

Abstract: "informatio= n passed=C2=A0directly to the software" can mean pretty much anything.= The charter has "user identifiers, and identity assertions."=C2= =A0

1. Same point as in Abstract aroun= d "information".

1.1 Roles:= =C2=A0
Add in roles for operators of AS and RC.=C2=A0
S= how trust framework between legal entities (user, RO, client operator, AS o= perator)
Differentiate between legal entities having a relationsh= ip or HCI and the actual protocol roles (RC, AS, RS)
What is the = difference between roles and parties? Can we avoid the term parties? RQ is = both a party and a role.
Alternative names:
client for = RC
user for RQ

1.2 Elements:
defined access token without using "credential"
G= rant as both a noun (what is being requested) and a verb=C2=A0
Gr= ant is already is a noun being used as an adjective in "Grant Negotiat= ion ..." and "Grant Response"
"Subject Inform= ation" is better than just "information" -- but is still ext= remely broad
The subject information should be about the user, no= t the RO. For example, in an enterprise use case where resource=C2=A0access= and identity claims are being requested, the RO is not the user, but could= be an administrator. The "subject information" is going to be ab= out the user of the client, not the administrator.

1.3.3 step 7 - what is a refreshed credential? We should refer to t= he defined terms.

2. title should be Grant = Request to match with Grant Response in (3), and use of "Grant Request= " in 2.7, 2.9, 5, 5.4, & 5.5=C2=A0

2.1= .2: "a RC MAY send a string known to the AS or RS"
= why "or"? Explain.

2.2 "sub_= ids"
are sub_ids a good idea, a best practice? despite warni= ngs in the protocol, developers will use an email identifier as a communica= tion identifier, or worse, a verified identifier.=C2=A0
GNAP is d= efining a query language here for subject identifiers.=C2=A0

=
2.3 Identifying a client via URL
Mobile Apps an= d SPA can identify themselves with an HTTPS url that only that client can r= eceive redirects to (universal link in iOS, android app link). The client p= asses the general identifier for the client (class_id?) and the AS ensures = the redirect URI belongs to that client. A parameter is passed on the redir= ect to the client that the client presents to the AS to prove it is an inst= ance of that client. The AS may then release access and claims to the clien= t. The AS may also provide an instance identifier for the client so that in= stance of the client can uniquely identify itself.

The editor note that instance_id is analogous=C2=A0to the client_id preven= ts an instance of the client in the preceding paragraph from uniquely ident= ifying itself, and the name is misleading.

Additio= nally, pre-registered identifiers (class_id which should be equivalent to c= lient_id for confidential clients) and dynamic identifiers (instance_id) ha= ve different operational and infrastructure requirements. pre-registered id= entifiers should be read only for the AS vs read / write for the AS. There = may be millions of dynamic identifier for one pre-registered identifier (mo= bile app, SPA)

2.3.1 Do we need to support = symmetric=C2=A0keys? Most OAuth clients support a secret, not a key.
<= div>
2.3.2
what are the supported public key= formats?
What if the client is able to use different proofing me= chanisms? How does it negotiate with the AS?


<= /div>
2.4.1 identifying the user
this identifier would= be useful if it had properties that other opaque identifiers did not have:= being globally unique. A reason developers have used the email in ID Token= s was that it was a globally unique string in contrast to the tuple of &quo= t;iss" and "sub" in the ID Token which was much more complic= ated to add and work with in a DB. Otherwise, we are creating yet another u= ser identifier.

2.5 interaction capabilitie= s / modes (section 3.3 as well)
While the document has renamed &q= uot;interaction capabilities" to "interaction modes", but th= e client is still declaring capabilities, but in 3.3 there are conflicting = statements

"If the RC has indicated a capabil= ity to interact with the RO in its request (Section 2.5)"

The AS MUST NOT respond with any interaction mode that the= RC did not indicate in its request.=C2=A0

usi= ng the same 4 interaction modes in the client request would make it easier = for the client to say which modes it supports, and the AS to respond with w= hich modes are allowed. It also allows all parameters required for a mode t= o be in the mode. For example the URL for a double redirection, vs a redire= ction to an information page after a user_code or decoupled redirect.
=

2.5 declaring RC capabilities
Editor&#= 39;s=C2=A0note on what this is supposed to do, and why it can't be done= by just adding the properties to the request.

= 2.7 perhaps this could be done by updating=C2=A0 an existing Grant Requ= est. This seems overly complicated.

2.8=C2= =A0Perhaps this should be in 2.2 where we are requesting information about = the user?
Given that solving the use cases solved by OIDC is in c= onflict with the editor note that OIDF should be doing the integration with= GNAP. The current model is confusing as requests are in one object, and re= sponses are in a different object. We don't have to combine the userinf= o endpoint request with the id_token request just because that was convenie= nt for OIDC. The editorial comments make thi seem much messier than it is.<= /div>

3. The URI can be stable, and the access to= ken is potentially superfluous. As the client is authenticating with the sa= me key in all subsequent requests, rotation of the URI or access token may = be superfluous. Having an access token for the AS seems that is used while = authenticating vs the typical access token for an RS seems very confusing t= o a developer.

Additionally, putting the access to= ken for calls to the AS in the HTTP Authorization header precludes using th= e HTTP Authorization header for client authentication in 8.

<= /div>
4.4.2 This functionality looks like a WebHook, and perhaps= belongs in the API between the client and the AS rather than an interactio= n that involves the user. Also, this functionality provides no protection t= o session fixation. The interaction reference has no value.

<= /div>
4.4.3 While it is good to see an editor's note that=C2= =A0a unique callback=C2=A0URL could be used, the statement "but it wou= ld not prevent an attacker from injecting an unrelated interaction referenc= e into this channel." is misleading. This would only happen if the cli= ent did not ensure it is the same user, as that would be linked to the corr= ect=C2=A0URL. Similarly, the interaction reference does not provide protect= ion if the client does not ensure it is the same user.
Using a un= ique callback URL would be much simpler, and appears to provide the same pr= otection as the interaction reference and the hashing.

=
5.=C2=A0
Continuing a Grant Request (which in (2) is = called an Access Request)
Is "continuing the right word"= ;?
We are either "validating" the request (5.1), pollin= g the request (5.2), modifying the request (5.3), reading the request (5.4)= , or cancelling the request (5.5).

Include editori= al discussion of replacing a request, replacing part of a request, and addi= ng to a request, and if we should have semantics for all 3 mechanisms.

8
While some binding mechanisms work = the same for the client calling the AS as the RS, the requirements are diff= erent. When the client calls the AS, the client is authenticating. When the= client is calling the RS, the client is proving it is authorized to access= the resource. The RS does not need to know the identity of the client -- j= ust that it is the client that the AS gave the access token to.
<= br>
8.2 Attached JWS
Why not a JWT?
Th= is is the ONLY self contained mechanism. All the other ones require all, or= most of the HTTP headers and the body to be kept together.

<= /div>
The editor note

"Alternatively= , we could add all these fields to the body of the request, but then it get= s awkward for non-body requests like GET/DELETE."

=
It is not awkward. A mechanism is described later of having the JWS as= an HTTP header. Something JWS was designed for.

T= he editor note

"A downside to this method is = that it requires the content type to be something other than application/js= on, and it doesn't work against an RS without additional profiling sinc= e it takes over the request body - plus we have to specify different delive= ry locations for a GET vs. a POST, for example."

Not being application/json is a feature as the AS can detect the si= gnature mechanism. Per above, the requirements for the AS and RS are differ= ent. The client can use the same mechanism of signing with an empty body an= d placing the JWS in an HTTP header just as it does below for requests with= no body. The RS is proving it was given the access token by the AS, and bi= nding that to time, URI, and method.


The editor note=C2=A0

"Additionally i= t is potentially fragile like a detached JWS since a multi-tier system coul= d parse the payload and pass the parsed payload downstream with potential t= ransformations. We might want to remove this in favor of general-purpose HT= TP signing, or at least provide guidance on its use."=C2=A0
=
is very misleading. The whole point is to pass the JWS betwe= en components=C2=A0so that each can independently verify the request. ALL t= he other mechanisms have the fragility described as different components ar= e going to pass around the JSON -- and even if they pass around the detache= d signature information and other headers, a component could transform the = JSON in parsing and stringifying the request.

The = straightforward=C2=A0way to use JOSE from a developers point of view would = be:

- use JWT
- include the key in the h= eader
- have "iat", the method, and the URI in the payl= oad
- put the JWT in the HTTP Authorization header for methods wi= thout a body

This is how I wrote it in my implemen= tation. It was very straightforward.

Only the last= point conflicts with GNAP as now written -- all the other aspects could be= how it is done for JWT.


Additio= nal feedback
the document name is redundant - protocol is in = it twice
(gnap =3D Grant Negotiation and Authorization Protocol)-= core-protocol
"draft-ietf-gnap-core" would be sufficien= t

1.2 Elements
Key - "A cryptograph= ic element binding a request to the holder of the key."
It i= s actually any holder of the key.=C2=A0

2.2= Editor's note "you'd need a full identity protocol and not ju= st this" implies that GNAP is not an identity protocol despite it supp= orting the OpenId Connect use cases.=C2=A0

3.5 Do = we need this section? The only thing with "handle" in the name is= user_handle. The access token is not really a handle.=C2=A0

=
=E1=90=A7
--000000000000b3336205b211cd99-- From nobody Tue Oct 20 02:40:33 2020 Return-Path: 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 52DA53A0FFD for ; Tue, 20 Oct 2020 02:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 mq2JsN--JxTc for ; Tue, 20 Oct 2020 02:40:28 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 20F4D3A1007 for ; Tue, 20 Oct 2020 02:40:27 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u62so59676iod.8 for ; Tue, 20 Oct 2020 02:40:27 -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=LXlFGfXDoG0RaUMCnqyZEHdEEIs1aErZanwWdh2/ZZk=; b=I1SU+Khm+p2+ok2UalfR0cXajzhxYw5KFZLtUugDeRiJ9iS9evQI//18gnCB/Raey7 TKtu8TSahrro5P3FF54brm6ODkjxXs1UCbSiPjYX0vCp8x+AXFls9JJoTPP/2u1wJCqV WBf1cvtuNDNN02+eimso+ggSvLC+5A5wfanYANPl0uYro4auj9dQYaXVUVZAktTTkCIO QOb3yQ3eHqqEzu/E22aHjb10z/TjaFPW8vnHPYRZ8E2SEBhlEoXLmUAT80zRrPQJm9d6 YgKC1HTloyDVvChY2xB4CUPC66o+/TSW3v9IFCPPz7xE53PO0GmtNBVSaa8rOA8ulo4Q FNIQ== 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=LXlFGfXDoG0RaUMCnqyZEHdEEIs1aErZanwWdh2/ZZk=; b=dXD+6cP7vqs0Ewf3Saoa0uE3vhaEMK7CyrjMt2Gz3FvDlyvxk5ByfFXgnWPeU52y2I k34qV9GXGtD40RgRCNBqkxqLXWPoGlzKWf1oS+bBKRmIdQ9Ss6F4rJhl0mPAk8PvL6Bl QmYmV1Axs6ocKpa0ww6y8YNzRR/IDEdfX1jEHDucKEfys0fUwKq+UXSvdL1m6bgkBuCD o0BKgsooXZ2U9GIaXR4h3RNzK30ROOF7TnJATfe52/bArh3ohjhNN7eDE1x6JRxcHGgu EWtndROoAFhaTRXzBv3ov89AgihO/SneRW7nA5U7PDvcsfNYo2g6t/zlkRrkLk07EWF2 lvVA== X-Gm-Message-State: AOAM533e5cinI848DuaXU3PolCQO+12kmhDHleuO1h0leWlfN/Xmgfyn kXNq1MuD61Je5msBbpHUpxel7lEUPxUMEuTIf5U= X-Google-Smtp-Source: ABdhPJxaVrt2ak33lqe9ghxR8QU2hElbyRQGfXrIySmAk49QS3oolhmUm0bff6MFX2Lyw6H6d+gmexUiiFz2sHvYmJE= X-Received: by 2002:a6b:dc15:: with SMTP id s21mr1404846ioc.162.1603186827101; Tue, 20 Oct 2020 02:40:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 20 Oct 2020 11:40:14 +0200 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005689ff05b2170527" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 09:40:31 -0000 --0000000000005689ff05b2170527 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Some comments marked with FI. Fabien Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt a =C3= =A9crit : > *Previous Feedback* > The following items were discussed in the design team, but did not make i= t > into the draft for WG discussion. A concern I have with many of the edito= r > notes (which I point out) is that they are heavily biased by Justin's > vision and misrepresent the options. > FI : I'm sure we can get past hard feelings and focus on the core of the concerns. The editor's notes do their best to point where discussion should happen. If some of them need further clarification, we can certainly do that. > > *Abstract:* "information passed directly to the software" can mean pretty > much anything. The charter has "user identifiers, and identity assertions= ." > > *1. *Same point as in Abstract around "information". > > *1.1* Roles: > Add in roles for operators of AS and RC. > Show trust framework between legal entities (user, RO, client operator, A= S > operator) > Differentiate between legal entities having a relationship or HCI and the > actual protocol roles (RC, AS, RS) > What is the difference between roles and parties? Can we avoid the term > parties? RQ is both a party and a role. > Alternative names: > client for RC > user for RQ > FI : here we should have a more general discussion on the terminology work that was started within the group. The point was that we could then replace in the document. Personal preference : - we had already a quite extensive discussion on why "client" can be problematic. I liked your "Grant Client" (GC) better. - end-user is clearer for me > > *1.2* Elements: > defined access token without using "credential" > Grant as both a noun (what is being requested) and a verb > Grant is already is a noun being used as an adjective in "Grant > Negotiation ..." and "Grant Response" > "Subject Information" is better than just "information" -- but is still > extremely broad > The subject information should be about the user, not the RO. For example= , > in an enterprise use case where resource access and identity claims are > being requested, the RO is not the user, but could be an administrator. T= he > "subject information" is going to be about the user of the client, not th= e > administrator. > FI : Justin has asked for feedback on this, that we didn't have much time to give. I agree with your comments. > > *1.3.3* step 7 - what is a refreshed credential? We should refer to the > defined terms. > > *2.* title should be Grant Request to match with Grant Response in (3), > and use of "Grant Request" in 2.7, 2.9, 5, 5.4, & 5.5 > > *2.1.2:* "a RC MAY send a string known to the AS or RS" > why "or"? Explain. > > *2.2* "sub_ids" > are sub_ids a good idea, a best practice? despite warnings in the > protocol, developers will use an email identifier as a communication > identifier, or worse, a verified identifier. > GNAP is defining a query language here for subject identifiers. > FI : it makes sense to ask this question. There's pro and cons. Pro =3D it'= s useful for the client to be able to reuse some knowledge from an AS it trusts / Con =3D despite all we say, people will indeed misuse this possibility. > > *2.3 *Identifying a client via URL > Mobile Apps and SPA can identify themselves with an HTTPS url that only > that client can receive redirects to (universal link in iOS, android app > link). The client passes the general identifier for the client (class_id?= ) > and the AS ensures the redirect URI belongs to that client. A parameter i= s > passed on the redirect to the client that the client presents to the AS t= o > prove it is an instance of that client. The AS may then release access an= d > claims to the client. The AS may also provide an instance identifier for > the client so that instance of the client can uniquely identify itself. > > The editor note that instance_id is analogous to the client_id prevents a= n > instance of the client in the preceding paragraph from uniquely identifyi= ng > itself, and the name is misleading. > > Additionally, pre-registered identifiers (class_id which should be > equivalent to client_id for confidential clients) and dynamic identifiers > (instance_id) have different operational and infrastructure requirements. > pre-registered identifiers should be read only for the AS vs read / write > for the AS. There may be millions of dynamic identifier for one > pre-registered identifier (mobile app, SPA) > > *2.3.1 *Do we need to support symmetric keys? Most OAuth clients support > a secret, not a key. > FI : it's difficult to assume people with use public key cryptography for everything. Seems to me the text is clear enough on what this implies. > > *2.3.2* > what are the supported public key formats? > What if the client is able to use different proofing mechanisms? How does > it negotiate with the AS? > > > *2.4.1* identifying the user > this identifier would be useful if it had properties that other opaque > identifiers did not have: being globally unique. A reason developers have > used the email in ID Tokens was that it was a globally unique string in > contrast to the tuple of "iss" and "sub" in the ID Token which was much > more complicated to add and work with in a DB. Otherwise, we are creating > yet another user identifier. > FI : OK but how would you make this a global identifier? Seems close to what DIF Keri is looking for (although I find the way they're doing it is overly/unnecessarily complex). Would that replace sub_ids? > > *2.5* interaction capabilities / modes (section 3.3 as well) > While the document has renamed "interaction capabilities" to "interaction > modes", but the client is still declaring capabilities, but in 3.3 there > are conflicting statements > > "If the RC has indicated a capability to interact with the RO in its > request (Section 2.5)" > > The AS MUST NOT respond with any interaction mode that the RC did not > indicate in its request. > > using the same 4 interaction modes in the client request would make it > easier for the client to say which modes it supports, and the AS to respo= nd > with which modes are allowed. It also allows all parameters required for = a > mode to be in the mode. For example the URL for a double redirection, vs = a > redirection to an information page after a user_code or decoupled redirec= t. > > *2.5* declaring RC capabilities > Editor's note on what this is supposed to do, and why it can't be done by > just adding the properties to the request. > > *2.7 *perhaps this could be done by updating an existing Grant Request. > This seems overly complicated. > > *2.8* Perhaps this should be in 2.2 where we are requesting information > about the user? > Given that solving the use cases solved by OIDC is in conflict with the > editor note that OIDF should be doing the integration with GNAP. The > current model is confusing as requests are in one object, and responses a= re > in a different object. We don't have to combine the userinfo endpoint > request with the id_token request just because that was convenient for > OIDC. The editorial comments make thi seem much messier than it is. > FI : the goal hasn't changed here. We still integrate with other projects such as OIDC. > > *3.* The URI can be stable, and the access token is potentially > superfluous. As the client is authenticating with the same key in all > subsequent requests, rotation of the URI or access token may be > superfluous. Having an access token for the AS seems that is used while > authenticating vs the typical access token for an RS seems very confusing > to a developer. > FI : why would that be confusing? > > Additionally, putting the access token for calls to the AS in the HTTP > Authorization header precludes using the HTTP Authorization header for > client authentication in 8. > FI : that's one of the choices we need to make. But that doesn't mean what is proposed is worse, it's just a different design with different tradeoffs. This requires a complete discussion on section 8 (which already occurred in the small group, but Justin will be able to comment). > > *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in > the API between the client and the AS rather than an interaction that > involves the user. Also, this functionality provides no protection to > session fixation. The interaction reference has no value. > > *4.4.3 *While it is good to see an editor's note that a unique > callback URL could be used, the statement "but it would not prevent an > attacker from injecting an unrelated interaction reference into this > channel." is misleading. This would only happen if the client did not > ensure it is the same user, as that would be linked to the correct URL. > Similarly, the interaction reference does not provide protection if the > client does not ensure it is the same user. > Using a unique callback URL would be much simpler, and appears to provide > the same protection as the interaction reference and the hashing. > FI : having to rely on the client only to ensure it is the same user is precisely what you want to avoid. Hence the hashing. > > *5. * > Continuing a Grant Request (which in (2) is called an Access Request) > Is "continuing the right word"? > We are either "validating" the request (5.1), polling the request (5.2), > modifying the request (5.3), reading the request (5.4), or cancelling the > request (5.5). > FI : continuation is broad enough to contain these different cases, I don't see that as a problem. > > Include editorial discussion of replacing a request, replacing part of a > request, and adding to a request, and if we should have semantics for all= 3 > mechanisms. > > *8* > While some binding mechanisms work the same for the client calling the AS > as the RS, the requirements are different. When the client calls the AS, > the client is authenticating. When the client is calling the RS, the clie= nt > is proving it is authorized to access the resource. The RS does not need = to > know the identity of the client -- just that it is the client that the AS > gave the access token to. > > *8.2 Attached JWS* > Why not a JWT? > This is the ONLY self contained mechanism. All the other ones require all= , > or most of the HTTP headers and the body to be kept together. > > The editor note > > "Alternatively, we could add all these fields to the body of the request, > but then it gets awkward for non-body requests like GET/DELETE." > > It is not awkward. A mechanism is described later of having the JWS as an > HTTP header. Something JWS was designed for. > > The editor note > > "A downside to this method is that it requires the content type to be > something other than application/json, and it doesn't work against an RS > without additional profiling since it takes over the request body - plus = we > have to specify different delivery locations for a GET vs. a POST, for > example." > > Not being application/json is a feature as the AS can detect the signatur= e > mechanism. Per above, the requirements for the AS and RS are different. T= he > client can use the same mechanism of signing with an empty body and placi= ng > the JWS in an HTTP header just as it does below for requests with no body= . > The RS is proving it was given the access token by the AS, and binding th= at > to time, URI, and method. > > > The editor note > > "Additionally it is potentially fragile like a detached JWS since a > multi-tier system could parse the payload and pass the parsed payload > downstream with potential transformations. We might want to remove this i= n > favor of general-purpose HTTP signing, or at least provide guidance on it= s > use." > > is very misleading. The whole point is to pass the JWS between > components so that each can independently verify the request. ALL the oth= er > mechanisms have the fragility described as different components are going > to pass around the JSON -- and even if they pass around the detached > signature information and other headers, a component could transform the > JSON in parsing and stringifying the request. > > The straightforward way to use JOSE from a developers point of view would > be: > > - use JWT > - include the key in the header > - have "iat", the method, and the URI in the payload > - put the JWT in the HTTP Authorization header for methods without a body > > This is how I wrote it in my implementation. It was very straightforward. > > Only the last point conflicts with GNAP as now written -- all the other > aspects could be how it is done for JWT. > > > *Additional feedback* > the document name is redundant - protocol is in it twice > (gnap =3D Grant Negotiation and Authorization Protocol)-core-protocol > "draft-ietf-gnap-core" would be sufficient > > 1.2 Elements > Key - "A cryptographic element binding a request to the holder of the key= ." > It is actually *any* holder of the key. > FI : yes. Which is always the case in cryptography, unless you have some hardware component to protect this. This can later be enclosed in a threat model section. > > 2.2 Editor's note "you'd need a full identity protocol and not just this" > implies that GNAP is not an identity protocol despite it supporting the > OpenId Connect use cases. > > 3.5 Do we need this section? The only thing with "handle" in the name is > user_handle. The access token is not really a handle. > > =E1=90=A7 > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005689ff05b2170527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Some comments marked with FI.=C2=A0

Fabien

Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hard= t <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Previous Feedback=
The following items were discussed=C2=A0in the design team, but d= id not make it into the draft for WG discussion. A concern I have=C2=A0with= many of the editor notes (which I point out) is that they are heavily bias= ed by Justin's vision and misrepresent the options.
<= /div>

FI : I'm sure = we can get past hard feelings and focus on the core of the concerns. The ed= itor's notes do their best to point where discussion should happen. If = some of them need further clarification, we can certainly do that.=C2=A0

Abstract: "information= passed=C2=A0directly to the software" can mean pretty much anything. = The charter has "user identifiers, and identity assertions."=C2= =A0

1. Same point as in Abstract aroun= d "information".

1.1 Roles:= =C2=A0
Add in roles for operators of AS and RC.=C2=A0
S= how trust framework between legal entities (user, RO, client operator, AS o= perator)
Differentiate between legal entities having a relationsh= ip or HCI and the actual protocol roles (RC, AS, RS)
What is the = difference between roles and parties? Can we avoid the term parties? RQ is = both a party and a role.
Alternative names:
client for = RC
user for RQ

FI : here we should have a more general dis= cussion on the terminology work that was started within the group. The poin= t was that we could then replace in the document.=C2=A0

Personal preference :
- we had already a quite extensive discussion on why "client" c= an be problematic. I liked your "Grant Client" (GC) better.=C2=A0=
- end-user is clearer for me

1.2 Elements:
defined access token wi= thout using "credential"
Grant as both a noun (what is = being requested) and a verb=C2=A0
Grant is already is a noun bein= g used as an adjective in "Grant Negotiation ..." and "Grant= Response"
"Subject Information" is better than ju= st "information" -- but is still extremely broad
The su= bject information should be about the user, not the RO. For example, in an = enterprise use case where resource=C2=A0access and identity claims are bein= g requested, the RO is not the user, but could be an administrator. The &qu= ot;subject information" is going to be about the user of the client, n= ot the administrator.

FI : Justin has asked for feedback on this, th= at we didn't have much time to give. I agree with your comments.=C2=A0<= /div>

1.3.3 step 7 - what is a = refreshed credential? We should refer to the defined terms.

2. title = should be Grant Request to match with Grant Response in (3), and use of &qu= ot;Grant Request" in 2.7, 2.9, 5, 5.4, & 5.5=C2=A0

<= /div>
2.1.2: "a RC MAY send a string known to the AS or RS&= quot;
why "or"? Explain.

2.= 2 "sub_ids"
are sub_ids a good idea, a best practic= e? despite warnings in the protocol, developers will use an email identifie= r as a communication identifier, or worse, a verified identifier.=C2=A0
GNAP is defining a query language here for subject identifiers.=C2= =A0

FI : it makes sense to ask this question. There's pro and co= ns. Pro =3D it's useful for the client to be able to reuse some knowled= ge from an AS it trusts / Con =3D despite all we say, people will indeed mi= suse this possibility.=C2=A0

= 2.3 Identifying a client via URL
Mobile Apps and SPA can iden= tify themselves with an HTTPS url that only that client can receive redirec= ts to (universal link in iOS, android app link). The client passes the gene= ral identifier for the client (class_id?) and the AS ensures the redirect U= RI belongs to that client. A parameter is passed on the redirect to the cli= ent that the client presents to the AS to prove it is an instance of that c= lient. The AS may then release access and claims to the client. The AS may = also provide an instance identifier for the client so that instance of the = client can uniquely identify itself.

The editor no= te that instance_id is analogous=C2=A0to the client_id prevents an instance= of the client in the preceding paragraph from uniquely identifying itself,= and the name is misleading.

Additionally, pre-reg= istered identifiers (class_id which should be equivalent to client_id for c= onfidential clients) and dynamic identifiers (instance_id) have different o= perational and infrastructure requirements. pre-registered identifiers shou= ld be read only for the AS vs read / write for the AS. There may be million= s of dynamic identifier for one pre-registered identifier (mobile app, SPA)=

2.3.1 Do we need to support symmetric=C2= =A0keys? Most OAuth clients support a secret, not a key.

FI : it'= ;s difficult to assume people with use public key cryptography for everythi= ng. Seems to me the text is clear enough on what this implies.=C2=A0
<= div dir=3D"auto">
=

2.3.2
what are the su= pported public key formats?
What if the client is able to use dif= ferent proofing mechanisms? How does it negotiate with the AS?

2.4.1 identifying the user
thi= s identifier would be useful if it had properties that other opaque identif= iers did not have: being globally unique. A reason developers have used the= email in ID Tokens was that it was a globally unique string in contrast to= the tuple of "iss" and "sub" in the ID Token which was= much more complicated to add and work with in a DB. Otherwise, we are crea= ting yet another user identifier.

FI : OK but how would you make thi= s a global identifier? Seems close to what DIF Keri is looking for (althoug= h I find the way they're doing it is overly/unnecessarily complex). Wou= ld that replace sub_ids?=C2=A0

<= b>2.5 interaction capabilities / modes (section 3.3 as well)
= While the document has renamed "interaction capabilities" to &quo= t;interaction modes", but the client is still declaring capabilities, = but in 3.3 there are conflicting statements

"= If the RC has indicated a capability to interact with the RO in its request= (Section 2.5)"

The AS MUST NOT respond w= ith any interaction mode that the RC did not indicate in its request.=C2=A0=

using the same 4 interaction modes in the cli= ent request would make it easier for the client to say which modes it suppo= rts, and the AS to respond with which modes are allowed. It also allows all= parameters required for a mode to be in the mode. For example the URL for = a double redirection, vs a redirection to an information page after a user_= code or decoupled redirect.

2.5 declaring R= C capabilities
Editor's=C2=A0note on what this is supposed to= do, and why it can't be done by just adding the properties to the requ= est.

2.7 perhaps this could be done by upda= ting=C2=A0 an existing Grant Request. This seems overly complicated.
<= div>
2.8=C2=A0Perhaps this should be in 2.2 where we a= re requesting information about the user?
Given that solving the = use cases solved by OIDC is in conflict with the editor note that OIDF shou= ld be doing the integration with GNAP. The current model is confusing as re= quests are in one object, and responses are in a different object. We don&#= 39;t have to combine the userinfo endpoint request with the id_token reques= t just because that was convenient for OIDC. The editorial comments make th= i seem much messier than it is.

FI : the goal hasn't changed her= e. We still integrate with other projects such as OIDC.=C2=A0

3. The URI can= be stable, and the access token is potentially superfluous. As the client = is authenticating with the same key in all subsequent requests, rotation of= the URI or access token may be superfluous. Having an access token for the= AS seems that is used while authenticating vs the typical access token for= an RS seems very confusing to a developer.
<= /div>

FI : why would that be c= onfusing?=C2=A0

<= /div>
Additionally, putting the access token for calls to the AS in the= HTTP Authorization header precludes using the HTTP Authorization header fo= r client authentication in 8.

FI : that's one of the choices we= need to make. But that doesn't mean what is proposed is worse, it'= s just a different design with different tradeoffs. This requires a complet= e discussion on section 8 (which already occurred in the small group, but J= ustin will be able to comment).=C2=A0

4.4.2 This functionality looks like a = WebHook, and perhaps belongs in the API between the client and the AS rathe= r than an interaction that involves the user. Also, this functionality prov= ides no protection to session fixation. The interaction reference has no va= lue.

4.4.3 While it is good to see an edito= r's note that=C2=A0a unique callback=C2=A0URL could be used, the statem= ent "but it would not prevent an attacker from injecting an unrelated = interaction reference into this channel." is misleading. This would on= ly happen if the client did not ensure it is the same user, as that would b= e linked to the correct=C2=A0URL. Similarly, the interaction reference does= not provide protection if the client does not ensure it is the same user.<= /div>
Using a unique callback URL would be much simpler, and appears to= provide the same protection as the interaction reference and the hashing.<= /div>

FI : having to rely on the client only to ensure it is the same user= is precisely what you want to avoid. Hence the hashing.=C2=A0

5.=C2=A0
Continuing a Grant= Request (which in (2) is called an Access Request)
Is "cont= inuing the right word"?
We are either "validating"= the request (5.1), polling the request (5.2), modifying the request (5.3),= reading the request (5.4), or cancelling the request (5.5).

FI : co= ntinuation is broad enough to contain these different cases, I don't se= e that as a problem.=C2=A0

Inclu= de editorial discussion of replacing a request, replacing part of a request= , and adding to a request, and if we should have semantics for all 3 mechan= isms.

=
8
While some binding mechanisms work the same for the= client calling the AS as the RS, the requirements are different. When the = client calls the AS, the client is authenticating. When the client is calli= ng the RS, the client is proving it is authorized to access the resource. T= he RS does not need to know the identity of the client -- just that it is t= he client that the AS gave the access token to.

8.2 Attached JWS
Why not a JWT?
This is the ONLY self contained mechanism. A= ll the other ones require all, or most of the HTTP headers and the body to = be kept together.

The editor note
<= br>
"Alternatively, we could add all these fields to the bod= y of the request, but then it gets awkward for non-body requests like GET/D= ELETE."

It is not awkward. A mechanism is des= cribed later of having the JWS as an HTTP header. Something JWS was designe= d for.

The editor note

&q= uot;A downside to this method is that it requires the content type to be so= mething other than application/json, and it doesn't work against an RS = without additional profiling since it takes over the request body - plus we= have to specify different delivery locations for a GET vs. a POST, for exa= mple."

Not being application/json is a fe= ature as the AS can detect the signature mechanism. Per above, the requirem= ents for the AS and RS are different. The client can use the same mechanism= of signing with an empty body and placing the JWS in an HTTP header just a= s it does below for requests with no body. The RS is proving it was given t= he access token by the AS, and binding that to time, URI, and method.
=


The editor note=C2=A0
"Additionally it is potentially fragile like a detached J= WS since a multi-tier system could parse the payload and pass the parsed pa= yload downstream with potential transformations. We might want to remove th= is in favor of general-purpose HTTP signing, or at least provide guidance o= n its use."=C2=A0

is very misleading. The who= le point is to pass the JWS between components=C2=A0so that each can indepe= ndently verify the request. ALL the other mechanisms have the fragility des= cribed as different components are going to pass around the JSON -- and eve= n if they pass around the detached signature information and other headers,= a component could transform the JSON in parsing and stringifying the reque= st.

The straightforward=C2=A0way to use JOSE from = a developers point of view would be:

- use JWT
- include the key in the header
- have "iat", th= e method, and the URI in the payload
- put the JWT in the HTTP Au= thorization header for methods without a body

This= is how I wrote it in my implementation. It was very straightforward.
=

Only the last point conflicts with GNAP as now written = -- all the other aspects could be how it is done for JWT.


Additional feedback
the document na= me is redundant - protocol is in it twice
(gnap =3D Grant Negotia= tion and Authorization Protocol)-core-protocol
"draft-ietf-g= nap-core" would be sufficient

1.2 Elements
Key - "A cryptographic element binding a request to the holder= of the key."
It is actually any holder of the key.= =C2=A0

FI : yes. Which is always the case in cryptography, unless yo= u have some hardware component to protect this. This can later be enclosed = in a threat model section.=C2=A0

2.2 Editor's note "you'd need a full identity protocol and no= t just this" implies that GNAP is not an identity protocol despite it = supporting the OpenId Connect use cases.=C2=A0

3.5= Do we need this section? The only thing with "handle" in the nam= e is user_handle. The access token is not really a handle.=C2=A0
=
=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--0000000000005689ff05b2170527-- From nobody Tue Oct 20 03:16:30 2020 Return-Path: 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 EE44A3A1118 for ; Tue, 20 Oct 2020 03:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, MIME_QP_LONG_LINE=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 (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 nfEsUAMJBbde for ; Tue, 20 Oct 2020 03:16:24 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 AB54D3A1110 for ; Tue, 20 Oct 2020 03:16:24 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id u19so2349395ion.3 for ; Tue, 20 Oct 2020 03:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=oYi9/wgTryh5QcQNBA59+m+WRGgVn17BduVIfShOdC8=; b=A/WnRyUYU1Ty+rQaUaHZLDVoPay7LqDKwL4D4JP3dVFwOt1iCi+9X9ERSomn9TwSaF RP6t/0YUKcilN029YR72bXV8GOE2Ef0QsLYJODnl3RaYozPLuXjrG73CLYUoFjQghhDf pX1pA5KskWqT3wZsfiHHkHncua2AJdJV8iDvTQ83Ac5rqJGsY0ss9ZT3Tt9XS2+Z72QW Ggs/gQwuYnBXQ68kIcK9imZphCNvXLpnHt5onR3j4CZqXDGcEsDDaGdkvYzjq6/klo30 yEB8wO7hPxw2E57VxDBc9Ri5mXFTfvVZHR51HAgd/Zu4yOThJaaLPcs7324XCl1NFLFe ujyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=oYi9/wgTryh5QcQNBA59+m+WRGgVn17BduVIfShOdC8=; b=ngxhEgTeI77enq/Rfo0AESVLsxeE1JCsUbGyF4WbTUUCSsz8n73fr5W1fzw1405Q2s j1GICv0x1YWY9ELuN/mNQEh37UgPbJ2kK0j4+2FMDHmzzZnsK6msi0+v/W/QeT4pDL5o jHisxvO4x8DmF4dTxnP+8T7wEmv7VgS7PUWoqU5wz3seA7kxInOJTK35ZQbiWAAi/O09 aSsPq+yWb6oG1XP46sSq0U0C378mPeQEWh+kOHTSlOK0PkFKZIf4AQFfZUZyyoqzfSIW ckMNuf7ueCQpVPmNfW+Ynxoiotz1tz2Q2HbHjAR5NB9fF+im36lkGL9R6lO1rnv+J5Ov n1pw== X-Gm-Message-State: AOAM531CUgmJqJXquzwANNcH3VEEJ6vuCo2BjDiY2mn51dUhvc8rs2lF HGrHJvaFpLbOGN8eIKBJWzs= X-Google-Smtp-Source: ABdhPJzLvYur77EmWuAz9fj3UHqIZdRd6GH7UNYoUNknE6Y+blrGbUxx29jomr3rr7e3NAyVs7H2Jg== X-Received: by 2002:a6b:fd08:: with SMTP id c8mr1533547ioi.16.1603188983735; Tue, 20 Oct 2020 03:16:23 -0700 (PDT) Received: from [192.168.86.20] (146-115-101-80.s7246.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.101.80]) by smtp.gmail.com with ESMTPSA id d6sm1474611ilf.19.2020.10.20.03.16.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 03:16:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F7C2B859-DFFE-4605-8361-DE32631936EB Content-Transfer-Encoding: 7bit From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Tue, 20 Oct 2020 06:12:57 -0400 Message-Id: References: Cc: Justin Richer , "txauth@ietf.org" In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (17H35) Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 10:16:29 -0000 --Apple-Mail-F7C2B859-DFFE-4605-8361-DE32631936EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Your interpretation of events is in contrast to mine. I=E2=80=99m not going= to argue further with you as there=E2=80=99s no point unless you get your w= ay. There were 2 detailed reviews from the design team that preferred Justi= n=E2=80=99s document as a starting point, none with yours. His was preferre= d for several reasons including ease of understanding and aligned better wit= h IETF protocol specs for cross area review. Best regards, Kathleen=20 Sent from my mobile device > On Oct 19, 2020, at 11:26 PM, Dick Hardt wrote: >=20 > =EF=BB=BF > I don't see how your take is different in the process you chose to take, v= s the process I had suggested in the WG meeting, and the chairs had set as t= he goals of the design team. Despite the WG not adopting your recommendation= to start with XYZ, you chose to ignore the WG and chairs and start with the= XYZ document. >=20 > wrt. RESTful design patterns, that was a design pattern that XAuth introdu= ced and that XYZ has adopted. The one comment about a suggestion I made that= was not RESTful -- I was asking for the parameters in JWS signing to be mov= ed from the JWS header to the JWS payload -- my suggestion was not making it= any less RESTful than it already was. Inaccurate representations like this c= ontributed to the tension in the meetings. >=20 > One of your criticisms of XAuth was the use of "non standard IETF language= " such as "sequence" -- a term that is now used numerous times in the draft.= =20 >=20 > I hope you had a RESTful vacation! >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty wrote: >>=20 >> My take is very different, Dick. I am starting a 2 week vacation and wil= l not be spending it arguing with you on the list. >>=20 >> Multiple reviews pointed to Justin=E2=80=99s document as a better startin= g point, not just mine. Your use case cases can be met and some of what you= were asking for did not follow RESTful design patterns. They really don=E2= =80=99t map to a future protocol well. You may need to write extension docu= ments, but your goals can be met. >>=20 >> Many calls were difficult as displayed in your message. Justin did a gre= at job handling the weekly tension and ensuring options were included for WG= discussion when agreement was not met. He=E2=80=99s completely amenable to= following the WG and chairs decisions. His document was also easier to fol= low and aligned better with numerous IETF documents. Please do keep Justin o= n as an editor. As you can see from the draft, there are many areas where WG= input on decision points are requested. >>=20 >> Best regards, >> Kathleen=20 >>=20 >> Sent from my mobile device >>=20 >>>> On Oct 9, 2020, at 8:26 PM, Dick Hardt wrote: >>>>=20 >>> =EF=BB=BF >>> Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting= -14, but I propose someone other than Justin be the document editor.=20 >>>=20 >>> I was on the design team to work on the goals set out by the chairs [1]:= =20 >>>=20 >>> "We expect the design team to decide on a solution outline that combines= the best of both proposals, and present this outline by Sep. 15" >>>=20 >>> Surprisingly, Kathleen convened the design team with her recommendation t= o start with the XYZ document with Justin as editor, and add in the diagrams= from XAuth. The rest of the design team had an opportunity to express their= concerns and Justin edited the document. In other words, I had to convince J= ustin to change the document, rather than the design team comparing and cont= rasting the proposals and selecting the best parts. I expressed my concerns w= ith our AD, and decided to continue participating in the design team. We did= make some progress on a number of issues thanks to the hard work of Fabien,= Justin, and Mike -- but many issues have been punted to the WG. >>>=20 >>> Justin has poured tons of energy into this project, and to his credit he= was a good editor at times, but there are areas where he was unwilling to d= eviate from his vision. >>>=20 >>> I am concerned about a repeat of what happened in OAuth 2.0: Erin had th= e pen and had strong views that often were not aligned with the rest of the W= G. A good example was Erin's distaste for bearer tokens. He factored that ou= t of the core document, which we are now adding back in with OAuth 2.1. Anyo= ne that participated in the WG saw the issues this had. >>>=20 >>> I'm not suggesting that Justin is Erin, but I think a more neutral edito= r of the core document will allow us to make progress more quickly.=20 >>>=20 >>> /Dick >>>=20 >>> [1] https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9e= W38I/ >>> =E1=90=A7 >>>=20 >>>> On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: >>>> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their ha= rd work and discussion as well. This draft contains aspects of XYZ and Xauth= , and introduces some new elements and pieces as well. As you'll see, there a= re many identified issues and decisions to be made, but even then I believe i= t hangs together fairly cohesively already thanks to the good engineering ef= fort and discussion that's gone in so far.=20 >>>>=20 >>>> Nothing in the document is final, of course. To me, this document repre= sents a good starting point for working group discussion and decisions, +1 f= or its adoption.=20 >>>>=20 >>>> - Justin >>>> ________________________________________ >>>> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [= kathleen.moriarty.ietf@gmail.com] >>>> Sent: Friday, October 9, 2020 6:55 PM >>>> To: txauth@ietf.org >>>> Subject: [GNAP] Design team >>>>=20 >>>> Greetings! >>>>=20 >>>> The design team has now come to a close. While there were too many iss= ues to resolve to all design team member satisfaction, great effort was put i= n to describe decision points for the WG to ease and hopefully speed the wor= king group process. As such, I am requesting that the WG adopts this versio= n (14 of XYZ) and works together to fully develop a single specification. >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >>>>=20 >>>> A tremendous thank you to each of the design team members for your hard= work and walking the fine line of when to put a stake in the ground (that t= he WG can always change once adopted) and listing our options for decision p= oints to ease the WG process. >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> Sent from my mobile device >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-F7C2B859-DFFE-4605-8361-DE32631936EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Your interpretation of events is in contras= t to mine.  I=E2=80=99m not going to argue further with you as there=E2= =80=99s no point unless you get your way.  There were 2 detailed review= s from the design team that preferred Justin=E2=80=99s document as a startin= g point, none with yours.  His was preferred for several reasons includ= ing ease of understanding and aligned better with IETF protocol specs for cr= oss area review.

Best regards,
Kathleen 
Sent from my mobile device

=
On Oct 19, 2020, at 11:26 PM, Dick Hardt <dick.= hardt@gmail.com> wrote:

=EF=BB=BF
I don't see how your take is d= ifferent in the process you chose to take, vs the process I had suggested in= the WG meeting, and the chairs had set as the goals of the design team. Des= pite the WG not adopting your recommendation to start with XYZ, you chose to= ignore the WG and chairs and start with the XYZ document.

wrt. RESTful design patterns, that was a design pattern that XAuth introdu= ced and that XYZ has adopted. The one comment about a suggestion I made that= was not RESTful -- I was asking for the parameters in JWS signing to be mov= ed from the JWS header to the JWS payload -- my suggestion was not making it= any less RESTful than it already was. Inaccurate representations like this c= ontributed to the tension in the meetings.

One of you= r criticisms of XAuth was the use of "non standard IETF language" such as "s= equence" -- a term that is now used numerous times in the draft. 
=

I hope you had a RESTful vacation!

<= div>





On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wro= te:

My take is very di= fferent, Dick.  I am starting a 2 week vacation and will not be spendin= g it arguing with you on the list.

Multiple review= s pointed to Justin=E2=80=99s document as a better starting point, not just m= ine.  Your use case cases can be met and some of what you were asking f= or did not follow RESTful design patterns.  They really don=E2=80=99t m= ap to a future protocol well.  You may need to write extension document= s, but your goals can be met.

Many calls were diffi= cult as displayed in your message.  Justin did a great job handling the= weekly tension and ensuring options were included for WG discussion when ag= reement was not met.  He=E2=80=99s completely amenable to following the= WG and chairs decisions.  His document was also easier to follow and a= ligned better with numerous IETF documents.  Please do keep Justin on a= s an editor. As you can see from the draft, there are many areas where WG in= put on decision points are requested.

Best regards,=
Kathleen 

Sent from my m= obile device

On Oct 9, 2= 020, at 8:26 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=
=EF=BB=BF
Tl;dr: G= iven where we are in the WG, I am not opposed to the WG adopting -14, but I p= ropose someone other than Justin be the document editor.

I was on th= e design team to work on the goals set out by the chairs [1]:

"We ex= pect the design team to decide on a solution outline that combines the best o= f both proposals, and present this outline by Sep. 15"

Surprisingly, K= athleen convened the design team with her recommendation to start with the X= YZ document with Justin as editor, and add in the diagrams from XAuth. The r= est of the design team had an opportunity to express their concerns and Just= in edited the document. In other words, I had to convince Justin to change t= he document, rather than the design team comparing and contrasting the propo= sals and selecting the best parts. I expressed my concerns with our AD, and d= ecided to continue participating in the design team. We did make some progre= ss on a number of issues thanks to the hard work of Fabien, Justin, and Mike= -- but many issues have been punted to the WG.

Justin has poured to= ns of energy into this project, and to his credit he was a good editor at ti= mes, but there are areas where he was unwilling to deviate from his vision. <= br>
I am concerned about a repeat of what happened in OAuth 2.0: Erin had= the pen and had strong views that often were not aligned with the rest of t= he WG. A good example was Erin's distaste for bearer tokens. He factored tha= t out of the core document, which we are now adding back in with OAuth 2.1. A= nyone that participated in the WG saw the issues this had.

I'm not su= ggesting that Justin is Erin, but I think a more neutral editor of the core d= ocument will allow us to make progress more quickly.

/Dick

[1= ] https://mailarchive.ietf.org/arch/msg/txauth/B= y7tDkJBxhmHbP7vKwubC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM Justin Richer <jricher@mit.edu> wrote:
Thanks, Kathleen, an= d thanks to Dick, Mike, and Fabian for all their hard work and discussion as= well. This draft contains aspects of XYZ and Xauth, and introduces some new= elements and pieces as well. As you'll see, there are many identified issue= s and decisions to be made, but even then I believe it hangs together fairly= cohesively already thanks to the good engineering effort and discussion tha= t's gone in so far.

Nothing in the document is final, of course. To me, this document represents= a good starting point for working group discussion and decisions, +1 for it= s adoption.

- Justin
________________________________________
From: TXAuth [t= xauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kathleen.moriarty.ietf= @gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org=
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.  While there were too many iss= ues to resolve to all design team member satisfaction, great effort was put i= n to describe decision points for the WG to ease and hopefully speed the wor= king group process.  As such, I am requesting that the WG adopts this v= ersion (14 of XYZ) and works together to fully develop a single specificatio= n.

https://datatracker.ietf.org/doc/dra= ft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard work= and walking the fine line of when to put a stake in the ground (that the WG= can always change once adopted) and listing our options for decision points= to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-F7C2B859-DFFE-4605-8361-DE32631936EB-- From nobody Tue Oct 20 10:06:58 2020 Return-Path: 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 4604A3A11B0 for ; Tue, 20 Oct 2020 10:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zy-bcUeP7VlF for ; Tue, 20 Oct 2020 10:06:55 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 A859A3A11A9 for ; Tue, 20 Oct 2020 10:06:54 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id h20so2820034lji.9 for ; Tue, 20 Oct 2020 10:06:54 -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=rrYOMpgzuy2fksQVmnPBbDkkrb2KarnlfuKBJnJuZTA=; b=jB4Lyc13mHn8HKlaRaN5W8ieE3LiuPNcsr4AxQ8qQ1P1uQKtipDU8Bqk+3dWniaG0a +ewfWwRKSL0nrrMOSmD7eztqElH7uRcpL/8yisVfXu+8CkWM1/w+g+a1zj821lWreLnE dmZ8sZ2ogRKH/5Xbp2LPR2FyH3+qo/iZrbveffIsQMNxTDpgeB/U4/Fn8+NnJA936zpI Q0hs9RrreR28DR9Nzk+RMF9VWhyb+3FUdM71XFXitFHgdophwj0LbljZssqGgP33b/cE B6XpaMxM5OxevRKjxrfCr69G5zbkzu0YI6hEDqr3i+pyNTVJ3k8a6TQHE2omsjHulojx ffHQ== 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=rrYOMpgzuy2fksQVmnPBbDkkrb2KarnlfuKBJnJuZTA=; b=Jvyij90UwEIF3PuSKzjxGuVVEbso7HSVhvcfJ/aVopVaMNbT8JGGKlaHgbqFvULDrn wxpE4tDdy6fhzD4zsNGnwnblVapTdeZ7mQhK3fNBpvlcEaFuBDRG29oRu8reYaWfJn/g lsj9DhpgFZEqCQ6wIQzBRxr2HlLzv/QuVZEGME13vV+oxEeZcUW6JJpCHdbkUFKXIqjU +s4o2T65XrKFrqdjvcmYgbTxVZ+4+ZDBs/kR6pYBgwnpnJsMhvlNN6CieJH8m3WxKbRJ r20vHXwRPTNhj266MMIkpdmLTALlmVD2dJ268H1yyjDYWLO3TQfUVKCQzdK+sjETeFIV 2PuQ== X-Gm-Message-State: AOAM533c8jjTEz6YkOMNOPYC+tTlNv6wYSq1XafA0xlzkg06uiZiUgSh fGrDyuCl9doHxL/SB3V4asTT24oB/16NN9TQOXA= X-Google-Smtp-Source: ABdhPJwY5rTA6ZP2rf6thAFPj5t+vzoAgAZ6Wa251BZMIEf7rWLGBDLFIobX4Q11xQnZmffMfZ8/mw1/Xd7BTLT20lI= X-Received: by 2002:a2e:9a43:: with SMTP id k3mr1696296ljj.69.1603213612592; Tue, 20 Oct 2020 10:06:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 20 Oct 2020 10:06:15 -0700 Message-ID: To: Kathleen Moriarty Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0b29705b21d41e6" Archived-At: Subject: Re: [GNAP] Design team X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 17:06:57 -0000 --000000000000e0b29705b21d41e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kathleeen, you keep talking about why we started with XYZ, I'm stating that the goal of the design team was NOT to choose a starting document, but to select the best ideas and create an outline. "We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15"[1] > > [1] https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/ I find your comment on me "getting my way" is dismissive of having a civil conversation. =E1=90=A7 On Tue, Oct 20, 2020 at 3:16 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Your interpretation of events is in contrast to mine. I=E2=80=99m not go= ing to > argue further with you as there=E2=80=99s no point unless you get your wa= y. There > were 2 detailed reviews from the design team that preferred Justin=E2=80= =99s > document as a starting point, none with yours. His was preferred for > several reasons including ease of understanding and aligned better with > IETF protocol specs for cross area review. > > Best regards, > Kathleen > > Sent from my mobile device > > On Oct 19, 2020, at 11:26 PM, Dick Hardt wrote: > > =EF=BB=BF > I don't see how your take is different in the process you chose to take, > vs the process I had suggested in the WG meeting, and the chairs had set = as > the goals of the design team. Despite the WG not adopting your > recommendation to start with XYZ, you chose to ignore the WG and chairs a= nd > start with the XYZ document. > > wrt. RESTful design patterns, that was a design pattern that XAuth > introduced and that XYZ has adopted. The one comment about a suggestion I > made that was not RESTful -- I was asking for the parameters in JWS signi= ng > to be moved from the JWS header to the JWS payload -- my suggestion was n= ot > making it any less RESTful than it already was. Inaccurate representation= s > like this contributed to the tension in the meetings. > > One of your criticisms of XAuth was the use of "non standard IETF > language" such as "sequence" -- a term that is now used numerous times in > the draft. > > I hope you had a RESTful vacation! > > > > > > > > On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> >> My take is very different, Dick. I am starting a 2 week vacation and >> will not be spending it arguing with you on the list. >> >> Multiple reviews pointed to Justin=E2=80=99s document as a better starti= ng point, >> not just mine. Your use case cases can be met and some of what you were >> asking for did not follow RESTful design patterns. They really don=E2= =80=99t map >> to a future protocol well. You may need to write extension documents, b= ut >> your goals can be met. >> >> Many calls were difficult as displayed in your message. Justin did a >> great job handling the weekly tension and ensuring options were included >> for WG discussion when agreement was not met. He=E2=80=99s completely a= menable to >> following the WG and chairs decisions. His document was also easier to >> follow and aligned better with numerous IETF documents. Please do keep >> Justin on as an editor. As you can see from the draft, there are many ar= eas >> where WG input on decision points are requested. >> >> Best regards, >> Kathleen >> >> Sent from my mobile device >> >> On Oct 9, 2020, at 8:26 PM, Dick Hardt wrote: >> >> =EF=BB=BF >> Tl;dr: Given where we are in the WG, I am not opposed to the WG adopting >> -14, but I propose someone other than Justin be the document editor. >> >> I was on the design team to work on the goals set out by the chairs [1]: >> >> "We expect the design team to decide on a solution outline that combines >> the best of both proposals, and present this outline by Sep. 15" >> >> Surprisingly, Kathleen convened the design team with her recommendation >> to start with the XYZ document with Justin as editor, and add in the >> diagrams from XAuth. The rest of the design team had an opportunity to >> express their concerns and Justin edited the document. In other words, I >> had to convince Justin to change the document, rather than the design te= am >> comparing and contrasting the proposals and selecting the best parts. I >> expressed my concerns with our AD, and decided to continue participating= in >> the design team. We did make some progress on a number of issues thanks = to >> the hard work of Fabien, Justin, and Mike -- but many issues have been >> punted to the WG. >> >> Justin has poured tons of energy into this project, and to his credit he >> was a good editor at times, but there are areas where he was unwilling t= o >> deviate from his vision. >> >> I am concerned about a repeat of what happened in OAuth 2.0: Erin had th= e >> pen and had strong views that often were not aligned with the rest of th= e >> WG. A good example was Erin's distaste for bearer tokens. He factored th= at >> out of the core document, which we are now adding back in with OAuth 2.1= . >> Anyone that participated in the WG saw the issues this had. >> >> I'm not suggesting that Justin is Erin, but I think a more neutral edito= r >> of the core document will allow us to make progress more quickly. >> >> /Dick >> >> [1] >> https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I= / >> =E1=90=A7 >> >> On Fri, Oct 9, 2020 at 5:04 PM Justin Richer wrote: >> >>> Thanks, Kathleen, and thanks to Dick, Mike, and Fabian for all their >>> hard work and discussion as well. This draft contains aspects of XYZ an= d >>> Xauth, and introduces some new elements and pieces as well. As you'll s= ee, >>> there are many identified issues and decisions to be made, but even the= n I >>> believe it hangs together fairly cohesively already thanks to the good >>> engineering effort and discussion that's gone in so far. >>> >>> Nothing in the document is final, of course. To me, this document >>> represents a good starting point for working group discussion and >>> decisions, +1 for its adoption. >>> >>> - Justin >>> ________________________________________ >>> From: TXAuth [txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [ >>> kathleen.moriarty.ietf@gmail.com] >>> Sent: Friday, October 9, 2020 6:55 PM >>> To: txauth@ietf.org >>> Subject: [GNAP] Design team >>> >>> Greetings! >>> >>> The design team has now come to a close. While there were too many >>> issues to resolve to all design team member satisfaction, great effort = was >>> put in to describe decision points for the WG to ease and hopefully spe= ed >>> the working group process. As such, I am requesting that the WG adopts >>> this version (14 of XYZ) and works together to fully develop a single >>> specification. >>> >>> https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ >>> >>> A tremendous thank you to each of the design team members for your hard >>> work and walking the fine line of when to put a stake in the ground (th= at >>> the WG can always change once adopted) and listing our options for deci= sion >>> points to ease the WG process. >>> >>> Best regards, >>> Kathleen >>> >>> Sent from my mobile device >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000e0b29705b21d41e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kathleeen, you keep talking about why we started with XYZ,= I'm stating that the goal of the design team=C2=A0was NOT to choose a = starting document, but to select the best ideas and create an outline.
=
"We expect the design team to= decide on a solution outline that combines the best of both proposals, and= present this outline by Sep. 15"[1]
[1]=C2=A0https://mailarchive.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vK= wubC9eW38I/=C2=A0

I find your comment on me "getting my way" is dismissive= of having a civil=C2=A0conversation.=C2=A0

3D""=E1=90=A7
=
On Tue= , Oct 20, 2020 at 3:16 AM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
= Your interpretation of events is in contrast to mine.=C2=A0 I=E2=80=99m not= going to argue further with you as there=E2=80=99s no point unless you get= your way.=C2=A0 There were 2 detailed reviews from the design team that pr= eferred Justin=E2=80=99s document as a starting point, none with yours.=C2= =A0 His was preferred for several reasons including ease of understanding a= nd aligned better with IETF protocol specs for cross area review.

<= /div>
Best regards,
Kathleen=C2=A0

Se= nt from my mobile device

On Oct 19, 2020, at 11:26 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
I don't see how your take is different in the process you ch= ose to take, vs the process I had suggested in the WG meeting, and the chai= rs had set as the goals of the design team. Despite the WG not adopting you= r recommendation to start with XYZ, you chose to ignore the WG and chairs a= nd start with the XYZ document.

wrt. RESTful design patt= erns, that was a design pattern that XAuth introduced and that XYZ has adop= ted. The one comment about a suggestion I made that was not RESTful -- I wa= s asking for the parameters in JWS signing to be moved from the JWS header = to the JWS payload -- my suggestion was not making it any less RESTful than= it already was. Inaccurate representations like this contributed to the te= nsion in the meetings.

One of your criticisms of XAu= th was the use of "non standard IETF language" such as "sequ= ence" -- a term that is now used numerous times in the draft.=C2=A0

I hope you had a RESTful vacation!







On Fri, Oct 9, 2020 at 6:34 PM Kathleen Moriarty <kathleen.moriarty.= ietf@gmail.com> wrote:

My take is very different, Dick.=C2=A0 I am starting a 2 week va= cation and will not be spending it arguing with you on the list.
Multiple reviews pointed to Justin=E2=80=99s document as a = better starting point, not just mine.=C2=A0 Your use case cases can be met = and some of what you were asking for did not follow RESTful design patterns= .=C2=A0 They really don=E2=80=99t map to a future protocol well.=C2=A0 You = may need to write extension documents, but your goals can be met.

Many calls were difficult as displayed in your message.=C2= =A0 Justin did a great job handling the weekly tension and ensuring options= were included for WG discussion when agreement was not met.=C2=A0 He=E2=80= =99s completely amenable to following the WG and chairs decisions.=C2=A0 Hi= s document was also easier to follow and aligned better with numerous IETF = documents.=C2=A0 Please do keep Justin on as an editor. As you can see from= the draft, there are many areas where WG input on decision points are requ= ested.

Best regards,
Kathleen=C2=A0

Sent from my mobile device

On Oct 9, 2020, at 8:26 PM, Dick Har= dt <dick.hardt= @gmail.com> wrote:

=EF=BB=BF
Tl;dr: Given where we are in = the WG, I am not opposed to the WG adopting -14, but I propose someone othe= r than Justin be the document editor.

I was on the design team to w= ork on the goals set out by the chairs [1]:

"We expect the des= ign team to decide on a solution outline that combines the best of both pro= posals, and present this outline by Sep. 15"

Surprisingly, Kath= leen convened the design team with her recommendation to start with the XYZ= document with Justin as editor, and add in the diagrams from XAuth. The re= st of the design team had an opportunity to express their concerns and Just= in edited the document. In other words, I had to convince Justin to change = the document, rather than the design team comparing and contrasting the pro= posals and selecting the best parts. I expressed my concerns with our AD, a= nd decided to continue participating in the design team. We did make some p= rogress on a number of issues thanks to the hard work of Fabien, Justin, an= d Mike -- but many issues have been punted to the WG.

Justin has po= ured tons of energy into this project, and to his credit he was a good edit= or at times, but there are areas where he was unwilling to deviate from his= vision.

I am concerned about a repeat of what happened in OAuth 2.= 0: Erin had the pen and had strong views that often were not aligned with t= he rest of the WG. A good example was Erin's distaste for bearer tokens= . He factored that out of the core document, which we are now adding back i= n with OAuth 2.1. Anyone that participated in the WG saw the issues this ha= d.

I'm not suggesting that Justin is Erin, but I think a more ne= utral editor of the core document will allow us to make progress more quick= ly.

/Dick

[1] https://mailarchi= ve.ietf.org/arch/msg/txauth/By7tDkJBxhmHbP7vKwubC9eW38I/
3D""=E1=90=A7

On Fri, Oct 9, 2020 at 5:04 PM Justin Richer <= jricher@mit.edu>= ; wrote:
Thanks,= Kathleen, and thanks to Dick, Mike, and Fabian for all their hard work and= discussion as well. This draft contains aspects of XYZ and Xauth, and intr= oduces some new elements and pieces as well. As you'll see, there are m= any identified issues and decisions to be made, but even then I believe it = hangs together fairly cohesively already thanks to the good engineering eff= ort and discussion that's gone in so far.

Nothing in the document is final, of course. To me, this document represent= s a good starting point for working group discussion and decisions, +1 for = its adoption.

- Justin
________________________________________
From: TXAuth [= txauth-bounces@ietf.org] on behalf of Kathleen Moriarty [kathleen.moriarty.i= etf@gmail.com]
Sent: Friday, October 9, 2020 6:55 PM
To: txauth@ietf.org
Subject: [GNAP] Design team

Greetings!

The design team has now come to a close.=C2=A0 While there were too many is= sues to resolve to all design team member satisfaction, great effort was pu= t in to describe decision points for the WG to ease and hopefully speed the= working group process.=C2=A0 As such, I am requesting that the WG adopts t= his version (14 of XYZ) and works together to fully develop a single specif= ication.

https://datatracker.ietf.org/doc/d= raft-richer-transactional-authz/

A tremendous thank you to each of the design team members for your hard wor= k and walking the fine line of when to put a stake in the ground (that the = WG can always change once adopted) and listing our options for decision poi= nts to ease the WG process.

Best regards,
Kathleen

Sent from my mobile device

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000e0b29705b21d41e6-- From nobody Tue Oct 20 10:45:57 2020 Return-Path: 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 94FF03A121B for ; Tue, 20 Oct 2020 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 c2pxvA32DAdp for ; Tue, 20 Oct 2020 10:45:54 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 31E7D3A121F for ; Tue, 20 Oct 2020 10:45:54 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id i2so2960539ljg.4 for ; Tue, 20 Oct 2020 10:45:54 -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=/l2Y6ux/xM9W7+R0Sb4YQXyFmUNkXCdjHq01ZpUMYhM=; b=aH0LJoQ/lw57N/OZ8Mhnv2pbdicIzXfTVrDA1a3F3wSlqmWdmh60SmiK+hO6q+yNtm zdS7TgCARzrbZq7y8n+z+lQerVUoMb7n1lLujT5TJ7sALsUUEnaWt/AMgyqYJzOIsrV3 8MkSTqB9AihW+DoBMI8xmWdxOPpI/5XYVA8NQeoDRGcZWaZ6VMmNsxUsK1IIl7W72gMQ ea1b8CkJBz1yYxp5KZEJAJzlmFOIRR7fSFVxjmKG6RYR2zRElALXqLTGVPUvu1ycUeB8 +qnbTHvTYiifOIHvii4rwTUtRqj4R29S3QRSv9MpNDf8TIvsviMrCQ/art6nuFn5yuO3 1KFQ== 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=/l2Y6ux/xM9W7+R0Sb4YQXyFmUNkXCdjHq01ZpUMYhM=; b=Wfq5DlmVTgUrFKMu8fInRr7/CONLT6LCQSi5ktSdECShm5mdj2wiI1qw4Tjl+L9HbI SVVcxVGVaxG3u12nMkUmZXq6yWHrq5RKgL0Dij4jsIhb1+1Tq3/FdHRB1A1RmFsuVgaY +f8uzfyxlVBFjzbEUW1r2Wn5LN8BdgkySIPEhWmm0NiSZV6z09dOcH69cH01ctDHnw7o XsIUtSXR1mugjpuIS733A+lSPxfe1w5i2kzojj1K+4AN4IpoyXMixRTRDq9aKPqd+9VT AV7DipSf6TBR3seDb1r3kziBEdSUA8y3xKu5zh4bOBPHZ4D/DfzCNE5OVEIQ7zJV0n+J lkeA== X-Gm-Message-State: AOAM531I9uOu+oUoikLf3v8FDd24A021bVkAGCH+CbwY/5W+1jpeM/aE wo+9OUvSEEhcsufWL9ECyxsoWCfW83/FJYi/aocDOUL/1GM= X-Google-Smtp-Source: ABdhPJyi2nNQfJqoumth43P7YC5NNP2RIPIoxRxSqdQWfsZ4RzOiyymPcB3eFr8lwIH7B9n1sAe6+cNJhpONLI7JZ8U= X-Received: by 2002:a2e:8853:: with SMTP id z19mr1621792ljj.142.1603215952209; Tue, 20 Oct 2020 10:45:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 20 Oct 2020 10:45:15 -0700 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000546bb305b21dcd85" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 17:45:57 -0000 --000000000000546bb305b21dcd85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Responses inline with sections without comments deleted ... On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault wrote: > Hi > > Some comments marked with FI. > > Fabien > > Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt a = =C3=A9crit : > >> *Previous Feedback* >> The following items were discussed in the design team, but did not make >> it into the draft for WG discussion. A concern I have with many of the >> editor notes (which I point out) is that they are heavily biased by >> Justin's vision and misrepresent the options. >> > > FI : I'm sure we can get past hard feelings and focus on the core of the > concerns. The editor's notes do their best to point where discussion shou= ld > happen. If some of them need further clarification, we can certainly do > that. > While I am disappointed that the design team did not decide on the best features or XYZ and XAuth, and instead started with the XYZ doc, I was not trying to express any hard feelings! Reading the draft, Justin clearly has a bias to using HTTP Signing rather than a self contained JOSE token. His comments (as noted below) on 8.2 misrepresent, and do not call out the advantage over all the other mechanisms of being self contained. Except for at the bottom, these are points for discussion that I brought up in the design team that did not make it into the draft for discussion. >> *2.3.1 *Do we need to support symmetric keys? Most OAuth clients support >> a secret, not a key. >> > > FI : it's difficult to assume people with use public key cryptography for > everything. Seems to me the text is clear enough on what this implies. > We are requiring HTTPS -- so the client has support for asymmetric crypto. My point is that the editor notes should bring up this question, which I asked in the design team. > >> *2.4.1* identifying the user >> this identifier would be useful if it had properties that other opaque >> identifiers did not have: being globally unique. A reason developers hav= e >> used the email in ID Tokens was that it was a globally unique string in >> contrast to the tuple of "iss" and "sub" in the ID Token which was much >> more complicated to add and work with in a DB. Otherwise, we are creatin= g >> yet another user identifier. >> > > FI : OK but how would you make this a global identifier? Seems close to > what DIF Keri is looking for (although I find the way they're doing it is > overly/unnecessarily complex). > Lots of options. No requirement to specify how the identifier is ensured to be unique as it should be opaque to the client. It could be a URI that starts with the AS URI, or a UUID. My point is that a note on this option should be in the draft. > Would that replace sub_ids? > yes > >> *3.* The URI can be stable, and the access token is potentially >> superfluous. As the client is authenticating with the same key in all >> subsequent requests, rotation of the URI or access token may be >> superfluous. Having an access token for the AS seems that is used while >> authenticating vs the typical access token for an RS seems very confusin= g >> to a developer. >> > > FI : why would that be confusing? > Because developers don't use access tokens when accessing an OAuth AS or an OIDC OP? > >> Additionally, putting the access token for calls to the AS in the HTTP >> Authorization header precludes using the HTTP Authorization header for >> client authentication in 8. >> > > FI : that's one of the choices we need to make. But that doesn't mean wha= t > is proposed is worse, it's just a different design with different > tradeoffs. This requires a complete discussion on section 8 (which alread= y > occurred in the small group, but Justin will be able to comment). > Agreed. I had asked for this to be called out as a discussion point in the editor notes. It was not. > >> *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in >> the API between the client and the AS rather than an interaction that >> involves the user. Also, this functionality provides no protection to >> session fixation. The interaction reference has no value. >> >> *4.4.3 *While it is good to see an editor's note that a unique >> callback URL could be used, the statement "but it would not prevent an >> attacker from injecting an unrelated interaction reference into this >> channel." is misleading. This would only happen if the client did not >> ensure it is the same user, as that would be linked to the correct URL. >> Similarly, the interaction reference does not provide protection if the >> client does not ensure it is the same user. >> Using a unique callback URL would be much simpler, and appears to provid= e >> the same protection as the interaction reference and the hashing. >> > > FI : having to rely on the client only to ensure it is the same user is > precisely what you want to avoid. Hence the hashing. > The hashing does not protect against session fixation if the client does not ensure it has the same user before and after the redirect. For example, if the user has a decoupled interaction such as scanning a QR code on their PC with their phone, the client cannot ensure it is the same user coming back. An attacker can trick a user into clicking on the decoupled URL that the attacker obtained from the AS. The hashing does not protect against this. /Dick =E1=90=A7 --000000000000546bb305b21dcd85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses inline with sections without co= mments deleted ...=C2=A0

On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault <= fabien.imbault@gmail.com>= ; wrote:
Hi

Some = comments marked with FI.=C2=A0

Fabien

Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Previ= ous Feedback
The following items were discussed=C2=A0in the design= team, but did not make it into the draft for WG discussion. A concern I ha= ve=C2=A0with many of the editor notes (which I point out) is that they are = heavily biased by Justin's vision and misrepresent the options.

FI : I= 'm sure we can get past hard feelings and focus on the core of the conc= erns. The editor's notes do their best to point where discussion should= happen. If some of them need further clarification, we can certainly do th= at.=C2=A0

While I am disappoint= ed that the design team did not decide on the best features or XYZ and XAut= h, and instead started with the XYZ doc, I was not trying to express any ha= rd feelings!

Reading the draft, Justin clearly has= a bias to using HTTP Signing rather than a self contained JOSE token.
His comments (as noted below) on 8.2 misrepresent, and do not call ou= t the advantage over all the other=C2=A0mechanisms of being self contained.=

Except for at the bottom, these are points for di= scussion that I brought up in the design team that did not make it into the= draft for discussion.=C2=A0


2.3.1 Do we need to support symmetric=C2=A0k= eys? Most OAuth clients support a secret, not a key.

FI : it's d= ifficult to assume people with use public key cryptography for everything. = Seems to me the text is clear enough on what this implies.=C2=A0

We are requiring HTTPS -- so the client h= as support for asymmetric crypto. My point is that the editor notes should = bring up this question, which I asked in the design team.
=C2=A0<= /div>

2.4.1 identif= ying the user
this identifier would be useful if it had propertie= s that other opaque identifiers did not have: being globally unique. A reas= on developers have used the email in ID Tokens was that it was a globally u= nique string in contrast to the tuple of "iss" and "sub"= ; in the ID Token which was much more complicated to add and work with in a= DB. Otherwise, we are creating yet another user identifier.

FI : OK= but how would you make this a global identifier? Seems close to what DIF K= eri is looking for (although I find the way they're doing it is overly/= unnecessarily complex).

Lots o= f options. No requirement to specify how the identifier is ensured to be un= ique as it should be opaque to the client. It could be a URI that starts wi= th the AS URI, or a UUID.

My point is that a note = on this option should be in the draft.

=C2=A0
Would that replace sub_ids?=C2=A0
=
yes
=C2=A0

3. The URI can be stable, an= d the access token is potentially superfluous. As the client is authenticat= ing with the same key in all subsequent requests, rotation of the URI or ac= cess token may be superfluous. Having an access token for the AS seems that= is used while authenticating vs the typical access token for an RS seems v= ery confusing to a developer.

FI : why would that be confusing?=C2= =A0

Because developers don'= t use access tokens when accessing an OAuth AS or an OIDC OP?
=C2= =A0

Additionally, putting the access token for calls to the AS in the H= TTP Authorization header precludes using the HTTP Authorization header for = client authentication in 8.

FI : that's one of the choices we ne= ed to make. But that doesn't mean what is proposed is worse, it's j= ust a different design with different tradeoffs. This requires a complete d= iscussion on section 8 (which already occurred in the small group, but Just= in will be able to comment).=C2=A0

<= div>Agreed. I had asked for this to be called out as a discussion point in = the editor notes. It was not.
=C2=A0

4.4.2 This functi= onality looks like a WebHook, and perhaps belongs in the API between the cl= ient and the AS rather than an interaction that involves the user. Also, th= is functionality provides no protection to session fixation. The interactio= n reference has no value.

4.4.3 While it is= good to see an editor's note that=C2=A0a unique callback=C2=A0URL coul= d be used, the statement "but it would not prevent an attacker from in= jecting an unrelated interaction reference into this channel." is misl= eading. This would only happen if the client did not ensure it is the same = user, as that would be linked to the correct=C2=A0URL. Similarly, the inter= action reference does not provide protection if the client does not ensure = it is the same user.
Using a unique callback URL would be much si= mpler, and appears to provide the same protection as the interaction refere= nce and the hashing.
=
FI : having to rely on the client only to ensur= e it is the same user is precisely what you want to avoid. Hence the hashin= g.=C2=A0

The hashing does not p= rotect against session fixation if the client does not ensure it has the sa= me user before and after the redirect.
=C2=A0
For examp= le, if the user has a decoupled interaction such as scanning a QR code on t= heir PC with their phone, the client cannot ensure it is the same user comi= ng back. An attacker can trick a user into clicking on the decoupled URL th= at the attacker obtained from the AS. The hashing does not protect against = this.

/Dick
3D""=E1=90=A7
--000000000000546bb305b21dcd85-- From nobody Wed Oct 21 01:16:06 2020 Return-Path: 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 3E3A93A1323 for ; Wed, 21 Oct 2020 01:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 jXZPnzQaV-RT for ; Wed, 21 Oct 2020 01:16:01 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 B96833A1321 for ; Wed, 21 Oct 2020 01:16:01 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id a20so804121ilk.13 for ; Wed, 21 Oct 2020 01:16:01 -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=IWtz1NbUczj0mLWIihiqy7KLS5/Hl6U61hLYxZlxc4g=; b=LaCU4hC9J18uy8LAeolpPDGJ82UFMjywd9nCOX+cstQQDCZRzpqyzyn/fkHlZqZPg9 r36S8GwICWftEXcThSjzkVWSeh8n1KV+RzJjI7Rl+d4fV1jb8WsHl+SdIfBt6g/dKnYu bHqWpSdlr/M3V+qggyrRTP8HaM8vLKb/JeOq4xnvGtIhaklSqL/fi4ZMTwmOD8Jcy6bY rk/VJBagyvI3a9VSI0Eoeru3hroKLYlUkefv0oDXxczNO/w0axqt5yi3MLwzHevuy6O0 +u7RakuaDY0ValuNoVr6q1BFoFaD+ARrsJwiVav2+RAXYQvUHYPcrfhSKG7ejYc5TRNu N6gQ== 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=IWtz1NbUczj0mLWIihiqy7KLS5/Hl6U61hLYxZlxc4g=; b=Y8rXh6ALXJBfPzbYqidwzy7gFMsZzv9MRVz26QALjGeeeDabUCDG3xZ1Z2WH1hdRHe NDdm6NGKYmXYulKFOHqAzhnRs49qD6LA+TzTL8yf8TFCrWAMDGSBL3wkYswNAaT/5Zqw 80Gx0+pYDi4ga3oIPvfPvMWSMgTjcYtyqUJlnzK60ZMtKYCYotCf9BN3snZPmmWPhYaP tJ2G6yV5dhiingKOUe2e7PjT6xe38WINNDrLmscnQ2JNgGxalr/71iQzQWR+Bec0mbfY t9EZkpSpagTK8MyJCMAwINdjXPsc073+K7OJt3moTXqkHyw5sRYnIZYniErLPQKCbtT0 v6ig== X-Gm-Message-State: AOAM532JEOkYMdwNjrdoLfCpfzuRWosPNp54reSw4f/Cf3dtQxTzeC1r k5KD83s/51WFMOOapHRVwfDJHKmO0y+ShobfNm0= X-Google-Smtp-Source: ABdhPJxRNe3iJcnu8CFydY66+6apoWZguKiPnxGwcs3Ymh/ZR4zu6VP3I/VdOnh+u1NfSahXK5hg4r1izduEzsDUcXw= X-Received: by 2002:a05:6e02:501:: with SMTP id d1mr1403705ils.68.1603268160892; Wed, 21 Oct 2020 01:16:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 21 Oct 2020 10:14:55 +0200 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000035b30d05b229f52f" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 08:16:04 -0000 --00000000000035b30d05b229f52f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Dick, it clarifies a few points. In the core of your email, I focus on 2 items : sub_ids and hash. Beyond that we will also need a further description of the possibilities/tradeoffs in section 8, to clarify for everyone (not included here, but will be useful). There are quite a few places where practical implementations could help us decide, beyond theorical arguments. Fabien Le mar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt a =C3= =A9crit : > Responses inline with sections without comments deleted ... > > On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault > wrote: > >> Hi >> >> Some comments marked with FI. >> >> Fabien >> >> Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt a = =C3=A9crit : >> >>> *Previous Feedback* >>> The following items were discussed in the design team, but did not make >>> it into the draft for WG discussion. A concern I have with many of the >>> editor notes (which I point out) is that they are heavily biased by >>> Justin's vision and misrepresent the options. >>> >> >> FI : I'm sure we can get past hard feelings and focus on the core of the >> concerns. The editor's notes do their best to point where discussion sho= uld >> happen. If some of them need further clarification, we can certainly do >> that. >> > > While I am disappointed that the design team did not decide on the best > features or XYZ and XAuth, and instead started with the XYZ doc, I was no= t > trying to express any hard feelings! > > Reading the draft, Justin clearly has a bias to using HTTP Signing rather > than a self contained JOSE token. > His comments (as noted below) on 8.2 misrepresent, and do not call out th= e > advantage over all the other mechanisms of being self contained. > > Except for at the bottom, these are points for discussion that I brought > up in the design team that did not make it into the draft for discussion. > > >>> *2.3.1 *Do we need to support symmetric keys? Most OAuth clients >>> support a secret, not a key. >>> >> >> FI : it's difficult to assume people with use public key cryptography fo= r >> everything. Seems to me the text is clear enough on what this implies. >> > > We are requiring HTTPS -- so the client has support for asymmetric crypto= . > My point is that the editor notes should bring up this question, which I > asked in the design team. > > >> >>> *2.4.1* identifying the user >>> this identifier would be useful if it had properties that other opaque >>> identifiers did not have: being globally unique. A reason developers ha= ve >>> used the email in ID Tokens was that it was a globally unique string in >>> contrast to the tuple of "iss" and "sub" in the ID Token which was much >>> more complicated to add and work with in a DB. Otherwise, we are creati= ng >>> yet another user identifier. >>> >> >> FI : OK but how would you make this a global identifier? Seems close to >> what DIF Keri is looking for (although I find the way they're doing it i= s >> overly/unnecessarily complex). >> > > Lots of options. No requirement to specify how the identifier is ensured > to be unique as it should be opaque to the client. It could be a URI that > starts with the AS URI, or a UUID. > > My point is that a note on this option should be in the draft. > FI : so the minimal requirement on which we agree is to have an opaque identifier. So typically this would be unique for the AS and transmitted through a user_handle (already in the spec). The client could make its own local mapping if it already knows something about the user. To know more about the user, it is possible to : - use a verifiable identity layer such as OIDC or equivalent - (TBD) use sub_ids, based on the information already locally available at the AS (with the limitations mentioned previously) ; or maybe we could use an alternative/complementary design. For instance a more explicit json on what is transmitted, or carry a correlation ID given by the client, or etc. > > >> Would that replace sub_ids? >> > > yes > > >> >>> *3.* The URI can be stable, and the access token is potentially >>> superfluous. As the client is authenticating with the same key in all >>> subsequent requests, rotation of the URI or access token may be >>> superfluous. Having an access token for the AS seems that is used while >>> authenticating vs the typical access token for an RS seems very confusi= ng >>> to a developer. >>> >> >> FI : why would that be confusing? >> > > Because developers don't use access tokens when accessing an OAuth AS or > an OIDC OP? > > >> >>> Additionally, putting the access token for calls to the AS in the HTTP >>> Authorization header precludes using the HTTP Authorization header for >>> client authentication in 8. >>> >> >> FI : that's one of the choices we need to make. But that doesn't mean >> what is proposed is worse, it's just a different design with different >> tradeoffs. This requires a complete discussion on section 8 (which alrea= dy >> occurred in the small group, but Justin will be able to comment). >> > > Agreed. I had asked for this to be called out as a discussion point in th= e > editor notes. It was not. > > >> >>> *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in >>> the API between the client and the AS rather than an interaction that >>> involves the user. Also, this functionality provides no protection to >>> session fixation. The interaction reference has no value. >>> >>> *4.4.3 *While it is good to see an editor's note that a unique >>> callback URL could be used, the statement "but it would not prevent an >>> attacker from injecting an unrelated interaction reference into this >>> channel." is misleading. This would only happen if the client did not >>> ensure it is the same user, as that would be linked to the correct URL. >>> Similarly, the interaction reference does not provide protection if the >>> client does not ensure it is the same user. >>> Using a unique callback URL would be much simpler, and appears to >>> provide the same protection as the interaction reference and the hashin= g. >>> >> >> FI : having to rely on the client only to ensure it is the same user is >> precisely what you want to avoid. Hence the hashing. >> > > The hashing does not protect against session fixation if the client does > not ensure it has the same user before and after the redirect. > > For example, if the user has a decoupled interaction such as scanning a Q= R > code on their PC with their phone, the client cannot ensure it is the sam= e > user coming back. An attacker can trick a user into clicking on the > decoupled URL that the attacker obtained from the AS. The hashing does no= t > protect against this. > FI : good point. We certainly need to handle that case correctly. We should note that to make sure we don't forget. That said, this comes as an additional requirement for some decoupled interaction modes, not as a replacement of the entire scheme. > > /Dick > =E1=90=A7 > --00000000000035b30d05b229f52f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Dick, it clarifies a few points. In the core = of your email, I focus on 2 items : sub_ids and hash.=C2=A0

Beyond that we will also need a furth= er description of the possibilities/tradeoffs in section 8, to clarify for = everyone (not included here, but will be useful).=C2=A0

There are quite a few places where practica= l implementations could help us decide, beyond theorical arguments.=C2=A0

Fabien=C2=A0

Le mar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt <dick.= hardt@gmail.com> a =C3=A9crit=C2=A0:
Responses inline with sections w= ithout comments deleted ...=C2=A0

On Tue, Oct 20, 2020 at 2:40 AM Fabien Imb= ault <fabien.imbault@gmail.com> wrote:
=
Hi=

Some comments marked wi= th FI.=C2=A0

Fabien
<= br>
Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
P= revious Feedback
The following items were discussed=C2=A0in the de= sign team, but did not make it into the draft for WG discussion. A concern = I have=C2=A0with many of the editor notes (which I point out) is that they = are heavily biased by Justin's vision and misrepresent the options.

FI= : I'm sure we can get past hard feelings and focus on the core of the = concerns. The editor's notes do their best to point where discussion sh= ould happen. If some of them need further clarification, we can certainly d= o that.=C2=A0

While I am disapp= ointed that the design team did not decide on the best features or XYZ and = XAuth, and instead started with the XYZ doc, I was not trying to express an= y hard feelings!

Reading the draft, Justin clearly= has a bias to using HTTP Signing rather than a self contained JOSE token.<= /div>
His comments (as noted below) on 8.2 misrepresent, and do not cal= l out the advantage over all the other=C2=A0mechanisms of being self contai= ned.

Except for at the bottom, these are points fo= r discussion that I brought up in the design team that did not make it into= the draft for discussion.=C2=A0


2.3.1 Do we need to support symmetric= =C2=A0keys? Most OAuth clients support a secret, not a key.

FI : it&= #39;s difficult to assume people with use public key cryptography for every= thing. Seems to me the text is clear enough on what this implies.=C2=A0

We are requiring HTTPS -- so the c= lient has support for asymmetric crypto. My point is that the editor notes = should bring up this question, which I asked in the design team.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=
2.4.1 identifying the user
this identifier woul= d be useful if it had properties that other opaque identifiers did not have= : being globally unique. A reason developers have used the email in ID Toke= ns was that it was a globally unique string in contrast to the tuple of &qu= ot;iss" and "sub" in the ID Token which was much more compli= cated to add and work with in a DB. Otherwise, we are creating yet another = user identifier.

=
FI : OK but how would you make this a global identi= fier? Seems close to what DIF Keri is looking for (although I find the way = they're doing it is overly/unnecessarily complex).

Lots of options. No requirement to specify how the= identifier is ensured to be unique as it should be opaque to the client. I= t could be a URI that starts with the AS URI, or a UUID.

My point is that a note on this option should be in the draft.
=

FI : so the minimal requirement on which we agree is to have an o= paque identifier. So typically this would be unique for the AS and transmit= ted through a user_handle (already in the spec). The client could make its = own local mapping if it already knows something about the user.=C2=A0
=

To know more about the user, = it is possible to :
- use a verifiable identity laye= r such as OIDC or equivalent=C2=A0
- (TBD) use sub_i= ds, based on the information already locally available at the AS (with the = limitations mentioned previously) ; or maybe we could use an alternative/co= mplementary design. For instance a more explicit json on what is transmitte= d, or carry a correlation ID given by the client, or etc.=C2=A0



=C2=A0
Would that replace sub_ids?=C2=A0

<= div>yes
=C2=A0

3. The URI can be stable, and the acces= s token is potentially superfluous. As the client is authenticating with th= e same key in all subsequent requests, rotation of the URI or access token = may be superfluous. Having an access token for the AS seems that is used wh= ile authenticating vs the typical access token for an RS seems very confusi= ng to a developer.
FI : why would that be confusing?=C2=A0

Because developers don't use access = tokens when accessing an OAuth AS or an OIDC OP?
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div>=C2=A0

Additionally, putting the access token for calls to the AS = in the HTTP Authorization header precludes using the HTTP Authorization hea= der for client authentication in 8.

FI : that's one of the choic= es we need to make. But that doesn't mean what is proposed is worse, it= 's just a different design with different tradeoffs. This requires a co= mplete discussion on section 8 (which already occurred in the small group, = but Justin will be able to comment).=C2=A0
Agreed. I had asked for this to be called out as a discussion p= oint in the editor notes. It was not.
=C2=A0

4.4.2 Thi= s functionality looks like a WebHook, and perhaps belongs in the API betwee= n the client and the AS rather than an interaction that involves the user. = Also, this functionality provides no protection to session fixation. The in= teraction reference has no value.

4.4.3 Whi= le it is good to see an editor's note that=C2=A0a unique callback=C2=A0= URL could be used, the statement "but it would not prevent an attacker= from injecting an unrelated interaction reference into this channel."= is misleading. This would only happen if the client did not ensure it is t= he same user, as that would be linked to the correct=C2=A0URL. Similarly, t= he interaction reference does not provide protection if the client does not= ensure it is the same user.
Using a unique callback URL would be= much simpler, and appears to provide the same protection as the interactio= n reference and the hashing.

FI : having to rely on the client onl= y to ensure it is the same user is precisely what you want to avoid. Hence = the hashing.=C2=A0

The hashing = does not protect against session fixation if the client does not ensure it = has the same user before and after the redirect.
=C2=A0
For example, if the user has a decoupled interaction such as scanning a QR= code on their PC with their phone, the client cannot ensure it is the same= user coming back. An attacker can trick a user into clicking on the decoup= led URL that the attacker obtained from the AS. The hashing does not protec= t against this.

FI : good point. We certainly need to handle t= hat case correctly. We should note that to make sure we don't forget.= =C2=A0
That said, this comes as an additional requir= ement for some decoupled interaction modes, not as a replacement of the ent= ire scheme.=C2=A0

/Dick
3D""=E1=90=A7<= /div>
--00000000000035b30d05b229f52f-- From nobody Wed Oct 21 08:58:06 2020 Return-Path: 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 415573A0FF9 for ; Wed, 21 Oct 2020 08:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999, URIBL_BLOCKED=0.001] 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 OPVnn-Ay3ENr for ; Wed, 21 Oct 2020 08:58:02 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32A83A003E for ; Wed, 21 Oct 2020 08:58:01 -0700 (PDT) Received: from [192.168.1.11] ([90.91.133.250]) by mwinf5d46 with ME id ifxy2300J5QJY7u03fxyXl; Wed, 21 Oct 2020 17:58:00 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 21 Oct 2020 17:58:00 +0200 X-ME-IP: 90.91.133.250 To: GNAP Mailing List From: Denis Message-ID: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> Date: Wed, 21 Oct 2020 17:57:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------70DC22E8B52BE3BBB164C940" Content-Language: en-GB Archived-At: Subject: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 15:58:05 -0000 This is a multi-part message in MIME format. --------------70DC22E8B52BE3BBB164C940 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I haven't read all the document in details, but I have browsed through it: this took me about 3 hours. As it is, I don't consider that the current text (more than 100 pages !) is a "good starting point". The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options (without indicating which parameters are required and which ones are optional) that it will be impossible to claim that an implementation complies with it. In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team. Here are some comments: 1.An overview is missing since the various features are only being discovered while reading the document. 2.A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ? 3.The whole document is "AS centric" while it should also be "RS centric". These two concepts have been explained on the mailing list. 4.The document only speaks about "_the_ AS", as if only one AS would exist which is obviously not the case.     The first access made to a RS shall be able to identify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able     to indicate which access rights are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate     which attributes or access rights are needed to perform each subsequent operation. 5."API’s documentation" versus "API discovery". Whereas the API’s documentation is static and not necessarily up to date or the RC software     is not necessarily up to date, API discovery provides real time information which is necessarily up to date. There should be an API discovery mechanism for RSs.     Using an appropriate HTTP OPTIONS request, the RC should be able to query the RS in order to know /at any point of time/: * the operations that can be done (i.e. which methods are available on which data objects), and * the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values) or in terms of capabilities (i.e. permissions granted). 6.The "user consent" phase has been ignored. It should be done at the RS. Using information obtained from a RS, a RC should be able     to select which AS it wants to contact and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase     is not done at the RS, it shall be done at the AS. 7.The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.     This is a matter of confidence to make sure for the RC (and for the user) that no "extra" information has been included by the AS into the access token. 8."Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The RO is associated with a RS, not with an AS.     The RS can know in advance with attributes or access rights are needed to grant a given operation. 9.The model should allow the use of both Access Control Lists and of Capabilities Lists. * Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation. * Capabilities lists contains operations granted on services within a RC. As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.     Whereas identifiers of users and/or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,     this is not the case for capabilities where a RO associated with a RS needs to interact with the AS either in advance or in real time     (which makes such mechanism much more complex). 10.In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier      of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list. 11.The text states: "Authorization Server (AS)Manages the requested delegations for the RO". This is only one of two possibilities.      The interaction between a RO and an AS should be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably       interact with the RS only. 12.The text states: "ResourceA protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process". The second part of the sentence should be deleted since a RO is not necessarily involved in the grant process. 13.The text states: "Resource Client (RC, aka "client")Requests tokens from the AS and uses tokens at the RS.       An instance of the RC software is identified by its key, which can be known to the AS prior to the first request". This is confusing. The key does not necessarily identify an instance of the RC software.       An instance of the RC software uses a binding key which (for privacy reasons) should be dynamic but which may alternatively be static. 14.For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided. 15.Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.       Hereafter are only some (of many) concerns about the current text. The most important is to identify which parameters shall be used       and may be used when making a call to get an access token.      The text states: "resourcesDescribes the rights that the RC is requesting for one or more access tokens to be used at RS’s.      Section 2.1". Then after: "Each object contains a "type" property that determines the type of API that the RC is calling. (...)The value of this field is under the control of the AS. The value of this field should not be under the control of the AS but of the RS. The text states: "actionsThe types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed      for the other cases. Revealing actions to an AS is against the user's privacy.      The text states: "locationsThe location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS." It is typically URLs (not URIs) but it may also be /service names/ so that an access token can be delegated by a first RS to a second RS      belonging to the same service without the need for the first RS to request another access token. Denis --------------70DC22E8B52BE3BBB164C940 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I haven't read all the document in details, but I have browsed through it: this took me about 3 hours.
As it is, I don't consider that the current text (more than 100 pages !) is a "good starting point".

The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options
(without indicating which parameters are required and which ones are optional) that it will be impossible to claim that
an implementation complies with it.

In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team.

Here are some comments:

1. An overview is missing since the various features are only being discovered while reading the document.

2. A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ?

3. The whole document is "AS centric" while it should also be "RS centric". These two concepts have been explained on the mailing list.

4. The document only speaks about "the AS", as if only one AS would exist which is obviously not the case.
    The first access made to a RS shall be able to identify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able
    to indicate which access rights are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate
    which attributes or access rights are needed to perform each subsequent operation.

5. "API’s documentation" versus "API discovery". Whereas the API’s documentation is static and not necessarily up to date or the RC software
    is not necessarily up to date, API discovery provides real time information which is necessarily up to date.

    There should be an API discovery mechanism for RSs.

    Using an appropriate HTTP OPTIONS request, the RC should be able to query the RS in order to know at any point of time:

  • the operations that can be done (i.e. which methods are available on which data objects), and
  • the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS
    and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted).

6. The "user consent" phase has been ignored. It should be done at the RS. Using information obtained from a RS, a RC should be able
    to select which AS it wants to contact and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase
    is not done at the RS, it shall be done at the AS.

7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
    This is a matter of confidence to make sure for the RC (and for the user) that no "extra" information has been included by the AS into the access token.

8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The RO is associated with a RS, not with an AS.
    The RS can know in advance with attributes or access rights are needed to grant a given operation.

9. The model should allow the use of both Access Control Lists and of Capabilities Lists.

  • Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation.
  • Capabilities lists contains operations granted on services within a RC.

     As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.
    Whereas identifiers of users and/or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,
    this is not the case for capabilities where a RO associated with a RS needs to interact with the AS either in advance or in real time
    (which makes such mechanism much more complex).

10. In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier
     of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list.

11. The text states: "Authorization Server (AS)  Manages the requested delegations for the RO". This is only one of two possibilities.
     The interaction between a RO and an AS should be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably
      interact with the RS only.

12. The text states: "Resource  A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process".
      The second part of the sentence should be deleted since a RO is not necessarily involved in the grant process.

13. The text states: "Resource Client (RC, aka "client")  Requests tokens from the AS and uses tokens at the RS. 
      An instance of the RC software is identified by its key, which can be known to the AS prior to the first request".

      This is confusing. The key does not necessarily identify an instance of the RC software.
      An instance of the RC software uses a binding key which (for privacy reasons) should be dynamic but which may alternatively be static.

14. For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided.

15. Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.
      Hereafter are only some (of many) concerns about the current text. The most important is to identify which parameters shall be used
      and may be used when making a call to get an access token.

     The text states: "resources  Describes the rights that the RC is requesting for one or more access tokens to be used at RS’s.
     Section 2.1". Then after: "Each object contains a "type" property that determines the type of API that the RC is calling.
      (...)  The value of this field is under the control of the AS.

     The value of this field should not be under the control of the AS but of the RS.

     The text states: "actions  The types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed
     for the other cases. Revealing actions to an AS is against the user's privacy.

     The text states: "locations  The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS."

     It is typically URLs (not URIs) but it may also be service names so that an access token can be delegated by a first RS to a second RS
     belonging to the same service without the need for the first RS to request another access token.

Denis

--------------70DC22E8B52BE3BBB164C940-- From nobody Wed Oct 21 10:20:42 2020 Return-Path: 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 A21E93A1338 for ; Wed, 21 Oct 2020 10:20: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 vEgSMlQMn02m for ; Wed, 21 Oct 2020 10:20:39 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 4BF213A1281 for ; Wed, 21 Oct 2020 10:20:31 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id b8so3952619ioh.11 for ; Wed, 21 Oct 2020 10:20:31 -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=yReML8uhSRiRf4QIW4qXmPe7dCqfu9lRfknxFxYyyNk=; b=kTUaazaELXF1k+X4zrIm7SNsnA5qF61flxWQ5EsRUX9HWUFKl5dcX9suWcsqraAJsj NDQowwFbc0NxzxUPdPFuvsfus0xlD/PLwEgf6RMb0E+wjvdgu8kBcTAeMFcEx/8QGyAV 83L9vYnmosTL+Js62Febq7u3jI/CzxJ4gPfRe/1zKTLrIvI2a5NEthC8HHjFqQURNLpZ JU/Zo+EViWLt6nRAs39PFeGNY3y93uwsoFEBsHhXd8/ubOTmuD7Vp+yEhZZSA4iXoSvl 1jjDdGgkxQKBacudpjmiKXe3H4H5scnNhTSdDSeJjid9TpVDO+Dq/2TTY2AQXHa8Ut17 cI5w== 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=yReML8uhSRiRf4QIW4qXmPe7dCqfu9lRfknxFxYyyNk=; b=ihrvUiXvqqqzyze+ZPo1VyiDAa774JvlU4DNPCOWYHFD6R/zsOM4MMKEiOHGUG7Wma BKuR8Hs0jLDcj/iWBbP6vZYYmi8Mh+Uy49Z8y9Et8X0JwcHN/7LqT8Cz2uenIWc457LM sidwLFDYWkx2pVDk0BcfnPtWeJRT03jNx7kZXTe1PSTvISRTKPQzl1Ge0mTVujxaLxcv nv1mxIqcpINU266OCUj0i6Bk5pjst//Ia5ishWtnlU3xkmf+0uLidAtjtvrOAG0X9jQS YUnjWc2BC9bLIGzvs2+1p9KjaSuEOWSa1kYGQ3FW+KdJ/NfMdoLf3fbc+cfLpXZFgkAE +pNw== X-Gm-Message-State: AOAM532QKKR/j+QgN/2Ih5NplgjsQfLOPPB9Te5VVjwjfTMrtVwaB+hy qllHN2KrASWCoEAO6wuojJIAWE06GHnso11lZZI= X-Google-Smtp-Source: ABdhPJzsnYuswQCVw0BV5dsDnzdzug9Jzl47dyxW3RzVT6jlqw+Gxdk2Ish7IbmSqRPu6Q1mvcFrjLjkgQ0hb6AOXK8= X-Received: by 2002:a6b:bad5:: with SMTP id k204mr3558058iof.144.1603300830367; Wed, 21 Oct 2020 10:20:30 -0700 (PDT) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> In-Reply-To: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> From: Fabien Imbault Date: Wed, 21 Oct 2020 19:20:18 +0200 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000076575305b23190a3" Archived-At: Subject: Re: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:20:42 -0000 --00000000000076575305b23190a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, The "many options" is only a temporary state, the goal was to expose the decisions that need to be made to the mailing list. We can quickly reduce to a manageable level by having focused discussions. As for the remainder of your comments, the only item we considered so far was one of principle: that privacy is an important goal of the work. The rest of the focus was on taking the best out of XYZ and XAuth. So incorporating the discussions that occurred just before the focus group wasn't a goal. You can already see that with regards to terminology, where insightful discussions occurred but the paint was really very fresh. I find what you explain really interesting. It will need to be analyzed in detail. The caveat is that we have less background experience of what it means in practice (compared to the current document vs OAuth2). I guess it will require a bit of experimentation, to avoid corner cases. More specific comments/questions coming later :-) Fabien Le mer. 21 oct. 2020 =C3=A0 17:58, Denis a =C3=A9crit = : > Hi, > > I haven't read all the document in details, but I have browsed through it= : > this took me about 3 hours. > As it is, I don't consider that the current text (more than 100 pages !) > is a "good starting point". > > The less that I can say is that the document is far from being crystal > clear, is too complex and includes so many options > (without indicating which parameters are required and which ones are > optional) that it will be impossible to claim that > an implementation complies with it. > > In addition, it is unfortunate that many of the discussions we have had o= n > the mailing list have not been incorporated by the design team. > > Here are some comments: > > 1. An overview is missing since the various features are only being > discovered while reading the document. > > 2. A key question that might interest a reader is the following: what are > the common points and the main differences with OAuth ? > > 3. The whole document is "AS centric" while it should also be "RS > centric". These two concepts have been explained on the mailing list. > > 4. The document only speaks about "*the* AS", as if only one AS would > exist which is obviously not the case. > The first access made to a RS shall be able to identify which ASs are > trusted by the RS. In addition, for each trusted AS, the RS should be abl= e > to indicate which access rights are needed to perform every operation > possible at that stage. For any subsequent stage, the RS may also indicat= e > which attributes or access rights are needed to perform each > subsequent operation. > > 5. "API=E2=80=99s documentation" versus "API discovery". Whereas the API= =E2=80=99s > documentation is static and not necessarily up to date or the RC software > is not necessarily up to date, API discovery provides real time > information which is necessarily up to date. > > There should be an API discovery mechanism for RSs. > > Using an appropriate HTTP OPTIONS request, the RC should be able to > query the RS in order to know *at any point of time*: > > > - the operations that can be done (i.e. which methods are available on > which data objects), and > - the access control characteristics associated with each of these > operations (i.e. which ASs are being trusted by the RS > and what should be the incorporated into access token(s) in terms of > attributes types (and optionally attribute values) > or in terms of capabilities (i.e. permissions granted). > > 6. The "user consent" phase has been ignored. It should be done at the > RS. Using information obtained from a RS, a RC should be able > to select which AS it wants to contact and explicitly agree to reques= t > the mentioned attributes to that AS. Alternatively, when the user consent > phase > is not done at the RS, it shall be done at the AS. > > 7. The content and the format of access tokens shall not be considered to > be opaque to the RC so that the RC can inspect it. > This is a matter of confidence to make sure for the RC (and for the > user) that no "extra" information has been included by the AS into the > access token. > > 8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", > full stop. The RO is associated with a RS, not with an AS. > The RS can know in advance with attributes or access rights are neede= d > to grant a given operation. > > 9. The model should allow the use of both Access Control Lists and of > Capabilities Lists. > > > - Access control lists contain identifiers of users and/or identifiers > of users groups or identity claims in relationship with an operation. > - Capabilities lists contains operations granted on services within a > RC. > > As a consequence, access tokens may contain identifiers of users > and/or identity claims and/or identifiers of users groups and/or > capabilities. > Whereas identifiers of users and/or identifiers of users groups and/o= r > identity claims may be managed by an AS independently from RSs, > this is not the case for capabilities where a RO associated with a RS > needs to interact with the AS either in advance or in real time > (which makes such mechanism much more complex). > > 10. In the case where access control lists are being used, there should > be a possibility for a RC, for privacy reasons, to hide the identifier > of the RS to the AS (usually a URL) when requesting an access token. > A method able to support such feature has been discussed extensively on t= he > mailing list. > > 11. The text states: "Authorization Server (AS) Manages the requested > delegations for the RO". This is only one of two possibilities. > The interaction between a RO and an AS should be considered as an > option. If a RO needs to interact, for privacy reasons, it should > preferably > interact with the RS only. > > 12. The text states: "Resource A protected API served by the RS and > accessed by the RC. Access to this resource is delegated by the RO as par= t > of the grant process". > The second part of the sentence should be deleted since a RO is not > necessarily involved in the grant process. > > 13. The text states: "Resource Client (RC, aka "client") Requests tokens > from the AS and uses tokens at the RS. > An instance of the RC software is identified by its key, which can > be known to the AS prior to the first request". > > This is confusing. The key does not necessarily identify an instanc= e > of the RC software. > An instance of the RC software uses a binding key which (for privac= y > reasons) should be dynamic but which may alternatively be static. > > 14. For privacy reasons, calls from an RS to an AS, such as token > introspection, should be avoided. > > 15. Section 2 deals with the parameters when making calls from a RC to an > AS. This section would need to be revisited. > Hereafter are only some (of many) concerns about the current text. > The most important is to identify which parameters shall be used > and may be used when making a call to get an access token. > > The text states: "resources Describes the rights that the RC is > requesting for one or more access tokens to be used at RS=E2=80=99s. > Section 2.1". Then after: "Each object contains a "type" property > that determines the type of API that the RC is calling. > (...) The value of this field is under the control of the AS. > > The value of this field should not be under the control of the AS bu= t > of the RS. > > The text states: "actions The types of actions the RC will take at > the RS". This is needed when capabilities are being used but not needed > for the other cases. Revealing actions to an AS is against the user'= s > privacy. > > The text states: "locations The location of the RS as an array of > strings. These strings are typically URIs identifying the location of the > RS." > > It is typically URLs (not URIs) but it may also be *service names* > so that an access token can be delegated by a first RS to a second RS > belonging to the same service without the need for the first RS to > request another access token. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000076575305b23190a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,

The "many options" is only a temporary state, the= goal was to expose the decisions that need to be made to the mailing list.= We can quickly reduce to a manageable level by having focused discussions.=

As for the remainder of= your comments, the only item we considered so far was one of principle: th= at privacy is an important goal of the work. The rest of the focus was on t= aking the best out of XYZ and XAuth. So incorporating the discussions that = occurred just before the focus group wasn't a goal. You can already see= that with regards to terminology, where insightful discussions occurred bu= t the paint was really very fresh.=C2=A0

<= div dir=3D"auto">I find what you explain really interesting. It will need t= o be analyzed in detail. The caveat is that we have less background experie= nce of what it means in practice (compared to the current document vs OAuth= 2). I guess it will require a bit of experimentation, to avoid corner cases= .

More specific comments= /questions coming later :-)=C2=A0

Fabien=C2=A0


Le mer= . 21 oct. 2020 =C3=A0 17:58, Denis <denis.ietf@free.fr> a =C3=A9c= rit=C2=A0:
=20 =20 =20

Hi,

I haven't read all the document in details, but I have browsed through it: this took me about 3 hours.
As it is, I don't consider that the current text (more than 100 pages !) is a "good starting point".

The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options
(without indicating which parameters are required and which ones are optional) that it will be impossible to claim that
an implementation complies with it.

In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team.

Here are some comments:

1. An overview is missing since the various features are only being discovered while reading the document.

2. A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ?

3. The whole document is "AS centric" while it should also b= e "RS centric". These two concepts have been explained on the mailing list.

4. The document only speaks about "the AS", as if only one AS would exist whic= h is obviously not the case.
=C2=A0=C2=A0=C2=A0 The first access made to a RS shall be able to i= dentify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able
=C2=A0=C2=A0=C2=A0 to indicate which access rights are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate
=C2=A0 =C2=A0 which attributes or access rights are needed to perform each subsequent operation.

5. "API=E2=80=99s documentation" versus "API discovery". Whereas the API=E2=80=99s documen= tation is static and not necessarily up to date or the RC software
=C2=A0=C2=A0=C2=A0 is not necessarily up to date, API discovery pro= vides real time information which is necessarily up to date.

=C2=A0=C2=A0=C2=A0 There should be an API discovery mechanism for RSs. =

=C2=A0=C2=A0=C2=A0 Using an appropriate HTTP OPTIONS request, the R= C should be able to query the RS in order to know at any point of time:

  • the operations that can be done (i.e. which methods are available on which data objects), and
  • the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS
    and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted).    <= /li>

6. The "user consent" phase has been ignored. It should be done at the RS. Using information obtained from a RS, a RC should be able
=C2=A0 =C2=A0 to select which AS it wants to contact and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase
=C2=A0 =C2=A0 is not done at the RS, it shall be done at the AS.
7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter of confidence to make sure for = the RC (and for the user) that no "extra" information has been included b= y the AS into the access token.

8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The = RO is associated with a RS, not with an AS.
=C2=A0=C2=A0=C2=A0 The RS can know in advance with attributes or access rights are needed to grant a given operation.

9. The model should allow the use of both Access Control Lists and of Capabilities Lists.

  • Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation.
  • Capabilities lists contains operations granted on services within a RC.

=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.
=C2=A0=C2=A0=C2=A0 Whereas identifiers of users and/or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,
=C2=A0=C2=A0=C2=A0 this is not the case for capabilities where a RO associated with a RS needs to interact with the AS either in advance or in real time
=C2=A0=C2=A0=C2=A0 (which makes such mechanism much more complex). =

10. In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier
=C2=A0=C2=A0=C2=A0=C2=A0 of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list.

11. The text states: "Authorization Server (AS)=C2=A0 Manages the requested delegations for the RO". This is only one of two possibilities.
=C2=A0=C2=A0=C2=A0=C2=A0 The interaction between a RO and an AS sho= uld be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interact with the RS only.

12. The text states: "Resource=C2=A0 A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process".
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The second part of the sentence should be deleted since a RO is not necessarily involved in the grant process.

13. The text states: "Resource Client (RC, aka "client")=C2=A0 Requests tokens from the AS and uses tokens at the RS.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the RC software is id= entified by its key, which can be known to the AS prior to the first request".

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is confusing. The key does not necessarily identify an instance of the RC software.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the RC software uses = a binding key which (for privacy reasons) should be dynamic but which may alternatively be static.

14. For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided.

15. Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hereafter are only some (of many) co= ncerns about the current text. The most important is to identify which parameters shall be used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and may be used when making a call to get an access token.

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "resour= ces=C2=A0 Describes the rights that the RC is requesting for one or more access tokens to be used at RS=E2=80=99s= .
=C2=A0=C2=A0=C2=A0=C2=A0 Section 2.1". Then after: "Each object contains a "type" property = that determines the type of API that the RC is calling.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (...)=C2=A0 The value of this field is under the control of the AS.

=C2=A0=C2=A0=C2=A0=C2=A0 The value of this field should not be under the control of the AS but of the RS.

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "actions=C2=A0 The types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed
=C2=A0=C2=A0=C2=A0=C2=A0 for the other cases. Revealing actions to an AS is against the user's privacy.

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "locations=C2= =A0 The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS."

=C2=A0=C2=A0=C2=A0=C2=A0 It is typically URLs (not URIs) but it may also be service names so that an access token can be delegated by a first RS to a second RS
=C2=A0=C2=A0=C2=A0=C2=A0 belonging to the same service without the need for the first RS to request another access token.

Denis

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--00000000000076575305b23190a3-- From nobody Wed Oct 21 10:36:34 2020 Return-Path: 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 725E83A13C7 for ; Wed, 21 Oct 2020 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 1pqNRXL_k8Fo for ; Wed, 21 Oct 2020 10:36:30 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 A19443A13C5 for ; Wed, 21 Oct 2020 10:36:29 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id l2so4223233lfk.0 for ; Wed, 21 Oct 2020 10:36:29 -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=Ak7RfcCsRlMCHwzT2X/Q0XHjNmP7KYYfrEELAos2DQs=; b=flDkXMT9YyhXTq7WTSN7jXdCIHSdHMVHwUdt1/nYUO/ja0gQo6HHXNysXaqMYb5bmt Gf2Ta6wSRzZOuowRiE7mZrjwgsR6jxpAtJhVcuZAYztvZPyU/XKTLifxqzXyIxbZcWB5 dYylCKaNNfhVty3NtMP8ze+bfRgtOHVt5iCrziuhO7+XM/ck1Ax7udz/dZ5m+vmJsR1k 9pD2x7rtTCfvRnlNl9wJm2l7Klj4pSYqXgbPP+dM0VP3T3zz+W4RJ8uNqWuVjli4zQbr h7/Sgq+W5f2ixslnViesTi7omct3R/du42U8pCuAShArdAzf8R4KZ5VWeqCEswfDxlge 5/ag== 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=Ak7RfcCsRlMCHwzT2X/Q0XHjNmP7KYYfrEELAos2DQs=; b=EqXHR9WejR92Et26fogA6b/JeAE7QUApqMZZjJWaznZ4ADdzm8MTYQ4TwlJYofXvEp 82Wut0iaPB8i6czMwEHoBe/nR0N4JfT3m1wqFkERt+rg1IO8nVFcaTyCoQ3PWUp0tqp9 6rKi2WDUsRJs/ab4N4RZab4J4HbCLG4f5kGsNFyLwvMn89sNxTfsunBi8rgZrhow3fTc QnkQWO1ZM8qKXM18xI3WbrjtCAvZjLXCS+AF5jeYSp+X6NNdehs3vDYlJ0dEA5kneW4/ j3Ua+JgNaS0XItVhiZqyftwBTO8PYiZ17HXeQptWsaexF6wmQuAHREi8c9WhVyVXOeKe KUIg== X-Gm-Message-State: AOAM530T06oub02NSvNb3nfn7AZ3DIOH9R5c9go6Gdp/sbbWSm+QjqmB gm0/ODo/nWaB0R9en5TMowvKTj7mopNEtsNoUjo= X-Google-Smtp-Source: ABdhPJxYkqYq/tPAbdQ8eFMtQ/dQaAfglMxhAiDSAZm62Wib4wclLLXp52Kj7orcytijSPIFfjdKXppWBo7BafZJakg= X-Received: by 2002:a05:6512:68a:: with SMTP id t10mr1554441lfe.221.1603301787622; Wed, 21 Oct 2020 10:36:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 21 Oct 2020 10:35:51 -0700 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000084e25e05b231c95b" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:36:32 -0000 --00000000000084e25e05b231c95b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien There *could* be value in GNAP creating yet-another-user-identifier if the identifier was guaranteed to be globally unique -- a property not held by "sub" in an ID Token. Using the SecEvent subject identifier draft for a client to share which user the client *thinks* it has is useful -- that is what the draft was intended for. In my opinion, querying for identifiers independent of what is already defined in OpenID and other standards is a path for developer misery. I don't think the hash provides any extra value if the redirect URL provided by the client to the AS is unique to the transaction. It has no value in a push back to the client, or a decoupled interaction -- both of which are susceptible to session fixation / phishing attacks. =E1=90=A7 On Wed, Oct 21, 2020 at 1:16 AM Fabien Imbault wrote: > Thanks Dick, it clarifies a few points. In the core of your email, I focu= s > on 2 items : sub_ids and hash. > > Beyond that we will also need a further description of the > possibilities/tradeoffs in section 8, to clarify for everyone (not includ= ed > here, but will be useful). > > There are quite a few places where practical implementations could help u= s > decide, beyond theorical arguments. > > Fabien > > Le mar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt a = =C3=A9crit : > >> Responses inline with sections without comments deleted ... >> >> On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault >> wrote: >> >>> Hi >>> >>> Some comments marked with FI. >>> >>> Fabien >>> >>> Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt a >>> =C3=A9crit : >>> >>>> *Previous Feedback* >>>> The following items were discussed in the design team, but did not mak= e >>>> it into the draft for WG discussion. A concern I have with many of the >>>> editor notes (which I point out) is that they are heavily biased by >>>> Justin's vision and misrepresent the options. >>>> >>> >>> FI : I'm sure we can get past hard feelings and focus on the core of th= e >>> concerns. The editor's notes do their best to point where discussion sh= ould >>> happen. If some of them need further clarification, we can certainly do >>> that. >>> >> >> While I am disappointed that the design team did not decide on the best >> features or XYZ and XAuth, and instead started with the XYZ doc, I was n= ot >> trying to express any hard feelings! >> >> Reading the draft, Justin clearly has a bias to using HTTP Signing rathe= r >> than a self contained JOSE token. >> His comments (as noted below) on 8.2 misrepresent, and do not call out >> the advantage over all the other mechanisms of being self contained. >> >> Except for at the bottom, these are points for discussion that I brought >> up in the design team that did not make it into the draft for discussion= . >> >> >>>> *2.3.1 *Do we need to support symmetric keys? Most OAuth clients >>>> support a secret, not a key. >>>> >>> >>> FI : it's difficult to assume people with use public key cryptography >>> for everything. Seems to me the text is clear enough on what this impli= es. >>> >> >> We are requiring HTTPS -- so the client has support for asymmetric >> crypto. My point is that the editor notes should bring up this question, >> which I asked in the design team. >> > >> >>> >>>> *2.4.1* identifying the user >>>> this identifier would be useful if it had properties that other opaque >>>> identifiers did not have: being globally unique. A reason developers h= ave >>>> used the email in ID Tokens was that it was a globally unique string i= n >>>> contrast to the tuple of "iss" and "sub" in the ID Token which was muc= h >>>> more complicated to add and work with in a DB. Otherwise, we are creat= ing >>>> yet another user identifier. >>>> >>> >>> FI : OK but how would you make this a global identifier? Seems close to >>> what DIF Keri is looking for (although I find the way they're doing it = is >>> overly/unnecessarily complex). >>> >> >> Lots of options. No requirement to specify how the identifier is ensured >> to be unique as it should be opaque to the client. It could be a URI tha= t >> starts with the AS URI, or a UUID. >> >> My point is that a note on this option should be in the draft. >> > > FI : so the minimal requirement on which we agree is to have an opaque > identifier. So typically this would be unique for the AS and transmitted > through a user_handle (already in the spec). The client could make its ow= n > local mapping if it already knows something about the user. > > To know more about the user, it is possible to : > - use a verifiable identity layer such as OIDC or equivalent > - (TBD) use sub_ids, based on the information already locally available a= t > the AS (with the limitations mentioned previously) ; or maybe we could us= e > an alternative/complementary design. For instance a more explicit json on > what is transmitted, or carry a correlation ID given by the client, or et= c. > > > >> >> >>> Would that replace sub_ids? >>> >> >> yes >> >> >>> >>>> *3.* The URI can be stable, and the access token is potentially >>>> superfluous. As the client is authenticating with the same key in all >>>> subsequent requests, rotation of the URI or access token may be >>>> superfluous. Having an access token for the AS seems that is used whil= e >>>> authenticating vs the typical access token for an RS seems very confus= ing >>>> to a developer. >>>> >>> >>> FI : why would that be confusing? >>> >> >> Because developers don't use access tokens when accessing an OAuth AS or >> an OIDC OP? >> > >> >>> >>>> Additionally, putting the access token for calls to the AS in the HTTP >>>> Authorization header precludes using the HTTP Authorization header for >>>> client authentication in 8. >>>> >>> >>> FI : that's one of the choices we need to make. But that doesn't mean >>> what is proposed is worse, it's just a different design with different >>> tradeoffs. This requires a complete discussion on section 8 (which alre= ady >>> occurred in the small group, but Justin will be able to comment). >>> >> >> Agreed. I had asked for this to be called out as a discussion point in >> the editor notes. It was not. >> >> >>> >>>> *4.4.2 *This functionality looks like a WebHook, and perhaps belongs >>>> in the API between the client and the AS rather than an interaction th= at >>>> involves the user. Also, this functionality provides no protection to >>>> session fixation. The interaction reference has no value. >>>> >>>> *4.4.3 *While it is good to see an editor's note that a unique >>>> callback URL could be used, the statement "but it would not prevent an >>>> attacker from injecting an unrelated interaction reference into this >>>> channel." is misleading. This would only happen if the client did not >>>> ensure it is the same user, as that would be linked to the correct URL= . >>>> Similarly, the interaction reference does not provide protection if th= e >>>> client does not ensure it is the same user. >>>> Using a unique callback URL would be much simpler, and appears to >>>> provide the same protection as the interaction reference and the hashi= ng. >>>> >>> >>> FI : having to rely on the client only to ensure it is the same user is >>> precisely what you want to avoid. Hence the hashing. >>> >> >> The hashing does not protect against session fixation if the client does >> not ensure it has the same user before and after the redirect. >> >> For example, if the user has a decoupled interaction such as scanning a >> QR code on their PC with their phone, the client cannot ensure it is the >> same user coming back. An attacker can trick a user into clicking on the >> decoupled URL that the attacker obtained from the AS. The hashing does n= ot >> protect against this. >> > > FI : good point. We certainly need to handle that case correctly. We > should note that to make sure we don't forget. > That said, this comes as an additional requirement for some decoupled > interaction modes, not as a replacement of the entire scheme. > >> >> /Dick >> =E1=90=A7 >> > --00000000000084e25e05b231c95b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabien

There *could* be value in GNA= P creating yet-another-user-identifier if the identifier was guaranteed to = be globally unique -- a property not held by "sub" in an ID Token= .

Using the SecEvent subject identifier draft for = a client to share which user the client *thinks* it has is useful -- that i= s what the draft was intended for. In my opinion, querying for identifiers = independent of what is already defined in OpenID and other standards is a p= ath for developer misery.

I don't think the ha= sh provides any extra value if the redirect URL provided by the client to t= he AS is unique to the transaction. It has no value in a push back to the c= lient, or a decoupled interaction -- both of which are susceptible to sessi= on fixation / phishing attacks.

3D""=E1=90= =A7

On Wed, Oct 21, 2020 at 1:16 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Thanks Dick, it clarifies a few points. In the core of your email, I focu= s on 2 items : sub_ids and hash.=C2=A0

Beyond that we will also need a further description of the p= ossibilities/tradeoffs in section 8, to clarify for everyone (not included = here, but will be useful).=C2=A0

There are quite a few places where practical implementations coul= d help us decide, beyond theorical arguments.=C2=A0
=
Fabien=C2=A0

Le m= ar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt <dick.hardt@gmail.com>= ; a =C3=A9crit=C2=A0:
Responses inline with sections with= out comments deleted ...=C2=A0

On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbaul= t <fabien.imbault@gmail.com> wrote:
Hi

Some comments marked with = FI.=C2=A0

Fabien

=
Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Prev= ious Feedback
The following items were discussed=C2=A0in the desig= n team, but did not make it into the draft for WG discussion. A concern I h= ave=C2=A0with many of the editor notes (which I point out) is that they are= heavily biased by Justin's vision and misrepresent the options.
<= /blockquote>

FI : = I'm sure we can get past hard feelings and focus on the core of the con= cerns. The editor's notes do their best to point where discussion shoul= d happen. If some of them need further clarification, we can certainly do t= hat.=C2=A0

While I am disappoin= ted that the design team did not decide on the best features or XYZ and XAu= th, and instead started with the XYZ doc, I was not trying to express any h= ard feelings!

Reading the draft, Justin clearly ha= s a bias to using HTTP Signing rather than a self contained JOSE token.
His comments (as noted below) on 8.2 misrepresent, and do not call o= ut the advantage over all the other=C2=A0mechanisms of being self contained= .

Except for at the bottom, these are points for d= iscussion that I brought up in the design team that did not make it into th= e draft for discussion.=C2=A0


2.3.1 Do we need to support symmetric=C2=A0= keys? Most OAuth clients support a secret, not a key.

FI : it's = difficult to assume people with use public key cryptography for everything.= Seems to me the text is clear enough on what this implies.=C2=A0

We are requiring HTTPS -- so the client = has support for asymmetric crypto. My point is that the editor notes should= bring up this question, which I asked in the design team.
=C2=A0

2.4.1 identifying the user
this ident= ifier would be useful if it had properties that other opaque identifiers di= d not have: being globally unique. A reason developers have used the email = in ID Tokens was that it was a globally unique string in contrast to the tu= ple of "iss" and "sub" in the ID Token which was much m= ore complicated to add and work with in a DB. Otherwise, we are creating ye= t another user identifier.

FI : OK but how would you make this a glo= bal identifier? Seems close to what DIF Keri is looking for (although I fin= d the way they're doing it is overly/unnecessarily complex).

Lots of options. No requirement to speci= fy how the identifier is ensured to be unique as it should be opaque to the= client. It could be a URI that starts with the AS URI, or a UUID.

My point is that a note on this option should be in the dr= aft.

=
FI : so the minimal requirement on which we agree is to h= ave an opaque identifier. So typically this would be unique for the AS and = transmitted through a user_handle (already in the spec). The client could m= ake its own local mapping if it already knows something about the user.=C2= =A0

To know more about t= he user, it is possible to :
- use a verifiable iden= tity layer such as OIDC or equivalent=C2=A0
- (TBD) = use sub_ids, based on the information already locally available at the AS (= with the limitations mentioned previously) ; or maybe we could use an alter= native/complementary design. For instance a more explicit json on what is t= ransmitted, or carry a correlation ID given by the client, or etc.=C2=A0



=C2=A0
Would that replace sub_ids?=C2=A0
<= /blockquote>

yes
=C2=A0
=

3. The URI = can be stable, and the access token is potentially superfluous. As the clie= nt is authenticating with the same key in all subsequent requests, rotation= of the URI or access token may be superfluous. Having an access token for = the AS seems that is used while authenticating vs the typical access token = for an RS seems very confusing to a developer.

FI : why would that b= e confusing?=C2=A0

Because deve= lopers don't use access tokens when accessing an OAuth AS or an OIDC OP= ?
=C2=A0
<= /div>

Additionally,= putting the access token for calls to the AS in the HTTP Authorization hea= der precludes using the HTTP Authorization header for client authentication= in 8.

FI : that's one of the choices we need to make. But that = doesn't mean what is proposed is worse, it's just a different desig= n with different tradeoffs. This requires a complete discussion on section = 8 (which already occurred in the small group, but Justin will be able to co= mment).=C2=A0

Agreed. I had ask= ed for this to be called out as a discussion point in the editor notes. It = was not.
=C2=A0

4.4.2 This functionality looks like a = WebHook, and perhaps belongs in the API between the client and the AS rathe= r than an interaction that involves the user. Also, this functionality prov= ides no protection to session fixation. The interaction reference has no va= lue.

4.4.3 While it is good to see an edito= r's note that=C2=A0a unique callback=C2=A0URL could be used, the statem= ent "but it would not prevent an attacker from injecting an unrelated = interaction reference into this channel." is misleading. This would on= ly happen if the client did not ensure it is the same user, as that would b= e linked to the correct=C2=A0URL. Similarly, the interaction reference does= not provide protection if the client does not ensure it is the same user.<= /div>
Using a unique callback URL would be much simpler, and appears to= provide the same protection as the interaction reference and the hashing.<= /div>

FI : having to rely on the client only to ensure it is the same user= is precisely what you want to avoid. Hence the hashing.=C2=A0
<= /blockquote>

The hashing does not protect against sessio= n fixation if the client does not ensure it has the same user before and af= ter the redirect.
=C2=A0
For example, if the user has a= decoupled interaction such as scanning a QR code on their PC with their ph= one, the client cannot ensure it is the same user coming back. An attacker = can trick a user into clicking on the decoupled URL that the attacker obtai= ned from the AS. The hashing does not protect against this.

FI= : good point. We certainly need to handle that case correctly. We should n= ote that to make sure we don't forget.=C2=A0
Tha= t said, this comes as an additional requirement for some decoupled interact= ion modes, not as a replacement of the entire scheme.=C2=A0
<= br>
/Dick
3D""=E1=90=A7
--00000000000084e25e05b231c95b-- From nobody Wed Oct 21 11:28:09 2020 Return-Path: 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 5796A3A1224 for ; Wed, 21 Oct 2020 11:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 3XMjrR0a8FYM for ; Wed, 21 Oct 2020 11:28:05 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 37C233A120A for ; Wed, 21 Oct 2020 11:28:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id n6so4169259ioc.12 for ; Wed, 21 Oct 2020 11:28:05 -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=ZKaEiBSisgWt5ZwEHTP0z10AbTKYwvO9RLlbo/RoHOs=; b=HNKYYAFe/YDHXx0KWkytkNa16teWNfjWKYOlRSb4ZNFp67co8twCCfO19Gbj80waWz qqZm7kchXaP9DBHIX5t62raXlYL0pq71PzFiuBCpvjeJKUf8veDFIKA7rVPiPRRvWAnC PcIAtaC0Fn9sOmNcool3g4R8p6mQfwVwM+GYkDyII7uwpRDr/xWCFWfTOc8MWEq4lIb3 dwb43xUCOtbfxf2GbnbhGun+3HfxnjClM27Cv/cY4yU+gljoVs9x9lHRKMfzPbE4UjZI tyEDIVRuK7YX/66OWCcPSALwK2klvZdBpvPJOUs3xCcFfKtCoeMPqcSD36yv7F1bSCG+ 3PiQ== 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=ZKaEiBSisgWt5ZwEHTP0z10AbTKYwvO9RLlbo/RoHOs=; b=g1kqLRCSLFBCppe6FaK7g92bCE4tZKjnEQbS865nZYjh17WR44e3khmi9Hki5UtYQV tj+bgrnPYKcqVNfzuanyCBEl/Z7DtbkXGG5N3UKU89vdXgCD/LXh7a4OwbKZnMMt7K2L XwCtKEqRfoDVmthXy9ZirSqNtsr/xSXNUWiTV8IjlzdW8SkPhdHnUb8HCMWcmHiMtmqe B8pEEJ/CiYu8vn5rXIcnr5FdRnptCYxSP1CngpwZ7U8eLY6dT03iCglIBe1MC2EMEd68 OH4/JeZiBIkM0QR8vEfiSW840mGzlP6Dy36gqQ1t63kRw7vN46c5g300QzlHbWl6hDzJ j1KQ== X-Gm-Message-State: AOAM5305J16B/wTk5xS5HNg6araMSJb2WPTNKSEamQfp0ukfosVYw1xF jSgMLqSztE/b5cZPojiC+xLtNgZxm6qfznOfn+E= X-Google-Smtp-Source: ABdhPJw0DfU8ftHvNi4h7pe39RaOV44zm/h38xr+haVwrQKb+l54MxPfFEUe/gYGm7yBO7TVvldDZBU7eXdqUcqluOc= X-Received: by 2002:a6b:3f88:: with SMTP id m130mr3793406ioa.78.1603304884063; Wed, 21 Oct 2020 11:28:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 21 Oct 2020 20:27:50 +0200 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000014d25305b23282c9" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 18:28:08 -0000 --00000000000014d25305b23282c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Regarding the identifier : I agree in principle, but "globally unique" is anything but trivial. Fabien Le mer. 21 oct. 2020 =C3=A0 19:36, Dick Hardt a =C3= =A9crit : > Hi Fabien > > There *could* be value in GNAP creating yet-another-user-identifier if th= e > identifier was guaranteed to be globally unique -- a property not held by > "sub" in an ID Token. > > Using the SecEvent subject identifier draft for a client to share which > user the client *thinks* it has is useful -- that is what the draft was > intended for. In my opinion, querying for identifiers independent of what > is already defined in OpenID and other standards is a path for developer > misery. > > I don't think the hash provides any extra value if the redirect URL > provided by the client to the AS is unique to the transaction. It has no > value in a push back to the client, or a decoupled interaction -- both of > which are susceptible to session fixation / phishing attacks. > > =E1=90=A7 > > On Wed, Oct 21, 2020 at 1:16 AM Fabien Imbault > wrote: > >> Thanks Dick, it clarifies a few points. In the core of your email, I >> focus on 2 items : sub_ids and hash. >> >> Beyond that we will also need a further description of the >> possibilities/tradeoffs in section 8, to clarify for everyone (not inclu= ded >> here, but will be useful). >> >> There are quite a few places where practical implementations could help >> us decide, beyond theorical arguments. >> >> Fabien >> >> Le mar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt a = =C3=A9crit : >> >>> Responses inline with sections without comments deleted ... >>> >>> On Tue, Oct 20, 2020 at 2:40 AM Fabien Imbault >>> wrote: >>> >>>> Hi >>>> >>>> Some comments marked with FI. >>>> >>>> Fabien >>>> >>>> Le mar. 20 oct. 2020 =C3=A0 05:27, Dick Hardt a >>>> =C3=A9crit : >>>> >>>>> *Previous Feedback* >>>>> The following items were discussed in the design team, but did not >>>>> make it into the draft for WG discussion. A concern I have with many = of the >>>>> editor notes (which I point out) is that they are heavily biased by >>>>> Justin's vision and misrepresent the options. >>>>> >>>> >>>> FI : I'm sure we can get past hard feelings and focus on the core of >>>> the concerns. The editor's notes do their best to point where discussi= on >>>> should happen. If some of them need further clarification, we can cert= ainly >>>> do that. >>>> >>> >>> While I am disappointed that the design team did not decide on the best >>> features or XYZ and XAuth, and instead started with the XYZ doc, I was = not >>> trying to express any hard feelings! >>> >>> Reading the draft, Justin clearly has a bias to using HTTP Signing >>> rather than a self contained JOSE token. >>> His comments (as noted below) on 8.2 misrepresent, and do not call out >>> the advantage over all the other mechanisms of being self contained. >>> >>> Except for at the bottom, these are points for discussion that I brough= t >>> up in the design team that did not make it into the draft for discussio= n. >>> >>> >>>>> *2.3.1 *Do we need to support symmetric keys? Most OAuth clients >>>>> support a secret, not a key. >>>>> >>>> >>>> FI : it's difficult to assume people with use public key cryptography >>>> for everything. Seems to me the text is clear enough on what this impl= ies. >>>> >>> >>> We are requiring HTTPS -- so the client has support for asymmetric >>> crypto. My point is that the editor notes should bring up this question= , >>> which I asked in the design team. >>> >> >>> >>>> >>>>> *2.4.1* identifying the user >>>>> this identifier would be useful if it had properties that other opaqu= e >>>>> identifiers did not have: being globally unique. A reason developers = have >>>>> used the email in ID Tokens was that it was a globally unique string = in >>>>> contrast to the tuple of "iss" and "sub" in the ID Token which was mu= ch >>>>> more complicated to add and work with in a DB. Otherwise, we are crea= ting >>>>> yet another user identifier. >>>>> >>>> >>>> FI : OK but how would you make this a global identifier? Seems close t= o >>>> what DIF Keri is looking for (although I find the way they're doing it= is >>>> overly/unnecessarily complex). >>>> >>> >>> Lots of options. No requirement to specify how the identifier is ensure= d >>> to be unique as it should be opaque to the client. It could be a URI th= at >>> starts with the AS URI, or a UUID. >>> >>> My point is that a note on this option should be in the draft. >>> >> >> FI : so the minimal requirement on which we agree is to have an opaque >> identifier. So typically this would be unique for the AS and transmitted >> through a user_handle (already in the spec). The client could make its o= wn >> local mapping if it already knows something about the user. >> >> To know more about the user, it is possible to : >> - use a verifiable identity layer such as OIDC or equivalent >> - (TBD) use sub_ids, based on the information already locally available >> at the AS (with the limitations mentioned previously) ; or maybe we coul= d >> use an alternative/complementary design. For instance a more explicit js= on >> on what is transmitted, or carry a correlation ID given by the client, o= r >> etc. >> >> >> >>> >>> >>>> Would that replace sub_ids? >>>> >>> >>> yes >>> >>> >>>> >>>>> *3.* The URI can be stable, and the access token is potentially >>>>> superfluous. As the client is authenticating with the same key in all >>>>> subsequent requests, rotation of the URI or access token may be >>>>> superfluous. Having an access token for the AS seems that is used whi= le >>>>> authenticating vs the typical access token for an RS seems very confu= sing >>>>> to a developer. >>>>> >>>> >>>> FI : why would that be confusing? >>>> >>> >>> Because developers don't use access tokens when accessing an OAuth AS o= r >>> an OIDC OP? >>> >> >>> >>>> >>>>> Additionally, putting the access token for calls to the AS in the HTT= P >>>>> Authorization header precludes using the HTTP Authorization header fo= r >>>>> client authentication in 8. >>>>> >>>> >>>> FI : that's one of the choices we need to make. But that doesn't mean >>>> what is proposed is worse, it's just a different design with different >>>> tradeoffs. This requires a complete discussion on section 8 (which alr= eady >>>> occurred in the small group, but Justin will be able to comment). >>>> >>> >>> Agreed. I had asked for this to be called out as a discussion point in >>> the editor notes. It was not. >>> >>> >>>> >>>>> *4.4.2 *This functionality looks like a WebHook, and perhaps belongs >>>>> in the API between the client and the AS rather than an interaction t= hat >>>>> involves the user. Also, this functionality provides no protection to >>>>> session fixation. The interaction reference has no value. >>>>> >>>>> *4.4.3 *While it is good to see an editor's note that a unique >>>>> callback URL could be used, the statement "but it would not prevent a= n >>>>> attacker from injecting an unrelated interaction reference into this >>>>> channel." is misleading. This would only happen if the client did not >>>>> ensure it is the same user, as that would be linked to the correct UR= L. >>>>> Similarly, the interaction reference does not provide protection if t= he >>>>> client does not ensure it is the same user. >>>>> Using a unique callback URL would be much simpler, and appears to >>>>> provide the same protection as the interaction reference and the hash= ing. >>>>> >>>> >>>> FI : having to rely on the client only to ensure it is the same user i= s >>>> precisely what you want to avoid. Hence the hashing. >>>> >>> >>> The hashing does not protect against session fixation if the client doe= s >>> not ensure it has the same user before and after the redirect. >>> >>> For example, if the user has a decoupled interaction such as scanning a >>> QR code on their PC with their phone, the client cannot ensure it is th= e >>> same user coming back. An attacker can trick a user into clicking on th= e >>> decoupled URL that the attacker obtained from the AS. The hashing does = not >>> protect against this. >>> >> >> FI : good point. We certainly need to handle that case correctly. We >> should note that to make sure we don't forget. >> That said, this comes as an additional requirement for some decoupled >> interaction modes, not as a replacement of the entire scheme. >> >>> >>> /Dick >>> =E1=90=A7 >>> >> --00000000000014d25305b23282c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,=C2=A0

Regarding the identifier : I agree in principle, but "gl= obally unique" is anything but trivial.=C2=A0

Fabien=C2=A0

Le mer. 21 oct. 2020 =C3=A0 19:36, Dick Hardt <= ;dick.hardt@gmail.com> a =C3= =A9crit=C2=A0:
Hi = Fabien

There *could* be value in GNAP creating yet-anoth= er-user-identifier if the identifier was guaranteed to be globally unique -= - a property not held by "sub" in an ID Token.

Using the SecEvent subject identifier draft for a client to share wh= ich user the client *thinks* it has is useful -- that is what the draft was= intended for. In my opinion, querying for identifiers independent of what = is already defined in OpenID and other standards is a path for developer mi= sery.

I don't think the hash provides any extr= a value if the redirect URL provided by the client to the AS is unique to t= he transaction. It has no value in a push back to the client, or a decouple= d interaction -- both of which are susceptible to session fixation / phishi= ng attacks.

3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Wed, Oct= 21, 2020 at 1:16 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
Thanks Dick, it clarifies a few points. In the core of yo= ur email, I focus on 2 items : sub_ids and hash.=C2=A0

Beyond that we will also need a further desc= ription of the possibilities/tradeoffs in section 8, to clarify for everyon= e (not included here, but will be useful).=C2=A0
There are quite a few places where practical imple= mentations could help us decide, beyond theorical arguments.=C2=A0

Fabien=C2=A0

Le mar. 20 oct. 2020 =C3=A0 19:45, Dick Hardt <d= ick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Response= s inline with sections without comments deleted ...=C2=A0

On Tue, Oct 20, 20= 20 at 2:40 AM Fabien Imbault <fabien.imbault= @gmail.com> wrote:
Hi

Some comments marked with FI.=C2=A0
Fabien

Le mar. 20 oct. 2020 =C3=A0 05:27= , Dick Hardt <dick.hardt@g= mail.com> a =C3=A9crit=C2=A0:
Previous Feedback
Th= e following items were discussed=C2=A0in the design team, but did not make = it into the draft for WG discussion. A concern I have=C2=A0with many of the= editor notes (which I point out) is that they are heavily biased by Justin= 's vision and misrepresent the options.
<= div dir=3D"auto">
FI : I'm sure we can get p= ast hard feelings and focus on the core of the concerns. The editor's n= otes do their best to point where discussion should happen. If some of them= need further clarification, we can certainly do that.=C2=A0

While I am disappointed that the design team = did not decide on the best features or XYZ and XAuth, and instead started w= ith the XYZ doc, I was not trying to express any hard feelings!
<= br>
Reading the draft, Justin clearly has a bias to using HTTP Si= gning rather than a self contained JOSE token.
His comments (as n= oted below) on 8.2 misrepresent, and do not call out the advantage over all= the other=C2=A0mechanisms of being self contained.

Except for at the bottom, these are points for discussion that I brought = up in the design team that did not make it into the draft for discussion.= =C2=A0


2.3.1 Do we need to support symmetric=C2=A0keys? Most OAuth client= s support a secret, not a key.

FI : it's difficult to assume peo= ple with use public key cryptography for everything. Seems to me the text i= s clear enough on what this implies.=C2=A0
We are requiring HTTPS -- so the client has support for asymmet= ric crypto. My point is that the editor notes should bring up this question= , which I asked in the design team.
=C2=A0

= 2.4.1 identifying the user
this identifier would be useful if= it had properties that other opaque identifiers did not have: being global= ly unique. A reason developers have used the email in ID Tokens was that it= was a globally unique string in contrast to the tuple of "iss" a= nd "sub" in the ID Token which was much more complicated to add a= nd work with in a DB. Otherwise, we are creating yet another user identifie= r.

FI : OK but how would you make this a global identifier? Seems cl= ose to what DIF Keri is looking for (although I find the way they're do= ing it is overly/unnecessarily complex).

=
Lots of options. No requirement to specify how the identifier is= ensured to be unique as it should be opaque to the client. It could be a U= RI that starts with the AS URI, or a UUID.

My poin= t is that a note on this option should be in the draft.

FI : s= o the minimal requirement on which we agree is to have an opaque identifier= . So typically this would be unique for the AS and transmitted through a us= er_handle (already in the spec). The client could make its own local mappin= g if it already knows something about the user.=C2=A0

To know more about the user, it is possible t= o :
- use a verifiable identity layer such as OIDC o= r equivalent=C2=A0
- (TBD) use sub_ids, based on the= information already locally available at the AS (with the limitations ment= ioned previously) ; or maybe we could use an alternative/complementary desi= gn. For instance a more explicit json on what is transmitted, or carry a co= rrelation ID given by the client, or etc.=C2=A0

=


=C2=A0
Would that replace sub_ids?=C2=A0

yes
=C2=A0

3. The URI can be stable, and the ac= cess token is potentially superfluous. As the client is authenticating with= the same key in all subsequent requests, rotation of the URI or access tok= en may be superfluous. Having an access token for the AS seems that is used= while authenticating vs the typical access token for an RS seems very conf= using to a developer.

FI : why would that be confusing?=C2=A0
<= /div>

Because developers don't use acce= ss tokens when accessing an OAuth AS or an OIDC OP?
=C2=A0
=

Additionally, putting the access token= for calls to the AS in the HTTP Authorization header precludes using the H= TTP Authorization header for client authentication in 8.

FI : that&#= 39;s one of the choices we need to make. But that doesn't mean what is = proposed is worse, it's just a different design with different tradeoff= s. This requires a complete discussion on section 8 (which already occurred= in the small group, but Justin will be able to comment).=C2=A0
=

Agreed. I had asked for this to be called = out as a discussion point in the editor notes. It was not.
=C2=A0=
<= div dir=3D"auto">

=
4.4.2 This functionality looks like a WebHook, and perhaps belo= ngs in the API between the client and the AS rather than an interaction tha= t involves the user. Also, this functionality provides no protection to ses= sion fixation. The interaction reference has no value.

=
4.4.3 While it is good to see an editor's note that=C2=A0a = unique callback=C2=A0URL could be used, the statement "but it would no= t prevent an attacker from injecting an unrelated interaction reference int= o this channel." is misleading. This would only happen if the client d= id not ensure it is the same user, as that would be linked to the correct= =C2=A0URL. Similarly, the interaction reference does not provide protection= if the client does not ensure it is the same user.
Using a uniqu= e callback URL would be much simpler, and appears to provide the same prote= ction as the interaction reference and the hashing.

FI : having to r= ely on the client only to ensure it is the same user is precisely what you = want to avoid. Hence the hashing.=C2=A0

The hashing does not protect against session fixation if the clien= t does not ensure it has the same user before and after the redirect.
=
=C2=A0
For example, if the user has a decoupled interaction = such as scanning a QR code on their PC with their phone, the client cannot = ensure it is the same user coming back. An attacker can trick a user into c= licking on the decoupled URL that the attacker obtained from the AS. The ha= shing does not protect against this.

FI : good point. We certa= inly need to handle that case correctly. We should note that to make sure w= e don't forget.=C2=A0
That said, this comes as a= n additional requirement for some decoupled interaction modes, not as a rep= lacement of the entire scheme.=C2=A0
=

/Dick
=
=E1=90=A7
--00000000000014d25305b23282c9-- From nobody Wed Oct 21 12:22:45 2020 Return-Path: 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 C92E53A13BE for ; Wed, 21 Oct 2020 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 JCxfhzUy_Twy for ; Wed, 21 Oct 2020 12:22:39 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFC03A13A5 for ; Wed, 21 Oct 2020 12:22:38 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09LJMa01016234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Oct 2020 15:22:37 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A03A0575-A069-4CE8-83A8-1A632AEEE983" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 21 Oct 2020 15:22:36 -0400 In-Reply-To: Cc: GNAP Mailing List To: Dick Hardt References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 19:22:44 -0000 --Apple-Mail=_A03A0575-A069-4CE8-83A8-1A632AEEE983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 19, 2020, at 11:26 PM, Dick Hardt wrote: >=20 > Previous Feedback > The following items were discussed in the design team, but did not = make it into the draft for WG discussion. A concern I have with many of = the editor notes (which I point out) is that they are heavily biased by = Justin's vision and misrepresent the options. >=20 I do not think this is an accurate representation of either the design = team process or the resulting document. The point of the editor=E2=80=99s = notes were to lay out options and capture discussion, and not just to = present my own limited view of the world. I do not personally agree with = all of the statements in every editor=E2=80=99s note, nor do I = personally think that all the options presented are equal =E2=80=94 but = even so, acting as editor for the design team, I sought to capture those = options as best as I could, and add commentary and context where = possible. The design team provided feedback to the document and to the = editor=E2=80=99s notes, and while they aren=E2=80=99t perfect, I do not = think that they are biased as you claim. Even so, like Fabien, I do hope we can move past this somehow lingering = bitterness and the working group can build a good protocol. Most of the feedback I=E2=80=99m giving here has been brought up before, = either on the public list, in the design team calls, or in design team = emails.=20 Again, apologies for the lengthy response email. As I mentioned in the = other thread, I personally think items like the list here are better = captured as GitHub issues, and I=E2=80=99d like to see us move to that = mechanism for capturing things soon, if we can. > Abstract: "information passed directly to the software" can mean = pretty much anything. The charter has "user identifiers, and identity = assertions."=20 The charter, as you know, is guidance for the group and not dictate. = Even so, the charter itself includes this line which is what the = abstract text in question was based off of: - Optimized inclusion of additional information (including = identifiers and=20 identity assertions) through the delegation process=20 The charter specifically does not limit what the protocol could be used = for, only what this WG will define for its use. Therefore I was = attempting to capture the broader scope of possibility in the abstract. >=20 > 1. Same point as in Abstract around "information". >=20 > 1.1 Roles:=20 > Add in roles for operators of AS and RC.=20 What roles do these play in the protocol itself? They may exist in = deployments, but the roles should be defined in terms of the protocol. > Show trust framework between legal entities (user, RO, client = operator, AS operator) Does this working group really want to get into the definition of legal = relationships? There are such a wide variety of possible deployments and = trust models, most of which don=E2=80=99t affect the nature of the = protocol itself, that I=E2=80=99m not sure we can narrow that down. > Differentiate between legal entities having a relationship or HCI and = the actual protocol roles (RC, AS, RS) The current draft does not define any legal entities, only protocol = roles (including human roles like RO and RQ). > What is the difference between roles and parties? Can we avoid the = term parties? RQ is both a party and a role. RQ is a role and is defined as such =E2=80=94 only in the name = =E2=80=9CRequesting Party=E2=80=9D (which as noted was taken from UMA2) = does =E2=80=9Cparty=E2=80=9D occur. The name of this entity is up for = discussion, still, and this is a reasonable argument for moving away = from =E2=80=9CRequesting Party=E2=80=9D. =E2=80=9CParties=E2=80=9D are traditionally entities that fill a role. I = did try to avoid the use of =E2=80=9Cparty=E2=80=9D where its use would = be inaccurate or ambiguous, though I=E2=80=99m sure this could be = cleaned up if you have specific instances of such language. > Alternative names: > client for RC > user for RQ These are already listed with the terms themselves. >=20 > 1.2 Elements: > defined access token without using "credential" This is largely modeled on the OAuth 2 definition of access token. Can = you expand on your issue with the term =E2=80=9Ccredential=E2=80=9D = here? Do you have an alternate definition to propose? > Grant as both a noun (what is being requested) and a verb=20 > Grant is already is a noun being used as an adjective in "Grant = Negotiation ..." and "Grant Response" Grant as a noun is problematic in several ways, not the least of which = is that it conflicts with how =E2=80=9Cgrant=E2=80=9D is both used (=E2=80= =9Ca credential given to the client to trade for a token=E2=80=9D) and = understood (=E2=80=9Cthe kind of action the client has to take=E2=80=9D) = in OAuth 2. It also leads to confusing semantic satitation when used in = context with the verb form.=20 If we follow the plain definitions outside of OAuth2, the =E2=80=9Cgrant=E2= =80=9D is the result of the request, but what we tend to talk about is = the ongoing state of the request. I would love for us to have a better = term for this artifact =E2=80=94 I had previously termed this element = =E2=80=9Cthe transaction=E2=80=9D.=20 > "Subject Information" is better than just "information" -- but is = still extremely broad > The subject information should be about the user, not the RO. For = example, in an enterprise use case where resource access and identity = claims are being requested, the RO is not the user, but could be an = administrator. The "subject information" is going to be about the user = of the client, not the administrator. I agree this is where things need to be made more explicit, especially = when stretched across different use cases. The =E2=80=9Cnormal=E2=80=9D = use case where the RQ and RO are the same person collapses this fine, = but not in all cases. Could an RQ request =E2=80=9Csubject = information=E2=80=9D about another user (the RO)? This isn=E2=80=99t = dissimilar to the CIBA use case of a call-center =E2=80=9Clogin". = Ultimately, I think we need to nail down which =E2=80=9Csubject=E2=80=9D = this returned information is about. >=20 > 1.3.3 step 7 - what is a refreshed credential? We should refer to the = defined terms. It=E2=80=99s specifically the URI and token values within the = =E2=80=9Ccontinue=E2=80=9D element that are returned from the AS, so = this text can be reworded.=20 >=20 > 2. title should be Grant Request to match with Grant Response in (3), = and use of "Grant Request" in 2.7, 2.9, 5, 5.4, & 5.5=20 Thanks, terminology can be made more consistent throughout the document, = for sure. >=20 > 2.1.2: "a RC MAY send a string known to the AS or RS" > why "or"? Explain. >=20 This logic is based on how OAuth 2 scopes are used in many places. If the AS knows about the string, it can enforce policies on what an RO = can approve or an RC can request. It=E2=80=99s really common to have = these kinds of policies. If the AS doesn=E2=80=99t know about the = string, the AS can still provide the request to the RO for approval and = convey the approved string information to an RS downstream for = enforcement. If the RS knows about the string, it can enforce policies on what the = token is good for, assuming the string is conveyed to the RS as-is. = Alternatively, the RS could be naive about the requested string and = instead rely on the AS to translate the string into something specific = for the RS to consume.=20 This is not an exclusive =E2=80=9Cor=E2=80=9D, of course. If both the AS = and RS know about the string, that also works fine. > 2.2 "sub_ids" > are sub_ids a good idea, a best practice? despite warnings in the = protocol, developers will use an email identifier as a communication = identifier, or worse, a verified identifier.=20 > GNAP is defining a query language here for subject identifiers.=20 We know from years of experience with OIDC and OAuth 2 that client = developers want to have an identifier they can correlate to other = information within their applications, and this is a feature to address = that.=20 >=20 > 2.3 Identifying a client via URL > Mobile Apps and SPA can identify themselves with an HTTPS url that = only that client can receive redirects to (universal link in iOS, = android app link). The client passes the general identifier for the = client (class_id?) and the AS ensures the redirect URI belongs to that = client. A parameter is passed on the redirect to the client that the = client presents to the AS to prove it is an instance of that client. The = AS may then release access and claims to the client. The AS may also = provide an instance identifier for the client so that instance of the = client can uniquely identify itself. >=20 > The editor note that instance_id is analogous to the client_id = prevents an instance of the client in the preceding paragraph from = uniquely identifying itself, and the name is misleading. The conflict only occurs if you want to call the class_id the client_id. = In practice, to serve this kind of client, the AS would register a = class_id and the developer would include that class_id with every = initial request.=20 >=20 > Additionally, pre-registered identifiers (class_id which should be = equivalent to client_id for confidential clients) and dynamic = identifiers (instance_id) have different operational and infrastructure = requirements. pre-registered identifiers should be read only for the AS = vs read / write for the AS. There may be millions of dynamic identifier = for one pre-registered identifier (mobile app, SPA) Thus why a class_id and an instance_id are different, and we no longer = have =E2=80=9Cclient_id=E2=80=9D that confuses the concepts.=20 I think it would be worthwhile to add an explicit =E2=80=9Cclass_id=E2=80=9D= field, but as I recall in the design team we didn=E2=80=99t quite = settle on that. What are you proposing should change? >=20 > 2.3.1 Do we need to support symmetric keys? Most OAuth clients support = a secret, not a key. I believe we should support symmetric keys (but not client secrets). I = also believe that we can safely do so using the client instance = reference, as laid out by the discussion in the section. The problems with symmetric crypto largely come from key distribution = and not the actual cryptography. If the keys are pre-placed or securely = delivered or derived out-of-band, symmetric crypto will fit fine in this = space. >=20 > 2.3.2 > what are the supported public key formats? What=E2=80=99s listed in the document are currently JWK and PEM, these = should be expandable to other formats (CWK for example). > What if the client is able to use different proofing mechanisms? How = does it negotiate with the AS? Inline negotiation of proofing mechanisms is dangerous at best, since = the RC needs to protect the negotiation request.=20 Most clients are likely to have one method that they always do, and it = will be based on the key material that they have access to, but the = discovery mechanisms in the draft would allow a more capable client of = dynamically selecting a mechanism.=20 Yaron raised the point of what is Mandatory to Implement, and I agree = that this is something that should be. >=20 >=20 > 2.4.1 identifying the user > this identifier would be useful if it had properties that other opaque = identifiers did not have: being globally unique. A reason developers = have used the email in ID Tokens was that it was a globally unique = string in contrast to the tuple of "iss" and "sub" in the ID Token which = was much more complicated to add and work with in a DB. Otherwise, we = are creating yet another user identifier. This identifier is very narrowly focused, and is used for the RC to = communicate its notion of =E2=80=9Cthe current user=E2=80=9D back to the = AS specifically. With that focus, it doesn=E2=80=99t need to be globally = unique or even recognizable to the RC, just a string assigned by the AS. = There are other subject identifiers that can fulfill a =E2=80=9Cglobally = unique=E2=80=9D role instead. Globally unique identifiers for users are = discussed in section 3.4 and linked from several sections, as was = suggested during design team conversations. Section 3.5 (that defines = where this string might come from) discusses that the user_handle string = talked about here could potentially be replaced by a more general = mechanism instead of this narrowly-focused one, which could in turn have = the aspects you are discussing. >=20 > 2.5 interaction capabilities / modes (section 3.3 as well) > While the document has renamed "interaction capabilities" to = "interaction modes", but the client is still declaring capabilities, but = in 3.3 there are conflicting statements >=20 > "If the RC has indicated a capability to interact with the RO in its = request (Section 2.5)" >=20 > The AS MUST NOT respond with any interaction mode that the RC did not = indicate in its request.=20 These are not in conflict =E2=80=94 the intended interpretation is that = IF the AS responds to an interaction then it does it in a particular = way, not that it MUST respond to an interaction it doesn=E2=80=99t know = how to handle. The rest of the sentence quoted above states in full = (emphasis added): If the RC has indicated a capability to interact with the RO in = its request = (Section 2.5 = ), and the AS has determined that interaction is both = supported and necessary, the AS responds to the RC with any of the = following values in the interact field of the response. In addition, all of the subsections in 3.3 have text like the following = (emphasis added): If the RC indicates that it can redirect to an arbitrary URL = (Section 2.5.1 = ) and the AS supports this mode for the RC's = request, So the RC declares what it can do, and the AS responds to any parts = that: - the AS supports - the AS determines are appropriate for what=E2=80=99s being = requested (resources and subject info) - the AS allows for that specific RC instance - the AS allows for any identified RO in the request The combination of these together tell the RC exactly what it is allowed = to do. Do you have a suggestion on how to make that more clear? >=20 > using the same 4 interaction modes in the client request would make it = easier for the client to say which modes it supports, and the AS to = respond with which modes are allowed. It also allows all parameters = required for a mode to be in the mode. For example the URL for a double = redirection, vs a redirection to an information page after a user_code = or decoupled redirect. As has been discussed at length, what you describe here is the same = negotiation model as in the draft. The only difference is whether the = post-interaction method is bundled as a property of the engagement = method, which is discussed in detail in the notes along with two = different proposals of how it could be done. >=20 > 2.5 declaring RC capabilities > Editor's note on what this is supposed to do, and why it can't be done = by just adding the properties to the request. This is a proposal for an inline advanced discovery mechanism. I=E2=80=99m= personally not a fan of keeping it if we don=E2=80=99t have a concrete = use for it, but at this stage it=E2=80=99s important to have options = like this listed. >=20 > 2.7 perhaps this could be done by updating an existing Grant Request. = This seems overly complicated. Updating an existing request is a different use case, much like = refreshing an access token is different from deriving an access token = through token exchange.=20 >=20 > 2.8 Perhaps this should be in 2.2 where we are requesting information = about the user? > Given that solving the use cases solved by OIDC is in conflict with = the editor note that OIDF should be doing the integration with GNAP. The = current model is confusing as requests are in one object, and responses = are in a different object. We don't have to combine the userinfo = endpoint request with the id_token request just because that was = convenient for OIDC. The editorial comments make thi seem much messier = than it is. >=20 I agree that it=E2=80=99s not ideal to combine the userinfo and id_token = elements, but that=E2=80=99s how OIDC defined this query language, and = an important aspect of this query language is that the top-level element = of the query object defines the =E2=80=9Ctarget=E2=80=9D of the = requested claims. We could ignore this part of the spec, but if we are = to use the OIDC query language, we shouldn=E2=80=99t be re-defining how = it works, which is what splitting up the components would do.=20 This stance is based on having implemented OIDC claims processing on = several platforms. If we were to break up the claims query language, it = would be difficult to re-use any existing parsing and processing = mechanisms. It would also not work for extensions to the OIDC claims = query language, such as one that=E2=80=99s proposed for VC=E2=80=99s: = https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ = I would rather see us focus on general purpose mechanisms for requesting = resources, subject identifiers, and bound assertions.=20 > 3. The URI can be stable, and the access token is potentially = superfluous. As the client is authenticating with the same key in all = subsequent requests, rotation of the URI or access token may be = superfluous. Having an access token for the AS seems that is used while = authenticating vs the typical access token for an RS seems very = confusing to a developer. The key here is that this is a :bound: access token, just one that is = bound to the client=E2=80=99s key in this case. It=E2=80=99s exactly the = same mechanism that the RC would use to call the RS, and that separation = of concerns is a key feature of this architecture. If we are expecting = GNAP developers to be confused by being asked to present an access = token, then I don=E2=80=99t think we have much hope. :) >=20 > Additionally, putting the access token for calls to the AS in the HTTP = Authorization header precludes using the HTTP Authorization header for = client authentication in 8. The purpose of the key presentation is not just for client = authentication, but about binding the message to a particular key = holder. This is what allows the same mechanisms to be used across = different elements of the protocol instead of having to invent new = things for each piece. >=20 > 4.4.2 This functionality looks like a WebHook, and perhaps belongs in = the API between the client and the AS rather than an interaction that = involves the user. Also, this functionality provides no protection to = session fixation. The interaction reference has no value. It=E2=80=99s functionality that is triggered post-interaction, just like = a post-interaction redirect to a callback URL (or the static page option = proposed in the notes). >=20 > 4.4.3 While it is good to see an editor's note that a unique callback = URL could be used, the statement "but it would not prevent an attacker = from injecting an unrelated interaction reference into this channel." is = misleading. This would only happen if the client did not ensure it is = the same user, as that would be linked to the correct URL. Similarly, = the interaction reference does not provide protection if the client does = not ensure it is the same user. > Using a unique callback URL would be much simpler, and appears to = provide the same protection as the interaction reference and the = hashing. >=20 I believe the unique URLs and reference/hash mechanism solve different = but related problems. This is an area for discussion, but I don=E2=80=99t = see a reason to :not: have cryptographic protection on front channel = mechanisms. OAuth 2 started without it, but OIDC added them back in = (with hybrid mode) and now JARM is defining a general-purpose way to do = that. > 5.=20 > Continuing a Grant Request (which in (2) is called an Access Request) > Is "continuing the right word"? > We are either "validating" the request (5.1), polling the request = (5.2), modifying the request (5.3), reading the request (5.4), or = cancelling the request (5.5). I believe =E2=80=9Ccontinue=E2=80=9D is a wide enough net to cover all = of these, as it=E2=80=99s action on a previously-started request. Do you = have a suggestion for a better encompassing term? >=20 > Include editorial discussion of replacing a request, replacing part of = a request, and adding to a request, and if we should have semantics for = all 3 mechanisms. This seems to be covered in the discussion on updating the request and = constraints on the atomicity of each portion of the request.=20 >=20 > 8 > While some binding mechanisms work the same for the client calling the = AS as the RS, the requirements are different. When the client calls the = AS, the client is authenticating. When the client is calling the RS, the = client is proving it is authorized to access the resource. The RS does = not need to know the identity of the client -- just that it is the = client that the AS gave the access token to. None of the mechanisms require the RS to know the identity of the RC. = The AS can verify the RC instance=E2=80=99s identity based on its key, = if the AS knows the key and has it associated to an instance. But I=E2=80=99= d also add that the AS doesn=E2=80=99t need to know the identity of the = RC either, in dynamic cases, since the key is just being introduced. In = those cases, as you state above, the =E2=80=9Cauthentication=E2=80=9D of = the client is a more complex process involving class identifiers (as = well as device posture and the like). This is an important discussion = for the WG to have as it gets at our model of what a =E2=80=9Cclient=E2=80= =9D is on several dimensions. Could you please expand on how you see using the same set of binding = mechanisms across the protocol would cause problems for AS, RS, or RC = developers?=20 >=20 > 8.2 Attached JWS > Why not a JWT? This is not a token, therefore JWT is not an appropriate technology. JWS = is appropriate as it provides a signature mechanism, which is what=E2=80=99= s being discussed here. > This is the ONLY self contained mechanism. All the other ones require = all, or most of the HTTP headers and the body to be kept together. That=E2=80=99s correct, are you suggesting a change, or that this should = be called out more explicitly? >=20 > The editor note >=20 > "Alternatively, we could add all these fields to the body of the = request, but then it gets awkward for non-body requests like = GET/DELETE." >=20 > It is not awkward. A mechanism is described later of having the JWS as = an HTTP header. Something JWS was designed for. I think it=E2=80=99s incredibly awkward for the signature layer to mess = around with the payload of the HTTP message itself. It breaks the = separation of these layers, and now the signature layers need to know = about the content and format of the HTTP message. For instance, you=E2=80=99d have to have the client put the signature = parameters (such as HTTP method and URI) either in the body of the = request OR in a special body that=E2=80=99s used only in body-less = requests, depending on what you=E2=80=99re doing. This is on top of = putting the signed element in a different place when you=E2=80=99re done = with it.=20 >=20 > The editor note >=20 > "A downside to this method is that it requires the content type to be = something other than application/json, and it doesn't work against an RS = without additional profiling since it takes over the request body - plus = we have to specify different delivery locations for a GET vs. a POST, = for example." >=20 > Not being application/json is a feature as the AS can detect the = signature mechanism. Per above, the requirements for the AS and RS are = different. The client can use the same mechanism of signing with an = empty body and placing the JWS in an HTTP header just as it does below = for requests with no body. The RS is proving it was given the access = token by the AS, and binding that to time, URI, and method. >=20 The note is accurate, it gets in the way of the RS=E2=80=99s input. This = signature wouldn=E2=80=99t work on an XML-based API, for example. And = what of an empty POST request? An API would now need to look for either = an empty body OR a JSON body. Or take a JSON based API, but one that=E2=80= =99s implemented with a strictly typed parser. Not only would you need = to pre-process the JOSE in order to extract the JSON (which I=E2=80=99ve = done in my implementation of this section, and it=E2=80=99s not pretty), = but now you=E2=80=99d also need to remove the additional fields that = cover the HTTP elements. The detached JWS method described in 8.1 would work in all of these = cases =E2=80=94 but with the developer doing the same thing every time. >=20 > The editor note=20 >=20 > "Additionally it is potentially fragile like a detached JWS since a = multi-tier system could parse the payload and pass the parsed payload = downstream with potential transformations. We might want to remove this = in favor of general-purpose HTTP signing, or at least provide guidance = on its use."=20 >=20 > is very misleading. The whole point is to pass the JWS between = components so that each can independently verify the request. ALL the = other mechanisms have the fragility described as different components = are going to pass around the JSON -- and even if they pass around the = detached signature information and other headers, a component could = transform the JSON in parsing and stringifying the request. >=20 Right, what I=E2=80=99m saying is that your specific use case has some = clear assumptions about the way integrity is processed within the = system. All of those need to be enumerated very carefully. > The straightforward way to use JOSE from a developers point of view = would be: >=20 > - use JWT > - include the key in the header > - have "iat", the method, and the URI in the payload > - put the JWT in the HTTP Authorization header for methods without a = body >=20 > This is how I wrote it in my implementation. It was very = straightforward. >=20 > Only the last point conflicts with GNAP as now written -- all the = other aspects could be how it is done for JWT. Additionally, the proposal laid out here has a significant anti-pattern = in including both the HTTP method and the HTTP URI in the HTTP entity = body itself. Doing so is not only redundant, but it causes more error = conditions that the application layer would need to check against. = Requiring these in all requests, and not just for the JOSE requests, = would also put a burden on other signature mechanisms that don=E2=80=99t = need it. HTTP Message Signatures, DPoP signatures, and (the historical) = OAuth PoP signatures all have mechanisms for including the HTTP elements = in the signature outside of the message body. Mutual TLS binding does = not need to extend the HTTP message at all in order to cover all aspects = under the signature. Why should all of these mechanisms put HTTP = components in the body? I understand that your own use case requires the incoming message to be = fully protected as a single unit, and the functionality in 8.2 enables = this, as we have discussed. Can you please explain how 8.2 does not = address your use case? I understand that it=E2=80=99s not how you built = it, but I think it=E2=80=99s important to understand what this different = approach would make impossible or difficult with what you=E2=80=99re = trying to solve. >=20 >=20 > Additional feedback > the document name is redundant - protocol is in it twice > (gnap =3D Grant Negotiation and Authorization Protocol)-core-protocol > "draft-ietf-gnap-core" would be sufficient >=20 The document name was suggested by the chairs. > 1.2 Elements > Key - "A cryptographic element binding a request to the holder of the = key." > It is actually any holder of the key.=20 Yes, thanks. >=20 > 2.2 Editor's note "you'd need a full identity protocol and not just = this" implies that GNAP is not an identity protocol despite it = supporting the OpenId Connect use cases.=20 GNAP supporting some of OIDC=E2=80=99s use cases does not make it a full = identity protocol, and there was significant pushback in GNAP trying to = define a full identity protocol with user schemas, authenticator = classes, assertion formats, authentication event information, and all of = that. There was middle ground in defining a few simple elements of the = OIDC use case, such as identifying the current user.=20 >=20 > 3.5 Do we need this section? The only thing with "handle" in the name = is user_handle. The access token is not really a handle.=20 Yes, I believe it provides necessary functionality. This section is for = providing a dynamic identifier that the RC can use for itself, and one = that it can use for the RQ in future requests. This section does mention = access tokens except in the example. =E2=80=94 Justin --Apple-Mail=_A03A0575-A069-4CE8-83A8-1A632AEEE983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 19, 2020, at 11:26 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Previous Feedback
The following items were = discussed in the design team, but did not make it into the draft = for WG discussion. A concern I have with many of the editor notes = (which I point out) is that they are heavily biased by Justin's vision = and misrepresent the options.


I= do not think this is an accurate representation of either the design = team process or the resulting document. The point of the editor=E2=80=99s = notes were to lay out options and capture discussion, and not just to = present my own limited view of the world. I do not personally agree with = all of the statements in every editor=E2=80=99s note, nor do I = personally think that all the options presented are equal =E2=80=94 but = even so, acting as editor for the design team, I sought to capture those = options as best as I could, and add commentary and context where = possible. The design team provided feedback to the document and to the = editor=E2=80=99s notes, and while they aren=E2=80=99t perfect, I do not = think that they are biased as you claim.

Even so, like Fabien, I do hope we can move past = this somehow lingering bitterness and the working group can build a good = protocol.

Most of the feedback I=E2=80= =99m giving here has been brought up before, either on the public list, = in the design team calls, or in design team emails. 

Again, apologies for the lengthy response email. = As I mentioned in the other thread, I personally think items like the = list here are better captured as GitHub issues, and I=E2=80=99d like to = see us move to that mechanism for capturing things soon, if we = can.

Abstract: "information passed directly to the = software" can mean pretty much anything. The charter has "user = identifiers, and identity = assertions." 

The charter, as you know, is guidance for the = group and not dictate. Even so, the charter itself includes this line = which is what the abstract text in question was based off = of:

	- =
Optimized inclusion of additional information (including identifiers and=20=

	=
identity assertions) through the delegation process

The charter specifically = does not limit what the protocol could be used for, only what this WG = will define for its use. Therefore I was attempting to capture the = broader scope of possibility in the abstract.


1. Same point as in = Abstract around "information".

1.1 = Roles: 
Add in roles for operators of AS and = RC. 

What roles do these play in the protocol itself? = They may exist in deployments, but the roles should be defined in terms = of the protocol.

Show trust framework between legal entities (user, RO, client = operator, AS operator)

Does this working group really want to get into = the definition of legal relationships? There are such a wide variety of = possible deployments and trust models, most of which don=E2=80=99t = affect the nature of the protocol itself, that I=E2=80=99m not sure we = can narrow that down.

Differentiate between legal entities having a relationship or = HCI and the actual protocol roles (RC, AS, = RS)

The = current draft does not define any legal entities, only protocol roles = (including human roles like RO and RQ).

What is the difference between roles and parties? Can we = avoid the term parties? RQ is both a party and a = role.

RQ is = a role and is defined as such =E2=80=94 only in the name =E2=80=9CRequesti= ng Party=E2=80=9D (which as noted was taken from UMA2) does =E2=80=9Cparty= =E2=80=9D occur. The name of this entity is up for discussion, still, = and this is a reasonable argument for moving away from =E2=80=9CRequesting= Party=E2=80=9D.

=E2=80=9CParties=E2=80=9D are = traditionally entities that fill a role. I did try to avoid the use of = =E2=80=9Cparty=E2=80=9D where its use would be inaccurate or ambiguous, = though I=E2=80=99m sure this could be cleaned up if you have specific = instances of such language.

Alternative names:
client for = RC
user for = RQ

These = are already listed with the terms themselves.


1.2 Elements:
defined = access token without using = "credential"

This is largely modeled on the OAuth 2 definition = of access token. Can you expand on your issue with the term = =E2=80=9Ccredential=E2=80=9D here? Do you have an alternate definition = to propose?

Grant as both a = noun (what is being requested) and a verb 
Grant= is already is a noun being used as an adjective in "Grant Negotiation = ..." and "Grant Response"

Grant as a noun is problematic in several ways, = not the least of which is that it conflicts with how =E2=80=9Cgrant=E2=80=9D= is both used (=E2=80=9Ca credential given to the client to trade for a = token=E2=80=9D) and understood (=E2=80=9Cthe kind of action the client = has to take=E2=80=9D) in OAuth 2. It also leads to confusing semantic = satitation when used in context with the verb form. 

If we follow the plain definitions outside of = OAuth2, the =E2=80=9Cgrant=E2=80=9D is the result of the request, but = what we tend to talk about is the ongoing state of the request. I would = love for us to have a better term for this artifact =E2=80=94 I had = previously termed this element =E2=80=9Cthe = transaction=E2=80=9D. 

"Subject Information" is better than just "information" -- = but is still extremely broad
The subject = information should be about the user, not the RO. For example, in an = enterprise use case where resource access and identity claims are = being requested, the RO is not the user, but could be an administrator. = The "subject information" is going to be about the user of the client, = not the administrator.

I agree this is where things need to be made more = explicit, especially when stretched across different use cases. The = =E2=80=9Cnormal=E2=80=9D use case where the RQ and RO are the same = person collapses this fine, but not in all cases. Could an RQ request = =E2=80=9Csubject information=E2=80=9D about another user (the RO)? This = isn=E2=80=99t dissimilar to the CIBA use case of a call-center = =E2=80=9Clogin". Ultimately, I think we need to nail down which = =E2=80=9Csubject=E2=80=9D this returned information is about.


1.3.3 step 7 - what is a refreshed = credential? We should refer to the defined = terms.

It=E2=80= =99s specifically the URI and token values within the =E2=80=9Ccontinue=E2= =80=9D element that are returned from the AS, so this text can be = reworded. 

2. title should be = Grant Request to match with Grant Response in (3), and use of "Grant = Request" in 2.7, 2.9, 5, 5.4, & = 5.5 

Thanks, terminology can be made more consistent = throughout the document, for sure.


2.1.2: = "a RC MAY send a string known to the AS or RS"
why = "or"? Explain.


This logic is based on how OAuth 2 scopes are used = in many places.

If the AS knows = about the string, it can enforce policies on what an RO can approve or = an RC can request. It=E2=80=99s really common to have these kinds of = policies. If the AS doesn=E2=80=99t know about the string, the AS can = still provide the request to the RO for approval and convey the approved = string information to an RS downstream for enforcement.

If the RS knows about the string, it can enforce = policies on what the token is good for, assuming the string is conveyed = to the RS as-is. Alternatively, the RS could be naive about the = requested string and instead rely on the AS to translate the string into = something specific for the RS to consume. 

This is not an exclusive =E2=80=9Cor=E2=80=9D, of = course. If both the AS and RS know about the string, that also works = fine.

2.2 "sub_ids"
are sub_ids a good = idea, a best practice? despite warnings in the protocol, developers will = use an email identifier as a communication identifier, or worse, a = verified identifier. 
GNAP is defining a query = language here for subject = identifiers. 

We know from years of experience with OIDC and = OAuth 2 that client developers want to have an identifier they can = correlate to other information within their applications, and this is a = feature to address that. 


2.3 = Identifying a client via URL
Mobile Apps and = SPA can identify themselves with an HTTPS url that only that client can = receive redirects to (universal link in iOS, android app link). The = client passes the general identifier for the client (class_id?) and the = AS ensures the redirect URI belongs to that client. A parameter is = passed on the redirect to the client that the client presents to the AS = to prove it is an instance of that client. The AS may then release = access and claims to the client. The AS may also provide an instance = identifier for the client so that instance of the client can uniquely = identify itself.

The editor note that instance_id is analogous to the = client_id prevents an instance of the client in the preceding paragraph = from uniquely identifying itself, and the name is = misleading.

The conflict only occurs if you want to call the = class_id the client_id. In practice, to serve this kind of client, the = AS would register a class_id and the developer would include that = class_id with every initial request. 


Additionally, = pre-registered identifiers (class_id which should be equivalent to = client_id for confidential clients) and dynamic identifiers = (instance_id) have different operational and infrastructure = requirements. pre-registered identifiers should be read only for the AS = vs read / write for the AS. There may be millions of dynamic identifier = for one pre-registered identifier (mobile app, = SPA)

Thus = why a class_id and an instance_id are different, and we no longer have = =E2=80=9Cclient_id=E2=80=9D that confuses the = concepts. 

I think it would be = worthwhile to add an explicit =E2=80=9Cclass_id=E2=80=9D field, but as I = recall in the design team we didn=E2=80=99t quite settle on = that.

What are you proposing should = change?


2.3.1 Do we need to = support symmetric keys? Most OAuth clients support a secret, not a = key.

I = believe we should support symmetric keys (but not client secrets). I = also believe that we can safely do so using the client instance = reference, as laid out by the discussion in the section.

The problems with symmetric crypto largely come = from key distribution and not the actual cryptography. If the keys are = pre-placed or securely delivered or derived out-of-band, symmetric = crypto will fit fine in this space.


2.3.2
what are the supported public = key formats?

What=E2=80=99s listed in the document are = currently JWK and PEM, these should be expandable to other formats (CWK = for example).

What if the client is able to use different proofing = mechanisms? How does it negotiate with the = AS?

Inline = negotiation of proofing mechanisms is dangerous at best, since the RC = needs to protect the negotiation request. 

Most clients are likely to have one method that = they always do, and it will be based on the key material that they have = access to, but the discovery mechanisms in the draft would allow a more = capable client of dynamically selecting a mechanism. 

Yaron raised the point of what is Mandatory to = Implement, and I agree that this is something that should be.



2.4.1 = identifying the user
this identifier would be = useful if it had properties that other opaque identifiers did not have: = being globally unique. A reason developers have used the email in ID = Tokens was that it was a globally unique string in contrast to the tuple = of "iss" and "sub" in the ID Token which was much more complicated to = add and work with in a DB. Otherwise, we are creating yet another user = identifier.

This identifier is very narrowly focused, and is = used for the RC to communicate its notion of =E2=80=9Cthe current = user=E2=80=9D back to the AS specifically. With that focus, it doesn=E2=80= =99t need to be globally unique or even recognizable to the RC, just a = string assigned by the AS. There are other subject identifiers that can = fulfill a =E2=80=9Cglobally unique=E2=80=9D role instead. Globally = unique identifiers for users are discussed in section 3.4 and linked = from several sections, as was suggested during design team = conversations. Section 3.5 (that defines where this string might come = from) discusses that the user_handle string talked about here could = potentially be replaced by a more general mechanism instead of this = narrowly-focused one, which could in turn have the aspects you are = discussing.


2.5 interaction = capabilities / modes (section 3.3 as well)
While = the document has renamed "interaction capabilities" to "interaction = modes", but the client is still declaring capabilities, but in 3.3 there = are conflicting statements

"If the RC has indicated a capability to interact with the RO = in its request (Section 2.5)"

The AS MUST NOT respond with any = interaction mode that the RC did not indicate in its request. 

These are not in conflict =E2=80=94 the intended = interpretation is that IF the AS responds to an interaction then it does = it in a particular way, not that it MUST respond to an interaction it = doesn=E2=80=99t know how to handle. The rest of the sentence quoted = above states in full (emphasis added):

If the RC has indicated a capability to interact with the RO = in its request (Section 2.5), and the AS has determined that interaction is both supported and necessary, the AS responds to the RC with any of the following values in the interact field of the = response.

In addition, all of the = subsections in 3.3 have text like the following (emphasis = added):

If the RC indicates that it can = redirect to an arbitrary = URL (Section 2.5.1) and the AS supports this mode for the RC's request,

So the RC declares what = it can do, and the AS responds to any parts that:

- the AS supports
- the AS = determines are appropriate for what=E2=80=99s being requested (resources = and subject info)
- the AS allows for that specific = RC instance
- the AS allows for any = identified RO in the request

The = combination of these together tell the RC exactly what it is allowed to = do.

Do you have a suggestion on how = to make that more clear?

using the same 4 interaction modes in = the client request would make it easier for the client to say which = modes it supports, and the AS to respond with which modes are allowed. = It also allows all parameters required for a mode to be in the mode. For = example the URL for a double redirection, vs a redirection to an = information page after a user_code or decoupled = redirect.

As = has been discussed at length, what you describe here is the same = negotiation model as in the draft. The only difference is whether the = post-interaction method is bundled as a property of the engagement = method, which is discussed in detail in the notes along with two = different proposals of how it could be done.


2.5 declaring RC capabilities
Editor's note on what this is supposed to do, and why it = can't be done by just adding the properties to the = request.

This= is a proposal for an inline advanced discovery mechanism. I=E2=80=99m = personally not a fan of keeping it if we don=E2=80=99t have a concrete = use for it, but at this stage it=E2=80=99s important to have options = like this listed.

2.7 perhaps this = could be done by updating  an existing Grant Request. This seems = overly complicated.

Updating an existing request is a different use = case, much like refreshing an access token is different from deriving an = access token through token exchange. 


2.8 Perhaps this should be in 2.2 where we are = requesting information about the user?
Given that = solving the use cases solved by OIDC is in conflict with the editor note = that OIDF should be doing the integration with GNAP. The current model = is confusing as requests are in one object, and responses are in a = different object. We don't have to combine the userinfo endpoint request = with the id_token request just because that was convenient for OIDC. The = editorial comments make thi seem much messier than it is.


I agree that it=E2=80=99s not ideal to combine the = userinfo and id_token elements, but that=E2=80=99s how OIDC defined this = query language, and an important aspect of this query language is that = the top-level element of the query object defines the =E2=80=9Ctarget=E2=80= =9D of the requested claims. We could ignore this part of the spec, but = if we are to use the OIDC query language, we shouldn=E2=80=99t be = re-defining how it works, which is what splitting up the components = would do. 

This stance is based = on having implemented OIDC claims processing on several platforms. If we = were to break up the claims query language, it would be difficult to = re-use any existing parsing and processing mechanisms. It would also not = work for extensions to the OIDC claims query language, such as one = that=E2=80=99s proposed for VC=E2=80=99s: https://mattrglobal.github.io/oidc-client-bound-assertions-spec= /

I would rather see us focus on = general purpose mechanisms for requesting resources, subject = identifiers, and bound assertions. 

3. The URI can be stable, and the access = token is potentially superfluous. As the client is authenticating with = the same key in all subsequent requests, rotation of the URI or access = token may be superfluous. Having an access token for the AS seems that = is used while authenticating vs the typical access token for an RS seems = very confusing to a developer.

The key here is that this is a :bound: access = token, just one that is bound to the client=E2=80=99s key in this case. = It=E2=80=99s exactly the same mechanism that the RC would use to call = the RS, and that separation of concerns is a key feature of this = architecture. If we are expecting GNAP developers to be confused by = being asked to present an access token, then I don=E2=80=99t think we = have much hope. :)

Additionally, putting the access token = for calls to the AS in the HTTP Authorization header precludes using the = HTTP Authorization header for client authentication in = 8.

The = purpose of the key presentation is not just for client authentication, = but about binding the message to a particular key holder. This is what = allows the same mechanisms to be used across different elements of the = protocol instead of having to invent new things for each piece.


4.4.2 This functionality looks like a = WebHook, and perhaps belongs in the API between the client and the AS = rather than an interaction that involves the user. Also, this = functionality provides no protection to session fixation. The = interaction reference has no = value.

It=E2=80= =99s functionality that is triggered post-interaction, just like a = post-interaction redirect to a callback URL (or the static page option = proposed in the notes).

4.4.3 While it is = good to see an editor's note that a unique callback URL could = be used, the statement "but it would not prevent an attacker from = injecting an unrelated interaction reference into this channel." is = misleading. This would only happen if the client did not ensure it is = the same user, as that would be linked to the correct URL. = Similarly, the interaction reference does not provide protection if the = client does not ensure it is the same user.
Using a = unique callback URL would be much simpler, and appears to provide the = same protection as the interaction reference and the hashing.


I believe the unique URLs and reference/hash = mechanism solve different but related problems. This is an area for = discussion, but I don=E2=80=99t see a reason to :not: have cryptographic = protection on front channel mechanisms. OAuth 2 started without it, but = OIDC added them back in (with hybrid mode) and now JARM is defining a = general-purpose way to do that.

5. 
Continuing a = Grant Request (which in (2) is called an Access Request)
Is "continuing the right word"?
We are = either "validating" the request (5.1), polling the request (5.2), = modifying the request (5.3), reading the request (5.4), or cancelling = the request (5.5).

I believe =E2=80=9Ccontinue=E2=80=9D is a wide = enough net to cover all of these, as it=E2=80=99s action on a = previously-started request. Do you have a suggestion for a better = encompassing term?

Include editorial discussion of = replacing a request, replacing part of a request, and adding to a = request, and if we should have semantics for all 3 = mechanisms.

This seems to be covered in the discussion on = updating the request and constraints on the atomicity of each portion of = the request. 

8
While some binding mechanisms work the same for the client = calling the AS as the RS, the requirements are different. When the = client calls the AS, the client is authenticating. When the client is = calling the RS, the client is proving it is authorized to access the = resource. The RS does not need to know the identity of the client -- = just that it is the client that the AS gave the access token = to.

None of = the mechanisms require the RS to know the identity of the RC. The AS can = verify the RC instance=E2=80=99s identity based on its key, if the AS = knows the key and has it associated to an instance. But I=E2=80=99d also = add that the AS doesn=E2=80=99t need to know the identity of the RC = either, in dynamic cases, since the key is just being introduced. In = those cases, as you state above, the =E2=80=9Cauthentication=E2=80=9D of = the client is a more complex process involving class identifiers (as = well as device posture and the like). This is an important discussion = for the WG to have as it gets at our model of what a =E2=80=9Cclient=E2=80= =9D is on several dimensions.

Could = you please expand on how you see using the same set of binding = mechanisms across the protocol would cause problems for AS, RS, or RC = developers? 

8.2 Attached = JWS
Why not a = JWT?

This = is not a token, therefore JWT is not an appropriate technology. JWS is = appropriate as it provides a signature mechanism, which is what=E2=80=99s = being discussed here.

This is the ONLY self contained mechanism. All the other ones = require all, or most of the HTTP headers and the body to be kept = together.

That=E2=80=99s correct, are you suggesting a = change, or that this should be called out more explicitly?


The editor note

"Alternatively, we could add all these = fields to the body of the request, but then it gets awkward for non-body = requests like GET/DELETE."

It is not awkward. A mechanism is described later of having = the JWS as an HTTP header. Something JWS was designed = for.

I = think it=E2=80=99s incredibly awkward for the signature layer to mess = around with the payload of the HTTP message itself. It breaks the = separation of these layers, and now the signature layers need to know = about the content and format of the HTTP message.

For instance, you=E2=80=99d have to have the = client put the signature parameters (such as HTTP method and URI) either = in the body of the request OR in a special body that=E2=80=99s used only = in body-less requests, depending on what you=E2=80=99re doing. This is = on top of putting the signed element in a different place when you=E2=80=99= re done with it. 


The = editor note

"A = downside to this method is that it requires the content type to be = something other than application/json, and it doesn't work against an RS = without additional profiling since it takes over the request body - plus = we have to specify different delivery locations for a GET vs. a POST, = for example."

Not being application/json is a feature = as the AS can detect the signature mechanism. Per above, the = requirements for the AS and RS are different. The client can use the = same mechanism of signing with an empty body and placing the JWS in an = HTTP header just as it does below for requests with no body. The RS is = proving it was given the access token by the AS, and binding that to = time, URI, and method.


The note is accurate, it gets in the way of the = RS=E2=80=99s input. This signature wouldn=E2=80=99t work on an XML-based = API, for example. And what of an empty POST request? An API would now = need to look for either an empty body OR a JSON body. Or take a JSON = based API, but one that=E2=80=99s implemented with a strictly typed = parser. Not only would you need to pre-process the JOSE in order to = extract the JSON (which I=E2=80=99ve done in my implementation of this = section, and it=E2=80=99s not pretty), but now you=E2=80=99d also need = to remove the additional fields that cover the HTTP = elements.

The detached JWS method = described in 8.1 would work in all of these cases =E2=80=94 but with the = developer doing the same thing every time.


The= editor note 

"Additionally it is potentially fragile like a detached JWS = since a multi-tier system could parse the payload and pass the parsed = payload downstream with potential transformations. We might want to = remove this in favor of general-purpose HTTP signing, or at least = provide guidance on its use." 

is very misleading. The whole point is = to pass the JWS between components so that each can independently = verify the request. ALL the other mechanisms have the fragility = described as different components are going to pass around the JSON -- = and even if they pass around the detached signature information and = other headers, a component could transform the JSON in parsing and = stringifying the request.


Right, what I=E2=80=99m saying is that your = specific use case has some clear assumptions about the way integrity is = processed within the system. All of those need to be enumerated very = carefully.

The = straightforward way to use JOSE from a developers point of view = would be:

- = use JWT
- include the key in the header
- have "iat", the method, and the URI in the = payload
- put the JWT in the HTTP Authorization = header for methods without a body

This is how I wrote it in my = implementation. It was very straightforward.

Only the last point conflicts with GNAP = as now written -- all the other aspects could be how it is done for = JWT.

Additionally, the proposal laid out here has a = significant anti-pattern in including both the HTTP method and the HTTP = URI in the HTTP entity body itself. Doing so is not only redundant, but = it causes more error conditions that the application layer would need to = check against. Requiring these in all requests, and not just for the = JOSE requests, would also put a burden on other signature mechanisms = that don=E2=80=99t need it. HTTP Message Signatures, DPoP signatures, = and (the historical) OAuth PoP signatures all have mechanisms for = including the HTTP elements in the signature outside of the message = body. Mutual TLS binding does not need to extend the HTTP message at all = in order to cover all aspects under the signature. Why should all of = these mechanisms put HTTP components in the body?

I understand that your own use case requires the = incoming message to be fully protected as a single unit, and the = functionality in 8.2 enables this, as we have discussed. Can you please = explain how 8.2 does not address your use case? I understand that it=E2=80= =99s not how you built it, but I think it=E2=80=99s important to = understand what this different approach would make impossible or = difficult with what you=E2=80=99re trying to solve.



Additional = feedback
the document name is redundant - = protocol is in it twice
(gnap =3D Grant Negotiation = and Authorization Protocol)-core-protocol
"draft-ietf-gnap-core" would be sufficient


The document name was suggested by the = chairs.

1.2 = Elements
Key - "A cryptographic element binding a = request to the holder of the key."
It is actually = any holder of the = key. 

Yes, thanks.


2.2 Editor's note "you'd = need a full identity protocol and not just this" implies that GNAP is = not an identity protocol despite it supporting the OpenId Connect use = cases. 

GNAP supporting some of OIDC=E2=80=99s use cases = does not make it a full identity protocol, and there was significant = pushback in GNAP trying to define a full identity protocol with user = schemas, authenticator classes, assertion formats, authentication event = information, and all of that. There was middle ground in defining a few = simple elements of the OIDC use case, such as identifying the current = user. 


3.5 Do we need this section? The only = thing with "handle" in the name is user_handle. The access token is not = really a handle. 

Yes, I believe it provides necessary = functionality. This section is for providing a dynamic identifier that = the RC can use for itself, and one that it can use for the RQ in future = requests. This section does mention access tokens except in the = example.

 =E2=80=94 = Justin

= --Apple-Mail=_A03A0575-A069-4CE8-83A8-1A632AEEE983-- From nobody Thu Oct 22 16:02:17 2020 Return-Path: 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 989FB3A0965 for ; Thu, 22 Oct 2020 16:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 5fmgsvUivlhb for ; Thu, 22 Oct 2020 16:02:09 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450: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 0182F3A0969 for ; Thu, 22 Oct 2020 16:02:08 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id b1so4269101lfp.11 for ; Thu, 22 Oct 2020 16:02:08 -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=gqL8JrP9F8IoOmMghUkoXNvsJOa29vOMmDQ0K+VKjLs=; b=HDum3ciZOCSuWbXQsImfLxmvIRIr6TUnbQAiK3zo37w3rTuFF8Q53DWJZXWVGH8aeL UTnrOXZnOXUaWl96RPD2sPjKmt2/XRFRLg0ngaV+wRZOSC3jnmeap+UKlVDR59j8wIvg +zu3V16+BAfwP3rVZ0S3elj5pmgB9KVCZNHKs5SAK9q7UvqasPlU/gijGsrdm/U6upkh XpmHzFcNfmhxu+6Zozo+O6N5rvMSwdOaw30u1OJ4NLlxzyap302ahNpezbNJAnZpKLOC rMSqgYZJUq3INiMQ9UnsuyErODb6oxiYnXjoVId3Av/gqENMMLk6JK6xc8yLKpAAy04V vUCQ== 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=gqL8JrP9F8IoOmMghUkoXNvsJOa29vOMmDQ0K+VKjLs=; b=FxSRAPdy4jg31yufLfSNic3NTvytM5driJk+UqYgN2Dczt6IZPpBI5AbKXbMbkmpFP Eo3suCFWQEcdEizor/oUG0W48XpvHBwe92vzVePm0JcTlLhbpp3lSqdFkVh+lwJP0vCZ Ze7eZLH91bhwLC0GqRRQ8oHVk2jE9ECdaso2wIrCw0EiQxbyHUzxGjI76sCo2+MgBQRY NMJLDE7qg1Tx3w/A5VmPxHuNRi9SB7+rGmcRjv0ab7845JaMr0TYnpoEAfskzYrWWUXb P/1ESD2Ez27PdB4HnUPJmXy/rNo6BRTvm8ndHRm9Oesb5r4RPBxepCy/nNMAkSGCjsIJ qbtg== X-Gm-Message-State: AOAM532/1MSihQp84l/m7d1YHFNhqW5SDMjFCI+olMOKZ7LjHnEdbjlS p1tL+WMcsTEj+1Z3AGjPvOPKO00cIHVozCdsers= X-Google-Smtp-Source: ABdhPJz3xzzKJo9WxHCGTzXL3KZpOJg1hpK9sWgmGXqM+s559qU1ioOBRCyUAPG8HCeveJrLD8YPW3qu2SIRk1E/cRc= X-Received: by 2002:a19:cb14:: with SMTP id b20mr1505308lfg.162.1603407726706; Thu, 22 Oct 2020 16:02:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 22 Oct 2020 16:01:29 -0700 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000fb06ea05b24a7398" Archived-At: Subject: Re: [GNAP] draft-ietf-gnap-core-protocol-00 feedback X-BeenThere: txauth@ietf.org 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, 22 Oct 2020 23:02:16 -0000 --000000000000fb06ea05b24a7398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, below are items I brought up, or noted in the draft, that I'd like to have added to the draft for WG discussion. On Wed, Oct 21, 2020 at 12:22 PM Justin Richer wrote: > On Oct 19, 2020, at 11:26 PM, Dick Hardt wrote: > > *Abstract:* "information passed directly to the software" can mean pretty > much anything. The charter has "user identifiers, and identity assertions= ." > > > The charter specifically does not limit what the protocol could be used > for, only what this WG will define for its use. Therefore I was attemptin= g > to capture the broader scope of possibility in the abstract. > I think it is so broad that it does not help a reader understand what the document is about. Would you add a note to have this discussed? This broad of a definition is new. > > > *1. *Same point as in Abstract around "information". > > *1.1* Roles: > Add in roles for operators of AS and RC. > > > What roles do these play in the protocol itself? They may exist in > deployments, but the roles should be defined in terms of the protocol. > The user and the RO don't move bits or do anything normative. The roles of operators are part of the trust. Please add to discussion. > > Show trust framework between legal entities (user, RO, client operator, A= S > operator) > > > Does this working group really want to get into the definition of legal > relationships? There are such a wide variety of possible deployments and > trust models, most of which don=E2=80=99t affect the nature of the protoc= ol itself, > that I=E2=80=99m not sure we can narrow that down. > I think it is a pretty straightforward trust relationship as I outlined in XAuth. Please add to discussion. > > Differentiate between legal entities having a relationship or HCI and the > actual protocol roles (RC, AS, RS) > > > The current draft does not define any legal entities, only protocol roles > (including human roles like RO and RQ). > Perhaps legal entities is the wrong term -- but there are non-protocol entities that we want to reference. > > What is the difference between roles and parties? Can we avoid the term > parties? RQ is both a party and a role. > > > RQ is a role and is defined as such =E2=80=94 only in the name =E2=80=9CR= equesting Party=E2=80=9D > (which as noted was taken from UMA2) does =E2=80=9Cparty=E2=80=9D occur. = The name of this > entity is up for discussion, still, and this is a reasonable argument for > moving away from =E2=80=9CRequesting Party=E2=80=9D. > > =E2=80=9CParties=E2=80=9D are traditionally entities that fill a role. I = did try to avoid > the use of =E2=80=9Cparty=E2=80=9D where its use would be inaccurate or a= mbiguous, though > I=E2=80=99m sure this could be cleaned up if you have specific instances = of such > language. > > Alternative names: > client for RC > user for RQ > > > These are already listed with the terms themselves. > But they are not listed as options. Please list all options that we are thinking of. > > > *1.2* Elements: > defined access token without using "credential" > > > This is largely modeled on the OAuth 2 definition of access token. Can yo= u > expand on your issue with the term =E2=80=9Ccredential=E2=80=9D here? Do = you have an > alternate definition to propose? > It is not defined. Can we define access token without using the word credential? > > Grant as both a noun (what is being requested) and a verb > Grant is already is a noun being used as an adjective in "Grant > Negotiation ..." and "Grant Response" > > > Grant as a noun is problematic in several ways, not the least of which is > that it conflicts with how =E2=80=9Cgrant=E2=80=9D is both used (=E2=80= =9Ca credential given to the > client to trade for a token=E2=80=9D) and understood (=E2=80=9Cthe kind o= f action the > client has to take=E2=80=9D) in OAuth 2. It also leads to confusing seman= tic > satitation when used in context with the verb form. > > If we follow the plain definitions outside of OAuth2, the =E2=80=9Cgrant= =E2=80=9D is the > result of the request, but what we tend to talk about is the ongoing stat= e > of the request. I would love for us to have a better term for this artifa= ct > =E2=80=94 I had previously termed this element =E2=80=9Cthe transaction= =E2=80=9D. > This is your opinion. I think that using grant as a noun as well allows us to describe what is granted. Please add to discussion. > > "Subject Information" is better than just "information" -- but is still > extremely broad > The subject information should be about the user, not the RO. For example= , > in an enterprise use case where resource access and identity claims are > being requested, the RO is not the user, but could be an administrator. T= he > "subject information" is going to be about the user of the client, not th= e > administrator. > > > I agree this is where things need to be made more explicit, especially > when stretched across different use cases. The =E2=80=9Cnormal=E2=80=9D u= se case where the > RQ and RO are the same person collapses this fine, but not in all cases. > Could an RQ request =E2=80=9Csubject information=E2=80=9D about another u= ser (the RO)? This > isn=E2=80=99t dissimilar to the CIBA use case of a call-center =E2=80=9Cl= ogin". Ultimately, > I think we need to nail down which =E2=80=9Csubject=E2=80=9D this returne= d information is > about. > please add to discussion > > > *1.3.3* step 7 - what is a refreshed credential? We should refer to the > defined terms. > > > It=E2=80=99s specifically the URI and token values within the =E2=80=9Cco= ntinue=E2=80=9D element > that are returned from the AS, so this text can be reworded. > > > *2.* title should be Grant Request to match with Grant Response in (3), > and use of "Grant Request" in 2.7, 2.9, 5, 5.4, & 5.5 > > > Thanks, terminology can be made more consistent throughout the document, > for sure. > > > *2.1.2:* "a RC MAY send a string known to the AS or RS" > why "or"? Explain. > > > This logic is based on how OAuth 2 scopes are used in many places. > > If the AS knows about the string, it can enforce policies on what an RO > can approve or an RC can request. It=E2=80=99s really common to have thes= e kinds of > policies. If the AS doesn=E2=80=99t know about the string, the AS can sti= ll provide > the request to the RO for approval and convey the approved string > information to an RS downstream for enforcement. > > If the RS knows about the string, it can enforce policies on what the > token is good for, assuming the string is conveyed to the RS as-is. > Alternatively, the RS could be naive about the requested string and inste= ad > rely on the AS to translate the string into something specific for the RS > to consume. > > This is not an exclusive =E2=80=9Cor=E2=80=9D, of course. If both the AS = and RS know about > the string, that also works fine. > please clarify in text > > *2.2* "sub_ids" > are sub_ids a good idea, a best practice? despite warnings in the > protocol, developers will use an email identifier as a communication > identifier, or worse, a verified identifier. > GNAP is defining a query language here for subject identifiers. > > > We know from years of experience with OIDC and OAuth 2 that client > developers want to have an identifier they can correlate to other > information within their applications, and this is a feature to address > that. > please add as an item to be discussed > > > *2.3 *Identifying a client via URL > Mobile Apps and SPA can identify themselves with an HTTPS url that only > that client can receive redirects to (universal link in iOS, android app > link). The client passes the general identifier for the client (class_id?= ) > and the AS ensures the redirect URI belongs to that client. A parameter i= s > passed on the redirect to the client that the client presents to the AS t= o > prove it is an instance of that client. The AS may then release access an= d > claims to the client. The AS may also provide an instance identifier for > the client so that instance of the client can uniquely identify itself. > > The editor note that instance_id is analogous to the client_id prevents a= n > instance of the client in the preceding paragraph from uniquely identifyi= ng > itself, and the name is misleading. > > > The conflict only occurs if you want to call the class_id the client_id. > In practice, to serve this kind of client, the AS would register a class_= id > and the developer would include that class_id with every initial request. > > > Additionally, pre-registered identifiers (class_id which should be > equivalent to client_id for confidential clients) and dynamic identifiers > (instance_id) have different operational and infrastructure requirements. > pre-registered identifiers should be read only for the AS vs read / write > for the AS. There may be millions of dynamic identifier for one > pre-registered identifier (mobile app, SPA) > > > Thus why a class_id and an instance_id are different, and we no longer > have =E2=80=9Cclient_id=E2=80=9D that confuses the concepts. > I agree they are different. Your suggestion is a pre registered app use instance_id on first use. I'm saying it should be class_id. > > I think it would be worthwhile to add an explicit =E2=80=9Cclass_id=E2=80= =9D field, but as > I recall in the design team we didn=E2=80=99t quite settle on that. > > What are you proposing should change? > I'm proposing that you add my suggestion as a discussion point. > > > *2.3.1 *Do we need to support symmetric keys? Most OAuth clients support > a secret, not a key. > > > I believe we should support symmetric keys (but not client secrets). I > also believe that we can safely do so using the client instance reference= , > as laid out by the discussion in the section. > > The problems with symmetric crypto largely come from key distribution and > not the actual cryptography. If the keys are pre-placed or securely > delivered or derived out-of-band, symmetric crypto will fit fine in this > space. > Please add as a discussion point. > > > *2.3.2* > what are the supported public key formats? > > > What=E2=80=99s listed in the document are currently JWK and PEM, these sh= ould be > expandable to other formats (CWK for example). > It is vague in the document where referenced. > > What if the client is able to use different proofing mechanisms? How does > it negotiate with the AS? > > > Inline negotiation of proofing mechanisms is dangerous at best, since the > RC needs to protect the negotiation request. > > Most clients are likely to have one method that they always do, and it > will be based on the key material that they have access to, but the > discovery mechanisms in the draft would allow a more capable client of > dynamically selecting a mechanism. > > Yaron raised the point of what is Mandatory to Implement, and I agree tha= t > this is something that should be. > Please add as a discussion. > > > > *2.4.1* identifying the user > this identifier would be useful if it had properties that other opaque > identifiers did not have: being globally unique. A reason developers have > used the email in ID Tokens was that it was a globally unique string in > contrast to the tuple of "iss" and "sub" in the ID Token which was much > more complicated to add and work with in a DB. Otherwise, we are creating > yet another user identifier. > > > This identifier is very narrowly focused, and is used for the RC to > communicate its notion of =E2=80=9Cthe current user=E2=80=9D back to the = AS specifically. > With that focus, it doesn=E2=80=99t need to be globally unique or even re= cognizable > to the RC, just a string assigned by the AS. There are other subject > identifiers that can fulfill a =E2=80=9Cglobally unique=E2=80=9D role ins= tead. Globally > unique identifiers for users are discussed in section 3.4 and linked from > several sections, as was suggested during design team conversations. > Section 3.5 (that defines where this string might come from) discusses th= at > the user_handle string talked about here could potentially be replaced by= a > more general mechanism instead of this narrowly-focused one, which could = in > turn have the aspects you are discussing. > Please add as a discussion. I don't see it being useful unless it supports a new use case. > > > *2.5* interaction capabilities / modes (section 3.3 as well) > While the document has renamed "interaction capabilities" to "interaction > modes", but the client is still declaring capabilities, but in 3.3 there > are conflicting statements > > "If the RC has indicated a capability to interact with the RO in its > request (Section 2.5)" > > The AS MUST NOT respond with any interaction mode that the RC did not > indicate in its request. > > > These are not in conflict =E2=80=94 the intended interpretation is that I= F the AS > responds to an interaction then it does it in a particular way, not that = it > MUST respond to an interaction it doesn=E2=80=99t know how to handle. The= rest of > the sentence quoted above states in full (emphasis added): > > If the RC has indicated a capability to interact with the RO in its > request > > (Section 2.5 > ), > *and the AS has determined that interaction is both supported and > necessary*, the AS responds to the RC with any of the following values in > the interact field of the response. > > In addition, all of the subsections in 3.3 have text like the following > (emphasis added): > > If the RC indicates that it can redirect to an arbitrary URL > > (Section 2.5.1 > ) > *and the AS supports this mode for the RC's request*, > > So the RC declares what it can do, and the AS responds to any parts that: > > - the AS supports > - the AS determines are appropriate for what=E2=80=99s being requested (r= esources > and subject info) > - the AS allows for that specific RC instance > - the AS allows for any identified RO in the request > > The combination of these together tell the RC exactly what it is allowed > to do. > > Do you have a suggestion on how to make that more clear? > > > using the same 4 interaction modes in the client request would make it > easier for the client to say which modes it supports, and the AS to respo= nd > with which modes are allowed. It also allows all parameters required for = a > mode to be in the mode. For example the URL for a double redirection, vs = a > redirection to an information page after a user_code or decoupled redirec= t. > > > As has been discussed at length, what you describe here is the same > negotiation model as in the draft. The only difference is whether the > post-interaction method is bundled as a property of the engagement method= , > which is discussed in detail in the notes along with two different > proposals of how it could be done. > Please add as a discussion point. We have different views -- both should be presented to the WG. > > > *2.5* declaring RC capabilities > Editor's note on what this is supposed to do, and why it can't be done by > just adding the properties to the request. > > > This is a proposal for an inline advanced discovery mechanism. I=E2=80=99= m > personally not a fan of keeping it if we don=E2=80=99t have a concrete us= e for it, > but at this stage it=E2=80=99s important to have options like this listed= . > Please add an editor's note so that others understand its purpose. > > > *2.7 *perhaps this could be done by updating an existing Grant Request. > This seems overly complicated. > > > Updating an existing request is a different use case, much like refreshin= g > an access token is different from deriving an access token through token > exchange. > Is it though? Please add as a discussion point. > > > *2.8* Perhaps this should be in 2.2 where we are requesting information > about the user? > Given that solving the use cases solved by OIDC is in conflict with the > editor note that OIDF should be doing the integration with GNAP. The > current model is confusing as requests are in one object, and responses a= re > in a different object. We don't have to combine the userinfo endpoint > request with the id_token request just because that was convenient for > OIDC. The editorial comments make thi seem much messier than it is. > > > I agree that it=E2=80=99s not ideal to combine the userinfo and id_token = elements, > but that=E2=80=99s how OIDC defined this query language, and an important= aspect of > this query language is that the top-level element of the query object > defines the =E2=80=9Ctarget=E2=80=9D of the requested claims. We could ig= nore this part of > the spec, but if we are to use the OIDC query language, we shouldn=E2=80= =99t be > re-defining how it works, which is what splitting up the components would > do. > > This stance is based on having implemented OIDC claims processing on > several platforms. If we were to break up the claims query language, it > would be difficult to re-use any existing parsing and processing > mechanisms. It would also not work for extensions to the OIDC claims quer= y > language, such as one that=E2=80=99s proposed for VC=E2=80=99s: > https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ > > I would rather see us focus on general purpose mechanisms for requesting > resources, subject identifiers, and bound assertions. > Please elaborate in the notes so that the various approaches are understood. > > *3.* The URI can be stable, and the access token is potentially > superfluous. As the client is authenticating with the same key in all > subsequent requests, rotation of the URI or access token may be > superfluous. Having an access token for the AS seems that is used while > authenticating vs the typical access token for an RS seems very confusing > to a developer. > > > The key here is that this is a :bound: access token, just one that is > bound to the client=E2=80=99s key in this case. It=E2=80=99s exactly the = same mechanism > that the RC would use to call the RS, and that separation of concerns is = a > key feature of this architecture. If we are expecting GNAP developers to = be > confused by being asked to present an access token, then I don=E2=80=99t = think we > have much hope. :) > Please add as a discussion point. > > > Additionally, putting the access token for calls to the AS in the HTTP > Authorization header precludes using the HTTP Authorization header for > client authentication in 8. > > > The purpose of the key presentation is not just for client authentication= , > but about binding the message to a particular key holder. This is what > allows the same mechanisms to be used across different elements of the > protocol instead of having to invent new things for each piece. > I don't understand your point here. Please clarify in the draft. > > > *4.4.2 *This functionality looks like a WebHook, and perhaps belongs in > the API between the client and the AS rather than an interaction that > involves the user. Also, this functionality provides no protection to > session fixation. The interaction reference has no value. > > > It=E2=80=99s functionality that is triggered post-interaction, just like = a > post-interaction redirect to a callback URL (or the static page option > proposed in the notes). > please add as a discussion point > > > *4.4.3 *While it is good to see an editor's note that a unique > callback URL could be used, the statement "but it would not prevent an > attacker from injecting an unrelated interaction reference into this > channel." is misleading. This would only happen if the client did not > ensure it is the same user, as that would be linked to the correct URL. > Similarly, the interaction reference does not provide protection if the > client does not ensure it is the same user. > Using a unique callback URL would be much simpler, and appears to provide > the same protection as the interaction reference and the hashing. > > > I believe the unique URLs and reference/hash mechanism solve different bu= t > related problems. This is an area for discussion, but I don=E2=80=99t see= a reason > to :not: have cryptographic protection on front channel mechanisms. OAuth= 2 > started without it, but OIDC added them back in (with hybrid mode) and no= w > JARM is defining a general-purpose way to do that. > please add as a discussion point > > *5. * > Continuing a Grant Request (which in (2) is called an Access Request) > Is "continuing the right word"? > We are either "validating" the request (5.1), polling the request (5.2), > modifying the request (5.3), reading the request (5.4), or cancelling the > request (5.5). > > > I believe =E2=80=9Ccontinue=E2=80=9D is a wide enough net to cover all of= these, as it=E2=80=99s > action on a previously-started request. Do you have a suggestion for a > better encompassing term? > Why do we need an encompassing term? Each one is descriptive on its own. > > > Include editorial discussion of replacing a request, replacing part of a > request, and adding to a request, and if we should have semantics for all= 3 > mechanisms. > > > This seems to be covered in the discussion on updating the request and > constraints on the atomicity of each portion of the request. > I did not take that away from what is in the draft. > > > *8* > While some binding mechanisms work the same for the client calling the AS > as the RS, the requirements are different. When the client calls the AS, > the client is authenticating. When the client is calling the RS, the clie= nt > is proving it is authorized to access the resource. The RS does not need = to > know the identity of the client -- just that it is the client that the AS > gave the access token to. > > > None of the mechanisms require the RS to know the identity of the RC. The > AS can verify the RC instance=E2=80=99s identity based on its key, if the= AS knows > the key and has it associated to an instance. But I=E2=80=99d also add th= at the AS > doesn=E2=80=99t need to know the identity of the RC either, in dynamic ca= ses, since > the key is just being introduced. In those cases, as you state above, the > =E2=80=9Cauthentication=E2=80=9D of the client is a more complex process = involving class > identifiers (as well as device posture and the like). This is an importan= t > discussion for the WG to have as it gets at our model of what a =E2=80=9C= client=E2=80=9D is > on several dimensions. > > Could you please expand on how you see using the same set of binding > mechanisms across the protocol would cause problems for AS, RS, or RC > developers? > I'm saying that the requirements are different between the client calling the AS, and calling the RS. > > > *8.2 Attached JWS* > Why not a JWT? > > > This is not a token, therefore JWT is not an appropriate technology. JWS > is appropriate as it provides a signature mechanism, which is what=E2=80= =99s being > discussed here. > An editor note here would then help people understand why it is not a JWT. > > This is the ONLY self contained mechanism. All the other ones require all= , > or most of the HTTP headers and the body to be kept together. > > > That=E2=80=99s correct, are you suggesting a change, or that this should = be called > out more explicitly? > It should be called out. > > > The editor note > > "Alternatively, we could add all these fields to the body of the request, > but then it gets awkward for non-body requests like GET/DELETE." > > It is not awkward. A mechanism is described later of having the JWS as an > HTTP header. Something JWS was designed for. > > > I think it=E2=80=99s incredibly awkward for the signature layer to mess a= round > with the payload of the HTTP message itself. It breaks the separation of > these layers, and now the signature layers need to know about the content > and format of the HTTP message. > > For instance, you=E2=80=99d have to have the client put the signature par= ameters > (such as HTTP method and URI) either in the body of the request OR in a > special body that=E2=80=99s used only in body-less requests, depending on= what > you=E2=80=99re doing. This is on top of putting the signed element in a d= ifferent > place when you=E2=80=99re done with it. > I have a different opinion. Please note for discussion with a balanced description. > > > The editor note > > "A downside to this method is that it requires the content type to be > something other than application/json, and it doesn't work against an RS > without additional profiling since it takes over the request body - plus = we > have to specify different delivery locations for a GET vs. a POST, for > example." > > Not being application/json is a feature as the AS can detect the signatur= e > mechanism. Per above, the requirements for the AS and RS are different. T= he > client can use the same mechanism of signing with an empty body and placi= ng > the JWS in an HTTP header just as it does below for requests with no body= . > The RS is proving it was given the access token by the AS, and binding th= at > to time, URI, and method. > > > The note is accurate, it gets in the way of the RS=E2=80=99s input. This = signature > wouldn=E2=80=99t work on an XML-based API, for example. And what of an em= pty POST > request? An API would now need to look for either an empty body OR a JSON > body. Or take a JSON based API, but one that=E2=80=99s implemented with a= strictly > typed parser. Not only would you need to pre-process the JOSE in order to > extract the JSON (which I=E2=80=99ve done in my implementation of this se= ction, and > it=E2=80=99s not pretty), but now you=E2=80=99d also need to remove the a= dditional fields > that cover the HTTP elements. > > The detached JWS method described in 8.1 would work in all of these cases > =E2=80=94 but with the developer doing the same thing every time. > I have a different opinion. Please mark for discussion. > > > The editor note > > "Additionally it is potentially fragile like a detached JWS since a > multi-tier system could parse the payload and pass the parsed payload > downstream with potential transformations. We might want to remove this i= n > favor of general-purpose HTTP signing, or at least provide guidance on it= s > use." > > is very misleading. The whole point is to pass the JWS between > components so that each can independently verify the request. ALL the oth= er > mechanisms have the fragility described as different components are going > to pass around the JSON -- and even if they pass around the detached > signature information and other headers, a component could transform the > JSON in parsing and stringifying the request. > > > Right, what I=E2=80=99m saying is that your specific use case has some cl= ear > assumptions about the way integrity is processed within the system. All o= f > those need to be enumerated very carefully. > I have a very different view from real world implementations. You have not presented a balanced view on the options. > > The straightforward way to use JOSE from a developers point of view would > be: > > - use JWT > - include the key in the header > - have "iat", the method, and the URI in the payload > - put the JWT in the HTTP Authorization header for methods without a body > > This is how I wrote it in my implementation. It was very straightforward. > > Only the last point conflicts with GNAP as now written -- all the other > aspects could be how it is done for JWT. > > > Additionally, the proposal laid out here has a significant anti-pattern i= n > including both the HTTP method and the HTTP URI in the HTTP entity body > itself. Doing so is not only redundant, but it causes more error conditio= ns > that the application layer would need to check against. Requiring these i= n > all requests, and not just for the JOSE requests, would also put a burden > on other signature mechanisms that don=E2=80=99t need it. HTTP Message Si= gnatures, > DPoP signatures, and (the historical) OAuth PoP signatures all have > mechanisms for including the HTTP elements in the signature outside of th= e > message body. Mutual TLS binding does not need to extend the HTTP message > at all in order to cover all aspects under the signature. Why should all = of > these mechanisms put HTTP components in the body? > > I understand that your own use case requires the incoming message to be > fully protected as a single unit, and the functionality in 8.2 enables > this, as we have discussed. Can you please explain how 8.2 does not addre= ss > your use case? I understand that it=E2=80=99s not how you built it, but I= think > it=E2=80=99s important to understand what this different approach would m= ake > impossible or difficult with what you=E2=80=99re trying to solve. > Please note as a discussion point. I did not suggest that other client authentication mechanisms include the elements, just mechanisms that want to be self contained, and that the elements are included where they makes sense for those mechanisms. > > > > *Additional feedback* > the document name is redundant - protocol is in it twice > (gnap =3D Grant Negotiation and Authorization Protocol)-core-protocol > "draft-ietf-gnap-core" would be sufficient > > > The document name was suggested by the chairs. > I just saw that. > > 1.2 Elements > Key - "A cryptographic element binding a request to the holder of the key= ." > It is actually *any* holder of the key. > > > Yes, thanks. > > > 2.2 Editor's note "you'd need a full identity protocol and not just this" > implies that GNAP is not an identity protocol despite it supporting the > OpenId Connect use cases. > > > GNAP supporting some of OIDC=E2=80=99s use cases does not make it a full = identity > protocol, and there was significant pushback in GNAP trying to define a > full identity protocol with user schemas, authenticator classes, assertio= n > formats, authentication event information, and all of that. There was > middle ground in defining a few simple elements of the OIDC use case, suc= h > as identifying the current user. > There was pushback in reinventing schemas. I don't recall any pushback on using GNAP to request and acquire claims, and nor do I recall any consensus on a middle ground on identifiers. > > 3.5 Do we need this section? The only thing with "handle" in the name is > user_handle. The access token is not really a handle. > > > Yes, I believe it provides necessary functionality. This section is for > providing a dynamic identifier that the RC can use for itself, and one th= at > it can use for the RQ in future requests. This section does mention acces= s > tokens except in the example. > But that can be defined in the section 2.3 I'd like to also point out that there was lots of negative feedback on handles and polymorphism in the recent Hacker News discussion. /Dick =E1=90=A7 --000000000000fb06ea05b24a7398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin, below=C2=A0are items I brought=C2= =A0up, or noted in the draft, that I'd like to have added to the draft = for WG discussion.

On Wed, Oct 21, 2020 at 12:22 PM Justin Richer <jricher@mit.edu> wrote:
On Oct 19, 2020, at 11:26 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= br>
Abstract: "information passed= =C2=A0directly to the software" can mean pretty much anything. The cha= rter has "user identifiers, and identity assertions."=C2=A0

The charter specifically does not limit wha= t the protocol could be used for, only what this WG will define for its use= . Therefore I was attempting to capture the broader scope of possibility in= the abstract.

I th= ink it is so broad that it does not help a reader understand what the docum= ent is about.

Would you add a note to have this di= scussed? This broad of a definition is new.
=C2=A0

=
1. Same point as in Abstract around "information= ".

1.1 Roles:=C2=A0
Ad= d in roles for operators of AS and RC.=C2=A0
=

What roles do these play in the protocol itself? They m= ay exist in deployments, but the roles should be defined in terms of the pr= otocol.

The user and the = RO don't move bits or do anything normative. The roles of operators are= part of the trust. Please add to discussion.
=C2=A0

Sho= w trust framework between legal entities (user, RO, client operator, AS ope= rator)

Does this working = group really want to get into the definition of legal relationships? There = are such a wide variety of possible deployments and trust models, most of w= hich don=E2=80=99t affect the nature of the protocol itself, that I=E2=80= =99m not sure we can narrow that down.
<= br>
I think it is a pretty straightforward trust relationship as = I outlined in XAuth. Please add to discussion.
=C2=A0

Di= fferentiate between legal entities having a relationship or HCI and the act= ual protocol roles (RC, AS, RS)

The current draft does not define any legal entities, only protocol = roles (including human roles like RO and RQ).

Perhaps legal entities is the wrong term -- but there = are non-protocol entities that we want to reference.
=C2=A0
=

<= div>What is the difference between roles and parties? Can we avoid the term= parties? RQ is both a party and a role.

RQ is a role and is defined as such =E2=80=94 only in the n= ame =E2=80=9CRequesting Party=E2=80=9D (which as noted was taken from UMA2)= does =E2=80=9Cparty=E2=80=9D occur. The name of this entity is up for disc= ussion, still, and this is a reasonable argument for moving away from =E2= =80=9CRequesting Party=E2=80=9D.

=E2=80=9CParties=E2=80=9D are traditional= ly entities that fill a role. I did try to avoid the use of =E2=80=9Cparty= =E2=80=9D where its use would be inaccurate or ambiguous, though I=E2=80=99= m sure this could be cleaned up if you have specific instances of such lang= uage.

<= div>Alternative names:
client for RC
user for RQ
<= /div>

These are already listed with t= he terms themselves.

But = they are not listed as options. Please list all options that we are thinkin= g of.
=C2=A0


1.2 Elements:
defined access token without using "credential"

This is largely modeled on the OAuth 2 = definition of access token. Can you expand on your issue with the term =E2= =80=9Ccredential=E2=80=9D here? Do you have an alternate definition to prop= ose?

It is not defined. C= an we define access token without using the word credential?
=C2= =A0

Grant as both a noun (what is being requested) and a verb=C2= =A0
Grant is already is a noun being used as an adjective in &quo= t;Grant Negotiation ..." and "Grant Response"

Grant as a noun is problematic in sever= al ways, not the least of which is that it conflicts with how =E2=80=9Cgran= t=E2=80=9D is both used (=E2=80=9Ca credential given to the client to trade= for a token=E2=80=9D) and understood (=E2=80=9Cthe kind of action the clie= nt has to take=E2=80=9D) in OAuth 2. It also leads to confusing semantic sa= titation when used in context with the verb form.=C2=A0

If we follow the plain definitions outside of OAuth2, the =E2=80=9Cgr= ant=E2=80=9D is the result of the request, but what we tend to talk about i= s the ongoing state of the request. I would love for us to have a better te= rm for this artifact =E2=80=94 I had previously termed this element =E2=80= =9Cthe transaction=E2=80=9D.=C2=A0

<= /div>
This is your opinion. I think that using grant as a noun as well = allows us to describe what is granted. Please add to discussion.
= =C2=A0

"Subject Information" is better than just "i= nformation" -- but is still extremely broad
The subject info= rmation should be about the user, not the RO. For example, in an enterprise= use case where resource=C2=A0access and identity claims are being requeste= d, the RO is not the user, but could be an administrator. The "subject= information" is going to be about the user of the client, not the adm= inistrator.

I agree this = is where things need to be made more explicit, especially when stretched ac= ross different use cases. The =E2=80=9Cnormal=E2=80=9D use case where the R= Q and RO are the same person collapses this fine, but not in all cases. Cou= ld an RQ request =E2=80=9Csubject information=E2=80=9D about another user (= the RO)? This isn=E2=80=99t dissimilar to the CIBA use case of a call-cente= r =E2=80=9Clogin". Ultimately, I think we need to nail down which =E2= =80=9Csubject=E2=80=9D this returned information is about.

please add to discussion
=C2=A0=


1.3.3 step 7 - what is a refreshed credenti= al? We should refer to the defined terms.

It=E2=80=99s specifically the URI and token values within = the =E2=80=9Ccontinue=E2=80=9D element that are returned from the AS, so th= is text can be reworded.=C2=A0


2. title should be Grant Request to= match with Grant Response in (3), and use of "Grant Request" in = 2.7, 2.9, 5, 5.4, & 5.5=C2=A0

Thanks, terminology can be made more consistent throughout the doc= ument, for sure.

<= div>
2.1.2: "a RC MAY send a string known to the = AS or RS"
why "or"? Explain.

<= /div>

This logic is based on how OAut= h 2 scopes are used in many places.

If the AS know= s about the string, it can enforce policies on what an RO can approve or an= RC can request. It=E2=80=99s really common to have these kinds of policies= . If the AS doesn=E2=80=99t know about the string, the AS can still provide= the request to the RO for approval and convey the approved string informat= ion to an RS downstream for enforcement.

If the RS= knows about the string, it can enforce policies on what the token is good = for, assuming the string is conveyed to the RS as-is. Alternatively, the RS= could be naive about the requested string and instead rely on the AS to tr= anslate the string into something specific for the RS to consume.=C2=A0

This is not an exclusive =E2=80=9Cor=E2=80=9D, of cou= rse. If both the AS and RS know about the string, that also works fine.

please clarify in text
=
=C2=A0

2.2 "sub_ids"
ar= e sub_ids a good idea, a best practice? despite warnings in the protocol, d= evelopers will use an email identifier as a communication identifier, or wo= rse, a verified identifier.=C2=A0
GNAP is defining a query langua= ge here for subject identifiers.=C2=A0
<= br>
We know from years of experience with OIDC and OAuth 2 that c= lient developers want to have an identifier they can correlate to other inf= ormation within their applications, and this is a feature to address that.= =C2=A0

please add as an i= tem to be discussed
=C2=A0


2.3 Ide= ntifying a client via URL
Mobile Apps and SPA can identify themse= lves with an HTTPS url that only that client can receive redirects to (univ= ersal link in iOS, android app link). The client passes the general identif= ier for the client (class_id?) and the AS ensures the redirect URI belongs = to that client. A parameter is passed on the redirect to the client that th= e client presents to the AS to prove it is an instance of that client. The = AS may then release access and claims to the client. The AS may also provid= e an instance identifier for the client so that instance of the client can = uniquely identify itself.

The editor note that ins= tance_id is analogous=C2=A0to the client_id prevents an instance of the cli= ent in the preceding paragraph from uniquely identifying itself, and the na= me is misleading.

The con= flict only occurs if you want to call the class_id the client_id. In practi= ce, to serve this kind of client, the AS would register a class_id and the = developer would include that class_id with every initial request.=C2=A0

A= dditionally, pre-registered identifiers (class_id which should be equivalen= t to client_id for confidential clients) and dynamic identifiers (instance_= id) have different operational and infrastructure requirements. pre-registe= red identifiers should be read only for the AS vs read / write for the AS. = There may be millions of dynamic identifier for one pre-registered identifi= er (mobile app, SPA)

Thus= why a class_id and an instance_id are different, and we no longer have =E2= =80=9Cclient_id=E2=80=9D that confuses the concepts.=C2=A0

I agree they are different. Your suggesti= on is a pre registered=C2=A0app use instance_id on first use. I'm sayin= g it should be class_id.
=C2=A0
<= br>
I think it would be worthwhile to add an explicit =E2=80=9Ccl= ass_id=E2=80=9D field, but as I recall in the design team we didn=E2=80=99t= quite settle on that.

What are you proposing shou= ld change?

I'm propos= ing that you add my suggestion as a discussion point.=C2=A0
=C2= =A0


2.3.1 Do we need to support symmetric= =C2=A0keys? Most OAuth clients support a secret, not a key.

I believe we should support symmetric ke= ys (but not client secrets). I also believe that we can safely do so using = the client instance reference, as laid out by the discussion in the section= .

The problems with symmetric crypto largely come = from key distribution and not the actual cryptography. If the keys are pre-= placed or securely delivered or derived out-of-band, symmetric crypto will = fit fine in this space.

P= lease add as a discussion point.
=C2=A0


<= b>2.3.2
what are the supported public key formats?

What=E2=80=99s listed in the docume= nt are currently JWK and PEM, these should be expandable to other formats (= CWK for example).

It is v= ague in the document=C2=A0where referenced.
=C2=A0

What = if the client is able to use different proofing mechanisms? How does it neg= otiate with the AS?

Inlin= e negotiation of proofing mechanisms is dangerous at best, since the RC nee= ds to protect the negotiation request.=C2=A0

Most = clients are likely to have one method that they always do, and it will be b= ased on the key material that they have access to, but the discovery mechan= isms in the draft would allow a more capable client of dynamically selectin= g a mechanism.=C2=A0

Yaron raised the point of wha= t is Mandatory to Implement, and I agree that this is something that should= be.

Please add as a disc= ussion.
=C2=A0



2.4.1 identifying the user
this identifier would be useful if it had = properties that other opaque identifiers did not have: being globally uniqu= e. A reason developers have used the email in ID Tokens was that it was a g= lobally unique string in contrast to the tuple of "iss" and "= ;sub" in the ID Token which was much more complicated to add and work = with in a DB. Otherwise, we are creating yet another user identifier.
=

This identifier is very narrow= ly focused, and is used for the RC to communicate its notion of =E2=80=9Cth= e current user=E2=80=9D back to the AS specifically. With that focus, it do= esn=E2=80=99t need to be globally unique or even recognizable to the RC, ju= st a string assigned by the AS. There are other subject identifiers that ca= n fulfill a =E2=80=9Cglobally unique=E2=80=9D role instead. Globally unique= identifiers for users are discussed in section 3.4 and linked from several= sections, as was suggested during design team conversations. Section 3.5 (= that defines where this string might come from) discusses that the user_han= dle string talked about here could potentially be replaced by a more genera= l mechanism instead of this narrowly-focused one, which could in turn have = the aspects you are discussing.

Please add as a discussion. I don't see it being useful unless i= t supports a new use case.
=C2=A0

=

2.5<= /b> interaction capabilities / modes (section 3.3 as well)
While = the document has renamed "interaction capabilities" to "inte= raction modes", but the client is still declaring capabilities, but in= 3.3 there are conflicting statements

"If the= RC has indicated a capability to interact with the RO in its request (Sect= ion 2.5)"

The AS MUST NOT respond with an= y interaction mode that the RC did not indicate in its request.=C2=A0

These are not in conflict = =E2=80=94 the intended interpretation is that IF the AS responds to an inte= raction then it does it in a particular way, not that it MUST respond to an= interaction it doesn=E2=80=99t know how to handle. The rest of the sentenc= e quoted above states in full (emphasis added):

If the RC has indicated a capability to interact with the RO in i= ts request (Section 2.5), and the AS has determined that interaction is both supported and necessary, the AS responds to the RC with any of the following values in the interact field of the response.
<= div>
In addition, all of the subsections in 3.3 have text lik= e the following (emphasis added):

If the RC indicates that it can redirect to an arbitrary URL (Section 2.5.1) and th= e AS supports this mode for the RC's request,

So the RC declares what it can do, an= d the AS responds to any parts that:

- the AS supports
- the AS determines are appropriate for w= hat=E2=80=99s being requested (resources and subject info)
- the AS allows for that specific RC= instance
- the AS a= llows for any identified RO in the request

The com= bination of these together tell the RC exactly what it is allowed to do.

Do you have a suggestion on how to make that more cl= ear?


using the same 4 interaction modes in the client request would make = it easier for the client to say which modes it supports, and the AS to resp= ond with which modes are allowed. It also allows all parameters required fo= r a mode to be in the mode. For example the URL for a double redirection, v= s a redirection to an information page after a user_code or decoupled redir= ect.

As has been discusse= d at length, what you describe here is the same negotiation model as in the= draft. The only difference is whether the post-interaction method is bundl= ed as a property of the engagement method, which is discussed in detail in = the notes along with two different proposals of how it could be done.
=

Please=C2=A0add as a discussio= n point. We have different views -- both should be presented to the WG.
=C2=A0


2.5 declaring RC capabilities<= /div>
Editor's=C2=A0note on what this is supposed to do, and why it= can't be done by just adding the properties to the request.

This is a proposal for an inline ad= vanced discovery mechanism. I=E2=80=99m personally not a fan of keeping it = if we don=E2=80=99t have a concrete use for it, but at this stage it=E2=80= =99s important to have options like this listed.

Please add an editor's note so that others unde= rstand=C2=A0its purpose.
=C2=A0


2.7 perhaps this could be done by updating=C2=A0 an existing Grant Request. T= his seems overly complicated.

=
Updating an existing request is a different use case, much like refres= hing an access token is different from deriving an access token through tok= en exchange.=C2=A0

Is it = though? Please add as a discussion point.
=C2=A0


2.8=C2=A0Perhaps this should be in 2.2 where we are requesti= ng information about the user?
Given that solving the use cases s= olved by OIDC is in conflict with the editor note that OIDF should be doing= the integration with GNAP. The current model is confusing as requests are = in one object, and responses are in a different object. We don't have t= o combine the userinfo endpoint request with the id_token request just beca= use that was convenient for OIDC. The editorial comments make thi seem much= messier than it is.


=
I agree that it=E2=80=99s not ideal to combine the userinfo and = id_token elements, but that=E2=80=99s how OIDC defined this query language,= and an important aspect of this query language is that the top-level eleme= nt of the query object defines the =E2=80=9Ctarget=E2=80=9D of the requeste= d claims. We could ignore this part of the spec, but if we are to use the O= IDC query language, we shouldn=E2=80=99t be re-defining how it works, which= is what splitting up the components would do.=C2=A0

This stance is based on having implemented OIDC claims processing on sev= eral platforms. If we were to break up the claims query language, it would = be difficult to re-use any existing parsing and processing mechanisms. It w= ould also not work for extensions to the OIDC claims query language, such a= s one that=E2=80=99s proposed for VC=E2=80=99s:=C2=A0ht= tps://mattrglobal.github.io/oidc-client-bound-assertions-spec/

I would rather see us focus on general purpose mechanisms = for requesting resources, subject identifiers, and bound assertions.=C2=A0<= /div>

Please elaborate in the n= otes so that the various approaches are understood.=C2=A0
=C2=A0<= /div>

3. The URI can be stable, and the access token is potential= ly superfluous. As the client is authenticating with the same key in all su= bsequent requests, rotation of the URI or access token may be superfluous. = Having an access token for the AS seems that is used while authenticating v= s the typical access token for an RS seems very confusing to a developer.

The key here is that this = is a :bound: access token, just one that is bound to the client=E2=80=99s k= ey in this case. It=E2=80=99s exactly the same mechanism that the RC would = use to call the RS, and that separation of concerns is a key feature of thi= s architecture. If we are expecting GNAP developers to be confused by being= asked to present an access token, then I don=E2=80=99t think we have much = hope. :)


P= lease add as a discussion point.
=C2=A0


A= dditionally, putting the access token for calls to the AS in the HTTP Autho= rization header precludes using the HTTP Authorization header for client au= thentication in 8.

The pu= rpose of the key presentation is not just for client authentication, but ab= out binding the message to a particular key holder. This is what allows the= same mechanisms to be used across different elements of the protocol inste= ad of having to invent new things for each piece.

I don't understand your point here. Please cla= rify in the draft.
=C2=A0


4.4.2 Th= is functionality looks like a WebHook, and perhaps belongs in the API betwe= en the client and the AS rather than an interaction that involves the user.= Also, this functionality provides no protection to session fixation. The i= nteraction reference has no value.

<= /div>
It=E2=80=99s functionality that is triggered post-interaction, ju= st like a post-interaction redirect to a callback URL (or the static page o= ption proposed in the notes).

=
please add as a discussion point
=C2=A0

<= div>4.4.3 While it is good to see an editor's note that=C2=A0a u= nique callback=C2=A0URL could be used, the statement "but it would not= prevent an attacker from injecting an unrelated interaction reference into= this channel." is misleading. This would only happen if the client di= d not ensure it is the same user, as that would be linked to the correct=C2= =A0URL. Similarly, the interaction reference does not provide protection if= the client does not ensure it is the same user.
Using a unique c= allback URL would be much simpler, and appears to provide the same protecti= on as the interaction reference and the hashing.

=

I believe the unique URLs and refere= nce/hash mechanism solve different but related problems. This is an area fo= r discussion, but I don=E2=80=99t see a reason to :not: have cryptographic = protection on front channel mechanisms. OAuth 2 started without it, but OID= C added them back in (with hybrid mode) and now JARM is defining a general-= purpose way to do that.

p= lease add as a discussion point
=C2=A0

5.=C2=A0
Continuing a Grant Request (which in (2) is called an Access Reque= st)
Is "continuing the right word"?
We are ei= ther "validating" the request (5.1), polling the request (5.2), m= odifying the request (5.3), reading the request (5.4), or cancelling the re= quest (5.5).

I believe = =E2=80=9Ccontinue=E2=80=9D is a wide enough net to cover all of these, as i= t=E2=80=99s action on a previously-started request. Do you have a suggestio= n for a better encompassing term?

Why do we need an encompassing term? Each one is descriptive on it= s own.=C2=A0

=

Include editorial discussion of replac= ing a request, replacing part of a request, and adding to a request, and if= we should have semantics for all 3 mechanisms.

This seems to be covered in the discussion on updati= ng the request and constraints on the atomicity of each portion of the requ= est.=C2=A0

I did not take= that away from what is in the draft.=C2=A0
=C2=A0


<= /div>
8
While some binding mechanisms work the same fo= r the client calling the AS as the RS, the requirements are different. When= the client calls the AS, the client is authenticating. When the client is = calling the RS, the client is proving it is authorized to access the resour= ce. The RS does not need to know the identity of the client -- just that it= is the client that the AS gave the access token to.

None of the mechanisms require the RS to know t= he identity of the RC. The AS can verify the RC instance=E2=80=99s identity= based on its key, if the AS knows the key and has it associated to an inst= ance. But I=E2=80=99d also add that the AS doesn=E2=80=99t need to know the= identity of the RC either, in dynamic cases, since the key is just being i= ntroduced. In those cases, as you state above, the =E2=80=9Cauthentication= =E2=80=9D of the client is a more complex process involving class identifie= rs (as well as device posture and the like). This is an important discussio= n for the WG to have as it gets at our model of what a =E2=80=9Cclient=E2= =80=9D is on several dimensions.

Could you please = expand on how you see using the same set of binding mechanisms across the p= rotocol would cause problems for AS, RS, or RC developers?=C2=A0

I'm saying that the requirement= s are different between the client calling the AS, and calling the RS.
=C2=A0

=

8.2 Attached JWS
Why = not a JWT?

This is not a = token, therefore JWT is not an appropriate technology. JWS is appropriate a= s it provides a signature mechanism, which is what=E2=80=99s being discusse= d here.

An editor note he= re would then help people understand why it is not a JWT.
=C2=A0<= /div>

This is the ONLY self contained mechanism. All the other ones requ= ire all, or most of the HTTP headers and the body to be kept together.

That=E2=80=99s correct, are y= ou suggesting a change, or that this should be called out more explicitly?<= /div>

It should be called out.<= /div>
=C2=A0

<= div>

The editor note
"Alternatively, we could add all these fields to the body = of the request, but then it gets awkward for non-body requests like GET/DEL= ETE."

It is not awkward. A mechanism is descr= ibed later of having the JWS as an HTTP header. Something JWS was designed = for.

I think it=E2= =80=99s incredibly awkward for the signature layer to mess around with the = payload of the HTTP message itself. It breaks the separation of these layer= s, and now the signature layers need to know about the content and format o= f the HTTP message.

For instance, you=E2=80=99d ha= ve to have the client put the signature parameters (such as HTTP method and= URI) either in the body of the request OR in a special body that=E2=80=99s= used only in body-less requests, depending on what you=E2=80=99re doing. T= his is on top of putting the signed element in a different place when you= =E2=80=99re done with it.=C2=A0

I have a different opinion. Please note for discussion with a balanc= ed description.
=C2=A0


The editor no= te

"A downside to this method is that it requ= ires the content type to be something other than application/json, and it d= oesn't work against an RS without additional profiling since it takes o= ver the request body - plus we have to specify different delivery locations= for a GET vs. a POST, for example."

Not = being application/json is a feature as the AS can detect the signature mech= anism. Per above, the requirements for the AS and RS are different. The cli= ent can use the same mechanism of signing with an empty body and placing th= e JWS in an HTTP header just as it does below for requests with no body. Th= e RS is proving it was given the access token by the AS, and binding that t= o time, URI, and method.


The note is accurate, it gets in the way of the RS=E2= =80=99s input. This signature wouldn=E2=80=99t work on an XML-based API, fo= r example. And what of an empty POST request? An API would now need to look= for either an empty body OR a JSON body. Or take a JSON based API, but one= that=E2=80=99s implemented with a strictly typed parser. Not only would yo= u need to pre-process the JOSE in order to extract the JSON (which I=E2=80= =99ve done in my implementation of this section, and it=E2=80=99s not prett= y), but now you=E2=80=99d also need to remove the additional fields that co= ver the HTTP elements.

The detached JWS method des= cribed in 8.1 would work in all of these cases =E2=80=94 but with the devel= oper doing the same thing every time.
I have a different opinion. Please mark for discussion.=C2=A0<= /div>
=C2=A0

<= div>

The editor note=C2=A0

"Additionally it is potentially fragile like a= detached JWS since a multi-tier system could parse the payload and pass th= e parsed payload downstream with potential transformations. We might want t= o remove this in favor of general-purpose HTTP signing, or at least provide= guidance on its use."=C2=A0

is very misleadi= ng. The whole point is to pass the JWS between components=C2=A0so that each= can independently verify the request. ALL the other mechanisms have the fr= agility described as different components are going to pass around the JSON= -- and even if they pass around the detached signature information and oth= er headers, a component could transform the JSON in parsing and stringifyin= g the request.


=
Right, what I=E2=80=99m saying is that your specific use case has some= clear assumptions about the way integrity is processed within the system. = All of those need to be enumerated very carefully.

I have a very different view from real world impl= ementations. You have not presented a balanced view on the options.
=C2=A0

The straightforward=C2=A0way to use JOSE from a develope= rs point of view would be:

- use JWT
- i= nclude the key in the header
- have "iat", the method, = and the URI in the payload
- put the JWT in the HTTP Authorizatio= n header for methods without a body

This is how I = wrote it in my implementation. It was very straightforward.

<= /div>
Only the last point conflicts with GNAP as now written -- all the= other aspects could be how it is done for JWT.

Additionally, the proposal laid out here has a signi= ficant anti-pattern in including both the HTTP method and the HTTP URI in t= he HTTP entity body itself. Doing so is not only redundant, but it causes m= ore error conditions that the application layer would need to check against= . Requiring these in all requests, and not just for the JOSE requests, woul= d also put a burden on other signature mechanisms that don=E2=80=99t need i= t. HTTP Message Signatures, DPoP signatures, and (the historical) OAuth PoP= signatures all have mechanisms for including the HTTP elements in the sign= ature outside of the message body. Mutual TLS binding does not need to exte= nd the HTTP message at all in order to cover all aspects under the signatur= e. Why should all of these mechanisms put HTTP components in the body?

I understand that your own use case requires the incom= ing message to be fully protected as a single unit, and the functionality i= n 8.2 enables this, as we have discussed. Can you please explain how 8.2 do= es not address your use case? I understand that it=E2=80=99s not how you bu= ilt it, but I think it=E2=80=99s important to understand what this differen= t approach would make impossible or difficult with what you=E2=80=99re tryi= ng to solve.

Please note = as a discussion point.

I did not suggest that othe= r client authentication mechanisms include the elements, just mechanisms th= at want to be self contained, and that the elements are included where they= makes sense for those mechanisms.
=C2=A0
=



Additional feedback
the document name is = redundant - protocol is in it twice
(gnap =3D Grant Negotiation a= nd Authorization Protocol)-core-protocol
"draft-ietf-gnap-co= re" would be sufficient

<= div>
The document name was suggested by the chairs.

I just saw that.
=C2=A0<= /div>

1.2 Elements
Key - "A cryptographic element binding= a request to the holder of the key."
It is actually any<= /b> holder of the key.=C2=A0

<= div>Yes, thanks.

<= div>
2.2 Editor's note "you'd need a full identi= ty protocol and not just this" implies that GNAP is not an identity pr= otocol despite it supporting the OpenId Connect use cases.=C2=A0

GNAP supporting some of OIDC=E2=80= =99s use cases does not make it a full identity protocol, and there was sig= nificant pushback in GNAP trying to define a full identity protocol with us= er schemas, authenticator classes, assertion formats, authentication event = information, and all of that. There was middle ground in defining a few sim= ple elements of the OIDC use case, such as identifying the current user.=C2= =A0

There was pushback in= reinventing schemas. I don't recall any pushback on using GNAP to requ= est and acquire claims, and nor do I recall any consensus on a middle groun= d on identifiers.



3.5 Do we need thi= s section? The only thing with "handle" in the name is user_handl= e. The access token is not really a handle.=C2=A0

Yes, I believe it provides necessary functionality. Thi= s section is for providing a dynamic identifier that the RC can use for its= elf, and one that it can use for the RQ in future requests. This section do= es mention access tokens except in the example.

But that can be defined in the section 2.3

<= /div>
I'd like to also point out that there was lots of negative fe= edback on handles and polymorphism=C2=A0in the recent Hacker News discussio= n.
=C2=A0
/Dick
3D""=E1=90=A7
--000000000000fb06ea05b24a7398-- From nobody Thu Oct 22 16:07:43 2020 Return-Path: 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 B3B373A0983 for ; Thu, 22 Oct 2020 16:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 SpOUFwukXF-m for ; Thu, 22 Oct 2020 16:07:39 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 8673F3A0980 for ; Thu, 22 Oct 2020 16:07:39 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 77so4313920lfl.2 for ; Thu, 22 Oct 2020 16:07:39 -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=T0gK7uPmL/BKd8/Q6AVTDsIvVojRVRLeXF4+VxMtnSw=; b=a/vhSEQpP7wRbV3b/j3hFHMkkUpHqLF1MHamIooeGY7EwuyJGgSVSKM01tJ/ceVCkS 3NSkZE5LshRZ4p839nflzedNvbbuzlV8gl0O0vwUyZB4g303Z8O447ezJItzuEE7z7er iazqzePVPjajbPUbqNNYCAJ8zodp4xcfHKZAQnNB6oi+4nIP5xha6nmRgEFu0pN6C81C 23j6gB6eOjUeI2FC3hJ668n9D5f6qo0NV9UGVgGcHRHj/3Pl++1ubv41qud5zbQKO6r7 15Z9fuen/BEZXeip5SZDFsyualSH99BsVZWghWFQ0euJWv4RaQSS2398j+nmAy1Zfe4w ZsJA== 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=T0gK7uPmL/BKd8/Q6AVTDsIvVojRVRLeXF4+VxMtnSw=; b=Tt9pAgA42974DR25HuM0sqUa4sD4I+xigRSLxtdLhd48Olg+kxacDEIdKejcFNx2KP MBM/2nepW8lCE5b/ZzwavnXIp6IVjF3zooH138ZkQlK6UdOEebLgehHCVN//yLNjc24O jNJiGvXxJS4+ORLM/Ndy8tTO91FkqnS1MiN3jGhNvoLUmz4fzG82edkCZc/P125u943N HBt2MlfEJsjxpWXT0zSTy7DXrfH6msC/Se6fHiSAv1zyco17rKcdRYkhSbclOzZAvl0+ jkXtFrvMGLbrugzPbxxPdOobRMuO0Tgs3hxJmCu9dSOEZREBZLmESagzSRu80oq0j/Ty tfjA== X-Gm-Message-State: AOAM532Of5IoZnTmbqYpVWqnKLaAErFvM15KG5FUmzZSQhbeq7KC8JLU QlFnrwX3Ufi9wOcaqlnUhhiUfd87JM7V7d8IE2gmLaY/S9U= X-Google-Smtp-Source: ABdhPJyt6i9xPwXEym+mUbyTy0kuRKktfEe4R21a9lhYI2YbhZNApVTNlAkDdHk6bNWFN+9G3WXrySgBYmJZja1UBi0= X-Received: by 2002:a05:6512:68a:: with SMTP id t10mr1477044lfe.221.1603408057515; Thu, 22 Oct 2020 16:07:37 -0700 (PDT) MIME-Version: 1.0 References: <9CC252F5-F88F-4068-8AB8-D9E4B8A48B2D@gmail.com> In-Reply-To: <9CC252F5-F88F-4068-8AB8-D9E4B8A48B2D@gmail.com> From: Dick Hardt Date: Thu, 22 Oct 2020 16:07:01 -0700 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b2c3bd05b24a874b" Archived-At: Subject: Re: [GNAP] Adopted: draft-richer-transactional-auth-14 X-BeenThere: txauth@ietf.org 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, 22 Oct 2020 23:07:42 -0000 --000000000000b2c3bd05b24a874b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yaron: would you elaborate on why you suggested the file name be draft-ietf-gnap-core-protocol rather than just draft-ietf-gnap-core? As GNAP is Grant Negotiation and Authorization Protocol, we have protocol in the file name twice. =E1=90=A7 On Sat, Oct 17, 2020 at 5:27 AM Yaron Sheffer wrote= : > We have clear WG consensus to adopt the draft, thank you all for your > support. > > > > Justin, can you please resubmit the draft as-is (no textual changes) as a > working group draft. I would suggest the name > draft-ietf-gnap-core-protocol. We will ask that the document source will = be > managed on GitHub [1]. > > > > The chairs will shortly announce additional draft editor(s). If you are > interested, please drop us a note. Note that this is a serious commitment= : > this is a large and complex document and will take some time and likely > quite a few revisions before it is published. > > > > This is a good time to review the document and submit comments to the > mailing list! > > > > Thanks, > > Yaron > > > > [1] https://github.com/ietf-wg-gnap > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b2c3bd05b24a874b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b2c3bd05b24a874b-- From nobody Thu Oct 22 16:15:05 2020 Return-Path: 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 2356B3A00D9 for ; Thu, 22 Oct 2020 16:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 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_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 O1X3EVY4Mxcn for ; Thu, 22 Oct 2020 16:15:02 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 5C2CE3A00C4 for ; Thu, 22 Oct 2020 16:15:02 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id a5so3730298ljj.11 for ; Thu, 22 Oct 2020 16:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1ihoSUJ+OQ2gLKMPZ1vH52YqQ0WDUDcB9HcbLrZHrig=; b=vI1NbIg9que0hcQw8u2cFrmv17l/Kt/2go4a80Gfcei5oL61fhEQdhhmeenSvBkg4l 7w5ArxulfoSK0C07TeUBTmXhlEcu3w3arCakM9ODHsAt82Iz0UYUhYu6Fu4KolZlQq7a T+hKIY0JaeMoicxAZUaiEvp4IGOoMwYiY97AaoErcGLFsHwzS+5z+Q1tOS3ciF2sGlBP JpdJuSGXteGUogUulvPCeFHnj58KYuGgIvsELaLPePvbjK/wTshjmdcExW5d/mOKNzKl fzMGif81S22KrE/PbbjxyhKQMwbi0m2Kt4NhNfEn+Qk6557RLvvhjQp9CvAuOWKJzjWg 8UbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1ihoSUJ+OQ2gLKMPZ1vH52YqQ0WDUDcB9HcbLrZHrig=; b=dqXELnciQ5GlsWUPxWsvodJJCbECKq8t4Gws0GjsLov4IMYSv9FEG4gxwDixydIguD coNhlbYafbpA76K+Acrz2K1tsp4GjVj851KH1HYjNIJxA3fKBtSgUtFkUMpk+zjLQLty 0zKKp0sOXpDyIi2Qv2v/8tg6f6MGCkzYA/e5ZzVuKe5ptJXAWsMAt7xlvTuPYefyjVUH LueOpFRG+BPrxX9Vum/ZdpIH2Ya3L1vJW7t7BrJFJipGcsBDcn2cRbgjUFh3qZ2Zh5Vx Ar23EWg9PNRVe5oXlsfUWYjV5SBXqrgKS6zqhpnFccBHcHt1NoAGt4qG8Gyp5Ixt1cP7 69tQ== X-Gm-Message-State: AOAM532+csVda8jif7tfEBKl1iNmD/dDlvuCp5M4tEDJ6UJ5DPcpukAO +NN35/cs0rVXml3Z+HXry9NZp/5nmyOk0yu3Xe8KpQAqkO0Uxw== X-Google-Smtp-Source: ABdhPJwtx2VTQJgHSUE+8ZMQWOKVmshBVKzic/E1FpjSNlPYiX95DtrMIwvYWyQGgYLY9xjTNZBflSyzS1gYTe53cXY= X-Received: by 2002:a2e:8853:: with SMTP id z19mr1824708ljj.142.1603408499628; Thu, 22 Oct 2020 16:14:59 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Thu, 22 Oct 2020 16:14:23 -0700 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000000cdd5605b24aa2a2" Archived-At: Subject: [GNAP] draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org 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, 22 Oct 2020 23:15:04 -0000 --0000000000000cdd5605b24aa2a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have heard that some people are uncertain about my view on the WG draft. Although I was disappointed that the design team did not select the best features from XYZ and XAuth[1], I do want us to move forward with what we have if the WG was supportive of adoption, which it was. I had hoped that the design team process would have been a forum for Justin and I, with help from the other members, to align on design choices -- as there are many nuances to those choices -- but now we will do that in the WG! /Dick [1] https://mailarchive.ietf.org/arch/msg/txauth/E8D1Id0QPUNxdRfSbeBOVECvn1c/ =E1=90=A7 --0000000000000cdd5605b24aa2a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have heard that some people are uncertain about my view = on the WG draft. Although I was disappointed that the design team did not s= elect the best features from XYZ and XAuth[1], I do want us to move=C2=A0fo= rward with what we have if the WG was supportive of adoption, which it was.=

I had hoped that the design team process would have bee= n a forum for Justin and I, with help from the other members, to align on d= esign choices -- as there are many nuances to those choices -- but now we w= ill do that in the WG!

3D""=E1=90= =A7
--0000000000000cdd5605b24aa2a2-- From mika.bostrom@smarkets.com Fri Oct 23 07:19:03 2020 Return-Path: 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 7082D3A0E22 for ; Fri, 23 Oct 2020 07:19:03 -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 (2048-bit key) header.d=smarkets.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 otF6pMTI8hDB for ; Fri, 23 Oct 2020 07:19:01 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 D3C7F3A0BDE for ; Fri, 23 Oct 2020 07:19:01 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id b2so921483ots.5 for ; Fri, 23 Oct 2020 07:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smarkets.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=DENai75wxK1tbbBVvzbE2LpR5T0R3+tRFUwy2aBXKvs=; b=ds72IVR/MVY0Cyozs9zDeAN9KuLqgpQ+j5C/S7WwxuemjVysnebisXBqGjSfb2ljhB J1/RFM/aWNdbSZj7B3jijKi1z5bZ++se0Dl1U/rVR2XobK/VubgDIIeS3fRnctHYTrdC 0J/4/pLk3hSI03i3GlX+9qXsd9FBpl650bjrUNUvrg3E03ID4McmQQfF6BEh3rO0fSaH Q9RWOcV4sO0eH7ncRLtQe2lJMnGmc1quFmVzI5ej+3ChMMqk2LGaVvkz1kKu+3YNv4Gt dffOx7KkFb5FskBIUppGZR+PmCDmn8gW3o1diN4gg5mrbj08Q6L57VfHN5GIoJ9Lp+c5 EMUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DENai75wxK1tbbBVvzbE2LpR5T0R3+tRFUwy2aBXKvs=; b=IAw4xBrdRykNWiC/eOUI3mf608vUo7jdvrroZyxfeAxwAiSMvt+PCpE8Ymtd7sUiJ6 Ae12olgLdgmHj9dfyYTmIYP5GA8RFXSzcefLjY5uXXvGA9u7aC/vmSyD16C1pBFyvnE0 JcZ4U7KRcZeLjnfuLtiOwlQa22dQnUiUst2HxH+P/LsiwsSw9gyrho343X0Sg+2wlPCH 4BZvYWcVNafvEwblzx5ymUrpN7GLUXdBXbUhHsU3/AF1IVohwYaoq6GkVtDYMW/A7Zhh YOAY9RofuRzVI+0geJ7mc9MMx+yyGY1cm6JXy3+8LtWzBBE798VqT+h3vCRnzrnCkBiE oaCg== X-Gm-Message-State: AOAM5331T7dYUtEuWcrFF/gC2tqPflSlirnGK298zu7DJTTSeHU9F2w2 DFnFn3rPqnTPjBhj6yPZWexD4dO7Pe3IXxPNiwiYy+tos586Cg== X-Google-Smtp-Source: ABdhPJxqxjeeR6Jx9a68X87n1ADYg9sfL6/MPhXcDPK/+rRw0ftGS2deL4I8Usx96rEPh9I1HTKrsZKhmiQrLYJGInk= X-Received: by 2002:a9d:7b48:: with SMTP id f8mr1628575oto.31.1603462740463; Fri, 23 Oct 2020 07:19:00 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Mika_Bostr=C3=B6m?= Date: Fri, 23 Oct 2020 15:18:49 +0100 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e737005b25743c5" Archived-At: X-Mailman-Approved-At: Fri, 23 Oct 2020 09:59:49 -0700 Subject: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 14:20:04 -0000 --0000000000000e737005b25743c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, everyone. For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made note about certain concerns, I was requested to send my comments to this working group. In short, I believe that the use of polymorphic JSON in the protocol invites subtle and confusing implementation problems. I also searched through the WG archives, and noticed that similar concerns were noted, briefly, in a thread in July. The problem with polymorphic values, as I see it, is that implementations will need to branch on the (inferred) type of a given field. This isn't quite as bad if the types are strictly different, but allows for subtle bugs when the value in question is a dictionary. What makes this unappealing is that "subtle bugs" in security protocols have a habit of turning into vulnerabilities. Let's say we have these imaginary payloads, both possible and valid in the same protocol step: # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } In both cases, the type of "public_key" field is a dictionary. In both cases, they even have the same keys. However, the values in the dictionaries are entirely different, and an implementation will have to branch to at least two possible decoding mechanisms. To make things worse, some JSON implementations may choose to encode non-dictionary values as strings, so it is possible for an originator to transmit what they expect and believe to be payload 1 format, but which the receiver will interpret to be in payload 2 format. And if the encoded string contains only digits, it will even parse correctly as a bignum. While the above is clearly a manufactured scenario, it nonetheless demonstrates the potential for logic bugs with polymorphic JSON. With richer types and more complex dictionaries, there will surely be more room for errors. Ambiguity in protocols is always a source of implementation complexity and interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in everyone's interest to keep implementation complexity and mistake potential to a minimum? Best regards, Mika --=20 Mika Bostr=C3=B6m Smarkets --0000000000000e737005b25743c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, everyone.

For backgro= und: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made n= ote about certain concerns, I was requested to send my comments to this wor= king group.

In short, I believe that the use o= f polymorphic JSON in the protocol invites subtle and confusing implementat= ion problems. I also searched through the WG archives, and noticed that sim= ilar concerns were noted, briefly, in a thread in July.

=
The problem with polymorphic values, as I see it, is that implem= entations will need to branch on the (inferred) type of a given field. This= isn't quite as bad if the types are strictly different, but allows for= subtle bugs when the value in question is a dictionary. What makes this un= appealing is that "subtle bugs" in security protocols have a habi= t of turning into vulnerabilities.

Let's say w= e have these imaginary payloads, both possible and valid in the same protoc= ol step:

# payload 1
{
=C2=A0 = ...,
=C2=A0 "public_key": {
=C2=A0=C2=A0=C2= =A0 "alg": "rsa",
=C2=A0=C2=A0=C2=A0 &quo= t;modulus": <BIGINT>
=C2=A0 }
}
# payload 2
{
=C2=A0 ...,
=C2=A0= "public_key": {
=C2=A0=C2=A0=C2=A0 "alg": &q= uot;rsa",
=C2=A0=C2=A0=C2=A0 "modulus": "<= encoded string>"
=C2=A0 }
}

In both cases, the type of "public_key" field is a dictiona= ry. In both cases, they even have the same keys. However, the values in the= dictionaries are entirely different, and an implementation will have to br= anch to at least two possible decoding mechanisms. To make things worse, so= me JSON implementations may choose to encode non-dictionary values as strin= gs, so it is possible for an originator to transmit what they expect and be= lieve to be payload 1 format, but which the receiver will interpret to be i= n payload 2 format. And if the encoded string contains only digits, it will= even parse correctly as a bignum.

While the a= bove is clearly a manufactured scenario, it nonetheless demonstrates the po= tential for logic bugs with polymorphic JSON. With richer types and more co= mplex dictionaries, there will surely be more room for errors.
Ambiguity in protocols is always a source of implementation co= mplexity and interoperability snags, but in an AuthN/AuthZ protocol it is w= orse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2= , wouldn't it be in everyone's interest to keep implementation comp= lexity and mistake potential to a minimum?

Bes= t regards,
Mika

--
Mika Bostr=C3=B6m
Smarkets<= br>
--0000000000000e737005b25743c5-- From nobody Fri Oct 23 10:19:15 2020 Return-Path: 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 D0BAE3A10A3; Fri, 23 Oct 2020 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xtoaha5eoroi; Fri, 23 Oct 2020 10:19:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBDB3A11F9; Fri, 23 Oct 2020 10:18:38 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09NHIaHV005325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Oct 2020 13:18:37 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9DAA2289-876C-4A61-9E5E-1AB8986B210C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 23 Oct 2020 13:18:36 -0400 In-Reply-To: Cc: txauth@ietf.org To: =?utf-8?Q?Mika_Bostr=C3=B6m?= References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 17:19:14 -0000 --Apple-Mail=_9DAA2289-876C-4A61-9E5E-1AB8986B210C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mika, Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. Some background: I built out the XYZ protocol (one of the predecessors = to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 The driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } This would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } // bearer token { key: false } // bound to the RC=E2=80=99s presented key { key: true } If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. While it might sound like polymorphism means that any field could have = any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. In your example below, each field within the dictionary would also need = to be typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because it=E2=80=99s interesting: A JSON encoder that encodes numbers as = strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of = =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in = JSON, and they shouldn=E2=80=99t be treated the same by a parser = implementation when mapping to a concrete object. It=E2=80=99s in this = kind of automated guessing that this class of bugs occur, and that=E2=80=99= s going to be the case whether or not you take advantage of JSON=E2=80=99= s polymorphic nature. I=E2=80=99ve run into cases where a parser library = was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of = mapping, but ended up introducing errors in more strict components = downstream. This is something that protocol designers need to be aware = of and guard against in the design of the protocol to reduce possible = ambiguities. Within GNAP today, we generally have things that branch = whether they=E2=80=99re an object (for a rich description of something) = or some non-structured special value (for a reference or other item).=20 The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. =E2=80=94 Justin > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = wrote: >=20 > Hello, everyone. >=20 > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my = comments to this working group. >=20 > In short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.=20 >=20 > The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >=20 > Let's say we have these imaginary payloads, both possible and valid in = the same protocol step: >=20 > # payload 1 > { > ..., > "public_key": { > "alg": "rsa", > "modulus": > } > } >=20 > # payload 2 > { > ..., > "public_key": { > "alg": "rsa", > "modulus": "" > } > } >=20 > In both cases, the type of "public_key" field is a dictionary. In both = cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >=20 > While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >=20 > Ambiguity in protocols is always a source of implementation complexity = and interoperability snags, but in an AuthN/AuthZ protocol it is worse: = it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, = wouldn't it be in everyone's interest to keep implementation complexity = and mistake potential to a minimum? >=20 > Best regards, > Mika >=20 > --=20 > Mika Bostr=C3=B6m > Smarkets > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_9DAA2289-876C-4A61-9E5E-1AB8986B210C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mika,

Thanks for = bringing this topic here =E2=80=94 I was able to see the forum = discussion that brought you here, and hopefully I can help clear up what = I mean with how polymorphism is used in the proposal. The short version = is that the goal is to avoid the kinds of = ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can = help that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems.

Some background: I built = out the XYZ protocol (one of the predecessors to the initial GNAP Draft) = in Java using strongly typed parsers and Java objects specifically to = prove to myself that it could be done in a way that made any sense in = the code. (My own open source implementation is at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an = object:

{ 
    key: {
      proof: httpsig,
      jwk: { =E2=80=A6 key value =E2=80=A6 = }
    },
  =   bearer_token: true,
    = bind_to_rc_key: true
}

This would be an illegal object as per = this alternate proposal, but then you=E2=80=99d have to check each field = and make sure it wasn=E2=80=99t put next to others in the same object. = I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99s= both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the = polymorphic approach to this same field, each of these three = mutually-exclusive states is written in a way that they cannot be sent = together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and = enforced by the syntax of JSON itself.

{ 
    key: {
    =   proof: httpsig,
      jwk: { = =E2=80=A6 key value =E2=80=A6 }
    = }
}

// bearer token

{
    key: false
}

// bound to the RC=E2=80=99s presented key

{
    key: true
}

If someone sends a = different type for this field, like an array or number or a null, this = doesn=E2=80=99t have a defined interpretation in the protocol and would = be a protocol level error.

While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value = is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value.

In your = example below, each field within the dictionary would also need to be = typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take =  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run = into cases where a parser library was trying to be overly =E2=80=9Chelpful= =E2=80=9D in doing this kind of mapping, but ended up introducing errors = in more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item). 

The design team created some simple = JSON Schemas for parts of the protocol during our discussion, but we = didn=E2=80=99t include them in the design document due to both lack of = time to keep it updated with the rapid changes to the protocol during = the design team discussion, and not knowing if there would be interest = in such material. I personally think it would be helpful to include as = an informative reference in the final document, but that=E2=80=99s = something for the working group to take up eventually.

 =E2=80=94 = Justin

On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:

Hello, = everyone.

For = background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and = when I made note about certain concerns, I was requested to send my = comments to this working group.

In short, I believe that the use of = polymorphic JSON in the protocol invites subtle and confusing = implementation problems. I also searched through the WG archives, and = noticed that similar concerns were noted, briefly, in a thread in July. =

The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities.

Let's say we have these imaginary = payloads, both possible and valid in the same protocol step:

# payload 1
{
  ...,
  = "public_key": {
    "alg": "rsa",
    "modulus": = <BIGINT>
  }
}

# = payload 2
{
  = ...,
  "public_key": {
    "alg": "rsa",
    "modulus": "<encoded = string>"
  }
}

In both cases, the type = of "public_key" field is a dictionary. In both cases, they even have the = same keys. However, the values in the dictionaries are entirely = different, and an implementation will have to branch to at least two = possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

While the above is = clearly a manufactured scenario, it nonetheless demonstrates the = potential for logic bugs with polymorphic JSON. With richer types and = more complex dictionaries, there will surely be more room for = errors.

Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum?

Best regards,
Mika

--
Mika Bostr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_9DAA2289-876C-4A61-9E5E-1AB8986B210C-- From nobody Fri Oct 23 12:08:06 2020 Return-Path: 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 6C3C33A12A7 for ; Fri, 23 Oct 2020 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 CImXMUpMSVeI for ; Fri, 23 Oct 2020 12:08:02 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 ABDE73A133E for ; Fri, 23 Oct 2020 12:08:01 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id 77so3365452lfl.2 for ; Fri, 23 Oct 2020 12:08:01 -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=uupUEGXktLCSMuYsAmRTm7CtV0a4HfJZPlf/SbX0/80=; b=iFGumFezjoRFsdCgqWrpsoUIwbPTWy1ZUOwQMTCS6XRNxfVFQudywhQnO3WqRow6/5 /22axI5cFPv5Zh8IbAckm/LPIk25oHkLR/iYb6VOtCEVXVtSBQrsBXW8ug2jBQMDvvF6 RXS3iX1L/bCaQR4CpnW7shn/ASRSj6k9T/D9WN4rVapjlxdDDxutOQezaMNxl5EziGPd XrprJx1fvTYiTvbGEGEPSU2AvUAc/uyFDM8dNslb4z7hwcLd1DbNLy625smp+JEK6wDK 4egozsqbqrYXEXZZr4bG3GNjcPLS2dvYbUDeZGUYsWiw2hGEc52QSYNuj8og4rofG54E qMYg== 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=uupUEGXktLCSMuYsAmRTm7CtV0a4HfJZPlf/SbX0/80=; b=Y2UBewr1iY55yfUa4fh9hfBie2A73HVQOoWZofBEatU3Zb49S30WinHupPahj1HKvy my8FAsVlLbYSTHV7wnBKTMCetrL9wsUGeyfEWX6od4JZT0TjeV6Kas7zq6IFrB6V0ExQ SdRRzkCSiSeXALX06sClB2oKlqK6c+Bci/eI4RrIfmbrWwrzudxiHOO9AzUJmChmea9w 8foHOr4GIPifWH2suvQlR6gBWGvZfQOzKziZ0yYg0Pzy6Q9kCaLYBFnBZGWxYHzZ+/xe EZ28ahYSws2c+aDu1apFn7ADd/iMzadd6ONwWfNrq2abvFQpuZ/7NowP1OIX3PvhkZfV QE/Q== X-Gm-Message-State: AOAM532rtX57AKlLuQZC7w/IKkSHrCz1+AF8bz4L/mWCZEf84B6q12ui mA/VYLVtms+v/lzJWQwanZ6ajySuxio1lYGZBL8= X-Google-Smtp-Source: ABdhPJxOrdx+jakJkRnxuZclSiH7iYfxkBKffee3GZuOkMuxo/29ytWNtfBpeMHQA4v8a9ND3DpMTY/mDT4hxjsXais= X-Received: by 2002:a19:cb14:: with SMTP id b20mr1189013lfg.162.1603480079578; Fri, 23 Oct 2020 12:07:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 23 Oct 2020 12:07:23 -0700 Message-ID: To: Justin Richer Cc: =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000008c3d6305b25b4c9c" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 19:08:05 -0000 --0000000000008c3d6305b25b4c9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Justin, As the draft has evolved, I question the continued use of polymorphism. Note that I appreciate the elegance of using a string for pass-by-reference, and an object for pass-by-value. In the current draft, the Every time you create or process a field it will mean only one thing, and there=E2=80=99s only one field to look at to answer a question. is violated in 2.3.1. Identifying the RC Instance instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. "client": { "instance_id": "client-541-ab" } If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. "client": "client-541-ab" The instance identifier can be sent two ways. Polymorphism is a convenience for the client, but requires the server to have two code paths for "instance_id". We discussed this in the design team, and I argued for having "instance_id" in the "client" object so that any updates, such as new devices assertions, could be in the "client" object. As noted above, while I appreciate the elegance of using a string (handle) to reference a previously provided object, it complicates how to update an existing object while providing the reference. In your example of the "key" object below, setting "proof" to bearer would avoid the issue you describe: { "key": { "proof": "bearer" } } In your example, when processing the "key" object, code is having to check both the JSON type of the property, as well as check the value of the "proof" property. In the example I provided, only the value of "proof" needs to be checked. The "proof" property is acting as a type for the "key" object. Not being a Java programmer, I don't know how this would work in a Java implementation, but node.js, the processing would need to be done as above. On a related note, there was significant negative feedback on handles and polymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D24855750 /Dick On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > Hi Mika, > > Thanks for bringing this topic here =E2=80=94 I was able to see the forum > discussion that brought you here, and hopefully I can help clear up what = I > mean with how polymorphism is used in the proposal. The short version is > that the goal is to *avoid* the kinds of ambiguity that make insecure > protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using > polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree > that misusing it or applying it sloppily can lead to ambiguous and insecu= re > systems. > > Some background: I built out the XYZ protocol (one of the predecessors to > the initial GNAP Draft) in Java using strongly typed parsers and Java > objects specifically to prove to myself that it could be done in a way th= at > made any sense in the code. (My own open source implementation is at > https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not ye= t up to > date with the GNAP spec). It was important to me that I be able to use th= e > system-wide configured parsers to implement this and not have to resort t= o > stepping through elements completely by hand. Java doesn=E2=80=99t make i= t simple > to get the hooks into the right places (especially with the Jackson parse= r > that I used), but it is definitely possible to create a deterministic and > strongly-typed parser and serializer for this kind of data structure. Som= e > of the rationale for using polymorphism is covered in the trailing append= ix > of the draft document ( > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), > but it=E2=80=99s still good to discuss this here as the working group dec= ides which > approaches to take. > > The driving reason for using polymorphism at the protocol level was to > simplify the protocol and make it :more: deterministic to create and > process, not less. Every time you create or process a field it will mean > only one thing, and there=E2=80=99s only one field to look at to answer a= question. > Without polymorphic field values, you usually need to rely on mutual > exclusivity of fields, which is prone to failure and requires additional > error checking. Take for example the key binding of access tokens. An > access token could be bound to the RC=E2=80=99s key used during the reque= st, to a > different key chosen by the AS, or it could be a bearer token with no key > at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of > boolean values and objects and express this set of mutually-exclusive > options in a non-ambiguous way. Without that, you=E2=80=99d need to have = different > fields for the options and include additional checks in your parser to ma= ke > sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with > this potential security vulnerability in an object: > > { > key: { > proof: httpsig, > jwk: { =E2=80=A6 key value =E2=80=A6 } > }, > bearer_token: true, > bind_to_rc_key: true > } > > This would be an illegal object as per this alternate proposal, but then > you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others > in the same object. I=E2=80=99ve done this exercise with many other proto= cols and > it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cg= ood=E2=80=9D examples > would pass code that doesn=E2=80=99t check this. With the polymorphic app= roach to > this same field, each of these three mutually-exclusive states is written > in a way that they cannot be sent together. It=E2=80=99s not just illegal= , it=E2=80=99s > impossible and enforced by the syntax of JSON itself. > > { > key: { > proof: httpsig, > jwk: { =E2=80=A6 key value =E2=80=A6 } > } > } > > // bearer token > > { > key: false > } > > // bound to the RC=E2=80=99s presented key > > { > key: true > } > > If someone sends a different type for this field, like an array or number > or a null, this doesn=E2=80=99t have a defined interpretation in the prot= ocol and > would be a protocol level error. > > While it might sound like polymorphism means that any field could have an= y > type or value, the opposite is true: each possible value is explicitly > typed, it=E2=80=99s just that there are potentially different types that = express > meaning for the field. This applies to all members of all objects > (dictionaries) as well as all members of an array (list). Every time you > process a field value or other element, you look at the type and then the > value to determine what to do with that typed value. > > In your example below, each field within the dictionary would also need t= o > be typed, and each type would need to have a clear indication of its > meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could > be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON n= umber) or an > =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would fu= rther say what > exactly the encoding of the string would be. That means that when you rea= d > the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was > or how it was represented, regardless of the input format. Seeing a numbe= r > there means exactly one interpretation and seeing a string means exactly > one (different) interpretation =E2=80=94 but importantly, both of them ar= e a > =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines= the type. An > implementation would likely use an internal BigInteger type of object to > represent the field value after parsing, so the question is how to go fro= m > the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just > apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply= it to all > sub-fields of that object. > > So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because > it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings,= and not > numbers, is not compliant with the JSON definitions of the field in > question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not > equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t = be treated > the same by a parser implementation when mapping to a concrete object. It= =E2=80=99s > in this kind of automated guessing that this class of bugs occur, and > that=E2=80=99s going to be the case whether or not you take advantage of= JSON=E2=80=99s > polymorphic nature. I=E2=80=99ve run into cases where a parser library wa= s trying > to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but= ended up > introducing errors in more strict components downstream. This is somethin= g > that protocol designers need to be aware of and guard against in the desi= gn > of the protocol to reduce possible ambiguities. Within GNAP today, we > generally have things that branch whether they=E2=80=99re an object (for = a rich > description of something) or some non-structured special value (for a > reference or other item). > > The design team created some simple JSON Schemas for parts of the protoco= l > during our discussion, but we didn=E2=80=99t include them in the design d= ocument > due to both lack of time to keep it updated with the rapid changes to the > protocol during the design team discussion, and not knowing if there woul= d > be interest in such material. I personally think it would be helpful to > include as an informative reference in the final document, but that=E2=80= =99s > something for the working group to take up eventually. > > =E2=80=94 Justin > > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < > mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: > > Hello, everyone. > > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and > when I made note about certain concerns, I was requested to send my > comments to this working group. > > In short, I believe that the use of polymorphic JSON in the protocol > invites subtle and confusing implementation problems. I also searched > through the WG archives, and noticed that similar concerns were noted, > briefly, in a thread in July. > > The problem with polymorphic values, as I see it, is that implementations > will need to branch on the (inferred) type of a given field. This isn't > quite as bad if the types are strictly different, but allows for subtle > bugs when the value in question is a dictionary. What makes this > unappealing is that "subtle bugs" in security protocols have a habit of > turning into vulnerabilities. > > Let's say we have these imaginary payloads, both possible and valid in th= e > same protocol step: > > # payload 1 > { > ..., > "public_key": { > "alg": "rsa", > "modulus": > } > } > > # payload 2 > { > ..., > "public_key": { > "alg": "rsa", > "modulus": "" > } > } > > In both cases, the type of "public_key" field is a dictionary. In both > cases, they even have the same keys. However, the values in the > dictionaries are entirely different, and an implementation will have to > branch to at least two possible decoding mechanisms. To make things worse= , > some JSON implementations may choose to encode non-dictionary values as > strings, so it is possible for an originator to transmit what they expect > and believe to be payload 1 format, but which the receiver will interpret > to be in payload 2 format. And if the encoded string contains only digits= , > it will even parse correctly as a bignum. > > While the above is clearly a manufactured scenario, it nonetheless > demonstrates the potential for logic bugs with polymorphic JSON. With > richer types and more complex dictionaries, there will surely be more roo= m > for errors. > > Ambiguity in protocols is always a source of implementation complexity an= d > interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's > terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it > be in everyone's interest to keep implementation complexity and mistake > potential to a minimum? > > Best regards, > Mika > > -- > Mika Bostr=C3=B6m > Smarkets > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > =E1=90=A7 --0000000000008c3d6305b25b4c9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Justin,

As the= draft has evolved, I question the continued use of polymorphism. Note that= I appreciate the elegance=C2=A0of using a string for pass-by-reference, an= d an object for pass-by-value.

In the current draf= t, the=C2=A0

Every time you create or process a field it will= mean only one thing, and there=E2=80=99s only one field to look at to answ= er a question.=C2=A0

is violated in <= a href=3D"https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-00#sect= ion-2.3.1" target=3D"_blank">2.3.1.=C2=A0 Identifying the RC Instance


=C2=A0 =C2=A0instance_id =C2=A0An identifier st= ring that the AS can use to identify the
=C2=A0 =C2=A0 =C2=A0 par= ticular instance of this RC.=C2=A0 The content and structure of this
<= div>=C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.

=C2=A0 =C2=A0"client": {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0"instance_id": "client-541-ab"
=C2=A0 = =C2=A0}

=C2=A0 =C2=A0If there are no additional fi= elds to send, the RC MAY send the
=C2=A0 =C2=A0instance identifie= r as a direct reference value in lieu of the
=C2=A0 =C2=A0object.=

=C2=A0 =C2=A0"client": "client-541= -ab"

The instance identifier can= be sent two ways. Polymorphism is a convenience for the client, but requir= es the server=C2=A0to have two code=C2=A0paths for "instance_id".= =C2=A0 We discussed this in the design team, and I argued for having "= instance_id" in the "client" object=C2=A0so that any updates= , such as new devices assertions, could be in the "client" object= . As noted above, while I appreciate the elegance of using a string (handle= ) to reference a previously provided object, it complicates how to update a= n existing object while providing the reference.

I= n your example of the "key" object below, setting "proof&quo= t; to bearer would avoid the issue you describe:

{= =C2=A0
=C2=A0"key": {=C2=A0
=C2=A0 =C2=A0 =C2=A0"proof= ": "bearer"
=C2=A0 =C2=A0 }
}

In your example, when processing the "key" object, code is= having to check both the JSON type of the property, as well as check the v= alue of the "proof" property. In the example I provided, only the= value of "proof" needs to be checked. The "proof" prop= erty is acting as a type for the "key" object.

Not being a Java programmer, I don't know how this would work in= a Java implementation, but node.js, the processing would need to be done a= s above.

On a related note, there was significant = negative feedback on handles and polymorphism in the Hacker News article=C2= =A0https://news.ycombinator.com/item?id=3D24855750=C2=A0
<= br>
/Dick


On Fri, Oct 23, 2020 at = 10:20 AM Justin Richer <jricher@mit.edu> wrote:
Hi Mika,

Thanks for bringing th= is topic here =E2=80=94 I was able to see the forum discussion that brought= you here, and hopefully I can help clear up what I mean with how polymorph= ism is used in the proposal. The short version is that the goal is to=C2=A0= avoid=C2=A0the kinds of ambiguity that make insecure protocols, and = so in that goal we=E2=80=99re fully aligned. I think that using polymorphis= m in very specific ways can help that goal =E2=80=94 just as I agree that m= isusing it or applying it sloppily can lead to ambiguous and insecure syste= ms.

Some background: I built out the XYZ protocol = (one of the predecessors to the initial GNAP Draft) in Java using strongly = typed parsers and Java objects specifically to prove to myself that it coul= d be done in a way that made any sense in the code. (My own open source imp= lementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to me= that I be able to use the system-wide configured parsers to implement this= and not have to resort to stepping through elements completely by hand. Ja= va doesn=E2=80=99t make it simple to get the hooks into the right places (e= specially with the Jackson parser that I used), but it is definitely possib= le to create a deterministic and strongly-typed parser and serializer for t= his kind of data structure. Some of the rationale for using polymorphism is= covered in the trailing appendix of the draft document (https://www.ietf.org/archive/id/dra= ft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polymor), b= ut it=E2=80=99s still good to discuss this here as the working group decide= s which approaches to take.=C2=A0

The driving reas= on for using polymorphism at the protocol level was to simplify the protoco= l and make it :more: deterministic to create and process, not less. Every t= ime you create or process a field it will mean only one thing, and there=E2= =80=99s only one field to look at to answer a question. Without polymorphic= field values, you usually need to rely on mutual exclusivity of fields, wh= ich is prone to failure and requires additional error checking. Take for ex= ample the key binding of access tokens. An access token could be bound to t= he RC=E2=80=99s key used during the request, to a different key chosen by t= he AS, or it could be a bearer token with no key at all. By making the =E2= =80=9Ckey=E2=80=9D field polymorphic, we can define it in terms of boolean = values and objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different field= s for the options and include additional checks in your parser to make sure= they weren=E2=80=99t sent simultaneously, otherwise you could get hit with= this potential security vulnerability in an object:

{=C2=A0
=C2=A0 =C2=A0 key: {
=C2=A0 =C2=A0 =C2=A0 pr= oof: httpsig,
=C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2= =80=A6 }
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 bearer_token: t= rue,
=C2=A0 =C2=A0 bind_to_rc_key: true
}
This would be an illegal object as per this alternate proposal,= but then you=E2=80=99d have to check each field and make sure it wasn=E2= =80=99t put next to others in the same object. I=E2=80=99ve done this exerc= ise with many other protocols and it=E2=80=99s both error prone and easy to= ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code that = doesn=E2=80=99t check this. With the polymorphic approach to this same fiel= d, each of these three mutually-exclusive states is written in a way that t= hey cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s im= possible and enforced by the syntax of JSON itself.

{=C2=A0
=C2=A0 =C2=A0 key: {
=C2=A0 =C2=A0 =C2= =A0 proof: httpsig,
=C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key val= ue =E2=80=A6 }
=C2=A0 =C2=A0 }
}

// bearer token

{
=C2=A0 =C2=A0 key: = false
}

// bound to the RC=E2=80= =99s presented key

{
=C2=A0 =C2=A0 key: = true
}

If someone sends a different type= for this field, like an array or number or a null, this doesn=E2=80=99t ha= ve a defined interpretation in the protocol and would be a protocol level e= rror.

While it might sound like polymorphism means= that any field could have any type or value, the opposite is true: each po= ssible value is explicitly typed, it=E2=80=99s just that there are potentia= lly different types that express meaning for the field. This applies to all= members of all objects (dictionaries) as well as all members of an array (= list). Every time you process a field value or other element, you look at t= he type and then the value to determine what to do with that typed value.

In your example below, each field within the dictio= nary would also need to be typed, and each type would need to have a clear = indication of its meaning. To take your strawman key format below, the =E2= =80=9Cmodulus=E2=80=9D field could be defined polymorphically as either a = =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2= =80=9D (a JSON string). The definition would further say what exactly the e= ncoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the = value was or how it was represented, regardless of the input format. Seeing= a number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both of t= hem are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that de= termines the type. An implementation would likely use an internal BigIntege= r type of object to represent the field value after parsing, so the questio= n is how to go from the JSON value (which is typed) into the BigInteger val= ue.You don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key= =E2=80=9D field, you apply it to all sub-fields of that object.=C2=A0
=

So let=E2=80=99s dig into the specific bug you bring up= in the strawman, because it=E2=80=99s interesting: A JSON encoder that enc= odes numbers as strings, and not numbers, is not compliant with the JSON de= finitions of the field in question. For another example, the quoted string = value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true= in JSON, and they shouldn=E2=80=99t be treated the same by a parser implem= entation when mapping to a concrete object. It=E2=80=99s in this kind of au= tomated guessing that this class of bugs occur, and that=E2=80=99s going to= be the case whether or not you take =C2=A0advantage of JSON=E2=80=99s poly= morphic nature. I=E2=80=99ve run into cases where a parser library was tryi= ng to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up introducing errors in more strict components downstream. This is= something that protocol designers need to be aware of and guard against in= the design of the protocol to reduce possible ambiguities. Within GNAP tod= ay, we generally have things that branch whether they=E2=80=99re an object = (for a rich description of something) or some non-structured special value = (for a reference or other item).=C2=A0

The design = team created some simple JSON Schemas for parts of the protocol during our = discussion, but we didn=E2=80=99t include them in the design document due t= o both lack of time to keep it updated with the rapid changes to the protoc= ol during the design team discussion, and not knowing if there would be int= erest in such material. I personally think it would be helpful to include a= s an informative reference in the final document, but that=E2=80=99s someth= ing for the working group to take up eventually.

= =C2=A0=E2=80=94 Justin

On Oct = 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarke= ts.com@dmarc.ietf.org> wrote:

He= llo, everyone.

For background: GNAP/TxAuth/XYZ/Oau= th3 came up on a discussion forum and when I made note about certain concer= ns, I was requested to send my comments to this working group.

In short, I believe that the use of polymorphic JSON in th= e protocol invites subtle and confusing implementation problems. I also sea= rched through the WG archives, and noticed that similar concerns were noted= , briefly, in a thread in July.

The problem w= ith polymorphic values, as I see it, is that implementations will need to b= ranch on the (inferred) type of a given field. This isn't quite as bad = if the types are strictly different, but allows for subtle bugs when the va= lue in question is a dictionary. What makes this unappealing is that "= subtle bugs" in security protocols have a habit of turning into vulner= abilities.

Let's say we have these imaginary p= ayloads, both possible and valid in the same protocol step:

<= /div>
# payload 1
{
=C2=A0 ...,
=C2=A0 &q= uot;public_key": {
=C2=A0=C2=A0=C2=A0 "alg": "= ;rsa",
=C2=A0=C2=A0=C2=A0 "modulus": <BIGIN= T>
=C2=A0 }
}

# payload 2
{
=C2=A0 ...,
=C2=A0 "public_key": {=
=C2=A0=C2=A0=C2=A0 "alg": "rsa",
= =C2=A0=C2=A0=C2=A0 "modulus": "<encoded string>"<= /div>
=C2=A0 }
}

In both cases, the = type of "public_key" field is a dictionary. In both cases, they e= ven have the same keys. However, the values in the dictionaries are entirel= y different, and an implementation will have to branch to at least two poss= ible decoding mechanisms. To make things worse, some JSON implementations m= ay choose to encode non-dictionary values as strings, so it is possible for= an originator to transmit what they expect and believe to be payload 1 for= mat, but which the receiver will interpret to be in payload 2 format. And i= f the encoded string contains only digits, it will even parse correctly as = a bignum.

While the above is clearly a manufac= tured scenario, it nonetheless demonstrates the potential for logic bugs wi= th polymorphic JSON. With richer types and more complex dictionaries, there= will surely be more room for errors.

Ambiguity in= protocols is always a source of implementation complexity and interoperabi= lity snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying= . If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in e= veryone's interest to keep implementation complexity and mistake potent= ial to a minimum?

Best regards,
Mika=

--
Mika Bostr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--0000000000008c3d6305b25b4c9c-- From nobody Fri Oct 23 12:42:06 2020 Return-Path: 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 8613D3A09E0 for ; Fri, 23 Oct 2020 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GETd7rDC0-_d for ; Fri, 23 Oct 2020 12:42:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CB93A09E7 for ; Fri, 23 Oct 2020 12:42:01 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09NJfvbP024167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Oct 2020 15:41:58 -0400 From: Justin Richer Message-Id: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_C4C06F75-0285-489C-AC66-08D7538217D6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 23 Oct 2020 15:41:57 -0400 In-Reply-To: Cc: =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List To: Dick Hardt References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 19:42:05 -0000 --Apple-Mail=_C4C06F75-0285-489C-AC66-08D7538217D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick, As you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored. The crux of my argument is that is exactly a case of pass-by-reference = vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol. =E2=80=94 Justin > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >=20 > Hey Justin, >=20 > As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >=20 > In the current draft, the=20 >=20 > Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question.=20 >=20 > is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >=20 >=20 > instance_id An identifier string that the AS can use to identify = the > particular instance of this RC. The content and structure of = this > identifier is opaque to the RC. >=20 > "client": { > "instance_id": "client-541-ab" > } >=20 > If there are no additional fields to send, the RC MAY send the > instance identifier as a direct reference value in lieu of the > object. >=20 > "client": "client-541-ab" >=20 > The instance identifier can be sent two ways. Polymorphism is a = convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >=20 > In your example of the "key" object below, setting "proof" to bearer = would avoid the issue you describe: >=20 > {=20 > "key": {=20 > "proof": "bearer"=20 > }=20 > } >=20 > In your example, when processing the "key" object, code is having to = check both the JSON type of the property, as well as check the value of = the "proof" property. In the example I provided, only the value of = "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >=20 > Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done = as above. >=20 > On a related note, there was significant negative feedback on handles = and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >=20 > /Dick >=20 >=20 > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer > wrote: > Hi Mika, >=20 > Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. >=20 > Some background: I built out the XYZ protocol (one of the predecessors = to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >=20 > The driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >=20 > {=20 > key: { > proof: httpsig, > jwk: { =E2=80=A6 key value =E2=80=A6 } > }, > bearer_token: true, > bind_to_rc_key: true > } >=20 > This would be an illegal object as per this alternate proposal, but = then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. >=20 > {=20 > key: { > proof: httpsig, > jwk: { =E2=80=A6 key value =E2=80=A6 } > } > } >=20 > // bearer token >=20 > { > key: false > } >=20 > // bound to the RC=E2=80=99s presented key >=20 > { > key: true > } >=20 > If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. >=20 > While it might sound like polymorphism means that any field could have = any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. >=20 > In your example below, each field within the dictionary would also = need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 >=20 > So let=E2=80=99s dig into the specific bug you bring up in the = strawman, because it=E2=80=99s interesting: A JSON encoder that encodes = numbers as strings, and not numbers, is not compliant with the JSON = definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in = this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where = a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item).=20 >=20 > The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. >=20 > =E2=80=94 Justin >=20 >> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>=20 >> Hello, everyone. >>=20 >> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my = comments to this working group. >>=20 >> In short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.=20 >>=20 >> The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >>=20 >> Let's say we have these imaginary payloads, both possible and valid = in the same protocol step: >>=20 >> # payload 1 >> { >> ..., >> "public_key": { >> "alg": "rsa", >> "modulus": >> } >> } >>=20 >> # payload 2 >> { >> ..., >> "public_key": { >> "alg": "rsa", >> "modulus": "" >> } >> } >>=20 >> In both cases, the type of "public_key" field is a dictionary. In = both cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >>=20 >> While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >>=20 >> Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum? >>=20 >> Best regards, >> Mika >>=20 >> --=20 >> Mika Bostr=C3=B6m >> Smarkets >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =E1=90=A7 --Apple-Mail=_C4C06F75-0285-489C-AC66-08D7538217D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dick,

As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.

The= crux of my argument is that is exactly a case of pass-by-reference vs = pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol.

 =E2=80=94 Justin

On Oct = 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey = Justin,

As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string = for pass-by-reference, and an object for pass-by-value.

In the current draft, = the 

Every time you create or process a field it will mean only = one thing, and there=E2=80=99s only one field to look at to answer a = question. 

is violated in 2.3.1.  Identifying the RC = Instance

  =  instance_id  An identifier string that the AS can use to = identify the
      particular = instance of this RC.  The content and structure of this
      identifier is opaque to the = RC.

  =  "client": {
      =  "instance_id": "client-541-ab"
  =  }

  =  If there are no additional fields to send, the RC MAY send = the
   instance identifier as a direct = reference value in lieu of the
  =  object.

   "client": "client-541-ab"

The instance identifier = can be sent two ways. Polymorphism is a convenience for the client, but = requires the server to have two code paths for = "instance_id".  We discussed this in the design team, and I argued = for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.

In = your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe:

{ 
 "key": = { 
     "proof": "bearer"
    }
}

In your example, when = processing the "key" object, code is having to check both the JSON type = of the property, as well as check the value of the "proof" property. In = the example I provided, only the value of "proof" needs to be checked. = The "proof" property is acting as a type for the "key" object.

Not being a Java = programmer, I don't know how this would work in a Java implementation, = but node.js, the processing would need to be done as above.

On a related note, there = was significant negative feedback on handles and polymorphism in the = Hacker News article https://news.ycombinator.com/item?id=3D24855750 
=

/Dick


On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = <jricher@mit.edu> wrote:
Hi Mika,

Thanks for bringing this = topic here =E2=80=94 I was able to see the forum discussion that brought = you here, and hopefully I can help clear up what I mean with how = polymorphism is used in the proposal. The short version is that the goal = is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems.

Some background: I built out the XYZ = protocol (one of the predecessors to the initial GNAP Draft) in Java = using strongly typed parsers and Java objects specifically to prove to = myself that it could be done in a way that made any sense in the code. = (My own open source implementation is at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an = object:

{ 
    key: {
      proof: httpsig,
      jwk: { =E2=80=A6 key value =E2=80=A6 = }
    },
  =   bearer_token: true,
    = bind_to_rc_key: true
}

This would be an illegal object as per = this alternate proposal, but then you=E2=80=99d have to check each field = and make sure it wasn=E2=80=99t put next to others in the same object. = I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99s= both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the = polymorphic approach to this same field, each of these three = mutually-exclusive states is written in a way that they cannot be sent = together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and = enforced by the syntax of JSON itself.

{ 
    key: {
    =   proof: httpsig,
      jwk: { = =E2=80=A6 key value =E2=80=A6 }
    = }
}

// bearer token

{
    key: false
}

// bound to the RC=E2=80=99s presented key

{
    key: true
}

If someone sends a = different type for this field, like an array or number or a null, this = doesn=E2=80=99t have a defined interpretation in the protocol and would = be a protocol level error.

While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value = is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value.

In your = example below, each field within the dictionary would also need to be = typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take =  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run = into cases where a parser library was trying to be overly =E2=80=9Chelpful= =E2=80=9D in doing this kind of mapping, but ended up introducing errors = in more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item). 

The design team created some simple = JSON Schemas for parts of the protocol during our discussion, but we = didn=E2=80=99t include them in the design document due to both lack of = time to keep it updated with the rapid changes to the protocol during = the design team discussion, and not knowing if there would be interest = in such material. I personally think it would be helpful to include as = an informative reference in the final document, but that=E2=80=99s = something for the working group to take up eventually.

 =E2=80=94 = Justin

On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m= <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:

Hello, everyone.

For background: GNAP/TxAuth/XYZ/Oauth3 = came up on a discussion forum and when I made note about certain = concerns, I was requested to send my comments to this working group.

In = short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.

The problem with polymorphic values, as = I see it, is that implementations will need to branch on the (inferred) = type of a given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into = vulnerabilities.

Let's say we have these imaginary payloads, both possible and = valid in the same protocol step:

# payload 1
{
  ...,
  = "public_key": {
    "alg": "rsa",
    "modulus": = <BIGINT>
  }
}

# = payload 2
{
  = ...,
  "public_key": {
    "alg": "rsa",
    "modulus": "<encoded = string>"
  }
}

In both cases, the type = of "public_key" field is a dictionary. In both cases, they even have the = same keys. However, the values in the dictionaries are entirely = different, and an implementation will have to branch to at least two = possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

While the above is = clearly a manufactured scenario, it nonetheless demonstrates the = potential for logic bugs with polymorphic JSON. With richer types and = more complex dictionaries, there will surely be more room for = errors.

Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum?

Best regards,
Mika

--
Mika Bostr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
3D""=E1=90=A7

= --Apple-Mail=_C4C06F75-0285-489C-AC66-08D7538217D6-- From nobody Fri Oct 23 12:53:18 2020 Return-Path: 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 BC1E13A0948 for ; Fri, 23 Oct 2020 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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=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 faDuNSu_vX0c for ; Fri, 23 Oct 2020 12:53:13 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450: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 DA1A73A0AE2 for ; Fri, 23 Oct 2020 12:53:12 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id a9so3489921lfc.7 for ; Fri, 23 Oct 2020 12:53:12 -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=eSZfZA0VvCtmfiw1AlCP0sIZPQExQ0xeZbjQLGjL5ZY=; b=gAxyiof4La4dTcwcywYkmhATJrFKFhMJxpyTBYUEdsDQS8mT/5URPDkEzDgSD8UcwH LSVcowH2SaSeIhtAQv2YbY/nvdxbZpY2rlGoUT6fGq63thdxHP+53DLwRTqC3cmn/Dvc UOP0p38WYQZNHR00gB6Bqxorxe2UjLvMnwknHWmmSvCZ9huY8H7A80VYR8kTKsvWqH5G jM2PChRUF4bYuzJoqMMQYLenY5XXfht8knDx4vlvVVSH2dBGJx8or1FHuh/Bnz0jFYb5 mzj3qSn5Wok4IaEidLovMC/Hl4x44aAuJ50weLDi3UDZAiTsa/ZGTVQ2O75Gc5IBZ9ne +ndA== 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=eSZfZA0VvCtmfiw1AlCP0sIZPQExQ0xeZbjQLGjL5ZY=; b=JyPvO+3CZ2zX+de6Iyg9r67ZPDvt0uP8BfW2SzdTpQd/tp8Ap9ieq7X5ZzolSt3moK QW3KV/z61DrSpAaNrz7+U/MFExJ391liBt4Z9t6r0Z0Lhe4XZW49yOKtQRpRCtFkNPnJ EzjPGAMOj1TAmF4FiJjcmM5fspDnEIEnJIjX1P5d4q1YWYVI/s0JtP22pZBFsNzFs/am bi8iYiYc2ZAGkOR6uCXNmcxbk21/V9QE1dSJlaaufc4AARI+dUL5FNzxLOpVQTvTn0s1 O1cmnRXejfDqQZ0nC9KhlWZ4L8wDoUz1wrPhmH3jIQFyXtOCSvFa0akVWZxKFiafoxon tktA== X-Gm-Message-State: AOAM533AOJrGz/gU5kZdNUG+ryIhpoSYfGGd+5kEhaRo5sdHmaTzxP6T IZ4Ki/qtHiPV1LJMwp6SeOE3rnldvDqRQPBlrVk= X-Google-Smtp-Source: ABdhPJw0IbA8bYa9XIaN95jngy/18JjAP088ZvrUOLiP+ef1SmEvPvicYxVx+UnD3gCoEuXHHeSOP1DLAuHd8LY/Ats= X-Received: by 2002:a05:6512:68a:: with SMTP id t10mr1210844lfe.221.1603482790604; Fri, 23 Oct 2020 12:53:10 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> In-Reply-To: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> From: Dick Hardt Date: Fri, 23 Oct 2020 12:52:34 -0700 Message-ID: To: Justin Richer Cc: =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000023335005b25bee10" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 19:53:17 -0000 --00000000000023335005b25bee10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin I did note that I was the one that argued for instance_id being in the object. Since it is in the object in the current draft, not including a pass by reference option would be preferable. As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on These are all attributes of the client that an AS may require on the initial grant request, and in future grant requests (which is when an instance_id) would be used. /Dick =E1=90=A7 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > Dick, > > As you=E2=80=99ll recall, I argued against including the client instance > identifier inside of the object as a mutually-exclusive field precisely > because of the principle violation that you are pointing out here, and so > it=E2=80=99s important to point out that the current text is a compromise= that > needs to be examined in the wider experience of the working group. I am o= n > the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D= option within an > object, but this needs to be explored. > > The crux of my argument is that is exactly a case of pass-by-reference vs > pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient > instance=E2=80=9D value itself but rather belong outside of that object i= n a > another part of the request. As stated in the editorial notes in this > section, we need to look carefully at how these concepts fit within the > model and where we would want to put them. Without concrete examples of > what these extensions look like and how they=E2=80=99re generated, that i= s nearly > impossible to do at this stage. I look forward to seeing examples of this > kind of data and how it can fit into the protocol. > > =E2=80=94 Justin > > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: > > Hey Justin, > > As the draft has evolved, I question the continued use of polymorphism. > Note that I appreciate the elegance of using a string for > pass-by-reference, and an object for pass-by-value. > > In the current draft, the > > Every time you create or process a field it will mean only one thing, and > there=E2=80=99s only one field to look at to answer a question. > > > is violated in 2.3.1. Identifying the RC Instance > > > > instance_id An identifier string that the AS can use to identify the > particular instance of this RC. The content and structure of this > identifier is opaque to the RC. > > "client": { > "instance_id": "client-541-ab" > } > > If there are no additional fields to send, the RC MAY send the > instance identifier as a direct reference value in lieu of the > object. > > "client": "client-541-ab" > > > The instance identifier can be sent two ways. Polymorphism is a > convenience for the client, but requires the server to have two code path= s > for "instance_id". We discussed this in the design team, and I argued fo= r > having "instance_id" in the "client" object so that any updates, such as > new devices assertions, could be in the "client" object. As noted above, > while I appreciate the elegance of using a string (handle) to reference a > previously provided object, it complicates how to update an existing obje= ct > while providing the reference. > > In your example of the "key" object below, setting "proof" to bearer woul= d > avoid the issue you describe: > > { > "key": { > "proof": "bearer" > } > } > > In your example, when processing the "key" object, code is having to chec= k > both the JSON type of the property, as well as check the value of the > "proof" property. In the example I provided, only the value of "proof" > needs to be checked. The "proof" property is acting as a type for the "ke= y" > object. > > Not being a Java programmer, I don't know how this would work in a Java > implementation, but node.js, the processing would need to be done as abov= e. > > On a related note, there was significant negative feedback on handles and > polymorphism in the Hacker News article > https://news.ycombinator.com/item?id=3D24855750 > > /Dick > > > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > >> Hi Mika, >> >> Thanks for bringing this topic here =E2=80=94 I was able to see the foru= m >> discussion that brought you here, and hopefully I can help clear up what= I >> mean with how polymorphism is used in the proposal. The short version is >> that the goal is to *avoid* the kinds of ambiguity that make insecure >> protocols, and so in that goal we=E2=80=99re fully aligned. I think that= using >> polymorphism in very specific ways can help that goal =E2=80=94 just as = I agree >> that misusing it or applying it sloppily can lead to ambiguous and insec= ure >> systems. >> >> Some background: I built out the XYZ protocol (one of the predecessors t= o >> the initial GNAP Draft) in Java using strongly typed parsers and Java >> objects specifically to prove to myself that it could be done in a way t= hat >> made any sense in the code. (My own open source implementation is at >> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not y= et up to >> date with the GNAP spec). It was important to me that I be able to use t= he >> system-wide configured parsers to implement this and not have to resort = to >> stepping through elements completely by hand. Java doesn=E2=80=99t make = it simple >> to get the hooks into the right places (especially with the Jackson pars= er >> that I used), but it is definitely possible to create a deterministic an= d >> strongly-typed parser and serializer for this kind of data structure. So= me >> of the rationale for using polymorphism is covered in the trailing appen= dix >> of the draft document ( >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#na= me-json-structures-and-polymor), >> but it=E2=80=99s still good to discuss this here as the working group de= cides which >> approaches to take. >> >> The driving reason for using polymorphism at the protocol level was to >> simplify the protocol and make it :more: deterministic to create and >> process, not less. Every time you create or process a field it will mean >> only one thing, and there=E2=80=99s only one field to look at to answer = a question. >> Without polymorphic field values, you usually need to rely on mutual >> exclusivity of fields, which is prone to failure and requires additional >> error checking. Take for example the key binding of access tokens. An >> access token could be bound to the RC=E2=80=99s key used during the requ= est, to a >> different key chosen by the AS, or it could be a bearer token with no ke= y >> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can de= fine it in terms of >> boolean values and objects and express this set of mutually-exclusive >> options in a non-ambiguous way. Without that, you=E2=80=99d need to have= different >> fields for the options and include additional checks in your parser to m= ake >> sure they weren=E2=80=99t sent simultaneously, otherwise you could get h= it with >> this potential security vulnerability in an object: >> >> { >> key: { >> proof: httpsig, >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> }, >> bearer_token: true, >> bind_to_rc_key: true >> } >> >> This would be an illegal object as per this alternate proposal, but then >> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t p= ut next to others >> in the same object. I=E2=80=99ve done this exercise with many other prot= ocols and >> it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9C= good=E2=80=9D examples >> would pass code that doesn=E2=80=99t check this. With the polymorphic ap= proach to >> this same field, each of these three mutually-exclusive states is writte= n >> in a way that they cannot be sent together. It=E2=80=99s not just illega= l, it=E2=80=99s >> impossible and enforced by the syntax of JSON itself. >> >> { >> key: { >> proof: httpsig, >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> } >> } >> >> // bearer token >> >> { >> key: false >> } >> >> // bound to the RC=E2=80=99s presented key >> >> { >> key: true >> } >> >> If someone sends a different type for this field, like an array or numbe= r >> or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and >> would be a protocol level error. >> >> While it might sound like polymorphism means that any field could have >> any type or value, the opposite is true: each possible value is explicit= ly >> typed, it=E2=80=99s just that there are potentially different types that= express >> meaning for the field. This applies to all members of all objects >> (dictionaries) as well as all members of an array (list). Every time you >> process a field value or other element, you look at the type and then th= e >> value to determine what to do with that typed value. >> >> In your example below, each field within the dictionary would also need >> to be typed, and each type would need to have a clear indication of its >> meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could >> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON = number) or an >> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would f= urther say what >> exactly the encoding of the string would be. That means that when you re= ad >> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confus= ion on what the value was >> or how it was represented, regardless of the input format. Seeing a numb= er >> there means exactly one interpretation and seeing a string means exactly >> one (different) interpretation =E2=80=94 but importantly, both of them a= re a >> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An >> implementation would likely use an internal BigInteger type of object to >> represent the field value after parsing, so the question is how to go fr= om >> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you appl= y it to all >> sub-fields of that object. >> >> So let=E2=80=99s dig into the specific bug you bring up in the strawman,= because >> it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings= , and not >> numbers, is not compliant with the JSON definitions of the field in >> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t= be treated >> the same by a parser implementation when mapping to a concrete object. I= t=E2=80=99s >> in this kind of automated guessing that this class of bugs occur, and >> that=E2=80=99s going to be the case whether or not you take advantage o= f JSON=E2=80=99s >> polymorphic nature. I=E2=80=99ve run into cases where a parser library w= as trying >> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up >> introducing errors in more strict components downstream. This is somethi= ng >> that protocol designers need to be aware of and guard against in the des= ign >> of the protocol to reduce possible ambiguities. Within GNAP today, we >> generally have things that branch whether they=E2=80=99re an object (for= a rich >> description of something) or some non-structured special value (for a >> reference or other item). >> >> The design team created some simple JSON Schemas for parts of the >> protocol during our discussion, but we didn=E2=80=99t include them in th= e design >> document due to both lack of time to keep it updated with the rapid chan= ges >> to the protocol during the design team discussion, and not knowing if th= ere >> would be interest in such material. I personally think it would be helpf= ul >> to include as an informative reference in the final document, but that= =E2=80=99s >> something for the working group to take up eventually. >> >> =E2=80=94 Justin >> >> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >> >> Hello, everyone. >> >> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and >> when I made note about certain concerns, I was requested to send my >> comments to this working group. >> >> In short, I believe that the use of polymorphic JSON in the protocol >> invites subtle and confusing implementation problems. I also searched >> through the WG archives, and noticed that similar concerns were noted, >> briefly, in a thread in July. >> >> The problem with polymorphic values, as I see it, is that implementation= s >> will need to branch on the (inferred) type of a given field. This isn't >> quite as bad if the types are strictly different, but allows for subtle >> bugs when the value in question is a dictionary. What makes this >> unappealing is that "subtle bugs" in security protocols have a habit of >> turning into vulnerabilities. >> >> Let's say we have these imaginary payloads, both possible and valid in >> the same protocol step: >> >> # payload 1 >> { >> ..., >> "public_key": { >> "alg": "rsa", >> "modulus": >> } >> } >> >> # payload 2 >> { >> ..., >> "public_key": { >> "alg": "rsa", >> "modulus": "" >> } >> } >> >> In both cases, the type of "public_key" field is a dictionary. In both >> cases, they even have the same keys. However, the values in the >> dictionaries are entirely different, and an implementation will have to >> branch to at least two possible decoding mechanisms. To make things wors= e, >> some JSON implementations may choose to encode non-dictionary values as >> strings, so it is possible for an originator to transmit what they expec= t >> and believe to be payload 1 format, but which the receiver will interpre= t >> to be in payload 2 format. And if the encoded string contains only digit= s, >> it will even parse correctly as a bignum. >> >> While the above is clearly a manufactured scenario, it nonetheless >> demonstrates the potential for logic bugs with polymorphic JSON. With >> richer types and more complex dictionaries, there will surely be more ro= om >> for errors. >> >> Ambiguity in protocols is always a source of implementation complexity >> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, would= n't >> it be in everyone's interest to keep implementation complexity and mista= ke >> potential to a minimum? >> >> Best regards, >> Mika >> >> -- >> Mika Bostr=C3=B6m >> Smarkets >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > =E1=90=A7 > > > --00000000000023335005b25bee10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin

I did note that I was the one th= at argued for instance_id being in the object. Since it is in the object in= the current draft, not including a pass by reference option would be prefe= rable.=C2=A0

As for concrete examples:
-= version of client
- version of OS
- security attestati= on of OS / device
- location of client device
- network= client is operating on

These are all attributes o= f the client that an AS may require=C2=A0on the initial grant request, and = in future grant requests (which is when an instance_id) would be used.

/Dick

3D""=E1=90=A7

On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Dick= ,

As you=E2=80=99ll recall, I argued against including t= he client instance identifier inside of the object as a mutually-exclusive = field precisely because of the principle violation that you are pointing ou= t here, and so it=E2=80=99s important to point out that the current text is= a compromise that needs to be examined in the wider experience of the work= ing group. I am on the side of removing the mutually-exclusive =E2=80=9Cins= tance_id=E2=80=9D option within an object, but this needs to be explored.

The crux of my argument is that is exactly a case o= f pass-by-reference vs pass-by-value, and that runtime attestations are not= part of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belo= ng outside of that object in a another part of the request. As stated in th= e editorial notes in this section, we need to look carefully at how these c= oncepts fit within the model and where we would want to put them. Without c= oncrete examples of what these extensions look like and how they=E2=80=99re= generated, that is nearly impossible to do at this stage. I look forward t= o seeing examples of this kind of data and how it can fit into the protocol= .

=C2=A0=E2=80=94 Justin

On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

As the draft has evolved, I question the continued use= of polymorphism. Note that I appreciate the elegance=C2=A0of using a strin= g for pass-by-reference, and an object for pass-by-value.

In the current draft, the=C2=A0

Every time you = create or process a field it will mean only one thing, and there=E2=80=99s = only one field to look at to answer a question.=C2=A0



=C2=A0 = =C2=A0instance_id =C2=A0An identifier string that the AS can use to identif= y the
=C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2=A0 = The content and structure of this
=C2=A0 =C2=A0 =C2=A0 identifier= is opaque to the RC.

=C2=A0 =C2=A0"client&qu= ot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "= client-541-ab"
=C2=A0 =C2=A0}

=C2= =A0 =C2=A0If there are no additional fields to send, the RC MAY send the
=C2=A0 =C2=A0instance identifier as a direct reference value in lie= u of the
=C2=A0 =C2=A0object.

=C2=A0 =C2= =A0"client": "client-541-ab"
The instance identifier can be sent two ways. Polymorphism is a= convenience for the client, but requires the server=C2=A0to have two code= =C2=A0paths for "instance_id".=C2=A0 We discussed this in the des= ign team, and I argued for having "instance_id" in the "clie= nt" object=C2=A0so that any updates, such as new devices assertions, c= ould be in the "client" object. As noted above, while I appreciat= e the elegance of using a string (handle) to reference a previously provide= d object, it complicates how to update an existing object while providing t= he reference.

In your example of the "key&quo= t; object below, setting "proof" to bearer would avoid the issue = you describe:

{=C2=A0
=C2=A0"key": {= =C2=A0
=C2=A0 =C2=A0 =C2=A0"proof": "bearer"
=C2= =A0 =C2=A0 }
}

In your example, when proce= ssing the "key" object, code is having to check both the JSON typ= e of the property, as well as check the value of the "proof" prop= erty. In the example I provided, only the value of "proof" needs = to be checked. The "proof" property is acting as a type for the &= quot;key" object.

Not being a Java programmer= , I don't know how this would work in a Java implementation, but node.j= s, the processing would need to be done as above.

= On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article=C2=A0https://news.ycombinator.com= /item?id=3D24855750=C2=A0

/Dick

=

On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote= :
Hi Mika,<= div>
Thanks for bringing this topic here =E2=80=94 I was able= to see the forum discussion that brought you here, and hopefully I can hel= p clear up what I mean with how polymorphism is used in the proposal. The s= hort version is that the goal is to=C2=A0avoid=C2=A0the kinds of amb= iguity that make insecure protocols, and so in that goal we=E2=80=99re full= y aligned. I think that using polymorphism in very specific ways can help t= hat goal =E2=80=94 just as I agree that misusing it or applying it sloppily= can lead to ambiguous and insecure systems.

Some = background: I built out the XYZ protocol (one of the predecessors to the in= itial GNAP Draft) in Java using strongly typed parsers and Java objects spe= cifically to prove to myself that it could be done in a way that made any s= ense in the code. (My own open source implementation is at=C2=A0https://github.co= m/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date wi= th the GNAP spec). It was important to me that I be able to use the system-= wide configured parsers to implement this and not have to resort to steppin= g through elements completely by hand. Java doesn=E2=80=99t make it simple = to get the hooks into the right places (especially with the Jackson parser = that I used), but it is definitely possible to create a deterministic and s= trongly-typed parser and serializer for this kind of data structure. Some o= f the rationale for using polymorphism is covered in the trailing appendix = of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html= #name-json-structures-and-polymor), but it=E2=80=99s still good to disc= uss this here as the working group decides which approaches to take.=C2=A0<= /div>

The driving reason for using polymorphism at the p= rotocol level was to simplify the protocol and make it :more: deterministic= to create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look at = to answer a question. Without polymorphic field values, you usually need to= rely on mutual exclusivity of fields, which is prone to failure and requir= es additional error checking. Take for example the key binding of access to= kens. An access token could be bound to the RC=E2=80=99s key used during th= e request, to a different key chosen by the AS, or it could be a bearer tok= en with no key at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphi= c, we can define it in terms of boolean values and objects and express this= set of mutually-exclusive options in a non-ambiguous way. Without that, yo= u=E2=80=99d need to have different fields for the options and include addit= ional checks in your parser to make sure they weren=E2=80=99t sent simultan= eously, otherwise you could get hit with this potential security vulnerabil= ity in an object:

{=C2=A0
=C2=A0 =C2=A0 = key: {
=C2=A0 =C2=A0 =C2=A0 proof: httpsig,
=C2=A0 =C2= =A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
=C2=A0 =C2=A0 }= ,
=C2=A0 =C2=A0 bearer_token: true,
=C2=A0 =C2=A0 bind_= to_rc_key: true
}

This would be an illeg= al object as per this alternate proposal, but then you=E2=80=99d have to ch= eck each field and make sure it wasn=E2=80=99t put next to others in the sa= me object. I=E2=80=99ve done this exercise with many other protocols and it= =E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood= =E2=80=9D examples would pass code that doesn=E2=80=99t check this. With th= e polymorphic approach to this same field, each of these three mutually-exc= lusive states is written in a way that they cannot be sent together. It=E2= =80=99s not just illegal, it=E2=80=99s impossible and enforced by the synta= x of JSON itself.

{=C2=A0
=C2=A0 = =C2=A0 key: {
=C2=A0 =C2=A0 =C2=A0 proof: httpsig,
=C2= =A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
=C2=A0 = =C2=A0 }
}

// bearer token
{
=C2=A0 =C2=A0 key: false
}

// bound to the RC=E2=80=99s presented key

<= /div>
{
=C2=A0 =C2=A0 key: true
}

If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in the= protocol and would be a protocol level error.

Whi= le it might sound like polymorphism means that any field could have any typ= e or value, the opposite is true: each possible value is explicitly typed, = it=E2=80=99s just that there are potentially different types that express m= eaning for the field. This applies to all members of all objects (dictionar= ies) as well as all members of an array (list). Every time you process a fi= eld value or other element, you look at the type and then the value to dete= rmine what to do with that typed value.

In your ex= ample below, each field within the dictionary would also need to be typed, = and each type would need to have a clear indication of its meaning. To take= your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could = be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON num= ber) or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition= would further say what exactly the encoding of the string would be. That m= eans that when you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2= =80=99t be any confusion on what the value was or how it was represented, r= egardless of the input format. Seeing a number there means exactly one inte= rpretation and seeing a string means exactly one (different) interpretation= =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, s= ince that=E2=80=99s the field that determines the type. An implementation w= ould likely use an internal BigInteger type of object to represent the fiel= d value after parsing, so the question is how to go from the JSON value (wh= ich is typed) into the BigInteger value.You don=E2=80=99t just apply the ty= pe rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub= -fields of that object.=C2=A0

So let=E2=80=99s dig= into the specific bug you bring up in the strawman, because it=E2=80=99s i= nteresting: A JSON encoder that encodes numbers as strings, and not numbers= , is not compliant with the JSON definitions of the field in question. For = another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not e= quivalent to the boolean value true in JSON, and they shouldn=E2=80=99t be = treated the same by a parser implementation when mapping to a concrete obje= ct. It=E2=80=99s in this kind of automated guessing that this class of bugs= occur, and that=E2=80=99s going to be the case whether or not you take =C2= =A0advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into ca= ses where a parser library was trying to be overly =E2=80=9Chelpful=E2=80= =9D in doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers nee= d to be aware of and guard against in the design of the protocol to reduce = possible ambiguities. Within GNAP today, we generally have things that bran= ch whether they=E2=80=99re an object (for a rich description of something) = or some non-structured special value (for a reference or other item).=C2=A0=

The design team created some simple JSON Schemas = for parts of the protocol during our discussion, but we didn=E2=80=99t incl= ude them in the design document due to both lack of time to keep it updated= with the rapid changes to the protocol during the design team discussion, = and not knowing if there would be interest in such material. I personally t= hink it would be helpful to include as an informative reference in the fina= l document, but that=E2=80=99s something for the working group to take up e= ventually.

=C2=A0=E2=80=94 Justin

On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6= m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:
Hello, everyone.

For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and w= hen I made note about certain concerns, I was requested to send my comments= to this working group.

In short, I believe th= at the use of polymorphic JSON in the protocol invites subtle and confusing= implementation problems. I also searched through the WG archives, and noti= ced that similar concerns were noted, briefly, in a thread in July.

The problem with polymorphic values, as I see it, is= that implementations will need to branch on the (inferred) type of a given= field. This isn't quite as bad if the types are strictly different, bu= t allows for subtle bugs when the value in question is a dictionary. What m= akes this unappealing is that "subtle bugs" in security protocols= have a habit of turning into vulnerabilities.

Let= 's say we have these imaginary payloads, both possible and valid in the= same protocol step:

# payload 1
{
=
=C2=A0 ...,
=C2=A0 "public_key": {
=C2= =A0=C2=A0=C2=A0 "alg": "rsa",
=C2=A0=C2= =A0=C2=A0 "modulus": <BIGINT>
=C2=A0 }
= }

# payload 2
{
=C2=A0 ...,
=C2=A0 "public_key": {
=C2=A0=C2=A0=C2=A0 "= ;alg": "rsa",
=C2=A0=C2=A0=C2=A0 "modulus&quo= t;: "<encoded string>"
=C2=A0 }
}
=

In both cases, the type of "public_key" field= is a dictionary. In both cases, they even have the same keys. However, the= values in the dictionaries are entirely different, and an implementation w= ill have to branch to at least two possible decoding mechanisms. To make th= ings worse, some JSON implementations may choose to encode non-dictionary v= alues as strings, so it is possible for an originator to transmit what they= expect and believe to be payload 1 format, but which the receiver will int= erpret to be in payload 2 format. And if the encoded string contains only d= igits, it will even parse correctly as a bignum.

While the above is clearly a manufactured scenario, it nonetheless demon= strates the potential for logic bugs with polymorphic JSON. With richer typ= es and more complex dictionaries, there will surely be more room for errors= .

Ambiguity in protocols is always a source of imp= lementation complexity and interoperability snags, but in an AuthN/AuthZ pr= otocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supe= rsede Oauth1/2, wouldn't it be in everyone's interest to keep imple= mentation complexity and mistake potential to a minimum?

=
Best regards,
Mika

--
Mika Bos= tr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""=E1=90=A7

--00000000000023335005b25bee10-- From nobody Fri Oct 23 13:35:47 2020 Return-Path: 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 117DA3A02BC for ; Fri, 23 Oct 2020 13:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5-O_cRzjb0_R for ; Fri, 23 Oct 2020 13:35:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A183B3A0147 for ; Fri, 23 Oct 2020 13:35:42 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09NKZccA010725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Oct 2020 16:35:39 -0400 From: Justin Richer Message-Id: <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_01259421-3EB2-4119-ADAF-C12915A1F7D9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 23 Oct 2020 16:35:38 -0400 In-Reply-To: Cc: =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List To: Dick Hardt References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 20:35:46 -0000 --Apple-Mail=_01259421-3EB2-4119-ADAF-C12915A1F7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >=20 > Justin >=20 > I did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable.=20 >=20 > As for concrete examples: > - version of client > - version of OS > - security attestation of OS / device > - location of client device > - network client is operating on >=20 > These are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used. >=20 This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman: { posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6= } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, client: =E2=80=9Cclient-541-ab" } This is a more fundamental question about GNAP than whether the syntax = uses polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. =E2=80=94 Justin > /Dick >=20 > =E1=90=A7 >=20 > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer > wrote: > Dick, >=20 > As you=E2=80=99ll recall, I argued against including the client = instance identifier inside of the object as a mutually-exclusive field = precisely because of the principle violation that you are pointing out = here, and so it=E2=80=99s important to point out that the current text = is a compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored. >=20 > The crux of my argument is that is exactly a case of pass-by-reference = vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol. >=20 > =E2=80=94 Justin >=20 >> On Oct 23, 2020, at 3:07 PM, Dick Hardt > wrote: >>=20 >> Hey Justin, >>=20 >> As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >>=20 >> In the current draft, the=20 >>=20 >> Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question.=20 >>=20 >> is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >>=20 >>=20 >> instance_id An identifier string that the AS can use to identify = the >> particular instance of this RC. The content and structure of = this >> identifier is opaque to the RC. >>=20 >> "client": { >> "instance_id": "client-541-ab" >> } >>=20 >> If there are no additional fields to send, the RC MAY send the >> instance identifier as a direct reference value in lieu of the >> object. >>=20 >> "client": "client-541-ab" >>=20 >> The instance identifier can be sent two ways. Polymorphism is a = convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >>=20 >> In your example of the "key" object below, setting "proof" to bearer = would avoid the issue you describe: >>=20 >> {=20 >> "key": {=20 >> "proof": "bearer"=20 >> }=20 >> } >>=20 >> In your example, when processing the "key" object, code is having to = check both the JSON type of the property, as well as check the value of = the "proof" property. In the example I provided, only the value of = "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >>=20 >> Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done = as above. >>=20 >> On a related note, there was significant negative feedback on handles = and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >>=20 >> /Dick >>=20 >>=20 >> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer > wrote: >> Hi Mika, >>=20 >> Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. >>=20 >> Some background: I built out the XYZ protocol (one of the = predecessors to the initial GNAP Draft) in Java using strongly typed = parsers and Java objects specifically to prove to myself that it could = be done in a way that made any sense in the code. (My own open source = implementation is at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >>=20 >> The driving reason for using polymorphism at the protocol level was = to simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >>=20 >> {=20 >> key: { >> proof: httpsig, >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> }, >> bearer_token: true, >> bind_to_rc_key: true >> } >>=20 >> This would be an illegal object as per this alternate proposal, but = then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. >>=20 >> {=20 >> key: { >> proof: httpsig, >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> } >> } >>=20 >> // bearer token >>=20 >> { >> key: false >> } >>=20 >> // bound to the RC=E2=80=99s presented key >>=20 >> { >> key: true >> } >>=20 >> If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. >>=20 >> While it might sound like polymorphism means that any field could = have any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. >>=20 >> In your example below, each field within the dictionary would also = need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 >>=20 >> So let=E2=80=99s dig into the specific bug you bring up in the = strawman, because it=E2=80=99s interesting: A JSON encoder that encodes = numbers as strings, and not numbers, is not compliant with the JSON = definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in = this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where = a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item).=20 >>=20 >> The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>>=20 >>> Hello, everyone. >>>=20 >>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my = comments to this working group. >>>=20 >>> In short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.=20 >>>=20 >>> The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >>>=20 >>> Let's say we have these imaginary payloads, both possible and valid = in the same protocol step: >>>=20 >>> # payload 1 >>> { >>> ..., >>> "public_key": { >>> "alg": "rsa", >>> "modulus": >>> } >>> } >>>=20 >>> # payload 2 >>> { >>> ..., >>> "public_key": { >>> "alg": "rsa", >>> "modulus": "" >>> } >>> } >>>=20 >>> In both cases, the type of "public_key" field is a dictionary. In = both cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >>>=20 >>> While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >>>=20 >>> Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum? >>>=20 >>> Best regards, >>> Mika >>>=20 >>> --=20 >>> Mika Bostr=C3=B6m >>> Smarkets >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =E1=90=A7 >=20 --Apple-Mail=_01259421-3EB2-4119-ADAF-C12915A1F7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin

I did note that I was the one that = argued for instance_id being in the object. Since it is in the object in = the current draft, not including a pass by reference option would be = preferable. 

As for concrete examples:
- version of = client
- version of OS
- = security attestation of OS / device
- location of = client device
- network client is operating = on

These are = all attributes of the client that an AS may require on the initial = grant request, and in future grant requests (which is when an = instance_id) would be used.


This is where our interpretations differ: I = don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in = the same way that the key, display information, class identifiers, and = other items currently represented by an instance_id are attributes of = the client instance. The attestation components don=E2=80=99t modify the = instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a = separate object, so you=E2=80=99d have something like this = strawman:

{

  posture: {
    = software_version: 1.2.3,
    os_version: = 14.3.2
    device_attestation: { =E2=80=A6 some = structure or signed blob? =E2=80=A6 }
    location: = { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
  = },

  client: = =E2=80=9Cclient-541-ab"

}

This is a = more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.

 =E2=80=94 Justin


/Dick

3D""=E1=90=A7

On Fri, Oct = 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Dick,

As you=E2=80=99ll recall, I argued against including the = client instance identifier inside of the object as a mutually-exclusive = field precisely because of the principle violation that you are pointing = out here, and so it=E2=80=99s important to point out that the current = text is a compromise that needs to be examined in the wider experience = of the working group. I am on the side of removing the = mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an = object, but this needs to be explored.

The crux of my argument is that is = exactly a case of pass-by-reference vs pass-by-value, and that runtime = attestations are not part of the =E2=80=9Cclient instance=E2=80=9D value = itself but rather belong outside of that object in a another part of the = request. As stated in the editorial notes in this section, we need to = look carefully at how these concepts fit within the model and where we = would want to put them. Without concrete examples of what these = extensions look like and how they=E2=80=99re generated, that is nearly = impossible to do at this stage. I look forward to seeing examples of = this kind of data and how it can fit into the protocol.

 =E2=80=94 = Justin

On Oct 23, 2020, at 3:07 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Hey = Justin,

As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string = for pass-by-reference, and an object for pass-by-value.

In the current draft, = the 

Every time you create or process a field it will mean only = one thing, and there=E2=80=99s only one field to look at to answer a = question. 

is violated in 2.3.1.  Identifying the RC = Instance

  =  instance_id  An identifier string that the AS can use to = identify the
      particular = instance of this RC.  The content and structure of this
      identifier is opaque to the = RC.

  =  "client": {
      =  "instance_id": "client-541-ab"
  =  }

  =  If there are no additional fields to send, the RC MAY send = the
   instance identifier as a direct = reference value in lieu of the
  =  object.

   "client": "client-541-ab"

The instance identifier = can be sent two ways. Polymorphism is a convenience for the client, but = requires the server to have two code paths for = "instance_id".  We discussed this in the design team, and I argued = for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.

In = your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe:

{ 
 "key": = { 
     "proof": "bearer"
    }
}

In your example, when = processing the "key" object, code is having to check both the JSON type = of the property, as well as check the value of the "proof" property. In = the example I provided, only the value of "proof" needs to be checked. = The "proof" property is acting as a type for the "key" object.

Not being a Java = programmer, I don't know how this would work in a Java implementation, = but node.js, the processing would need to be done as above.

On a related note, there = was significant negative feedback on handles and polymorphism in the = Hacker News article https://news.ycombinator.com/item?id=3D24855750 
=

/Dick


On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = <jricher@mit.edu> wrote:
Hi Mika,

Thanks for bringing this = topic here =E2=80=94 I was able to see the forum discussion that brought = you here, and hopefully I can help clear up what I mean with how = polymorphism is used in the proposal. The short version is that the goal = is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems.

Some background: I built out the XYZ = protocol (one of the predecessors to the initial GNAP Draft) in Java = using strongly typed parsers and Java objects specifically to prove to = myself that it could be done in a way that made any sense in the code. = (My own open source implementation is at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an = object:

{ 
    key: {
      proof: httpsig,
      jwk: { =E2=80=A6 key value =E2=80=A6 = }
    },
  =   bearer_token: true,
    = bind_to_rc_key: true
}

This would be an illegal object as per = this alternate proposal, but then you=E2=80=99d have to check each field = and make sure it wasn=E2=80=99t put next to others in the same object. = I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99s= both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the = polymorphic approach to this same field, each of these three = mutually-exclusive states is written in a way that they cannot be sent = together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and = enforced by the syntax of JSON itself.

{ 
    key: {
    =   proof: httpsig,
      jwk: { = =E2=80=A6 key value =E2=80=A6 }
    = }
}

// bearer token

{
    key: false
}

// bound to the RC=E2=80=99s presented key

{
    key: true
}

If someone sends a = different type for this field, like an array or number or a null, this = doesn=E2=80=99t have a defined interpretation in the protocol and would = be a protocol level error.

While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value = is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value.

In your = example below, each field within the dictionary would also need to be = typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take =  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run = into cases where a parser library was trying to be overly =E2=80=9Chelpful= =E2=80=9D in doing this kind of mapping, but ended up introducing errors = in more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item). 

The design team created some simple = JSON Schemas for parts of the protocol during our discussion, but we = didn=E2=80=99t include them in the design document due to both lack of = time to keep it updated with the rapid changes to the protocol during = the design team discussion, and not knowing if there would be interest = in such material. I personally think it would be helpful to include as = an informative reference in the final document, but that=E2=80=99s = something for the working group to take up eventually.

 =E2=80=94 = Justin

On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m= <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:

Hello, everyone.

For background: GNAP/TxAuth/XYZ/Oauth3 = came up on a discussion forum and when I made note about certain = concerns, I was requested to send my comments to this working group.

In = short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.

The problem with polymorphic values, as = I see it, is that implementations will need to branch on the (inferred) = type of a given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into = vulnerabilities.

Let's say we have these imaginary payloads, both possible and = valid in the same protocol step:

# payload 1
{
  ...,
  = "public_key": {
    "alg": "rsa",
    "modulus": = <BIGINT>
  }
}

# = payload 2
{
  = ...,
  "public_key": {
    "alg": "rsa",
    "modulus": "<encoded = string>"
  }
}

In both cases, the type = of "public_key" field is a dictionary. In both cases, they even have the = same keys. However, the values in the dictionaries are entirely = different, and an implementation will have to branch to at least two = possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

While the above is = clearly a manufactured scenario, it nonetheless demonstrates the = potential for logic bugs with polymorphic JSON. With richer types and = more complex dictionaries, there will surely be more room for = errors.

Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum?

Best regards,
Mika

--
Mika Bostr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
3D""=E1=90=A7


= --Apple-Mail=_01259421-3EB2-4119-ADAF-C12915A1F7D9-- From nobody Fri Oct 23 14:19:23 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8483A11D6; Fri, 23 Oct 2020 14:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: txauth@ietf.org, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348775288.5087.17087608299261751323@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:52 -0700 Archived-At: Subject: [GNAP] gnap - Requested session has been scheduled for IETF 109 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:57 -0000 Dear Yaron Sheffer, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gnap Session 1 (2:00 requested) Tuesday, 17 November 2020, Session I 1200-1400 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/gnap.ics Request Information: --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls rats sacm secdispatch secevent suit teep tls tokbind trans httpbis quic saag uta Technology Overlap: oauth People who must be present: Yaron Sheffer Roman Danyliw Leif Johansson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 23 18:27:12 2020 Return-Path: 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 3EA753A0B91 for ; Fri, 23 Oct 2020 18:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 kpbBvzdQXtVK for ; Fri, 23 Oct 2020 18:27:07 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 1E3AA3A0B8B for ; Fri, 23 Oct 2020 18:27:06 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z17so4162442iog.11 for ; Fri, 23 Oct 2020 18:27:06 -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=x23mXio73WDIWBNkxVL6qpy/hkC4T2NrEOsNvnMSTPk=; b=k7nUR2Ve2iXI3NQ5/5yIdvD4vPzgc4Y0mZtRugNH/NBv+JhOi2xV7Vbd9zBBfrWKiz T1zgauMp1+U5Sp/aEJYydXcsOoS1wGKKU3i2j7KTaFaemCzJV71USDzpYyxwuWwVxxVq yhYJC2eQNoWXnvaDN3XG+lViru2DevhaMdJjA5Ug4KSgOE/8y6ECJdI/A/pxTMw2wogt C6mhXwPK5mzmNp26r2XhfuQXA9gadZauvS7APuhL/kJC6k8BvZc/tIUtHTFXgawKguAY B+/DJAlp3lpZWdtM/p0oiIVlh+NAA4Acgue9OFDliIX/tiKAuA7fpTdcQco6PEbCe9xB wnTA== 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=x23mXio73WDIWBNkxVL6qpy/hkC4T2NrEOsNvnMSTPk=; b=IWU+MKdMZSg5uban4CBSTCwVTHIsarmyDvJrl1SVd583gjknwfrfbzuqrVNMiZMv/Z zrsWGp0uPw5/VSLYaYvZ6ZCao/LeqNZiINebg6peTZJlNsevGPXKWkazKYsz8QriN7BB qmWP9cEUa8lv2JcE0znKXVz6OKRnD4Yn/5BzmRPObJcJWuGQ7z9eoUX+Vg2sbVkDVMbz 3vEqXAqj+ujuzZ5xdU6IkcoSw0ZhppdzxnY+qd7yfJmYd8OpgBqXW9U7t6CUntTwOnhG iHrTzrEa9sOJbKSiYE6hqV7OgeLjWa5z9UJ5RXIXjJlrRJsiCejTCgNcq/M+KHP8OfQz ODsw== X-Gm-Message-State: AOAM533et8q5vEBhpfR5aKuMsxtXhtNzUeGVepRwRHUf04Jtb1ZAZi9p XMycF3AQ4814yQAQSQihb75pa9MsPo+XwB/gjF8= X-Google-Smtp-Source: ABdhPJy+SQt13XXeOCTB+3NL3SR8bKmyqJbb3pVEfR3QAvG6TW8z96dSu2SAk3PPU/bu56qMYNJwC0lizo0NnFSYBf4= X-Received: by 2002:a5d:87c7:: with SMTP id q7mr3831098ios.162.1603502825919; Fri, 23 Oct 2020 18:27:05 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> From: Fabien Imbault Date: Sat, 24 Oct 2020 03:26:54 +0200 Message-ID: To: Justin Richer Cc: Dick Hardt , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000055dbe405b260982e" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 01:27:11 -0000 --00000000000055dbe405b260982e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, Let me try to approach the issue under a different light. More like a product manager would deal with feature selection to make it intuitive for its users. For most people, riding a bike is far easier than using a unicycle. Feels more stable. And yet it's way easier to design for a single wheel than to build with 2. Because then you'll need a lot more accessories (chain, chain ring, etc.). Even so producing a bike doesn't have to be a brittle process, it can be industrialized. Back to the GNAP topic. Ultimately we should strive to make the spec as simple as can be. But we need to ask: simple for whom? For the bike owner or for the bike vendor? (short answer: the priority should be simplicity for spec users, not spec implementers and even less spec designers). The initial question that is asked is very interesting: isn't the design flawed if GNAP is using json polyphormism? Or if the AS needs to handle the state of the request? Or if we must handle token revocation? Or if we are looking for a global unique identifier? The argument stems of the fact that is still arguably harder and more error prone to implement. Fair enough. >From a spec implementer's perspective, it may well be more complex. It mostly impacts the json library you'll end up using, plus a bit of input/output decoration around it. Even golang provides utilities for this, despite not exactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I mean, I wished it could be simpler, but it's manageable and there are other ways to reach levels of insurance that it does work as intended (json schema, test cases to validate the implementation, etc.). Arguably it is still easier from an implementation perspective than say, json-ld, which is massively used in the SSI community. But ultimately who are we designing for? Are we striving to go easy on the spec implementer? Or are we trying to make sure end-developers using the client libraries won't shoot themselves in the foot? The job to be done (JTBD), from the end-developer's perspective, is to efficiently ship an application. And provide authN/authZ capabilities for end-users by relying on some well known implementation. In turn, this spec implementer will rely on cryptographic utility libraries that deals internally with the complexity of their own domain, so that we don't have to. And here we could launch another HN flame war that starts with the title "JWT sucks because". Which does have its set of very real issues but that's beyond the point. Note that any decent flamewar will be efficiently fueled by people hating medium. Is it outrageous for blog posts to be behind a paywall? Maybe but it's even more outrageous to lack consistency, either by not knowing how to get around a paywall if you're into a hacker punk movement, or on the contrary by to not paying a subscription if you believe that surveillance capitalism, to reuse Zuboff's terms, should be eradicated. What likely seems an unnecessary sidenote tries to illustrate the point: for Justin it was easier to publish on medium, because as a blog publisher, you might not want to deal with hosting your own blog. But maybe as a reader you'll find that annoying. Different audiences, different JTBD, different tradeoffs. Polyphormism is a tool that enables the end-developer to have minimal knowledge of what it means to deal with a GNAP client library. You prepare the request, send to the endpoint and you're good to go. Massively simpler than OAuth2 or any similar protocol by the way (as anyone with teaching experience on the subject might acknowledge). And there's a lot more to be done to make sure we indeed reduce the complexity for the end-developer and the end-user. If we find a better way to deal with that simplicity balance, I'm all in. But the arguments need to be way more convincing than just saying that it may be difficult to implement or validate. Cheers. Fabien Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9= crit : > > > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: > > Justin > > I did note that I was the one that argued for instance_id being in the > object. Since it is in the object in the current draft, not including a > pass by reference option would be preferable. > > As for concrete examples: > - version of client > - version of OS > - security attestation of OS / device > - location of client device > - network client is operating on > > These are all attributes of the client that an AS may require on the > initial grant request, and in future grant requests (which is when an > instance_id) would be used. > > > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes > of the client=E2=80=9D in the same way that the key, display information,= class > identifiers, and other items currently represented by an instance_id are > attributes of the client instance. The attestation components don=E2=80= =99t modify > the instance so much as present additional information on top of the clie= nt > instance itself. This is why I argue that they ought to be handled in a > separate object, so you=E2=80=99d have something like this strawman: > > { > > posture: { > software_version: 1.2.3, > os_version: 14.3.2 > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > }, > > client: =E2=80=9Cclient-541-ab" > > } > > This is a more fundamental question about GNAP than whether the syntax > uses polymorphism: this is about GNAP being very explicit about the data > model of its elements. OAuth 2=E2=80=99s incredibly loose and broad model= of what > the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pro= blematic in > practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to > define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture > the different aspects that are out there. I think we=E2=80=99re getting c= loser here > in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, bu= t we still need to > be more precise about what exactly a client instance includes, and what i= t > does not. > > =E2=80=94 Justin > > > /Dick > > =E1=90=A7 > > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > >> Dick, >> >> As you=E2=80=99ll recall, I argued against including the client instance >> identifier inside of the object as a mutually-exclusive field precisely >> because of the principle violation that you are pointing out here, and s= o >> it=E2=80=99s important to point out that the current text is a compromis= e that >> needs to be examined in the wider experience of the working group. I am = on >> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >> object, but this needs to be explored. >> >> The crux of my argument is that is exactly a case of pass-by-reference v= s >> pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient >> instance=E2=80=9D value itself but rather belong outside of that object = in a >> another part of the request. As stated in the editorial notes in this >> section, we need to look carefully at how these concepts fit within the >> model and where we would want to put them. Without concrete examples of >> what these extensions look like and how they=E2=80=99re generated, that = is nearly >> impossible to do at this stage. I look forward to seeing examples of thi= s >> kind of data and how it can fit into the protocol. >> >> =E2=80=94 Justin >> >> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >> >> Hey Justin, >> >> As the draft has evolved, I question the continued use of polymorphism. >> Note that I appreciate the elegance of using a string for >> pass-by-reference, and an object for pass-by-value. >> >> In the current draft, the >> >> Every time you create or process a field it will mean only one thing, an= d >> there=E2=80=99s only one field to look at to answer a question. >> >> >> is violated in 2.3.1. Identifying the RC Instance >> >> >> >> instance_id An identifier string that the AS can use to identify the >> particular instance of this RC. The content and structure of this >> identifier is opaque to the RC. >> >> "client": { >> "instance_id": "client-541-ab" >> } >> >> If there are no additional fields to send, the RC MAY send the >> instance identifier as a direct reference value in lieu of the >> object. >> >> "client": "client-541-ab" >> >> >> The instance identifier can be sent two ways. Polymorphism is a >> convenience for the client, but requires the server to have two code pat= hs >> for "instance_id". We discussed this in the design team, and I argued f= or >> having "instance_id" in the "client" object so that any updates, such as >> new devices assertions, could be in the "client" object. As noted above, >> while I appreciate the elegance of using a string (handle) to reference = a >> previously provided object, it complicates how to update an existing obj= ect >> while providing the reference. >> >> In your example of the "key" object below, setting "proof" to bearer >> would avoid the issue you describe: >> >> { >> "key": { >> "proof": "bearer" >> } >> } >> >> In your example, when processing the "key" object, code is having to >> check both the JSON type of the property, as well as check the value of = the >> "proof" property. In the example I provided, only the value of "proof" >> needs to be checked. The "proof" property is acting as a type for the "k= ey" >> object. >> >> Not being a Java programmer, I don't know how this would work in a Java >> implementation, but node.js, the processing would need to be done as abo= ve. >> >> On a related note, there was significant negative feedback on handles an= d >> polymorphism in the Hacker News article >> https://news.ycombinator.com/item?id=3D24855750 >> >> /Dick >> >> >> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >> >>> Hi Mika, >>> >>> Thanks for bringing this topic here =E2=80=94 I was able to see the for= um >>> discussion that brought you here, and hopefully I can help clear up wha= t I >>> mean with how polymorphism is used in the proposal. The short version i= s >>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>> protocols, and so in that goal we=E2=80=99re fully aligned. I think tha= t using >>> polymorphism in very specific ways can help that goal =E2=80=94 just as= I agree >>> that misusing it or applying it sloppily can lead to ambiguous and inse= cure >>> systems. >>> >>> Some background: I built out the XYZ protocol (one of the predecessors >>> to the initial GNAP Draft) in Java using strongly typed parsers and Jav= a >>> objects specifically to prove to myself that it could be done in a way = that >>> made any sense in the code. (My own open source implementation is at >>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not = yet up >>> to date with the GNAP spec). It was important to me that I be able to u= se >>> the system-wide configured parsers to implement this and not have to re= sort >>> to stepping through elements completely by hand. Java doesn=E2=80=99t m= ake it >>> simple to get the hooks into the right places (especially with the Jack= son >>> parser that I used), but it is definitely possible to create a >>> deterministic and strongly-typed parser and serializer for this kind of >>> data structure. Some of the rationale for using polymorphism is covered= in >>> the trailing appendix of the draft document ( >>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#n= ame-json-structures-and-polymor), >>> but it=E2=80=99s still good to discuss this here as the working group d= ecides which >>> approaches to take. >>> >>> The driving reason for using polymorphism at the protocol level was to >>> simplify the protocol and make it :more: deterministic to create and >>> process, not less. Every time you create or process a field it will mea= n >>> only one thing, and there=E2=80=99s only one field to look at to answer= a question. >>> Without polymorphic field values, you usually need to rely on mutual >>> exclusivity of fields, which is prone to failure and requires additiona= l >>> error checking. Take for example the key binding of access tokens. An >>> access token could be bound to the RC=E2=80=99s key used during the req= uest, to a >>> different key chosen by the AS, or it could be a bearer token with no k= ey >>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can d= efine it in terms of >>> boolean values and objects and express this set of mutually-exclusive >>> options in a non-ambiguous way. Without that, you=E2=80=99d need to hav= e different >>> fields for the options and include additional checks in your parser to = make >>> sure they weren=E2=80=99t sent simultaneously, otherwise you could get = hit with >>> this potential security vulnerability in an object: >>> >>> { >>> key: { >>> proof: httpsig, >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> }, >>> bearer_token: true, >>> bind_to_rc_key: true >>> } >>> >>> This would be an illegal object as per this alternate proposal, but the= n >>> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others >>> in the same object. I=E2=80=99ve done this exercise with many other pro= tocols and >>> it=E2=80=99s both error prone and easy to ignore since all the =E2=80= =9Cgood=E2=80=9D examples >>> would pass code that doesn=E2=80=99t check this. With the polymorphic a= pproach to >>> this same field, each of these three mutually-exclusive states is writt= en >>> in a way that they cannot be sent together. It=E2=80=99s not just illeg= al, it=E2=80=99s >>> impossible and enforced by the syntax of JSON itself. >>> >>> { >>> key: { >>> proof: httpsig, >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> } >>> } >>> >>> // bearer token >>> >>> { >>> key: false >>> } >>> >>> // bound to the RC=E2=80=99s presented key >>> >>> { >>> key: true >>> } >>> >>> If someone sends a different type for this field, like an array or >>> number or a null, this doesn=E2=80=99t have a defined interpretation in= the >>> protocol and would be a protocol level error. >>> >>> While it might sound like polymorphism means that any field could have >>> any type or value, the opposite is true: each possible value is explici= tly >>> typed, it=E2=80=99s just that there are potentially different types tha= t express >>> meaning for the field. This applies to all members of all objects >>> (dictionaries) as well as all members of an array (list). Every time yo= u >>> process a field value or other element, you look at the type and then t= he >>> value to determine what to do with that typed value. >>> >>> In your example below, each field within the dictionary would also need >>> to be typed, and each type would need to have a clear indication of its >>> meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could >>> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON= number) or an >>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would = further say what >>> exactly the encoding of the string would be. That means that when you r= ead >>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confu= sion on what the value was >>> or how it was represented, regardless of the input format. Seeing a num= ber >>> there means exactly one interpretation and seeing a string means exactl= y >>> one (different) interpretation =E2=80=94 but importantly, both of them = are a >>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determin= es the type. An >>> implementation would likely use an internal BigInteger type of object t= o >>> represent the field value after parsing, so the question is how to go f= rom >>> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you app= ly it to all >>> sub-fields of that object. >>> >>> So let=E2=80=99s dig into the specific bug you bring up in the strawman= , because >>> it=E2=80=99s interesting: A JSON encoder that encodes numbers as string= s, and not >>> numbers, is not compliant with the JSON definitions of the field in >>> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >>> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated >>> the same by a parser implementation when mapping to a concrete object. = It=E2=80=99s >>> in this kind of automated guessing that this class of bugs occur, and >>> that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s >>> polymorphic nature. I=E2=80=99ve run into cases where a parser library = was trying >>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, b= ut ended up >>> introducing errors in more strict components downstream. This is someth= ing >>> that protocol designers need to be aware of and guard against in the de= sign >>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>> generally have things that branch whether they=E2=80=99re an object (fo= r a rich >>> description of something) or some non-structured special value (for a >>> reference or other item). >>> >>> The design team created some simple JSON Schemas for parts of the >>> protocol during our discussion, but we didn=E2=80=99t include them in t= he design >>> document due to both lack of time to keep it updated with the rapid cha= nges >>> to the protocol during the design team discussion, and not knowing if t= here >>> would be interest in such material. I personally think it would be help= ful >>> to include as an informative reference in the final document, but that= =E2=80=99s >>> something for the working group to take up eventually. >>> >>> =E2=80=94 Justin >>> >>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>> >>> Hello, everyone. >>> >>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum an= d >>> when I made note about certain concerns, I was requested to send my >>> comments to this working group. >>> >>> In short, I believe that the use of polymorphic JSON in the protocol >>> invites subtle and confusing implementation problems. I also searched >>> through the WG archives, and noticed that similar concerns were noted, >>> briefly, in a thread in July. >>> >>> The problem with polymorphic values, as I see it, is that >>> implementations will need to branch on the (inferred) type of a given >>> field. This isn't quite as bad if the types are strictly different, but >>> allows for subtle bugs when the value in question is a dictionary. What >>> makes this unappealing is that "subtle bugs" in security protocols have= a >>> habit of turning into vulnerabilities. >>> >>> Let's say we have these imaginary payloads, both possible and valid in >>> the same protocol step: >>> >>> # payload 1 >>> { >>> ..., >>> "public_key": { >>> "alg": "rsa", >>> "modulus": >>> } >>> } >>> >>> # payload 2 >>> { >>> ..., >>> "public_key": { >>> "alg": "rsa", >>> "modulus": "" >>> } >>> } >>> >>> In both cases, the type of "public_key" field is a dictionary. In both >>> cases, they even have the same keys. However, the values in the >>> dictionaries are entirely different, and an implementation will have to >>> branch to at least two possible decoding mechanisms. To make things wor= se, >>> some JSON implementations may choose to encode non-dictionary values as >>> strings, so it is possible for an originator to transmit what they expe= ct >>> and believe to be payload 1 format, but which the receiver will interpr= et >>> to be in payload 2 format. And if the encoded string contains only digi= ts, >>> it will even parse correctly as a bignum. >>> >>> While the above is clearly a manufactured scenario, it nonetheless >>> demonstrates the potential for logic bugs with polymorphic JSON. With >>> richer types and more complex dictionaries, there will surely be more r= oom >>> for errors. >>> >>> Ambiguity in protocols is always a source of implementation complexity >>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, woul= dn't >>> it be in everyone's interest to keep implementation complexity and mist= ake >>> potential to a minimum? >>> >>> Best regards, >>> Mika >>> >>> -- >>> Mika Bostr=C3=B6m >>> Smarkets >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> =E1=90=A7 >> >> >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000055dbe405b260982e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0
=
Let me try to approach the issue under a different light. More li= ke a product manager would deal with feature selection to make it intuitive= for its users.=C2=A0

For most people, riding a bike is far easier than using a unicycl= e. Feels more stable. And yet it's way easier to design for a single wh= eel than to build with 2. Because then you'll need a lot more accessori= es (chain, chain ring, etc.). Even so producing a bike doesn't have to = be a brittle process, it can be industrialized.=C2=A0

Back to the GNAP topic.=C2=A0
Ultimately we should strive to= make the spec as simple as can be. But we need to ask: simple for whom? Fo= r the bike owner or for the bike vendor?=C2=A0
(short answer: the priority sh= ould be simplicity for spec users, not spec implementers and even less spec= designers).=C2=A0

The initial question that i= s asked is very interesting: isn't the design flawed if GNAP is using j= son polyphormism? Or if the AS needs to handle the state of the request? Or= if we must handle token revocation? Or if we are looking for a global uniq= ue identifier? The argument stems of the fact that is still arguably harder= and more error prone to implement. Fair enough.=C2=A0

From a spec implementer's perspective, i= t may well be more complex. It mostly impacts the json library you'll e= nd up using, plus a bit of input/output decoration around it. Even golang p= rovides utilities for this, despite not exactly being made for this kind of= purpose.
My practical experience implementing it is= that it's not that big a deal. I mean, I wished it could be simpler, b= ut it's manageable and there are other ways to reach levels of insuranc= e that it does work as intended (json schema, test cases to validate the im= plementation, etc.). Arguably it is still easier from an implementation per= spective than say, json-ld, which is massively used in the SSI community.= =C2=A0

But ultimately wh= o are we designing for? Are we striving to go easy on the spec implementer?= Or are we trying to make sure end-developers using the client libraries wo= n't shoot themselves in the foot?

The job to be done (JTBD), from the end-developer's persp= ective, is to efficiently ship an application. And provide authN/authZ capa= bilities for end-users by relying on some well known implementation.=C2=A0<= /div>
In turn, this spec implementer will rely on cryptogr= aphic utility libraries that deals internally with the complexity of their = own domain, so that we don't have to. And here we could launch another = HN flame war that starts with the title "JWT sucks because". Whic= h does have its set of very real issues but that's beyond the point.=C2= =A0
Note that any decent flamewar will be efficientl= y fueled by people hating medium. Is it outrageous for blog posts to be beh= ind a paywall? Maybe but it's even more outrageous to lack consistency,= either by not knowing how to get around a paywall if you're into a hac= ker punk movement, or on the contrary by to not paying a subscription if yo= u believe that surveillance capitalism, to reuse Zuboff's terms, should= be eradicated.=C2=A0
What likely seems an unnecessa= ry sidenote tries to illustrate the point: for Justin it was easier to publ= ish on medium, because as a blog publisher, you might not want to deal with= hosting your own blog. But maybe as a reader you'll find that annoying= . Different audiences, different JTBD, different tradeoffs.=C2=A0

Polyphormism is a tool that enabl= es the end-developer to have minimal knowledge of what it means to deal wit= h a GNAP client library. You prepare the request, send to the endpoint and = you're good to go. Massively simpler than OAuth2 or any similar protoco= l by the way (as anyone with teaching experience on the subject might ackno= wledge). And=C2=A0 there's a lot more to be done to make sure we indeed= reduce the complexity for the end-developer and the end-user.=C2=A0
<= div dir=3D"auto">
If we find a better way to dea= l with that simplicity balance, I'm all in. But the arguments need to b= e way more convincing than just saying that it may be difficult to implemen= t or validate.=C2=A0

Che= ers.
Fabien





Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:


On Oct 2= 3, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

J= ustin

I did note that I was the one that argued for inst= ance_id being in the object. Since it is in the object in the current draft= , not including a pass by reference option would be preferable.=C2=A0
=

As for concrete examples:
- version of client=
- version of OS
- security attestation of OS / device<= /div>
- location of client device
- network client is operati= ng on

These are all attributes of the client that = an AS may require=C2=A0on the initial grant request, and in future grant re= quests (which is when an instance_id) would be used.


This is where our interpretation= s differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2= =80=9D in the same way that the key, display information, class identifiers= , and other items currently represented by an instance_id are attributes of= the client instance. The attestation components don=E2=80=99t modify the i= nstance so much as present additional information on top of the client inst= ance itself. This is why I argue that they ought to be handled in a separat= e object, so you=E2=80=99d have something like this strawman:
{

=C2=A0 posture: {
=C2=A0 = =C2=A0 software_version: 1.2.3,
=C2=A0 =C2=A0 os_version: 14.3.2<= /div>
=C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some structure or s= igned blob? =E2=80=A6 }
=C2=A0 =C2=A0 location: { lat: =E2=80=A6,= lon: =E2=80=A6, alt: =E2=80=A6 }
=C2=A0 },

<= div>=C2=A0 client: =E2=80=9Cclient-541-ab"

}<= /div>

This is a more fundamental question about GNAP tha= n whether the syntax uses polymorphism: this is about GNAP being very expli= cit about the data model of its elements. OAuth 2=E2=80=99s incredibly loos= e and broad model of what the term =E2=80=9Cclient=E2=80=9D is referring to= , exactly, is deeply problematic in practice. We=E2=80=99re even seeing tha= t in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed clien= t=E2=80=9D, and even then that doesn=E2=80=99t fully capture the different = aspects that are out there. I think we=E2=80=99re getting closer here in GN= AP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we st= ill need to be more precise about what exactly a client instance includes, = and what it does not.

=C2=A0=E2=80=94 Justin
=


/Di= ck

3D""=E1=90=A7

On Fri, Oct 23, 2020= at 12:42 PM Justin Richer <jri= cher@mit.edu> wrote:
Dick,

As you=E2=80=99ll recall, I argue= d against including the client instance identifier inside of the object as = a mutually-exclusive field precisely because of the principle violation tha= t you are pointing out here, and so it=E2=80=99s important to point out tha= t the current text is a compromise that needs to be examined in the wider e= xperience of the working group. I am on the side of removing the mutually-e= xclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but this ne= eds to be explored.

The crux of my argument is tha= t is exactly a case of pass-by-reference vs pass-by-value, and that runtime= attestations are not part of the =E2=80=9Cclient instance=E2=80=9D value i= tself but rather belong outside of that object in a another part of the req= uest. As stated in the editorial notes in this section, we need to look car= efully at how these concepts fit within the model and where we would want t= o put them. Without concrete examples of what these extensions look like an= d how they=E2=80=99re generated, that is nearly impossible to do at this st= age. I look forward to seeing examples of this kind of data and how it can = fit into the protocol.

=C2=A0=E2=80=94 Justin

On Oct 23, 2020, at 3:07 PM, = Dick Hardt <dick.hardt@gma= il.com> wrote:

Hey J= ustin,

As the draft has evolved, I question the cont= inued use of polymorphism. Note that I appreciate the elegance=C2=A0of usin= g a string for pass-by-reference, and an object for pass-by-value.

In the current draft, the=C2=A0

Every = time you create or process a field it will mean only one thing, and there= =E2=80=99s only one field to look at to answer a question.=C2=A0



=C2=A0 = =C2=A0instance_id =C2=A0An identifier string that the AS can use to identif= y the
=C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2=A0 = The content and structure of this
=C2=A0 =C2=A0 =C2=A0 identifier= is opaque to the RC.

=C2=A0 =C2=A0"client&qu= ot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "= client-541-ab"
=C2=A0 =C2=A0}

=C2= =A0 =C2=A0If there are no additional fields to send, the RC MAY send the
=C2=A0 =C2=A0instance identifier as a direct reference value in lie= u of the
=C2=A0 =C2=A0object.

=C2=A0 =C2= =A0"client": "client-541-ab"
The instance identifier can be sent two ways. Polymorphism is a= convenience for the client, but requires the server=C2=A0to have two code= =C2=A0paths for "instance_id".=C2=A0 We discussed this in the des= ign team, and I argued for having "instance_id" in the "clie= nt" object=C2=A0so that any updates, such as new devices assertions, c= ould be in the "client" object. As noted above, while I appreciat= e the elegance of using a string (handle) to reference a previously provide= d object, it complicates how to update an existing object while providing t= he reference.

In your example of the "key&quo= t; object below, setting "proof" to bearer would avoid the issue = you describe:

{=C2=A0
=C2=A0"key": {= =C2=A0
=C2=A0 =C2=A0 =C2=A0"proof": "bearer"
=C2= =A0 =C2=A0 }
}

In your example, when proce= ssing the "key" object, code is having to check both the JSON typ= e of the property, as well as check the value of the "proof" prop= erty. In the example I provided, only the value of "proof" needs = to be checked. The "proof" property is acting as a type for the &= quot;key" object.

Not being a Java programmer= , I don't know how this would work in a Java implementation, but node.j= s, the processing would need to be done as above.

= On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D2= 4855750=C2=A0

/Dick

<= br>
On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:
Hi Mika,

Thank= s for bringing this topic here =E2=80=94 I was able to see the forum discus= sion that brought you here, and hopefully I can help clear up what I mean w= ith how polymorphism is used in the proposal. The short version is that the= goal is to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecur= e protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using polymorphism in very specific ways can help that goal =E2=80=94 just = as I agree that misusing it or applying it sloppily can lead to ambiguous a= nd insecure systems.

Some background: I built out = the XYZ protocol (one of the predecessors to the initial GNAP Draft) in Jav= a using strongly typed parsers and Java objects specifically to prove to my= self that it could be done in a way that made any sense in the code. (My ow= n open source implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but note = that it=E2=80=99s not yet up to date with the GNAP spec). It was important = to me that I be able to use the system-wide configured parsers to implement= this and not have to resort to stepping through elements completely by han= d. Java doesn=E2=80=99t make it simple to get the hooks into the right plac= es (especially with the Jackson parser that I used), but it is definitely p= ossible to create a deterministic and strongly-typed parser and serializer = for this kind of data structure. Some of the rationale for using polymorphi= sm is covered in the trailing appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf= -gnap-core-protocol-00.html#name-json-structures-and-polymor), but it= =E2=80=99s still good to discuss this here as the working group decides whi= ch approaches to take.=C2=A0

The driving reason fo= r using polymorphism at the protocol level was to simplify the protocol and= make it :more: deterministic to create and process, not less. Every time y= ou create or process a field it will mean only one thing, and there=E2=80= =99s only one field to look at to answer a question. Without polymorphic fi= eld values, you usually need to rely on mutual exclusivity of fields, which= is prone to failure and requires additional error checking. Take for examp= le the key binding of access tokens. An access token could be bound to the = RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80= =9Ckey=E2=80=9D field polymorphic, we can define it in terms of boolean val= ues and objects and express this set of mutually-exclusive options in a non= -ambiguous way. Without that, you=E2=80=99d need to have different fields f= or the options and include additional checks in your parser to make sure th= ey weren=E2=80=99t sent simultaneously, otherwise you could get hit with th= is potential security vulnerability in an object:

= {=C2=A0
=C2=A0 =C2=A0 key: {
=C2=A0 =C2=A0 =C2=A0 proof= : httpsig,
=C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80= =A6 }
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 bearer_token: true= ,
=C2=A0 =C2=A0 bind_to_rc_key: true
}

This would be an illegal object as per this alternate proposal, bu= t then you=E2=80=99d have to check each field and make sure it wasn=E2=80= =99t put next to others in the same object. I=E2=80=99ve done this exercise= with many other protocols and it=E2=80=99s both error prone and easy to ig= nore since all the =E2=80=9Cgood=E2=80=9D examples would pass code that doe= sn=E2=80=99t check this. With the polymorphic approach to this same field, = each of these three mutually-exclusive states is written in a way that they= cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impos= sible and enforced by the syntax of JSON itself.

<= div>{=C2=A0
=C2=A0 =C2=A0 key: {
=C2=A0 =C2=A0 =C2=A0 p= roof: httpsig,
=C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value = =E2=80=A6 }
=C2=A0 =C2=A0 }
}

= // bearer token

{
=C2=A0 =C2=A0 key: fal= se
}

// bound to the RC=E2=80=99s = presented key

{
=C2=A0 =C2=A0 key: true<= /div>
}

If someone sends a different type for = this field, like an array or number or a null, this doesn=E2=80=99t have a = defined interpretation in the protocol and would be a protocol level error.=

While it might sound like polymorphism means that= any field could have any type or value, the opposite is true: each possibl= e value is explicitly typed, it=E2=80=99s just that there are potentially d= ifferent types that express meaning for the field. This applies to all memb= ers of all objects (dictionaries) as well as all members of an array (list)= . Every time you process a field value or other element, you look at the ty= pe and then the value to determine what to do with that typed value.
<= div>
In your example below, each field within the dictionary = would also need to be typed, and each type would need to have a clear indic= ation of its meaning. To take your strawman key format below, the =E2=80=9C= modulus=E2=80=9D field could be defined polymorphically as either a =E2=80= =9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (= a JSON string). The definition would further say what exactly the encoding = of the string would be. That means that when you read the =E2=80=9Cmodulus= =E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value w= as or how it was represented, regardless of the input format. Seeing a numb= er there means exactly one interpretation and seeing a string means exactly= one (different) interpretation =E2=80=94 but importantly, both of them are= a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An implementation would likely use an internal BigInteger type = of object to represent the field value after parsing, so the question is ho= w to go from the JSON value (which is typed) into the BigInteger value.You = don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D= field, you apply it to all sub-fields of that object.=C2=A0

=
So let=E2=80=99s dig into the specific bug you bring up in the s= trawman, because it=E2=80=99s interesting: A JSON encoder that encodes numb= ers as strings, and not numbers, is not compliant with the JSON definitions= of the field in question. For another example, the quoted string value of = =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON,= and they shouldn=E2=80=99t be treated the same by a parser implementation = when mapping to a concrete object. It=E2=80=99s in this kind of automated g= uessing that this class of bugs occur, and that=E2=80=99s going to be the c= ase whether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic n= ature. I=E2=80=99ve run into cases where a parser library was trying to be = overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended u= p introducing errors in more strict components downstream. This is somethin= g that protocol designers need to be aware of and guard against in the desi= gn of the protocol to reduce possible ambiguities. Within GNAP today, we ge= nerally have things that branch whether they=E2=80=99re an object (for a ri= ch description of something) or some non-structured special value (for a re= ference or other item).=C2=A0

The design team crea= ted some simple JSON Schemas for parts of the protocol during our discussio= n, but we didn=E2=80=99t include them in the design document due to both la= ck of time to keep it updated with the rapid changes to the protocol during= the design team discussion, and not knowing if there would be interest in = such material. I personally think it would be helpful to include as an info= rmative reference in the final document, but that=E2=80=99s something for t= he working group to take up eventually.

=C2=A0=E2= =80=94 Justin

On Oct 23, 2020,= at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org= > wrote:

Hello, everyone.
<= div>
For background: GNAP/TxAuth/XYZ/Oauth3 came up on a disc= ussion forum and when I made note about certain concerns, I was requested t= o send my comments to this working group.

In s= hort, I believe that the use of polymorphic JSON in the protocol invites su= btle and confusing implementation problems. I also searched through the WG = archives, and noticed that similar concerns were noted, briefly, in a threa= d in July.

The problem with polymorphic value= s, as I see it, is that implementations will need to branch on the (inferre= d) type of a given field. This isn't quite as bad if the types are stri= ctly different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into vulnerabilities.
=
Let's say we have these imaginary payloads, both possibl= e and valid in the same protocol step:

# payload 1=
{
=C2=A0 ...,
=C2=A0 "public_key":= {
=C2=A0=C2=A0=C2=A0 "alg": "rsa",
=
=C2=A0=C2=A0=C2=A0 "modulus": <BIGINT>
=C2= =A0 }
}

# payload 2
{
=C2=A0 ...,
=C2=A0 "public_key": {
=C2=A0= =C2=A0=C2=A0 "alg": "rsa",
=C2=A0=C2=A0=C2=A0= "modulus": "<encoded string>"
=C2=A0 }=
}

In both cases, the type of "publ= ic_key" field is a dictionary. In both cases, they even have the same = keys. However, the values in the dictionaries are entirely different, and a= n implementation will have to branch to at least two possible decoding mech= anisms. To make things worse, some JSON implementations may choose to encod= e non-dictionary values as strings, so it is possible for an originator to = transmit what they expect and believe to be payload 1 format, but which the= receiver will interpret to be in payload 2 format. And if the encoded stri= ng contains only digits, it will even parse correctly as a bignum.

While the above is clearly a manufactured scenario, it= nonetheless demonstrates the potential for logic bugs with polymorphic JSO= N. With richer types and more complex dictionaries, there will surely be mo= re room for errors.

Ambiguity in protocols is alwa= ys a source of implementation complexity and interoperability snags, but in= an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 i= s intended to supersede Oauth1/2, wouldn't it be in everyone's inte= rest to keep implementation complexity and mistake potential to a minimum?<= br>

Best regards,
Mika
--
Mika Bostr=C3=B6m
Smarkets
--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7


--
TXAuth mailing list
TXAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/txauth
--00000000000055dbe405b260982e-- From nobody Sat Oct 24 14:50:14 2020 Return-Path: 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 A13BE3A0957 for ; Sat, 24 Oct 2020 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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=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 2iUiVLCmovo5 for ; Sat, 24 Oct 2020 14:50:07 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 239193A07C4 for ; Sat, 24 Oct 2020 14:50:07 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id i2so5568996ljg.4 for ; Sat, 24 Oct 2020 14:50:07 -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=jTj8b8MNSxfQL1R9raaH0rKGbcZi0JKcHZIhRQ14wR0=; b=avB78yVl/8LD+RXkG8P1hXzHMuwG2Z+1EWSC6ePcmbkI8uvaHoTcRBRvcfSc2XqG8A FlmPXI8N9lufLRLswP/gUZEKIrMCfvvmcNoMX70CI0Fvay+A7K7eoRBm3lseOxboCdpL AMFXmfMMiuEtoe/x1avK50iBZY6vtAPWxqkR8XKc0G6tdItv7h8MdAGeB++nTVxCxdZ1 17ekI53XlBdadGX7lFrPuM/halb/ou7h8JAjBamV3cEC1PwvM6hKvpDQquswrzgCgZv2 puBT+djCgYPdpYvnxXpVeQ6Ytbx2otZrF81mbSV+jOx2Q12oRI2xJsrfq8hMarXO/AwP IEdg== 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=jTj8b8MNSxfQL1R9raaH0rKGbcZi0JKcHZIhRQ14wR0=; b=GH7x6O56nPUc+4TYIGrUkOIDpO0y50sDUHvyq4/quyZPOs+kyKHbjPZJ8/KGKvI3NA /7uVjbKlHkMpte+MQ/tI3JK9M7SrMSeUnZdd38iizYt4aMRQQCFJzRZ8Up+mX25mOJp4 hErYPwAbpUbhdtEKqbh1CgYrXNMSHGlB2amx9FRzQQvavODxq/+BYmpniFnPvcWCuy+E P9XBZA2WbC+Edo0+0nfMtW2PKlDJjH1rUR+cbikt5kwj3D/I46v+4KUs2IwgI8rSFg4U mLfjCHuQaglUhb+gV9suaVxJDxeNJz36UsPgFm2VllBsA6HrAnrpNVvAV/frgX9kmrrM VT4Q== X-Gm-Message-State: AOAM533ljhqHpdX/W1jxMe6xHsrHy9y89lpltwP6fHtWnRLfuk1oHHfO y0iA2H473O/0kNxAfkf1JBAFHOT9Mnws2fywO9UP06yRDYo= X-Google-Smtp-Source: ABdhPJw+abi7znaR8Oko2GPulhVmuo/mNR/bcfx3E0vsUY67KkVkDkM2HpkqMco1V+50cqDBD33EDaU9ygMysINpKmE= X-Received: by 2002:a2e:b557:: with SMTP id a23mr3310271ljn.5.1603576205132; Sat, 24 Oct 2020 14:50:05 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Dick Hardt Date: Sat, 24 Oct 2020 14:49:28 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000013c65305b271ae22" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 21:50:13 -0000 --00000000000013c65305b271ae22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm confused by your logic Fabien. If a client library developer wants to expose polymorphism, they can do that independent of what is in the protocol. I differ on who our stakeholders are. I think our stakeholders are in least to most important: - AS developer - RS developer - client developer - user A client library developer can expose whatever interface they want to simplify implementation. I list the user so that we don't lose site of a critical role. /Dick =E1=90=A7 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault wrote: > Hi there, > > Let me try to approach the issue under a different light. More like a > product manager would deal with feature selection to make it intuitive fo= r > its users. > > For most people, riding a bike is far easier than using a unicycle. Feels > more stable. And yet it's way easier to design for a single wheel than to > build with 2. Because then you'll need a lot more accessories (chain, cha= in > ring, etc.). Even so producing a bike doesn't have to be a brittle proces= s, > it can be industrialized. > > Back to the GNAP topic. > Ultimately we should strive to make the spec as simple as can be. But we > need to ask: simple for whom? For the bike owner or for the bike vendor? > (short answer: the priority should be simplicity for spec users, not spec > implementers and even less spec designers). > > The initial question that is asked is very interesting: isn't the design > flawed if GNAP is using json polyphormism? Or if the AS needs to handle t= he > state of the request? Or if we must handle token revocation? Or if we are > looking for a global unique identifier? The argument stems of the fact th= at > is still arguably harder and more error prone to implement. Fair enough. > > From a spec implementer's perspective, it may well be more complex. It > mostly impacts the json library you'll end up using, plus a bit of > input/output decoration around it. Even golang provides utilities for thi= s, > despite not exactly being made for this kind of purpose. > My practical experience implementing it is that it's not that big a deal. > I mean, I wished it could be simpler, but it's manageable and there are > other ways to reach levels of insurance that it does work as intended (js= on > schema, test cases to validate the implementation, etc.). Arguably it is > still easier from an implementation perspective than say, json-ld, which = is > massively used in the SSI community. > > But ultimately who are we designing for? Are we striving to go easy on th= e > spec implementer? Or are we trying to make sure end-developers using the > client libraries won't shoot themselves in the foot? > > The job to be done (JTBD), from the end-developer's perspective, is to > efficiently ship an application. And provide authN/authZ capabilities for > end-users by relying on some well known implementation. > In turn, this spec implementer will rely on cryptographic utility > libraries that deals internally with the complexity of their own domain, = so > that we don't have to. And here we could launch another HN flame war that > starts with the title "JWT sucks because". Which does have its set of ver= y > real issues but that's beyond the point. > Note that any decent flamewar will be efficiently fueled by people hating > medium. Is it outrageous for blog posts to be behind a paywall? Maybe but > it's even more outrageous to lack consistency, either by not knowing how = to > get around a paywall if you're into a hacker punk movement, or on the > contrary by to not paying a subscription if you believe that surveillance > capitalism, to reuse Zuboff's terms, should be eradicated. > What likely seems an unnecessary sidenote tries to illustrate the point: > for Justin it was easier to publish on medium, because as a blog publishe= r, > you might not want to deal with hosting your own blog. But maybe as a > reader you'll find that annoying. Different audiences, different JTBD, > different tradeoffs. > > Polyphormism is a tool that enables the end-developer to have minimal > knowledge of what it means to deal with a GNAP client library. You prepar= e > the request, send to the endpoint and you're good to go. Massively simple= r > than OAuth2 or any similar protocol by the way (as anyone with teaching > experience on the subject might acknowledge). And there's a lot more to = be > done to make sure we indeed reduce the complexity for the end-developer a= nd > the end-user. > > If we find a better way to deal with that simplicity balance, I'm all in. > But the arguments need to be way more convincing than just saying that it > may be difficult to implement or validate. > > Cheers. > Fabien > > > > > > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : > >> >> >> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >> >> Justin >> >> I did note that I was the one that argued for instance_id being in the >> object. Since it is in the object in the current draft, not including a >> pass by reference option would be preferable. >> >> As for concrete examples: >> - version of client >> - version of OS >> - security attestation of OS / device >> - location of client device >> - network client is operating on >> >> These are all attributes of the client that an AS may require on the >> initial grant request, and in future grant requests (which is when an >> instance_id) would be used. >> >> >> This is where our interpretations differ: I don=E2=80=99t see these as >> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key,= display >> information, class identifiers, and other items currently represented by= an >> instance_id are attributes of the client instance. The attestation >> components don=E2=80=99t modify the instance so much as present addition= al >> information on top of the client instance itself. This is why I argue th= at >> they ought to be handled in a separate object, so you=E2=80=99d have som= ething like >> this strawman: >> >> { >> >> posture: { >> software_version: 1.2.3, >> os_version: 14.3.2 >> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >> }, >> >> client: =E2=80=9Cclient-541-ab" >> >> } >> >> This is a more fundamental question about GNAP than whether the syntax >> uses polymorphism: this is about GNAP being very explicit about the data >> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mode= l of what >> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pr= oblematic in >> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havi= ng to >> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture >> the different aspects that are out there. I think we=E2=80=99re getting = closer here >> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, b= ut we still need to >> be more precise about what exactly a client instance includes, and what = it >> does not. >> >> =E2=80=94 Justin >> >> >> /Dick >> >> =E1=90=A7 >> >> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >> >>> Dick, >>> >>> As you=E2=80=99ll recall, I argued against including the client instanc= e >>> identifier inside of the object as a mutually-exclusive field precisely >>> because of the principle violation that you are pointing out here, and = so >>> it=E2=80=99s important to point out that the current text is a compromi= se that >>> needs to be examined in the wider experience of the working group. I am= on >>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >>> object, but this needs to be explored. >>> >>> The crux of my argument is that is exactly a case of pass-by-reference >>> vs pass-by-value, and that runtime attestations are not part of the =E2= =80=9Cclient >>> instance=E2=80=9D value itself but rather belong outside of that object= in a >>> another part of the request. As stated in the editorial notes in this >>> section, we need to look carefully at how these concepts fit within the >>> model and where we would want to put them. Without concrete examples of >>> what these extensions look like and how they=E2=80=99re generated, that= is nearly >>> impossible to do at this stage. I look forward to seeing examples of th= is >>> kind of data and how it can fit into the protocol. >>> >>> =E2=80=94 Justin >>> >>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>> >>> Hey Justin, >>> >>> As the draft has evolved, I question the continued use of polymorphism. >>> Note that I appreciate the elegance of using a string for >>> pass-by-reference, and an object for pass-by-value. >>> >>> In the current draft, the >>> >>> Every time you create or process a field it will mean only one thing, >>> and there=E2=80=99s only one field to look at to answer a question. >>> >>> >>> is violated in 2.3.1. Identifying the RC Instance >>> >>> >>> >>> instance_id An identifier string that the AS can use to identify th= e >>> particular instance of this RC. The content and structure of thi= s >>> identifier is opaque to the RC. >>> >>> "client": { >>> "instance_id": "client-541-ab" >>> } >>> >>> If there are no additional fields to send, the RC MAY send the >>> instance identifier as a direct reference value in lieu of the >>> object. >>> >>> "client": "client-541-ab" >>> >>> >>> The instance identifier can be sent two ways. Polymorphism is a >>> convenience for the client, but requires the server to have two code pa= ths >>> for "instance_id". We discussed this in the design team, and I argued = for >>> having "instance_id" in the "client" object so that any updates, such a= s >>> new devices assertions, could be in the "client" object. As noted above= , >>> while I appreciate the elegance of using a string (handle) to reference= a >>> previously provided object, it complicates how to update an existing ob= ject >>> while providing the reference. >>> >>> In your example of the "key" object below, setting "proof" to bearer >>> would avoid the issue you describe: >>> >>> { >>> "key": { >>> "proof": "bearer" >>> } >>> } >>> >>> In your example, when processing the "key" object, code is having to >>> check both the JSON type of the property, as well as check the value of= the >>> "proof" property. In the example I provided, only the value of "proof" >>> needs to be checked. The "proof" property is acting as a type for the "= key" >>> object. >>> >>> Not being a Java programmer, I don't know how this would work in a Java >>> implementation, but node.js, the processing would need to be done as ab= ove. >>> >>> On a related note, there was significant negative feedback on handles >>> and polymorphism in the Hacker News article >>> https://news.ycombinator.com/item?id=3D24855750 >>> >>> /Dick >>> >>> >>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >>> >>>> Hi Mika, >>>> >>>> Thanks for bringing this topic here =E2=80=94 I was able to see the fo= rum >>>> discussion that brought you here, and hopefully I can help clear up wh= at I >>>> mean with how polymorphism is used in the proposal. The short version = is >>>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>>> protocols, and so in that goal we=E2=80=99re fully aligned. I think th= at using >>>> polymorphism in very specific ways can help that goal =E2=80=94 just a= s I agree >>>> that misusing it or applying it sloppily can lead to ambiguous and ins= ecure >>>> systems. >>>> >>>> Some background: I built out the XYZ protocol (one of the predecessors >>>> to the initial GNAP Draft) in Java using strongly typed parsers and Ja= va >>>> objects specifically to prove to myself that it could be done in a way= that >>>> made any sense in the code. (My own open source implementation is at >>>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not= yet up >>>> to date with the GNAP spec). It was important to me that I be able to = use >>>> the system-wide configured parsers to implement this and not have to r= esort >>>> to stepping through elements completely by hand. Java doesn=E2=80=99t = make it >>>> simple to get the hooks into the right places (especially with the Jac= kson >>>> parser that I used), but it is definitely possible to create a >>>> deterministic and strongly-typed parser and serializer for this kind o= f >>>> data structure. Some of the rationale for using polymorphism is covere= d in >>>> the trailing appendix of the draft document ( >>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#= name-json-structures-and-polymor), >>>> but it=E2=80=99s still good to discuss this here as the working group = decides which >>>> approaches to take. >>>> >>>> The driving reason for using polymorphism at the protocol level was to >>>> simplify the protocol and make it :more: deterministic to create and >>>> process, not less. Every time you create or process a field it will me= an >>>> only one thing, and there=E2=80=99s only one field to look at to answe= r a question. >>>> Without polymorphic field values, you usually need to rely on mutual >>>> exclusivity of fields, which is prone to failure and requires addition= al >>>> error checking. Take for example the key binding of access tokens. An >>>> access token could be bound to the RC=E2=80=99s key used during the re= quest, to a >>>> different key chosen by the AS, or it could be a bearer token with no = key >>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can = define it in terms of >>>> boolean values and objects and express this set of mutually-exclusive >>>> options in a non-ambiguous way. Without that, you=E2=80=99d need to ha= ve different >>>> fields for the options and include additional checks in your parser to= make >>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could get= hit with >>>> this potential security vulnerability in an object: >>>> >>>> { >>>> key: { >>>> proof: httpsig, >>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>> }, >>>> bearer_token: true, >>>> bind_to_rc_key: true >>>> } >>>> >>>> This would be an illegal object as per this alternate proposal, but >>>> then you=E2=80=99d have to check each field and make sure it wasn=E2= =80=99t put next to >>>> others in the same object. I=E2=80=99ve done this exercise with many o= ther >>>> protocols and it=E2=80=99s both error prone and easy to ignore since a= ll the =E2=80=9Cgood=E2=80=9D >>>> examples would pass code that doesn=E2=80=99t check this. With the pol= ymorphic >>>> approach to this same field, each of these three mutually-exclusive st= ates >>>> is written in a way that they cannot be sent together. It=E2=80=99s no= t just >>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSON it= self. >>>> >>>> { >>>> key: { >>>> proof: httpsig, >>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>> } >>>> } >>>> >>>> // bearer token >>>> >>>> { >>>> key: false >>>> } >>>> >>>> // bound to the RC=E2=80=99s presented key >>>> >>>> { >>>> key: true >>>> } >>>> >>>> If someone sends a different type for this field, like an array or >>>> number or a null, this doesn=E2=80=99t have a defined interpretation i= n the >>>> protocol and would be a protocol level error. >>>> >>>> While it might sound like polymorphism means that any field could have >>>> any type or value, the opposite is true: each possible value is explic= itly >>>> typed, it=E2=80=99s just that there are potentially different types th= at express >>>> meaning for the field. This applies to all members of all objects >>>> (dictionaries) as well as all members of an array (list). Every time y= ou >>>> process a field value or other element, you look at the type and then = the >>>> value to determine what to do with that typed value. >>>> >>>> In your example below, each field within the dictionary would also nee= d >>>> to be typed, and each type would need to have a clear indication of it= s >>>> meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could >>>> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSO= N number) or an >>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would= further say what >>>> exactly the encoding of the string would be. That means that when you = read >>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any conf= usion on what the value was >>>> or how it was represented, regardless of the input format. Seeing a nu= mber >>>> there means exactly one interpretation and seeing a string means exact= ly >>>> one (different) interpretation =E2=80=94 but importantly, both of them= are a >>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determi= nes the type. An >>>> implementation would likely use an internal BigInteger type of object = to >>>> represent the field value after parsing, so the question is how to go = from >>>> the JSON value (which is typed) into the BigInteger value.You don=E2= =80=99t just >>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you ap= ply it to all >>>> sub-fields of that object. >>>> >>>> So let=E2=80=99s dig into the specific bug you bring up in the strawma= n, >>>> because it=E2=80=99s interesting: A JSON encoder that encodes numbers = as strings, >>>> and not numbers, is not compliant with the JSON definitions of the fie= ld in >>>> question. For another example, the quoted string value of =E2=80=9Ctru= e=E2=80=9D is not >>>> equivalent to the boolean value true in JSON, and they shouldn=E2=80= =99t be treated >>>> the same by a parser implementation when mapping to a concrete object.= It=E2=80=99s >>>> in this kind of automated guessing that this class of bugs occur, and >>>> that=E2=80=99s going to be the case whether or not you take advantage= of JSON=E2=80=99s >>>> polymorphic nature. I=E2=80=99ve run into cases where a parser library= was trying >>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, = but ended up >>>> introducing errors in more strict components downstream. This is somet= hing >>>> that protocol designers need to be aware of and guard against in the d= esign >>>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>>> generally have things that branch whether they=E2=80=99re an object (f= or a rich >>>> description of something) or some non-structured special value (for a >>>> reference or other item). >>>> >>>> The design team created some simple JSON Schemas for parts of the >>>> protocol during our discussion, but we didn=E2=80=99t include them in = the design >>>> document due to both lack of time to keep it updated with the rapid ch= anges >>>> to the protocol during the design team discussion, and not knowing if = there >>>> would be interest in such material. I personally think it would be hel= pful >>>> to include as an informative reference in the final document, but that= =E2=80=99s >>>> something for the working group to take up eventually. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>> >>>> Hello, everyone. >>>> >>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum >>>> and when I made note about certain concerns, I was requested to send m= y >>>> comments to this working group. >>>> >>>> In short, I believe that the use of polymorphic JSON in the protocol >>>> invites subtle and confusing implementation problems. I also searched >>>> through the WG archives, and noticed that similar concerns were noted, >>>> briefly, in a thread in July. >>>> >>>> The problem with polymorphic values, as I see it, is that >>>> implementations will need to branch on the (inferred) type of a given >>>> field. This isn't quite as bad if the types are strictly different, bu= t >>>> allows for subtle bugs when the value in question is a dictionary. Wha= t >>>> makes this unappealing is that "subtle bugs" in security protocols hav= e a >>>> habit of turning into vulnerabilities. >>>> >>>> Let's say we have these imaginary payloads, both possible and valid in >>>> the same protocol step: >>>> >>>> # payload 1 >>>> { >>>> ..., >>>> "public_key": { >>>> "alg": "rsa", >>>> "modulus": >>>> } >>>> } >>>> >>>> # payload 2 >>>> { >>>> ..., >>>> "public_key": { >>>> "alg": "rsa", >>>> "modulus": "" >>>> } >>>> } >>>> >>>> In both cases, the type of "public_key" field is a dictionary. In both >>>> cases, they even have the same keys. However, the values in the >>>> dictionaries are entirely different, and an implementation will have t= o >>>> branch to at least two possible decoding mechanisms. To make things wo= rse, >>>> some JSON implementations may choose to encode non-dictionary values a= s >>>> strings, so it is possible for an originator to transmit what they exp= ect >>>> and believe to be payload 1 format, but which the receiver will interp= ret >>>> to be in payload 2 format. And if the encoded string contains only dig= its, >>>> it will even parse correctly as a bignum. >>>> >>>> While the above is clearly a manufactured scenario, it nonetheless >>>> demonstrates the potential for logic bugs with polymorphic JSON. With >>>> richer types and more complex dictionaries, there will surely be more = room >>>> for errors. >>>> >>>> Ambiguity in protocols is always a source of implementation complexity >>>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse= : >>>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wou= ldn't >>>> it be in everyone's interest to keep implementation complexity and mis= take >>>> potential to a minimum? >>>> >>>> Best regards, >>>> Mika >>>> >>>> -- >>>> Mika Bostr=C3=B6m >>>> Smarkets >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> =E1=90=A7 >>> >>> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000013c65305b271ae22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm confused by your logic Fabien.

= If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=C2=A0

I = differ on who our stakeholders are.=C2=A0

I think = our stakeholders are in least to most important:

<= ul>
  • AS developer
  • RS developer
  • client developer
  • u= ser

    • A client library developer can expos= e whatever interface they want to simplify implementation.

    I list the user so that we don't lose site of a critical role.=

    /Dick


    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <= ;fabien.imbault@gmail.com&g= t; wrote:
    Hi there,=C2=A0

    Let me try to approach the issue under a different light. More like a p= roduct manager would deal with feature selection to make it intuitive for i= ts users.=C2=A0

    For most people, riding a bike is far easier than using a unicycle. Fee= ls more stable. And yet it's way easier to design for a single wheel th= an to build with 2. Because then you'll need a lot more accessories (ch= ain, chain ring, etc.). Even so producing a bike doesn't have to be a b= rittle process, it can be industrialized.=C2=A0

    =
    Back to the GNAP topic.=C2=A0
    = Ultimately we should strive to make = the spec as simple as can be. But we need to ask: simple for whom? For the = bike owner or for the bike vendor?=C2=A0
    = (short answer: the priority should b= e simplicity for spec users, not spec implementers and even less spec desig= ners).=C2=A0

    The initial question that is aske= d is very interesting: isn't the design flawed if GNAP is using json po= lyphormism? Or if the AS needs to handle the state of the request? Or if we= must handle token revocation? Or if we are looking for a global unique ide= ntifier? The argument stems of the fact that is still arguably harder and m= ore error prone to implement. Fair enough.=C2=A0
    From a spec implementer's perspective, it may = well be more complex. It mostly impacts the json library you'll end up = using, plus a bit of input/output decoration around it. Even golang provide= s utilities for this, despite not exactly being made for this kind of purpo= se.
    My practical experience implementing it is that = it's not that big a deal. I mean, I wished it could be simpler, but it&= #39;s manageable and there are other ways to reach levels of insurance that= it does work as intended (json schema, test cases to validate the implemen= tation, etc.). Arguably it is still easier from an implementation perspecti= ve than say, json-ld, which is massively used in the SSI community.=C2=A0

    But ultimately who are we= designing for? Are we striving to go easy on the spec implementer? Or are = we trying to make sure end-developers using the client libraries won't = shoot themselves in the foot?

    The job to be done (JTBD), from the end-developer's perspective, = is to efficiently ship an application. And provide authN/authZ capabilities= for end-users by relying on some well known implementation.=C2=A0
    In turn, this spec implementer will rely on cryptographic ut= ility libraries that deals internally with the complexity of their own doma= in, so that we don't have to. And here we could launch another HN flame= war that starts with the title "JWT sucks because". Which does h= ave its set of very real issues but that's beyond the point.=C2=A0
    Note that any decent flamewar will be efficiently fueled= by people hating medium. Is it outrageous for blog posts to be behind a pa= ywall? Maybe but it's even more outrageous to lack consistency, either = by not knowing how to get around a paywall if you're into a hacker punk= movement, or on the contrary by to not paying a subscription if you believ= e that surveillance capitalism, to reuse Zuboff's terms, should be erad= icated.=C2=A0
    What likely seems an unnecessary siden= ote tries to illustrate the point: for Justin it was easier to publish on m= edium, because as a blog publisher, you might not want to deal with hosting= your own blog. But maybe as a reader you'll find that annoying. Differ= ent audiences, different JTBD, different tradeoffs.=C2=A0

    Polyphormism is a tool that enables the e= nd-developer to have minimal knowledge of what it means to deal with a GNAP= client library. You prepare the request, send to the endpoint and you'= re good to go. Massively simpler than OAuth2 or any similar protocol by the= way (as anyone with teaching experience on the subject might acknowledge).= And=C2=A0 there's a lot more to be done to make sure we indeed reduce = the complexity for the end-developer and the end-user.=C2=A0

    If we find a better way to deal with = that simplicity balance, I'm all in. But the arguments need to be way m= ore convincing than just saying that it may be difficult to implement or va= lidate.=C2=A0

    Cheers.
    Fabien





    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:


    On Oct 23, 2020, at 3= :52 PM, Dick Hardt <dick.h= ardt@gmail.com> wrote:

    Justin
    I did note that I was the one that argued for instance_id being= in the object. Since it is in the object in the current draft, not includi= ng a pass by reference option would be preferable.=C2=A0

    As for concrete examples:
    - version of client
    - = version of OS
    - security attestation of OS / device
    - l= ocation of client device
    - network client is operating on

    These are all attributes of the client that an AS may req= uire=C2=A0on the initial grant request, and in future grant requests (which= is when an instance_id) would be used.


    This is where our interpretations differ: I d= on=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in the= same way that the key, display information, class identifiers, and other i= tems currently represented by an instance_id are attributes of the client i= nstance. The attestation components don=E2=80=99t modify the instance so mu= ch as present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, so = you=E2=80=99d have something like this strawman:

    {=

    =C2=A0 posture: {
    =C2=A0 =C2=A0 softwar= e_version: 1.2.3,
    =C2=A0 =C2=A0 os_version: 14.3.2
    =C2= =A0 =C2=A0 device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 }
    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80= =A6, alt: =E2=80=A6 }
    =C2=A0 },

    =C2=A0 c= lient: =E2=80=9Cclient-541-ab"

    }
    This is a more fundamental question about GNAP than whether th= e syntax uses polymorphism: this is about GNAP being very explicit about th= e data model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, i= s deeply problematic in practice. We=E2=80=99re even seeing that in the OAu= th 2.1 work with having to define a =E2=80=9Ccredentialed client=E2=80=9D, = and even then that doesn=E2=80=99t fully capture the different aspects that= are out there. I think we=E2=80=99re getting closer here in GNAP with expl= icit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to = be more precise about what exactly a client instance includes, and what it = does not.

    =C2=A0=E2=80=94 Justin


    /Dick

    =E1=90=A7

    On Fri, Oct 23, 2020 at 12:= 42 PM Justin Richer <jricher@mi= t.edu> wrote:
    Dick,

    As you=E2=80=99ll recall, I argued again= st including the client instance identifier inside of the object as a mutua= lly-exclusive field precisely because of the principle violation that you a= re pointing out here, and so it=E2=80=99s important to point out that the c= urrent text is a compromise that needs to be examined in the wider experien= ce of the working group. I am on the side of removing the mutually-exclusiv= e =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.

    The crux of my argument is that is ex= actly a case of pass-by-reference vs pass-by-value, and that runtime attest= ations are not part of the =E2=80=9Cclient instance=E2=80=9D value itself b= ut rather belong outside of that object in a another part of the request. A= s stated in the editorial notes in this section, we need to look carefully = at how these concepts fit within the model and where we would want to put t= hem. Without concrete examples of what these extensions look like and how t= hey=E2=80=99re generated, that is nearly impossible to do at this stage. I = look forward to seeing examples of this kind of data and how it can fit int= o the protocol.

    =C2=A0=E2=80=94 Justin
    <= div>
    On Oct 23, 2020, at 3:07 PM, Dick Ha= rdt <dick.hardt@gmail.com<= /a>> wrote:

    Hey Justin,<= br>

    As the draft has evolved, I question the continued u= se of polymorphism. Note that I appreciate the elegance=C2=A0of using a str= ing for pass-by-reference, and an object for pass-by-value.

    <= /div>
    In the current draft, the=C2=A0

    Every time yo= u create or process a field it will mean only one thing, and there=E2=80=99= s only one field to look at to answer a question.=C2=A0
    <= div>


    =C2=A0 =C2=A0inst= ance_id =C2=A0An identifier string that the AS can use to identify the
    =C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2=A0 The conten= t and structure of this
    =C2=A0 =C2=A0 =C2=A0 identifier is opaque= to the RC.

    =C2=A0 =C2=A0"client": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541= -ab"
    =C2=A0 =C2=A0}

    =C2=A0 =C2=A0If= there are no additional fields to send, the RC MAY send the
    =C2= =A0 =C2=A0instance identifier as a direct reference value in lieu of the
    =C2=A0 =C2=A0object.

    =C2=A0 =C2=A0"cl= ient": "client-541-ab"

    The instance identifier can be sent two ways. Polymorphism is a convenienc= e for the client, but requires the server=C2=A0to have two code=C2=A0paths = for "instance_id".=C2=A0 We discussed this in the design team, an= d I argued for having "instance_id" in the "client" obj= ect=C2=A0so that any updates, such as new devices assertions, could be in t= he "client" object. As noted above, while I appreciate the elegan= ce of using a string (handle) to reference a previously provided object, it= complicates how to update an existing object while providing the reference= .

    In your example of the "key" object be= low, setting "proof" to bearer would avoid the issue you describe= :

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2= =A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2=A0 } =
    }

    In your example, when processing the &qu= ot;key" object, code is having to check both the JSON type of the prop= erty, as well as check the value of the "proof" property. In the = example I provided, only the value of "proof" needs to be checked= . The "proof" property is acting as a type for the "key"= ; object.

    Not being a Java programmer, I don't= know how this would work in a Java implementation, but node.js, the proces= sing would need to be done as above.

    On a related = note, there was significant negative feedback on handles and polymorphism i= n the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24855750= =C2=A0

    /Dick


    On Fri= , Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Mika,

    Thanks for brin= ging this topic here =E2=80=94 I was able to see the forum discussion that = brought you here, and hopefully I can help clear up what I mean with how po= lymorphism is used in the proposal. The short version is that the goal is t= o=C2=A0avoid=C2=A0the kinds of ambiguity that make insecure protocol= s, and so in that goal we=E2=80=99re fully aligned. I think that using poly= morphism in very specific ways can help that goal =E2=80=94 just as I agree= that misusing it or applying it sloppily can lead to ambiguous and insecur= e systems.

    Some background: I built out the XYZ pr= otocol (one of the predecessors to the initial GNAP Draft) in Java using st= rongly typed parsers and Java objects specifically to prove to myself that = it could be done in a way that made any sense in the code. (My own open sou= rce implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but note that it=E2= =80=99s not yet up to date with the GNAP spec). It was important to me that= I be able to use the system-wide configured parsers to implement this and = not have to resort to stepping through elements completely by hand. Java do= esn=E2=80=99t make it simple to get the hooks into the right places (especi= ally with the Jackson parser that I used), but it is definitely possible to= create a deterministic and strongly-typed parser and serializer for this k= ind of data structure. Some of the rationale for using polymorphism is cove= red in the trailing appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core= -protocol-00.html#name-json-structures-and-polymor), but it=E2=80=99s s= till good to discuss this here as the working group decides which approache= s to take.=C2=A0

    The driving reason for using poly= morphism at the protocol level was to simplify the protocol and make it :mo= re: deterministic to create and process, not less. Every time you create or= process a field it will mean only one thing, and there=E2=80=99s only one = field to look at to answer a question. Without polymorphic field values, yo= u usually need to rely on mutual exclusivity of fields, which is prone to f= ailure and requires additional error checking. Take for example the key bin= ding of access tokens. An access token could be bound to the RC=E2=80=99s k= ey used during the request, to a different key chosen by the AS, or it coul= d be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D= field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way.= Without that, you=E2=80=99d need to have different fields for the options = and include additional checks in your parser to make sure they weren=E2=80= =99t sent simultaneously, otherwise you could get hit with this potential s= ecurity vulnerability in an object:

    {=C2=A0
    <= div>=C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 bearer_token: true,
    = =C2=A0 =C2=A0 bind_to_rc_key: true
    }

    Thi= s would be an illegal object as per this alternate proposal, but then you= =E2=80=99d have to check each field and make sure it wasn=E2=80=99t put nex= t to others in the same object. I=E2=80=99ve done this exercise with many o= ther protocols and it=E2=80=99s both error prone and easy to ignore since a= ll the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t= check this. With the polymorphic approach to this same field, each of thes= e three mutually-exclusive states is written in a way that they cannot be s= ent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and en= forced by the syntax of JSON itself.

    {=C2=A0<= /div>
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsi= g,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 }
    }

    // bearer toke= n

    {
    =C2=A0 =C2=A0 key: false
    }=

    // bound to the RC=E2=80=99s presented key<= /div>

    {
    =C2=A0 =C2=A0 key: true
    }

    If someone sends a different type for this field, li= ke an array or number or a null, this doesn=E2=80=99t have a defined interp= retation in the protocol and would be a protocol level error.
    While it might sound like polymorphism means that any field cou= ld have any type or value, the opposite is true: each possible value is exp= licitly typed, it=E2=80=99s just that there are potentially different types= that express meaning for the field. This applies to all members of all obj= ects (dictionaries) as well as all members of an array (list). Every time y= ou process a field value or other element, you look at the type and then th= e value to determine what to do with that typed value.

    =
    In your example below, each field within the dictionary would also nee= d to be typed, and each type would need to have a clear indication of its m= eaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON strin= g). The definition would further say what exactly the encoding of the strin= g would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D fie= ld there wouldn=E2=80=99t be any confusion on what the value was or how it = was represented, regardless of the input format. Seeing a number there mean= s exactly one interpretation and seeing a string means exactly one (differe= nt) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cm= odulus=E2=80=9D, since that=E2=80=99s the field that determines the type. A= n implementation would likely use an internal BigInteger type of object to = represent the field value after parsing, so the question is how to go from = the JSON value (which is typed) into the BigInteger value.You don=E2=80=99t= just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you a= pply it to all sub-fields of that object.=C2=A0

    So= let=E2=80=99s dig into the specific bug you bring up in the strawman, beca= use it=E2=80=99s interesting: A JSON encoder that encodes numbers as string= s, and not numbers, is not compliant with the JSON definitions of the field= in question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not equivalent to the boolean value true in JSON, and they sho= uldn=E2=80=99t be treated the same by a parser implementation when mapping = to a concrete object. It=E2=80=99s in this kind of automated guessing that = this class of bugs occur, and that=E2=80=99s going to be the case whether o= r not you take =C2=A0advantage of JSON=E2=80=99s polymorphic nature. I=E2= =80=99ve run into cases where a parser library was trying to be overly =E2= =80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introduc= ing errors in more strict components downstream. This is something that pro= tocol designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally ha= ve things that branch whether they=E2=80=99re an object (for a rich descrip= tion of something) or some non-structured special value (for a reference or= other item).=C2=A0

    The design team created some s= imple JSON Schemas for parts of the protocol during our discussion, but we = didn=E2=80=99t include them in the design document due to both lack of time= to keep it updated with the rapid changes to the protocol during the desig= n team discussion, and not knowing if there would be interest in such mater= ial. I personally think it would be helpful to include as an informative re= ference in the final document, but that=E2=80=99s something for the working= group to take up eventually.

    =C2=A0=E2=80=94 Just= in

    On Oct 23, 2020, at 10:18 A= M, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wr= ote:

    Hello, everyone.

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion foru= m and when I made note about certain concerns, I was requested to send my c= omments to this working group.

    In short, I bel= ieve that the use of polymorphic JSON in the protocol invites subtle and co= nfusing implementation problems. I also searched through the WG archives, a= nd noticed that similar concerns were noted, briefly, in a thread in July. =

    The problem with polymorphic values, as I see= it, is that implementations will need to branch on the (inferred) type of = a given field. This isn't quite as bad if the types are strictly differ= ent, but allows for subtle bugs when the value in question is a dictionary.= What makes this unappealing is that "subtle bugs" in security pr= otocols have a habit of turning into vulnerabilities.

    <= div>Let's say we have these imaginary payloads, both possible and valid= in the same protocol step:

    # payload 1
    = {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    =C2=A0= =C2=A0=C2=A0 "modulus": <BIGINT>
    =C2=A0 }
    }

    # payload 2
    {
    =C2=A0 ...,=
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0 &q= uot;alg": "rsa",
    =C2=A0=C2=A0=C2=A0 "modulus&= quot;: "<encoded string>"
    =C2=A0 }
    }

    In both cases, the type of "public_key" fi= eld is a dictionary. In both cases, they even have the same keys. However, = the values in the dictionaries are entirely different, and an implementatio= n will have to branch to at least two possible decoding mechanisms. To make= things worse, some JSON implementations may choose to encode non-dictionar= y values as strings, so it is possible for an originator to transmit what t= hey expect and believe to be payload 1 format, but which the receiver will = interpret to be in payload 2 format. And if the encoded string contains onl= y digits, it will even parse correctly as a bignum.

    While the above is clearly a manufactured scenario, it nonetheless de= monstrates the potential for logic bugs with polymorphic JSON. With richer = types and more complex dictionaries, there will surely be more room for err= ors.

    Ambiguity in protocols is always a source of = implementation complexity and interoperability snags, but in an AuthN/AuthZ= protocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to s= upersede Oauth1/2, wouldn't it be in everyone's interest to keep im= plementation complexity and mistake potential to a minimum?
    <= br>
    Best regards,
    Mika

    --
    <= div>
    Mika = Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAu= th@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/txauth
    3D""=E1=90=A7


    --
    TXAuth mailing list
    TXAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/txauth
    --00000000000013c65305b271ae22-- From nobody Sat Oct 24 15:25:21 2020 Return-Path: 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 688CA3A111C for ; Sat, 24 Oct 2020 15:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 LlSSgmBYMsOP for ; Sat, 24 Oct 2020 15:25:15 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 481223A0B6D for ; Sat, 24 Oct 2020 15:25:15 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id y17so4801435ilg.4 for ; Sat, 24 Oct 2020 15:25:15 -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=QN8FGmb1U5gGq0yKQrNeqTATk+opECszwSLBjIShG6U=; b=D3vtDq77EKVjhbK8FC0nX3dvJPKKzw9vwuI0LZ0BQNsCArjbQ8rlaR9GQPwZoYBI2D 67w4MTklEZA+kOpfGfEoNltM01NIv+7exSp8vvznNKOvVAGG0hwXi9dMmFiKVr9Vucxd /JyFuR1GcVXU1hK40yqnv7Dq5++Sl6GobG8Az4TFRcnjtFdwn+TNqZfKJh31v32WpT86 ly4+mzTnfS/oDkrx+vQZIJgkYy8K+6M5eNZf5TUo8CCa05lxeZ3Q+fuDOTITh7ZezUkQ v7benutDDWvYGJ2t/AEIbr9HBKLIzoTVT545KW+Mjz04wvM+zqBZr4ZkIOZ0nx9+ZWFM fzZw== 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=QN8FGmb1U5gGq0yKQrNeqTATk+opECszwSLBjIShG6U=; b=iAVN+SHNgGgmBXDDyg62lwqgfpfiu5aKqgib4vlg4hNPoCFwWLQzkggbVzOn0L/uB2 KcFC9ex0kL0j0/kY8hqLzocL3Tlbo/zH0B32EqhgK7JSLGefvK4Dcg0Q6rlMbGNfqsso 8o2sz9ra6dhiIjkUVMOWGmxZoZ2yZ+gKBvrsD+5uRTxrhLPtR9mQquK5F+2AW0tlxZBW QvA3nF1UAY/2n9UOlCqpol+9D82cvIaxsy5cyMq+n9Y/VGBll+kFndjBXboMlDqtSdGR Fcmx+qCn8d/b+VsvT+GCufGPNWjX7P+y61XWLLEtlizYdePvCyp3PG/Wl7tCZutr81gN /sOQ== X-Gm-Message-State: AOAM533Bh1+2ZckMhIkRPEKJyl27Njcn8VZToP7iTRahinez/fDyzIsw 5QMqbKpaBrtSwOYIS5Mo1xPfPUFLPNx9FSYkWw4= X-Google-Smtp-Source: ABdhPJwbQB7ibIUU+FKG+pYL++qz64nRidpk8NOROQ3k+CikylYKnVZUW646IuvYKKzJbA/VYB9H3qL5DmNfd0wg7jI= X-Received: by 2002:a92:ae0a:: with SMTP id s10mr6351569ilh.289.1603578314239; Sat, 24 Oct 2020 15:25:14 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sun, 25 Oct 2020 00:25:01 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ca34ad05b2722b2d" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 22:25:19 -0000 --000000000000ca34ad05b2722b2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Independantly from the debate on polyphormism, I beg to differ on your order preference. Your assumption is that AS devs matter the most, because they're doing the important security implementation. But eating our own dogfood might help a lot to change that view. Most security issues occur because users of the spec are unable to deal with the complexity that is passed onto them. 99% of the people that will actually use the output of the work are application developers (client or RS) and their own users. Our intent as well as the protocol drive the usage. Client libraries may help, but they're not a silver bullet, especially because GNAP ultimately has no control about what people do there (for better or worse). And everything we do here will help get to the better part. I'm not saying we don't intend to also care about AS developers (beginning with ourselves) but it's a second order optimisation. And since it's a tendancy we're leaning towards by default, I'm pretty sure we won't forget that anyway. Fabien Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3= =A9crit : > I'm confused by your logic Fabien. > > If a client library developer wants to expose polymorphism, they can do > that independent of what is in the protocol. > > I differ on who our stakeholders are. > > I think our stakeholders are in least to most important: > > > - AS developer > - RS developer > - client developer > - user > > > A client library developer can expose whatever interface they want to > simplify implementation. > > I list the user so that we don't lose site of a critical role. > > /Dick > > > =E1=90=A7 > > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault > wrote: > >> Hi there, >> >> Let me try to approach the issue under a different light. More like a >> product manager would deal with feature selection to make it intuitive f= or >> its users. >> >> For most people, riding a bike is far easier than using a unicycle. Feel= s >> more stable. And yet it's way easier to design for a single wheel than t= o >> build with 2. Because then you'll need a lot more accessories (chain, ch= ain >> ring, etc.). Even so producing a bike doesn't have to be a brittle proce= ss, >> it can be industrialized. >> >> Back to the GNAP topic. >> Ultimately we should strive to make the spec as simple as can be. But we >> need to ask: simple for whom? For the bike owner or for the bike vendor? >> (short answer: the priority should be simplicity for spec users, not spe= c >> implementers and even less spec designers). >> >> The initial question that is asked is very interesting: isn't the design >> flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the >> state of the request? Or if we must handle token revocation? Or if we ar= e >> looking for a global unique identifier? The argument stems of the fact t= hat >> is still arguably harder and more error prone to implement. Fair enough. >> >> From a spec implementer's perspective, it may well be more complex. It >> mostly impacts the json library you'll end up using, plus a bit of >> input/output decoration around it. Even golang provides utilities for th= is, >> despite not exactly being made for this kind of purpose. >> My practical experience implementing it is that it's not that big a deal= . >> I mean, I wished it could be simpler, but it's manageable and there are >> other ways to reach levels of insurance that it does work as intended (j= son >> schema, test cases to validate the implementation, etc.). Arguably it is >> still easier from an implementation perspective than say, json-ld, which= is >> massively used in the SSI community. >> >> But ultimately who are we designing for? Are we striving to go easy on >> the spec implementer? Or are we trying to make sure end-developers using >> the client libraries won't shoot themselves in the foot? >> >> The job to be done (JTBD), from the end-developer's perspective, is to >> efficiently ship an application. And provide authN/authZ capabilities fo= r >> end-users by relying on some well known implementation. >> In turn, this spec implementer will rely on cryptographic utility >> libraries that deals internally with the complexity of their own domain,= so >> that we don't have to. And here we could launch another HN flame war tha= t >> starts with the title "JWT sucks because". Which does have its set of ve= ry >> real issues but that's beyond the point. >> Note that any decent flamewar will be efficiently fueled by people hatin= g >> medium. Is it outrageous for blog posts to be behind a paywall? Maybe bu= t >> it's even more outrageous to lack consistency, either by not knowing how= to >> get around a paywall if you're into a hacker punk movement, or on the >> contrary by to not paying a subscription if you believe that surveillanc= e >> capitalism, to reuse Zuboff's terms, should be eradicated. >> What likely seems an unnecessary sidenote tries to illustrate the point: >> for Justin it was easier to publish on medium, because as a blog publish= er, >> you might not want to deal with hosting your own blog. But maybe as a >> reader you'll find that annoying. Different audiences, different JTBD, >> different tradeoffs. >> >> Polyphormism is a tool that enables the end-developer to have minimal >> knowledge of what it means to deal with a GNAP client library. You prepa= re >> the request, send to the endpoint and you're good to go. Massively simpl= er >> than OAuth2 or any similar protocol by the way (as anyone with teaching >> experience on the subject might acknowledge). And there's a lot more to= be >> done to make sure we indeed reduce the complexity for the end-developer = and >> the end-user. >> >> If we find a better way to deal with that simplicity balance, I'm all in= . >> But the arguments need to be way more convincing than just saying that i= t >> may be difficult to implement or validate. >> >> Cheers. >> Fabien >> >> >> >> >> >> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : >> >>> >>> >>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>> >>> Justin >>> >>> I did note that I was the one that argued for instance_id being in the >>> object. Since it is in the object in the current draft, not including a >>> pass by reference option would be preferable. >>> >>> As for concrete examples: >>> - version of client >>> - version of OS >>> - security attestation of OS / device >>> - location of client device >>> - network client is operating on >>> >>> These are all attributes of the client that an AS may require on the >>> initial grant request, and in future grant requests (which is when an >>> instance_id) would be used. >>> >>> >>> This is where our interpretations differ: I don=E2=80=99t see these as >>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key= , display >>> information, class identifiers, and other items currently represented b= y an >>> instance_id are attributes of the client instance. The attestation >>> components don=E2=80=99t modify the instance so much as present additio= nal >>> information on top of the client instance itself. This is why I argue t= hat >>> they ought to be handled in a separate object, so you=E2=80=99d have so= mething like >>> this strawman: >>> >>> { >>> >>> posture: { >>> software_version: 1.2.3, >>> os_version: 14.3.2 >>> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>> }, >>> >>> client: =E2=80=9Cclient-541-ab" >>> >>> } >>> >>> This is a more fundamental question about GNAP than whether the syntax >>> uses polymorphism: this is about GNAP being very explicit about the dat= a >>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mod= el of what >>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply p= roblematic in >>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with hav= ing to >>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that does= n=E2=80=99t fully capture >>> the different aspects that are out there. I think we=E2=80=99re getting= closer here >>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, = but we still need to >>> be more precise about what exactly a client instance includes, and what= it >>> does not. >>> >>> =E2=80=94 Justin >>> >>> >>> /Dick >>> >>> =E1=90=A7 >>> >>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >>> >>>> Dick, >>>> >>>> As you=E2=80=99ll recall, I argued against including the client instan= ce >>>> identifier inside of the object as a mutually-exclusive field precisel= y >>>> because of the principle violation that you are pointing out here, and= so >>>> it=E2=80=99s important to point out that the current text is a comprom= ise that >>>> needs to be examined in the wider experience of the working group. I a= m on >>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >>>> object, but this needs to be explored. >>>> >>>> The crux of my argument is that is exactly a case of pass-by-reference >>>> vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient >>>> instance=E2=80=9D value itself but rather belong outside of that objec= t in a >>>> another part of the request. As stated in the editorial notes in this >>>> section, we need to look carefully at how these concepts fit within th= e >>>> model and where we would want to put them. Without concrete examples o= f >>>> what these extensions look like and how they=E2=80=99re generated, tha= t is nearly >>>> impossible to do at this stage. I look forward to seeing examples of t= his >>>> kind of data and how it can fit into the protocol. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>>> >>>> Hey Justin, >>>> >>>> As the draft has evolved, I question the continued use of polymorphism= . >>>> Note that I appreciate the elegance of using a string for >>>> pass-by-reference, and an object for pass-by-value. >>>> >>>> In the current draft, the >>>> >>>> Every time you create or process a field it will mean only one thing, >>>> and there=E2=80=99s only one field to look at to answer a question. >>>> >>>> >>>> is violated in 2.3.1. Identifying the RC Instance >>>> >>>> >>>> >>>> instance_id An identifier string that the AS can use to identify t= he >>>> particular instance of this RC. The content and structure of th= is >>>> identifier is opaque to the RC. >>>> >>>> "client": { >>>> "instance_id": "client-541-ab" >>>> } >>>> >>>> If there are no additional fields to send, the RC MAY send the >>>> instance identifier as a direct reference value in lieu of the >>>> object. >>>> >>>> "client": "client-541-ab" >>>> >>>> >>>> The instance identifier can be sent two ways. Polymorphism is a >>>> convenience for the client, but requires the server to have two code p= aths >>>> for "instance_id". We discussed this in the design team, and I argued= for >>>> having "instance_id" in the "client" object so that any updates, such = as >>>> new devices assertions, could be in the "client" object. As noted abov= e, >>>> while I appreciate the elegance of using a string (handle) to referenc= e a >>>> previously provided object, it complicates how to update an existing o= bject >>>> while providing the reference. >>>> >>>> In your example of the "key" object below, setting "proof" to bearer >>>> would avoid the issue you describe: >>>> >>>> { >>>> "key": { >>>> "proof": "bearer" >>>> } >>>> } >>>> >>>> In your example, when processing the "key" object, code is having to >>>> check both the JSON type of the property, as well as check the value o= f the >>>> "proof" property. In the example I provided, only the value of "proof" >>>> needs to be checked. The "proof" property is acting as a type for the = "key" >>>> object. >>>> >>>> Not being a Java programmer, I don't know how this would work in a Jav= a >>>> implementation, but node.js, the processing would need to be done as a= bove. >>>> >>>> On a related note, there was significant negative feedback on handles >>>> and polymorphism in the Hacker News article >>>> https://news.ycombinator.com/item?id=3D24855750 >>>> >>>> /Dick >>>> >>>> >>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote= : >>>> >>>>> Hi Mika, >>>>> >>>>> Thanks for bringing this topic here =E2=80=94 I was able to see the f= orum >>>>> discussion that brought you here, and hopefully I can help clear up w= hat I >>>>> mean with how polymorphism is used in the proposal. The short version= is >>>>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>>>> protocols, and so in that goal we=E2=80=99re fully aligned. I think t= hat using >>>>> polymorphism in very specific ways can help that goal =E2=80=94 just = as I agree >>>>> that misusing it or applying it sloppily can lead to ambiguous and in= secure >>>>> systems. >>>>> >>>>> Some background: I built out the XYZ protocol (one of the predecessor= s >>>>> to the initial GNAP Draft) in Java using strongly typed parsers and J= ava >>>>> objects specifically to prove to myself that it could be done in a wa= y that >>>>> made any sense in the code. (My own open source implementation is at >>>>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s no= t yet up >>>>> to date with the GNAP spec). It was important to me that I be able to= use >>>>> the system-wide configured parsers to implement this and not have to = resort >>>>> to stepping through elements completely by hand. Java doesn=E2=80=99t= make it >>>>> simple to get the hooks into the right places (especially with the Ja= ckson >>>>> parser that I used), but it is definitely possible to create a >>>>> deterministic and strongly-typed parser and serializer for this kind = of >>>>> data structure. Some of the rationale for using polymorphism is cover= ed in >>>>> the trailing appendix of the draft document ( >>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html= #name-json-structures-and-polymor), >>>>> but it=E2=80=99s still good to discuss this here as the working group= decides which >>>>> approaches to take. >>>>> >>>>> The driving reason for using polymorphism at the protocol level was t= o >>>>> simplify the protocol and make it :more: deterministic to create and >>>>> process, not less. Every time you create or process a field it will m= ean >>>>> only one thing, and there=E2=80=99s only one field to look at to answ= er a question. >>>>> Without polymorphic field values, you usually need to rely on mutual >>>>> exclusivity of fields, which is prone to failure and requires additio= nal >>>>> error checking. Take for example the key binding of access tokens. An >>>>> access token could be bound to the RC=E2=80=99s key used during the r= equest, to a >>>>> different key chosen by the AS, or it could be a bearer token with no= key >>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can= define it in terms of >>>>> boolean values and objects and express this set of mutually-exclusive >>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need to h= ave different >>>>> fields for the options and include additional checks in your parser t= o make >>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could ge= t hit with >>>>> this potential security vulnerability in an object: >>>>> >>>>> { >>>>> key: { >>>>> proof: httpsig, >>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>> }, >>>>> bearer_token: true, >>>>> bind_to_rc_key: true >>>>> } >>>>> >>>>> This would be an illegal object as per this alternate proposal, but >>>>> then you=E2=80=99d have to check each field and make sure it wasn=E2= =80=99t put next to >>>>> others in the same object. I=E2=80=99ve done this exercise with many = other >>>>> protocols and it=E2=80=99s both error prone and easy to ignore since = all the =E2=80=9Cgood=E2=80=9D >>>>> examples would pass code that doesn=E2=80=99t check this. With the po= lymorphic >>>>> approach to this same field, each of these three mutually-exclusive s= tates >>>>> is written in a way that they cannot be sent together. It=E2=80=99s n= ot just >>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSON i= tself. >>>>> >>>>> { >>>>> key: { >>>>> proof: httpsig, >>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>> } >>>>> } >>>>> >>>>> // bearer token >>>>> >>>>> { >>>>> key: false >>>>> } >>>>> >>>>> // bound to the RC=E2=80=99s presented key >>>>> >>>>> { >>>>> key: true >>>>> } >>>>> >>>>> If someone sends a different type for this field, like an array or >>>>> number or a null, this doesn=E2=80=99t have a defined interpretation = in the >>>>> protocol and would be a protocol level error. >>>>> >>>>> While it might sound like polymorphism means that any field could hav= e >>>>> any type or value, the opposite is true: each possible value is expli= citly >>>>> typed, it=E2=80=99s just that there are potentially different types t= hat express >>>>> meaning for the field. This applies to all members of all objects >>>>> (dictionaries) as well as all members of an array (list). Every time = you >>>>> process a field value or other element, you look at the type and then= the >>>>> value to determine what to do with that typed value. >>>>> >>>>> In your example below, each field within the dictionary would also >>>>> need to be typed, and each type would need to have a clear indication= of >>>>> its meaning. To take your strawman key format below, the =E2=80=9Cmod= ulus=E2=80=9D field >>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D= (a JSON number) or an >>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition woul= d further say what >>>>> exactly the encoding of the string would be. That means that when you= read >>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any con= fusion on what the value was >>>>> or how it was represented, regardless of the input format. Seeing a n= umber >>>>> there means exactly one interpretation and seeing a string means exac= tly >>>>> one (different) interpretation =E2=80=94 but importantly, both of the= m are a >>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determ= ines the type. An >>>>> implementation would likely use an internal BigInteger type of object= to >>>>> represent the field value after parsing, so the question is how to go= from >>>>> the JSON value (which is typed) into the BigInteger value.You don=E2= =80=99t just >>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you a= pply it to all >>>>> sub-fields of that object. >>>>> >>>>> So let=E2=80=99s dig into the specific bug you bring up in the strawm= an, >>>>> because it=E2=80=99s interesting: A JSON encoder that encodes numbers= as strings, >>>>> and not numbers, is not compliant with the JSON definitions of the fi= eld in >>>>> question. For another example, the quoted string value of =E2=80=9Ctr= ue=E2=80=9D is not >>>>> equivalent to the boolean value true in JSON, and they shouldn=E2=80= =99t be treated >>>>> the same by a parser implementation when mapping to a concrete object= . It=E2=80=99s >>>>> in this kind of automated guessing that this class of bugs occur, and >>>>> that=E2=80=99s going to be the case whether or not you take advantag= e of JSON=E2=80=99s >>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser librar= y was trying >>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping,= but ended up >>>>> introducing errors in more strict components downstream. This is some= thing >>>>> that protocol designers need to be aware of and guard against in the = design >>>>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>>>> generally have things that branch whether they=E2=80=99re an object (= for a rich >>>>> description of something) or some non-structured special value (for a >>>>> reference or other item). >>>>> >>>>> The design team created some simple JSON Schemas for parts of the >>>>> protocol during our discussion, but we didn=E2=80=99t include them in= the design >>>>> document due to both lack of time to keep it updated with the rapid c= hanges >>>>> to the protocol during the design team discussion, and not knowing if= there >>>>> would be interest in such material. I personally think it would be he= lpful >>>>> to include as an informative reference in the final document, but tha= t=E2=80=99s >>>>> something for the working group to take up eventually. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>> >>>>> Hello, everyone. >>>>> >>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum >>>>> and when I made note about certain concerns, I was requested to send = my >>>>> comments to this working group. >>>>> >>>>> In short, I believe that the use of polymorphic JSON in the protocol >>>>> invites subtle and confusing implementation problems. I also searched >>>>> through the WG archives, and noticed that similar concerns were noted= , >>>>> briefly, in a thread in July. >>>>> >>>>> The problem with polymorphic values, as I see it, is that >>>>> implementations will need to branch on the (inferred) type of a given >>>>> field. This isn't quite as bad if the types are strictly different, b= ut >>>>> allows for subtle bugs when the value in question is a dictionary. Wh= at >>>>> makes this unappealing is that "subtle bugs" in security protocols ha= ve a >>>>> habit of turning into vulnerabilities. >>>>> >>>>> Let's say we have these imaginary payloads, both possible and valid i= n >>>>> the same protocol step: >>>>> >>>>> # payload 1 >>>>> { >>>>> ..., >>>>> "public_key": { >>>>> "alg": "rsa", >>>>> "modulus": >>>>> } >>>>> } >>>>> >>>>> # payload 2 >>>>> { >>>>> ..., >>>>> "public_key": { >>>>> "alg": "rsa", >>>>> "modulus": "" >>>>> } >>>>> } >>>>> >>>>> In both cases, the type of "public_key" field is a dictionary. In bot= h >>>>> cases, they even have the same keys. However, the values in the >>>>> dictionaries are entirely different, and an implementation will have = to >>>>> branch to at least two possible decoding mechanisms. To make things w= orse, >>>>> some JSON implementations may choose to encode non-dictionary values = as >>>>> strings, so it is possible for an originator to transmit what they ex= pect >>>>> and believe to be payload 1 format, but which the receiver will inter= pret >>>>> to be in payload 2 format. And if the encoded string contains only di= gits, >>>>> it will even parse correctly as a bignum. >>>>> >>>>> While the above is clearly a manufactured scenario, it nonetheless >>>>> demonstrates the potential for logic bugs with polymorphic JSON. With >>>>> richer types and more complex dictionaries, there will surely be more= room >>>>> for errors. >>>>> >>>>> Ambiguity in protocols is always a source of implementation complexit= y >>>>> and interoperability snags, but in an AuthN/AuthZ protocol it is wors= e: >>>>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wo= uldn't >>>>> it be in everyone's interest to keep implementation complexity and mi= stake >>>>> potential to a minimum? >>>>> >>>>> Best regards, >>>>> Mika >>>>> >>>>> -- >>>>> Mika Bostr=C3=B6m >>>>> Smarkets >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> =E1=90=A7 >>>> >>>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000ca34ad05b2722b2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Dick,

    Ind= ependantly from the debate on polyphormism, I beg to differ on your order p= reference.=C2=A0

    Your as= sumption is that AS devs matter the most,=C2=A0because they're doing the important security implementation.= But eating our own dogfood might help a lot to change that view. Most secu= rity issues occur because users of the spec are unable to deal with the com= plexity that is passed onto them.=C2=A0

    <= /div>
    99% of the people that will actually use the output = of the work are application developers (client or RS) and their own users.= =C2=A0

    Our intent as well as the protocol drive the usage. C= lient libraries may help, but they're not a silver bullet, especially b= ecause GNAP ultimately has no control about what people do there (for bette= r or worse). And everything we do here will help get to the better part.=C2= =A0

    I'm not s= aying we don't intend to also care about AS developers (beginning with = ourselves) but it's a second order optimisation. And since it's a t= endancy we're leaning towards by default, I'm pretty sure we won= 9;t forget that anyway.=C2=A0

    Fabien=C2=A0



    Le sam. 24 oct. 2020 =C3=A0 23= :50, Dick Hardt <dick.hardt@gmai= l.com> a =C3=A9crit=C2=A0:
    <= div dir=3D"ltr">I'm confused by your logic Fabien.

    I= f a client library developer wants to expose polymorphism, they can do that= independent of what is in the protocol.=C2=A0

    I d= iffer on who our stakeholders are.=C2=A0

    I think o= ur stakeholders are in least to most important:

  • AS developer
  • RS developer
  • client developer
  • us= er

    • A client library developer can expose= whatever interface they want to simplify implementation.

    I list the user so that we don't lose site of a critical role.<= /div>

    /Dick


    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank" rel=3D"norefer= rer">fabien.imbault@gmail.com> wrote:
    Hi there,= =C2=A0

    Let me try to approach the issue un= der a different light. More like a product manager would deal with feature = selection to make it intuitive for its users.=C2=A0

    For most people, riding a bike is f= ar easier than using a unicycle. Feels more stable. And yet it's way ea= sier to design for a single wheel than to build with 2. Because then you= 9;ll need a lot more accessories (chain, chain ring, etc.). Even so produci= ng a bike doesn't have to be a brittle process, it can be industrialize= d.=C2=A0

    Back to the GNA= P topic.=C2=A0
    = Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=C2= =A0
    (short answer: the priority should be simplicity for spec users, not spec= implementers and even less spec designers).=C2=A0

    The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to han= dle the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the fa= ct that is still arguably harder and more error prone to implement. Fair en= ough.=C2=A0

    From a spec = implementer's perspective, it may well be more complex. It mostly impac= ts the json library you'll end up using, plus a bit of input/output dec= oration around it. Even golang provides utilities for this, despite not exa= ctly being made for this kind of purpose.
    My practic= al experience implementing it is that it's not that big a deal. I mean,= I wished it could be simpler, but it's manageable and there are other = ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still e= asier from an implementation perspective than say, json-ld, which is massiv= ely used in the SSI community.=C2=A0

    But ultimately who are we designing for? Are we striving to go= easy on the spec implementer? Or are we trying to make sure end-developers= using the client libraries won't shoot themselves in the foot?

    The job to be done (JTBD), from= the end-developer's perspective, is to efficiently ship an application= . And provide authN/authZ capabilities for end-users by relying on some wel= l known implementation.=C2=A0
    In turn, this spec imp= lementer will rely on cryptographic utility libraries that deals internally= with the complexity of their own domain, so that we don't have to. And= here we could launch another HN flame war that starts with the title "= ;JWT sucks because". Which does have its set of very real issues but t= hat's beyond the point.=C2=A0
    Note that any dece= nt flamewar will be efficiently fueled by people hating medium. Is it outra= geous for blog posts to be behind a paywall? Maybe but it's even more o= utrageous to lack consistency, either by not knowing how to get around a pa= ywall if you're into a hacker punk movement, or on the contrary by to n= ot paying a subscription if you believe that surveillance capitalism, to re= use Zuboff's terms, should be eradicated.=C2=A0
    = What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, y= ou might not want to deal with hosting your own blog. But maybe as a reader= you'll find that annoying. Different audiences, different JTBD, differ= ent tradeoffs.=C2=A0

    Pol= yphormism is a tool that enables the end-developer to have minimal knowledg= e of what it means to deal with a GNAP client library. You prepare the requ= est, send to the endpoint and you're good to go. Massively simpler than= OAuth2 or any similar protocol by the way (as anyone with teaching experie= nce on the subject might acknowledge). And=C2=A0 there's a lot more to = be done to make sure we indeed reduce the complexity for the end-developer = and the end-user.=C2=A0

    = If we find a better way to deal with that simplicity balance, I'm all i= n. But the arguments need to be way more convincing than just saying that i= t may be difficult to implement or validate.=C2=A0
    <= br>
    Cheers.
    Fabien





    Le ven. 23 oct. 2020 =C3=A0 22:= 35, Justin Richer <jricher@mit.= edu> a =C3=A9crit=C2=A0:


    On Oct 23,= 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin

    I did note that I was the one that argue= d for instance_id being in the object. Since it is in the object in the cur= rent draft, not including a pass by reference option would be preferable.= =C2=A0

    As for concrete examples:
    - versi= on of client
    - version of OS
    - security attestation of = OS / device
    - location of client device
    - network clien= t is operating on

    These are all attributes of the = client that an AS may require=C2=A0on the initial grant request, and in fut= ure grant requests (which is when an instance_id) would be used.
    =

    This is where our in= terpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of t= he client=E2=80=9D in the same way that the key, display information, class= identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t = modify the instance so much as present additional information on top of the= client instance itself. This is why I argue that they ought to be handled = in a separate object, so you=E2=80=99d have something like this strawman:

    {

    =C2=A0 posture: {
    <= div>=C2=A0 =C2=A0 software_version: 1.2.3,
    =C2=A0 =C2=A0 os_versi= on: 14.3.2
    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some str= ucture or signed blob? =E2=80=A6 }
    =C2=A0 =C2=A0 location: { lat:= =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
    =C2=A0 },
    =
    =C2=A0 client: =E2=80=9Cclient-541-ab"

    }

    This is a more fundamental question abo= ut GNAP than whether the syntax uses polymorphism: this is about GNAP being= very explicit about the data model of its elements. OAuth 2=E2=80=99s incr= edibly loose and broad model of what the term =E2=80=9Cclient=E2=80=9D is r= eferring to, exactly, is deeply problematic in practice. We=E2=80=99re even= seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccredent= ialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the= different aspects that are out there. I think we=E2=80=99re getting closer= here in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D= , but we still need to be more precise about what exactly a client instance= includes, and what it does not.

    =C2=A0=E2=80=94 J= ustin


    /Dick

    3D""=E1=90=A7

    =
    On Fri, Oc= t 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
    Dick,

    As you=E2=80= =99ll recall, I argued against including the client instance identifier ins= ide of the object as a mutually-exclusive field precisely because of the pr= inciple violation that you are pointing out here, and so it=E2=80=99s impor= tant to point out that the current text is a compromise that needs to be ex= amined in the wider experience of the working group. I am on the side of re= moving the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within a= n object, but this needs to be explored.

    The crux = of my argument is that is exactly a case of pass-by-reference vs pass-by-va= lue, and that runtime attestations are not part of the =E2=80=9Cclient inst= ance=E2=80=9D value itself but rather belong outside of that object in a an= other part of the request. As stated in the editorial notes in this section= , we need to look carefully at how these concepts fit within the model and = where we would want to put them. Without concrete examples of what these ex= tensions look like and how they=E2=80=99re generated, that is nearly imposs= ible to do at this stage. I look forward to seeing examples of this kind of= data and how it can fit into the protocol.

    =C2=A0= =E2=80=94 Justin

    On Oct 2= 3, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin,

    As the draft = has evolved, I question the continued use of polymorphism. Note that I appr= eciate the elegance=C2=A0of using a string for pass-by-reference, and an ob= ject for pass-by-value.

    In the current draft, the= =C2=A0

    Every time you create or process a field it will= mean only one thing, and there=E2=80=99s only one field to look at to answ= er a question.=C2=A0

    is violated in <= a href=3D"https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-00#sect= ion-2.3.1" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer no= referrer" target=3D"_blank">2.3.1.=C2=A0 Identifying the RC Instance


    =C2=A0 =C2=A0instance_id =C2=A0An identifi= er string that the AS can use to identify the
    =C2=A0 =C2=A0 =C2= =A0 particular instance of this RC.=C2=A0 The content and structure of this=
    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.
    <= br>
    =C2=A0 =C2=A0"client": {
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0"instance_id": "client-541-ab"
    = =C2=A0 =C2=A0}

    =C2=A0 =C2=A0If there are no additi= onal fields to send, the RC MAY send the
    =C2=A0 =C2=A0instance id= entifier as a direct reference value in lieu of the
    =C2=A0 =C2=A0= object.

    =C2=A0 =C2=A0"client": "cli= ent-541-ab"

    The instance identif= ier can be sent two ways. Polymorphism is a convenience for the client, but= requires the server=C2=A0to have two code=C2=A0paths for "instance_id= ".=C2=A0 We discussed this in the design team, and I argued for having= "instance_id" in the "client" object=C2=A0so that any = updates, such as new devices assertions, could be in the "client"= object. As noted above, while I appreciate the elegance of using a string = (handle) to reference a previously provided object, it complicates how to u= pdate an existing object while providing the reference.

    In your example of the "key" object below, setting "pr= oof" to bearer would avoid the issue you describe:

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0&quo= t;proof": "bearer"
    =C2=A0 =C2=A0 }
    }
    <= br>
    In your example, when processing the "key" object, = code is having to check both the JSON type of the property, as well as chec= k the value of the "proof" property. In the example I provided, o= nly the value of "proof" needs to be checked. The "proof&quo= t; property is acting as a type for the "key" object.
    <= br>
    Not being a Java programmer, I don't know how this would = work in a Java implementation, but node.js, the processing would need to be= done as above.

    On a related note, there was signi= ficant negative feedback on handles and polymorphism in the Hacker News art= icle=C2=A0https://news.ycombinator.com/item?id=3D24855750=C2=A0

    /Dick


    On Fri, Oct 23, = 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Mika,

    Thanks for br= inging this topic here =E2=80=94 I was able to see the forum discussion tha= t brought you here, and hopefully I can help clear up what I mean with how = polymorphism is used in the proposal. The short version is that the goal is= to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecure protoc= ols, and so in that goal we=E2=80=99re fully aligned. I think that using po= lymorphism in very specific ways can help that goal =E2=80=94 just as I agr= ee that misusing it or applying it sloppily can lead to ambiguous and insec= ure systems.

    Some background: I built out the XYZ = protocol (one of the predecessors to the initial GNAP Draft) in Java using = strongly typed parsers and Java objects specifically to prove to myself tha= t it could be done in a way that made any sense in the code. (My own open s= ource implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but no= te that it=E2=80=99s not yet up to date with the GNAP spec). It was importa= nt to me that I be able to use the system-wide configured parsers to implem= ent this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the right p= laces (especially with the Jackson parser that I used), but it is definitel= y possible to create a deterministic and strongly-typed parser and serializ= er for this kind of data structure. Some of the rationale for using polymor= phism is covered in the trailing appendix of the draft document (https://www.ietf.org/archive= /id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polymor<= /a>), but it=E2=80=99s still good to discuss this here as the working group= decides which approaches to take.=C2=A0

    The drivi= ng reason for using polymorphism at the protocol level was to simplify the = protocol and make it :more: deterministic to create and process, not less. = Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fie= lds, which is prone to failure and requires additional error checking. Take= for example the key binding of access tokens. An access token could be bou= nd to the RC=E2=80=99s key used during the request, to a different key chos= en by the AS, or it could be a bearer token with no key at all. By making t= he =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in terms of bo= olean values and objects and express this set of mutually-exclusive options= in a non-ambiguous way. Without that, you=E2=80=99d need to have different= fields for the options and include additional checks in your parser to mak= e sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with this potential security vulnerability in an object:

    {=C2=A0
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 = =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key = value =E2=80=A6 }
    =C2=A0 =C2=A0 }
    }

    // bearer token

    {
    =C2=A0 =C2=A0 ke= y: false
    }

    // bound to the RC=E2= =80=99s presented key

    {
    =C2=A0 =C2=A0 ke= y: true
    }

    If someone sends a different t= ype for this field, like an array or number or a null, this doesn=E2=80=99t= have a defined interpretation in the protocol and would be a protocol leve= l error.

    While it might sound like polymorphism me= ans that any field could have any type or value, the opposite is true: each= possible value is explicitly typed, it=E2=80=99s just that there are poten= tially different types that express meaning for the field. This applies to = all members of all objects (dictionaries) as well as all members of an arra= y (list). Every time you process a field value or other element, you look a= t the type and then the value to determine what to do with that typed value= .

    In your example below, each field within the dic= tionary would also need to be typed, and each type would need to have a cle= ar indication of its meaning. To take your strawman key format below, the = =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as either = a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2= =80=9D (a JSON string). The definition would further say what exactly the e= ncoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the = value was or how it was represented, regardless of the input format. Seeing= a number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both of t= hem are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that de= termines the type. An implementation would likely use an internal BigIntege= r type of object to represent the field value after parsing, so the questio= n is how to go from the JSON value (which is typed) into the BigInteger val= ue.You don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key= =E2=80=9D field, you apply it to all sub-fields of that object.=C2=A0
    =

    So let=E2=80=99s dig into the specific bug you bring up= in the strawman, because it=E2=80=99s interesting: A JSON encoder that enc= odes numbers as strings, and not numbers, is not compliant with the JSON de= finitions of the field in question. For another example, the quoted string = value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true= in JSON, and they shouldn=E2=80=99t be treated the same by a parser implem= entation when mapping to a concrete object. It=E2=80=99s in this kind of au= tomated guessing that this class of bugs occur, and that=E2=80=99s going to= be the case whether or not you take =C2=A0advantage of JSON=E2=80=99s poly= morphic nature. I=E2=80=99ve run into cases where a parser library was tryi= ng to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up introducing errors in more strict components downstream. This is= something that protocol designers need to be aware of and guard against in= the design of the protocol to reduce possible ambiguities. Within GNAP tod= ay, we generally have things that branch whether they=E2=80=99re an object = (for a rich description of something) or some non-structured special value = (for a reference or other item).=C2=A0

    The design = team created some simple JSON Schemas for parts of the protocol during our = discussion, but we didn=E2=80=99t include them in the design document due t= o both lack of time to keep it updated with the rapid changes to the protoc= ol during the design team discussion, and not knowing if there would be int= erest in such material. I personally think it would be helpful to include a= s an informative reference in the final document, but that=E2=80=99s someth= ing for the working group to take up eventually.

    = =C2=A0=E2=80=94 Justin


    Hel= lo, everyone.

    For background: GNAP/TxAuth/XYZ/Oaut= h3 came up on a discussion forum and when I made note about certain concern= s, I was requested to send my comments to this working group.

    In short, I believe that the use of polymorphic JSON in the= protocol invites subtle and confusing implementation problems. I also sear= ched through the WG archives, and noticed that similar concerns were noted,= briefly, in a thread in July.

    The problem wi= th polymorphic values, as I see it, is that implementations will need to br= anch on the (inferred) type of a given field. This isn't quite as bad i= f the types are strictly different, but allows for subtle bugs when the val= ue in question is a dictionary. What makes this unappealing is that "s= ubtle bugs" in security protocols have a habit of turning into vulnera= bilities.

    Let's say we have these imaginary pa= yloads, both possible and valid in the same protocol step:

    # payload 1
    {
    =C2=A0 ...,
    =C2=A0 &qu= ot;public_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "= rsa",
    =C2=A0=C2=A0=C2=A0 "modulus": <BIGINT= >
    =C2=A0 }
    }

    # payload 2
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {<= /div>
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    = =C2=A0=C2=A0=C2=A0 "modulus": "<encoded string>"<= /div>
    =C2=A0 }
    }

    In both cases, the = type of "public_key" field is a dictionary. In both cases, they e= ven have the same keys. However, the values in the dictionaries are entirel= y different, and an implementation will have to branch to at least two poss= ible decoding mechanisms. To make things worse, some JSON implementations m= ay choose to encode non-dictionary values as strings, so it is possible for= an originator to transmit what they expect and believe to be payload 1 for= mat, but which the receiver will interpret to be in payload 2 format. And i= f the encoded string contains only digits, it will even parse correctly as = a bignum.

    While the above is clearly a manufac= tured scenario, it nonetheless demonstrates the potential for logic bugs wi= th polymorphic JSON. With richer types and more complex dictionaries, there= will surely be more room for errors.

    Ambiguity in= protocols is always a source of implementation complexity and interoperabi= lity snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying= . If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in e= veryone's interest to keep implementation complexity and mistake potent= ial to a minimum?

    Best regards,
    Mika=

    --
    Mika Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    3D""= =E1=90=A7


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    --000000000000ca34ad05b2722b2d-- From nobody Sat Oct 24 15:40:17 2020 Return-Path: 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 432433A0A29 for ; Sat, 24 Oct 2020 15:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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=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 it_48E1-_FEV for ; Sat, 24 Oct 2020 15:40:10 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 A92243A09EE for ; Sat, 24 Oct 2020 15:40:10 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id n5so4794474ile.7 for ; Sat, 24 Oct 2020 15:40:10 -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=3ZpFp1/X0Abxfrp556dqbrRda2obxBITnuPYtRWUcIc=; b=Ar8803CgupXjTD3lVjirlex/T+qCZjHCe4/sQ0bT7+VgWpsgHDRw9ZgRIZOQX3PQqG v5k9EBOuAZDxiolmAAQ8yKR2w4Rp8l70pPXJu1FKufdgyUpZaLF+0ep8soPZge3Zeyhv mNoy45LarbIp1rbk5aVWivwPFktrLzwonnXUREb3zk5hPYTbZCbAiWj14sdsVfu34HzL ICT34sbRs/cs8GY5lj2RjY4gw+jy2oT85z5eChHdnpjODFtD7uwCctBjpYmtXRSA9WRv i6EsiB/qzP14/i/q0YCh7sFgmMFflRvX3vZGrHsFEo+bDPt1vKKejavhCoQaE8C/ttMo fZyQ== 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=3ZpFp1/X0Abxfrp556dqbrRda2obxBITnuPYtRWUcIc=; b=TTx1FLa6jGFSBIgj3QsCTAjzmghZ5aBhkmbyx4HZrMWUmOJydQ90EnoImnN0khXTIv SIrX04kwBsv89QzgHAWey+G8fv5fJLUcwaOfuxpm7e325t14bJ3V68+1zsnctNtsWpt/ ksJftW34MJ+mCvVntFMsOurMk0CY8pqh0TkoZjul19780/KMsFsRhYWkbvSq+xpVx627 a8pqcCF8TY0lluNhN6fnj31HkKRDlN3GBXHJi0IpnJuRlGRVhSUtY9jJUZ2zA+KACcyp dOMRRO8NLE2fenkFuVrdCvHWrRP+pUp5LBNg1hhsoCj4khqBoJK1wcj3Ukku2m8sPrZz KlzQ== X-Gm-Message-State: AOAM533/+q+B0jv3wuvQ44CW3smqTt1j+KwfxrMUmJ6Om3/2jgNPyDRw I9rLLc1mlfMwn23yuzdQuQygK60bWrxtjaySGeM= X-Google-Smtp-Source: ABdhPJxADX5hKw5K+Rcaz6FYRmEI0rXYokfRbEKTCKUfdTm3ygtW3o3iGUKOYwPKDxOJobrLyYwXPHLXn78zdtIdONM= X-Received: by 2002:a92:9106:: with SMTP id t6mr6508356ild.178.1603579209771; Sat, 24 Oct 2020 15:40:09 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sun, 25 Oct 2020 00:39:57 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000002af25905b272613c" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 22:40:16 -0000 --0000000000002af25905b272613c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm just realizing your "least to most important" might actually say the same as what I was trying to say. So I'm not even sure what we're arguing against :-) In brief my point if it wasn't clear is that we should be crystal clear on where we put the cursor of simplicity, because this can mean different things for different people and different roles. And as we see on HN we need to better explain our design choices. Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a =C3=A9crit : > Hi Dick, > > Independantly from the debate on polyphormism, I beg to differ on your > order preference. > > Your assumption is that AS devs matter the most, because they're doing > the important security implementation. But eating our own dogfood might > help a lot to change that view. Most security issues occur because users = of > the spec are unable to deal with the complexity that is passed onto them. > > 99% of the people that will actually use the output of the work are > application developers (client or RS) and their own users. > > Our intent as well as the protocol drive the usage. Client libraries may > help, but they're not a silver bullet, especially because GNAP ultimately > has no control about what people do there (for better or worse). And > everything we do here will help get to the better part. > > I'm not saying we don't intend to also care about AS developers (beginnin= g > with ourselves) but it's a second order optimisation. And since it's a > tendancy we're leaning towards by default, I'm pretty sure we won't forge= t > that anyway. > > Fabien > > > > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : > >> I'm confused by your logic Fabien. >> >> If a client library developer wants to expose polymorphism, they can do >> that independent of what is in the protocol. >> >> I differ on who our stakeholders are. >> >> I think our stakeholders are in least to most important: >> >> >> - AS developer >> - RS developer >> - client developer >> - user >> >> >> A client library developer can expose whatever interface they want to >> simplify implementation. >> >> I list the user so that we don't lose site of a critical role. >> >> /Dick >> >> >> =E1=90=A7 >> >> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >> wrote: >> >>> Hi there, >>> >>> Let me try to approach the issue under a different light. More like a >>> product manager would deal with feature selection to make it intuitive = for >>> its users. >>> >>> For most people, riding a bike is far easier than using a unicycle. >>> Feels more stable. And yet it's way easier to design for a single wheel >>> than to build with 2. Because then you'll need a lot more accessories >>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be = a >>> brittle process, it can be industrialized. >>> >>> Back to the GNAP topic. >>> Ultimately we should strive to make the spec as simple as can be. But w= e >>> need to ask: simple for whom? For the bike owner or for the bike vendor= ? >>> (short answer: the priority should be simplicity for spec users, not >>> spec implementers and even less spec designers). >>> >>> The initial question that is asked is very interesting: isn't the desig= n >>> flawed if GNAP is using json polyphormism? Or if the AS needs to handle= the >>> state of the request? Or if we must handle token revocation? Or if we a= re >>> looking for a global unique identifier? The argument stems of the fact = that >>> is still arguably harder and more error prone to implement. Fair enough= . >>> >>> From a spec implementer's perspective, it may well be more complex. It >>> mostly impacts the json library you'll end up using, plus a bit of >>> input/output decoration around it. Even golang provides utilities for t= his, >>> despite not exactly being made for this kind of purpose. >>> My practical experience implementing it is that it's not that big a >>> deal. I mean, I wished it could be simpler, but it's manageable and the= re >>> are other ways to reach levels of insurance that it does work as intend= ed >>> (json schema, test cases to validate the implementation, etc.). Arguabl= y it >>> is still easier from an implementation perspective than say, json-ld, w= hich >>> is massively used in the SSI community. >>> >>> But ultimately who are we designing for? Are we striving to go easy on >>> the spec implementer? Or are we trying to make sure end-developers usin= g >>> the client libraries won't shoot themselves in the foot? >>> >>> The job to be done (JTBD), from the end-developer's perspective, is to >>> efficiently ship an application. And provide authN/authZ capabilities f= or >>> end-users by relying on some well known implementation. >>> In turn, this spec implementer will rely on cryptographic utility >>> libraries that deals internally with the complexity of their own domain= , so >>> that we don't have to. And here we could launch another HN flame war th= at >>> starts with the title "JWT sucks because". Which does have its set of v= ery >>> real issues but that's beyond the point. >>> Note that any decent flamewar will be efficiently fueled by people >>> hating medium. Is it outrageous for blog posts to be behind a paywall? >>> Maybe but it's even more outrageous to lack consistency, either by not >>> knowing how to get around a paywall if you're into a hacker punk moveme= nt, >>> or on the contrary by to not paying a subscription if you believe that >>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated. >>> What likely seems an unnecessary sidenote tries to illustrate the point= : >>> for Justin it was easier to publish on medium, because as a blog publis= her, >>> you might not want to deal with hosting your own blog. But maybe as a >>> reader you'll find that annoying. Different audiences, different JTBD, >>> different tradeoffs. >>> >>> Polyphormism is a tool that enables the end-developer to have minimal >>> knowledge of what it means to deal with a GNAP client library. You prep= are >>> the request, send to the endpoint and you're good to go. Massively simp= ler >>> than OAuth2 or any similar protocol by the way (as anyone with teaching >>> experience on the subject might acknowledge). And there's a lot more t= o be >>> done to make sure we indeed reduce the complexity for the end-developer= and >>> the end-user. >>> >>> If we find a better way to deal with that simplicity balance, I'm all >>> in. But the arguments need to be way more convincing than just saying t= hat >>> it may be difficult to implement or validate. >>> >>> Cheers. >>> Fabien >>> >>> >>> >>> >>> >>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a = =C3=A9crit : >>> >>>> >>>> >>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>>> >>>> Justin >>>> >>>> I did note that I was the one that argued for instance_id being in the >>>> object. Since it is in the object in the current draft, not including = a >>>> pass by reference option would be preferable. >>>> >>>> As for concrete examples: >>>> - version of client >>>> - version of OS >>>> - security attestation of OS / device >>>> - location of client device >>>> - network client is operating on >>>> >>>> These are all attributes of the client that an AS may require on the >>>> initial grant request, and in future grant requests (which is when an >>>> instance_id) would be used. >>>> >>>> >>>> This is where our interpretations differ: I don=E2=80=99t see these as >>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the ke= y, display >>>> information, class identifiers, and other items currently represented = by an >>>> instance_id are attributes of the client instance. The attestation >>>> components don=E2=80=99t modify the instance so much as present additi= onal >>>> information on top of the client instance itself. This is why I argue = that >>>> they ought to be handled in a separate object, so you=E2=80=99d have s= omething like >>>> this strawman: >>>> >>>> { >>>> >>>> posture: { >>>> software_version: 1.2.3, >>>> os_version: 14.3.2 >>>> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>> }, >>>> >>>> client: =E2=80=9Cclient-541-ab" >>>> >>>> } >>>> >>>> This is a more fundamental question about GNAP than whether the syntax >>>> uses polymorphism: this is about GNAP being very explicit about the da= ta >>>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mo= del of what >>>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply = problematic in >>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with ha= ving to >>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doe= sn=E2=80=99t fully capture >>>> the different aspects that are out there. I think we=E2=80=99re gettin= g closer here >>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D,= but we still need to >>>> be more precise about what exactly a client instance includes, and wha= t it >>>> does not. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> /Dick >>>> >>>> =E1=90=A7 >>>> >>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote= : >>>> >>>>> Dick, >>>>> >>>>> As you=E2=80=99ll recall, I argued against including the client insta= nce >>>>> identifier inside of the object as a mutually-exclusive field precise= ly >>>>> because of the principle violation that you are pointing out here, an= d so >>>>> it=E2=80=99s important to point out that the current text is a compro= mise that >>>>> needs to be examined in the wider experience of the working group. I = am on >>>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2= =80=9D option within an >>>>> object, but this needs to be explored. >>>>> >>>>> The crux of my argument is that is exactly a case of pass-by-referenc= e >>>>> vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient >>>>> instance=E2=80=9D value itself but rather belong outside of that obje= ct in a >>>>> another part of the request. As stated in the editorial notes in this >>>>> section, we need to look carefully at how these concepts fit within t= he >>>>> model and where we would want to put them. Without concrete examples = of >>>>> what these extensions look like and how they=E2=80=99re generated, th= at is nearly >>>>> impossible to do at this stage. I look forward to seeing examples of = this >>>>> kind of data and how it can fit into the protocol. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>>>> >>>>> Hey Justin, >>>>> >>>>> As the draft has evolved, I question the continued use of >>>>> polymorphism. Note that I appreciate the elegance of using a string f= or >>>>> pass-by-reference, and an object for pass-by-value. >>>>> >>>>> In the current draft, the >>>>> >>>>> Every time you create or process a field it will mean only one thing, >>>>> and there=E2=80=99s only one field to look at to answer a question. >>>>> >>>>> >>>>> is violated in 2.3.1. Identifying the RC Instance >>>>> >>>>> >>>>> >>>>> instance_id An identifier string that the AS can use to identify >>>>> the >>>>> particular instance of this RC. The content and structure of >>>>> this >>>>> identifier is opaque to the RC. >>>>> >>>>> "client": { >>>>> "instance_id": "client-541-ab" >>>>> } >>>>> >>>>> If there are no additional fields to send, the RC MAY send the >>>>> instance identifier as a direct reference value in lieu of the >>>>> object. >>>>> >>>>> "client": "client-541-ab" >>>>> >>>>> >>>>> The instance identifier can be sent two ways. Polymorphism is a >>>>> convenience for the client, but requires the server to have two code = paths >>>>> for "instance_id". We discussed this in the design team, and I argue= d for >>>>> having "instance_id" in the "client" object so that any updates, such= as >>>>> new devices assertions, could be in the "client" object. As noted abo= ve, >>>>> while I appreciate the elegance of using a string (handle) to referen= ce a >>>>> previously provided object, it complicates how to update an existing = object >>>>> while providing the reference. >>>>> >>>>> In your example of the "key" object below, setting "proof" to bearer >>>>> would avoid the issue you describe: >>>>> >>>>> { >>>>> "key": { >>>>> "proof": "bearer" >>>>> } >>>>> } >>>>> >>>>> In your example, when processing the "key" object, code is having to >>>>> check both the JSON type of the property, as well as check the value = of the >>>>> "proof" property. In the example I provided, only the value of "proof= " >>>>> needs to be checked. The "proof" property is acting as a type for the= "key" >>>>> object. >>>>> >>>>> Not being a Java programmer, I don't know how this would work in a >>>>> Java implementation, but node.js, the processing would need to be don= e as >>>>> above. >>>>> >>>>> On a related note, there was significant negative feedback on handles >>>>> and polymorphism in the Hacker News article >>>>> https://news.ycombinator.com/item?id=3D24855750 >>>>> >>>>> /Dick >>>>> >>>>> >>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer >>>>> wrote: >>>>> >>>>>> Hi Mika, >>>>>> >>>>>> Thanks for bringing this topic here =E2=80=94 I was able to see the = forum >>>>>> discussion that brought you here, and hopefully I can help clear up = what I >>>>>> mean with how polymorphism is used in the proposal. The short versio= n is >>>>>> that the goal is to *avoid* the kinds of ambiguity that make >>>>>> insecure protocols, and so in that goal we=E2=80=99re fully aligned.= I think that >>>>>> using polymorphism in very specific ways can help that goal =E2=80= =94 just as I >>>>>> agree that misusing it or applying it sloppily can lead to ambiguous= and >>>>>> insecure systems. >>>>>> >>>>>> Some background: I built out the XYZ protocol (one of the >>>>>> predecessors to the initial GNAP Draft) in Java using strongly typed >>>>>> parsers and Java objects specifically to prove to myself that it cou= ld be >>>>>> done in a way that made any sense in the code. (My own open source >>>>>> implementation is at https://github.com/bspk/oauth.xyz-java, but >>>>>> note that it=E2=80=99s not yet up to date with the GNAP spec). It wa= s important to >>>>>> me that I be able to use the system-wide configured parsers to imple= ment >>>>>> this and not have to resort to stepping through elements completely = by >>>>>> hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places >>>>>> (especially with the Jackson parser that I used), but it is definite= ly >>>>>> possible to create a deterministic and strongly-typed parser and ser= ializer >>>>>> for this kind of data structure. Some of the rationale for using >>>>>> polymorphism is covered in the trailing appendix of the draft docume= nt ( >>>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.htm= l#name-json-structures-and-polymor), >>>>>> but it=E2=80=99s still good to discuss this here as the working grou= p decides which >>>>>> approaches to take. >>>>>> >>>>>> The driving reason for using polymorphism at the protocol level was >>>>>> to simplify the protocol and make it :more: deterministic to create = and >>>>>> process, not less. Every time you create or process a field it will = mean >>>>>> only one thing, and there=E2=80=99s only one field to look at to ans= wer a question. >>>>>> Without polymorphic field values, you usually need to rely on mutual >>>>>> exclusivity of fields, which is prone to failure and requires additi= onal >>>>>> error checking. Take for example the key binding of access tokens. A= n >>>>>> access token could be bound to the RC=E2=80=99s key used during the = request, to a >>>>>> different key chosen by the AS, or it could be a bearer token with n= o key >>>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we ca= n define it in terms of >>>>>> boolean values and objects and express this set of mutually-exclusiv= e >>>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need to = have different >>>>>> fields for the options and include additional checks in your parser = to make >>>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could g= et hit with >>>>>> this potential security vulnerability in an object: >>>>>> >>>>>> { >>>>>> key: { >>>>>> proof: httpsig, >>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>> }, >>>>>> bearer_token: true, >>>>>> bind_to_rc_key: true >>>>>> } >>>>>> >>>>>> This would be an illegal object as per this alternate proposal, but >>>>>> then you=E2=80=99d have to check each field and make sure it wasn=E2= =80=99t put next to >>>>>> others in the same object. I=E2=80=99ve done this exercise with many= other >>>>>> protocols and it=E2=80=99s both error prone and easy to ignore since= all the =E2=80=9Cgood=E2=80=9D >>>>>> examples would pass code that doesn=E2=80=99t check this. With the p= olymorphic >>>>>> approach to this same field, each of these three mutually-exclusive = states >>>>>> is written in a way that they cannot be sent together. It=E2=80=99s = not just >>>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSON = itself. >>>>>> >>>>>> { >>>>>> key: { >>>>>> proof: httpsig, >>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>> } >>>>>> } >>>>>> >>>>>> // bearer token >>>>>> >>>>>> { >>>>>> key: false >>>>>> } >>>>>> >>>>>> // bound to the RC=E2=80=99s presented key >>>>>> >>>>>> { >>>>>> key: true >>>>>> } >>>>>> >>>>>> If someone sends a different type for this field, like an array or >>>>>> number or a null, this doesn=E2=80=99t have a defined interpretation= in the >>>>>> protocol and would be a protocol level error. >>>>>> >>>>>> While it might sound like polymorphism means that any field could >>>>>> have any type or value, the opposite is true: each possible value is >>>>>> explicitly typed, it=E2=80=99s just that there are potentially diffe= rent types that >>>>>> express meaning for the field. This applies to all members of all ob= jects >>>>>> (dictionaries) as well as all members of an array (list). Every time= you >>>>>> process a field value or other element, you look at the type and the= n the >>>>>> value to determine what to do with that typed value. >>>>>> >>>>>> In your example below, each field within the dictionary would also >>>>>> need to be typed, and each type would need to have a clear indicatio= n of >>>>>> its meaning. To take your strawman key format below, the =E2=80=9Cmo= dulus=E2=80=9D field >>>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an >>>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition wou= ld further say what >>>>>> exactly the encoding of the string would be. That means that when yo= u read >>>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any co= nfusion on what the value was >>>>>> or how it was represented, regardless of the input format. Seeing a = number >>>>>> there means exactly one interpretation and seeing a string means exa= ctly >>>>>> one (different) interpretation =E2=80=94 but importantly, both of th= em are a >>>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that deter= mines the type. An >>>>>> implementation would likely use an internal BigInteger type of objec= t to >>>>>> represent the field value after parsing, so the question is how to g= o from >>>>>> the JSON value (which is typed) into the BigInteger value.You don=E2= =80=99t just >>>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you = apply it to all >>>>>> sub-fields of that object. >>>>>> >>>>>> So let=E2=80=99s dig into the specific bug you bring up in the straw= man, >>>>>> because it=E2=80=99s interesting: A JSON encoder that encodes number= s as strings, >>>>>> and not numbers, is not compliant with the JSON definitions of the f= ield in >>>>>> question. For another example, the quoted string value of =E2=80=9Ct= rue=E2=80=9D is not >>>>>> equivalent to the boolean value true in JSON, and they shouldn=E2=80= =99t be treated >>>>>> the same by a parser implementation when mapping to a concrete objec= t. It=E2=80=99s >>>>>> in this kind of automated guessing that this class of bugs occur, an= d >>>>>> that=E2=80=99s going to be the case whether or not you take advanta= ge of JSON=E2=80=99s >>>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser libra= ry was trying >>>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping= , but ended up >>>>>> introducing errors in more strict components downstream. This is som= ething >>>>>> that protocol designers need to be aware of and guard against in the= design >>>>>> of the protocol to reduce possible ambiguities. Within GNAP today, w= e >>>>>> generally have things that branch whether they=E2=80=99re an object = (for a rich >>>>>> description of something) or some non-structured special value (for = a >>>>>> reference or other item). >>>>>> >>>>>> The design team created some simple JSON Schemas for parts of the >>>>>> protocol during our discussion, but we didn=E2=80=99t include them i= n the design >>>>>> document due to both lack of time to keep it updated with the rapid = changes >>>>>> to the protocol during the design team discussion, and not knowing i= f there >>>>>> would be interest in such material. I personally think it would be h= elpful >>>>>> to include as an informative reference in the final document, but th= at=E2=80=99s >>>>>> something for the working group to take up eventually. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Hello, everyone. >>>>>> >>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum >>>>>> and when I made note about certain concerns, I was requested to send= my >>>>>> comments to this working group. >>>>>> >>>>>> In short, I believe that the use of polymorphic JSON in the protocol >>>>>> invites subtle and confusing implementation problems. I also searche= d >>>>>> through the WG archives, and noticed that similar concerns were note= d, >>>>>> briefly, in a thread in July. >>>>>> >>>>>> The problem with polymorphic values, as I see it, is that >>>>>> implementations will need to branch on the (inferred) type of a give= n >>>>>> field. This isn't quite as bad if the types are strictly different, = but >>>>>> allows for subtle bugs when the value in question is a dictionary. W= hat >>>>>> makes this unappealing is that "subtle bugs" in security protocols h= ave a >>>>>> habit of turning into vulnerabilities. >>>>>> >>>>>> Let's say we have these imaginary payloads, both possible and valid >>>>>> in the same protocol step: >>>>>> >>>>>> # payload 1 >>>>>> { >>>>>> ..., >>>>>> "public_key": { >>>>>> "alg": "rsa", >>>>>> "modulus": >>>>>> } >>>>>> } >>>>>> >>>>>> # payload 2 >>>>>> { >>>>>> ..., >>>>>> "public_key": { >>>>>> "alg": "rsa", >>>>>> "modulus": "" >>>>>> } >>>>>> } >>>>>> >>>>>> In both cases, the type of "public_key" field is a dictionary. In >>>>>> both cases, they even have the same keys. However, the values in the >>>>>> dictionaries are entirely different, and an implementation will have= to >>>>>> branch to at least two possible decoding mechanisms. To make things = worse, >>>>>> some JSON implementations may choose to encode non-dictionary values= as >>>>>> strings, so it is possible for an originator to transmit what they e= xpect >>>>>> and believe to be payload 1 format, but which the receiver will inte= rpret >>>>>> to be in payload 2 format. And if the encoded string contains only d= igits, >>>>>> it will even parse correctly as a bignum. >>>>>> >>>>>> While the above is clearly a manufactured scenario, it nonetheless >>>>>> demonstrates the potential for logic bugs with polymorphic JSON. Wit= h >>>>>> richer types and more complex dictionaries, there will surely be mor= e room >>>>>> for errors. >>>>>> >>>>>> Ambiguity in protocols is always a source of implementation >>>>>> complexity and interoperability snags, but in an AuthN/AuthZ protoco= l it is >>>>>> worse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oaut= h1/2, >>>>>> wouldn't it be in everyone's interest to keep implementation complex= ity and >>>>>> mistake potential to a minimum? >>>>>> >>>>>> Best regards, >>>>>> Mika >>>>>> >>>>>> -- >>>>>> Mika Bostr=C3=B6m >>>>>> Smarkets >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> =E1=90=A7 >>>>> >>>>> >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --0000000000002af25905b272613c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm just realizing your "least to most important= " might actually say the same as what I was trying to say. So I'm = not even sure what we're arguing against :-)=C2=A0
    In brief my point if it wasn't clear is that w= e should be crystal clear on where we put the cursor of simplicity, because= this can mean different things for different people and different roles.= =C2=A0
    And as we see on HN we need to better explain= our design choices.=C2=A0


    Le dim. 25 oct.= 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Dick,

    <= /div>
    Independantly from the debate on polyphormism, I beg= to differ on your order preference.=C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're doing the importan= t security implementation. But eating our own dogfood might help a lot to c= hange that view. Most security issues occur because users of the spec are u= nable to deal with the complexity that is passed onto them.=C2=A0

    99% of the people that wil= l actually use the output of the work are application developers (client or= RS) and their own users.=C2=A0

    Our intent as well as the = protocol drive the usage. Client libraries may help, but they're not a = silver bullet, especially because GNAP ultimately has no control about what= people do there (for better or worse). And everything we do here will help= get to the better part.=C2=A0

    I'm not saying we don't intend to also care about AS = developers (beginning with ourselves) but it's a second order optimisat= ion. And since it's a tendancy we're leaning towards by default, I&= #39;m pretty sure we won't forget that anyway.=C2=A0

    Fabien=C2=A0



    Le = sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com&g= t; a =C3=A9crit=C2=A0:
    I'm confused by your logic Fabien.

    If a client = library developer wants to expose polymorphism, they can do that independen= t of what is in the protocol.=C2=A0

    I differ on wh= o our stakeholders are.=C2=A0

    I think our stakehol= ders are in least to most important:

    • AS de= veloper
    • RS developer
    • client developer
    • user

    A client library developer can expose whatever i= nterface they want to simplify implementation.

    I l= ist the user so that we don't lose site of a critical role.
    <= br>
    /Dick


    3D""=E1= =90=A7

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi there,= =C2=A0

    Let me try to approach the issue un= der a different light. More like a product manager would deal with feature = selection to make it intuitive for its users.=C2=A0

    For most people, riding a bike is f= ar easier than using a unicycle. Feels more stable. And yet it's way ea= sier to design for a single wheel than to build with 2. Because then you= 9;ll need a lot more accessories (chain, chain ring, etc.). Even so produci= ng a bike doesn't have to be a brittle process, it can be industrialize= d.=C2=A0

    Back to the GNA= P topic.=C2=A0
    = Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=C2= =A0
    (short answer: the priority should be simplicity for spec users, not spec= implementers and even less spec designers).=C2=A0

    The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to han= dle the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the fa= ct that is still arguably harder and more error prone to implement. Fair en= ough.=C2=A0

    From a spec = implementer's perspective, it may well be more complex. It mostly impac= ts the json library you'll end up using, plus a bit of input/output dec= oration around it. Even golang provides utilities for this, despite not exa= ctly being made for this kind of purpose.
    My practic= al experience implementing it is that it's not that big a deal. I mean,= I wished it could be simpler, but it's manageable and there are other = ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still e= asier from an implementation perspective than say, json-ld, which is massiv= ely used in the SSI community.=C2=A0

    But ultimately who are we designing for? Are we striving to go= easy on the spec implementer? Or are we trying to make sure end-developers= using the client libraries won't shoot themselves in the foot?

    The job to be done (JTBD), from= the end-developer's perspective, is to efficiently ship an application= . And provide authN/authZ capabilities for end-users by relying on some wel= l known implementation.=C2=A0
    In turn, this spec imp= lementer will rely on cryptographic utility libraries that deals internally= with the complexity of their own domain, so that we don't have to. And= here we could launch another HN flame war that starts with the title "= ;JWT sucks because". Which does have its set of very real issues but t= hat's beyond the point.=C2=A0
    Note that any dece= nt flamewar will be efficiently fueled by people hating medium. Is it outra= geous for blog posts to be behind a paywall? Maybe but it's even more o= utrageous to lack consistency, either by not knowing how to get around a pa= ywall if you're into a hacker punk movement, or on the contrary by to n= ot paying a subscription if you believe that surveillance capitalism, to re= use Zuboff's terms, should be eradicated.=C2=A0
    = What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, y= ou might not want to deal with hosting your own blog. But maybe as a reader= you'll find that annoying. Different audiences, different JTBD, differ= ent tradeoffs.=C2=A0

    Pol= yphormism is a tool that enables the end-developer to have minimal knowledg= e of what it means to deal with a GNAP client library. You prepare the requ= est, send to the endpoint and you're good to go. Massively simpler than= OAuth2 or any similar protocol by the way (as anyone with teaching experie= nce on the subject might acknowledge). And=C2=A0 there's a lot more to = be done to make sure we indeed reduce the complexity for the end-developer = and the end-user.=C2=A0

    = If we find a better way to deal with that simplicity balance, I'm all i= n. But the arguments need to be way more convincing than just saying that i= t may be difficult to implement or validate.=C2=A0
    <= br>
    Cheers.
    Fabien





    Le ven. 23 oct. 2020 =C3=A0 22:= 35, Justin Richer <j= richer@mit.edu> a =C3=A9crit=C2=A0:


    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Justin

    I did note that I w= as the one that argued for instance_id being in the object. Since it is in = the object in the current draft, not including a pass by reference option w= ould be preferable.=C2=A0

    As for concrete examples= :
    - version of client
    - version of OS
    - secur= ity attestation of OS / device
    - location of client device
    <= div>- network client is operating on

    These are all= attributes of the client that an AS may require=C2=A0on the initial grant = request, and in future grant requests (which is when an instance_id) would = be used.


    T= his is where our interpretations differ: I don=E2=80=99t see these as =E2= =80=9Cattributes of the client=E2=80=9D in the same way that the key, displ= ay information, class identifiers, and other items currently represented by= an instance_id are attributes of the client instance. The attestation comp= onents don=E2=80=99t modify the instance so much as present additional info= rmation on top of the client instance itself. This is why I argue that they= ought to be handled in a separate object, so you=E2=80=99d have something = like this strawman:

    {

    =C2= =A0 posture: {
    =C2=A0 =C2=A0 software_version: 1.2.3,
    = =C2=A0 =C2=A0 os_version: 14.3.2
    =C2=A0 =C2=A0 device_attestation= : { =E2=80=A6 some structure or signed blob? =E2=80=A6 }
    =C2=A0 = =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
    =C2=A0 },

    =C2=A0 client: =E2=80=9Cclient-541-ab= "

    }

    This is a more f= undamental question about GNAP than whether the syntax uses polymorphism: t= his is about GNAP being very explicit about the data model of its elements.= OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80= =9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in pract= ice. We=E2=80=99re even seeing that in the OAuth 2.1 work with having to de= fine a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2= =80=99t fully capture the different aspects that are out there. I think we= =E2=80=99re getting closer here in GNAP with explicit definition of =E2=80= =9Cclient instance=E2=80=9D, but we still need to be more precise about wha= t exactly a client instance includes, and what it does not.

    <= /div>
    =C2=A0=E2=80=94 Justin


    /Dick

    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
    Dick,

    As you=E2=80=99ll recall, I argued against incl= uding the client instance identifier inside of the object as a mutually-exc= lusive field precisely because of the principle violation that you are poin= ting out here, and so it=E2=80=99s important to point out that the current = text is a compromise that needs to be examined in the wider experience of t= he working group. I am on the side of removing the mutually-exclusive =E2= =80=9Cinstance_id=E2=80=9D option within an object, but this needs to be ex= plored.

    The crux of my argument is that is exactly= a case of pass-by-reference vs pass-by-value, and that runtime attestation= s are not part of the =E2=80=9Cclient instance=E2=80=9D value itself but ra= ther belong outside of that object in a another part of the request. As sta= ted in the editorial notes in this section, we need to look carefully at ho= w these concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how they= =E2=80=99re generated, that is nearly impossible to do at this stage. I loo= k forward to seeing examples of this kind of data and how it can fit into t= he protocol.

    =C2=A0=E2=80=94 Justin


    Hey Justin,

    As the draft has evolved, I que= stion the continued use of polymorphism. Note that I appreciate the eleganc= e=C2=A0of using a string for pass-by-reference, and an object for pass-by-v= alue.

    In the current draft, the=C2=A0
    Every time you create or process a field it will mean only one thin= g, and there=E2=80=99s only one field to look at to answer a question.=C2= =A0



    =C2=A0 =C2=A0instance_id =C2=A0An identifier str= ing that the AS can use to identify the
    =C2=A0 =C2=A0 =C2=A0 part= icular instance of this RC.=C2=A0 The content and structure of this
    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.

    =C2=A0 =C2=A0"client": {
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0"instance_id": "client-541-ab"
    =C2=A0 =C2= =A0}

    =C2=A0 =C2=A0If there are no additional field= s to send, the RC MAY send the
    =C2=A0 =C2=A0instance identifier a= s a direct reference value in lieu of the
    =C2=A0 =C2=A0object.

    =C2=A0 =C2=A0"client": "client-541-ab= "

    The instance identifier can be= sent two ways. Polymorphism is a convenience for the client, but requires = the server=C2=A0to have two code=C2=A0paths for "instance_id".=C2= =A0 We discussed this in the design team, and I argued for having "ins= tance_id" in the "client" object=C2=A0so that any updates, s= uch as new devices assertions, could be in the "client" object. A= s noted above, while I appreciate the elegance of using a string (handle) t= o reference a previously provided object, it complicates how to update an e= xisting object while providing the reference.

    In y= our example of the "key" object below, setting "proof" = to bearer would avoid the issue you describe:

    {=C2= =A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"proof&qu= ot;: "bearer"
    =C2=A0 =C2=A0 }
    }

    <= div>In your example, when processing the "key" object, code is ha= ving to check both the JSON type of the property, as well as check the valu= e of the "proof" property. In the example I provided, only the va= lue of "proof" needs to be checked. The "proof" propert= y is acting as a type for the "key" object.

    <= div>Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done as a= bove.

    On a related note, there was significant neg= ative feedback on handles and polymorphism in the Hacker News article=C2=A0= https://news.ycombinator.com/item?id=3D24855750=C2=A0

    /Dick


    On Fri, Oct 23, 2= 020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:
    Hi Mika,

    Thank= s for bringing this topic here =E2=80=94 I was able to see the forum discus= sion that brought you here, and hopefully I can help clear up what I mean w= ith how polymorphism is used in the proposal. The short version is that the= goal is to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecur= e protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using polymorphism in very specific ways can help that goal =E2=80=94 just = as I agree that misusing it or applying it sloppily can lead to ambiguous a= nd insecure systems.

    Some background: I built out = the XYZ protocol (one of the predecessors to the initial GNAP Draft) in Jav= a using strongly typed parsers and Java objects specifically to prove to my= self that it could be done in a way that made any sense in the code. (My ow= n open source implementation is at=C2=A0https://github.com/bspk/oauth.x= yz-java, but note that it=E2=80=99s not yet up to date with the GNAP sp= ec). It was important to me that I be able to use the system-wide configure= d parsers to implement this and not have to resort to stepping through elem= ents completely by hand. Java doesn=E2=80=99t make it simple to get the hoo= ks into the right places (especially with the Jackson parser that I used), = but it is definitely possible to create a deterministic and strongly-typed = parser and serializer for this kind of data structure. Some of the rational= e for using polymorphism is covered in the trailing appendix of the draft d= ocument (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=C2=A0

    The driving reason for using polymorphism at the proto= col level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field it w= ill mean only one thing, and there=E2=80=99s only one field to look at to a= nswer a question. Without polymorphic field values, you usually need to rel= y on mutual exclusivity of fields, which is prone to failure and requires a= dditional error checking. Take for example the key binding of access tokens= . An access token could be bound to the RC=E2=80=99s key used during the re= quest, to a different key chosen by the AS, or it could be a bearer token w= ith no key at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, w= e can define it in terms of boolean values and objects and express this set= of mutually-exclusive options in a non-ambiguous way. Without that, you=E2= =80=99d need to have different fields for the options and include additiona= l checks in your parser to make sure they weren=E2=80=99t sent simultaneous= ly, otherwise you could get hit with this potential security vulnerability = in an object:

    {=C2=A0
    =C2=A0 =C2=A0 key:= {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 = =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 bearer_token: true,
    =C2=A0 =C2=A0 bind_to_r= c_key: true
    }

    This would be an illegal o= bject as per this alternate proposal, but then you=E2=80=99d have to check = each field and make sure it wasn=E2=80=99t put next to others in the same o= bject. I=E2=80=99ve done this exercise with many other protocols and it=E2= =80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2= =80=9D examples would pass code that doesn=E2=80=99t check this. With the p= olymorphic approach to this same field, each of these three mutually-exclus= ive states is written in a way that they cannot be sent together. It=E2=80= =99s not just illegal, it=E2=80=99s impossible and enforced by the syntax o= f JSON itself.

    {=C2=A0
    =C2=A0 =C2= =A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 = =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2= =A0 }
    }

    // bearer token

    {
    =C2=A0 =C2=A0 key: false
    }
    <= br>
    // bound to the RC=E2=80=99s presented key

    {
    =C2=A0 =C2=A0 key: true
    }

    =
    If someone sends a different type for this field, like an array or num= ber or a null, this doesn=E2=80=99t have a defined interpretation in the pr= otocol and would be a protocol level error.

    While = it might sound like polymorphism means that any field could have any type o= r value, the opposite is true: each possible value is explicitly typed, it= =E2=80=99s just that there are potentially different types that express mea= ning for the field. This applies to all members of all objects (dictionarie= s) as well as all members of an array (list). Every time you process a fiel= d value or other element, you look at the type and then the value to determ= ine what to do with that typed value.

    In your exam= ple below, each field within the dictionary would also need to be typed, an= d each type would need to have a clear indication of its meaning. To take y= our strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be= defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON numbe= r) or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition w= ould further say what exactly the encoding of the string would be. That mea= ns that when you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2= =80=99t be any confusion on what the value was or how it was represented, r= egardless of the input format. Seeing a number there means exactly one inte= rpretation and seeing a string means exactly one (different) interpretation= =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, s= ince that=E2=80=99s the field that determines the type. An implementation w= ould likely use an internal BigInteger type of object to represent the fiel= d value after parsing, so the question is how to go from the JSON value (wh= ich is typed) into the BigInteger value.You don=E2=80=99t just apply the ty= pe rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub= -fields of that object.=C2=A0

    So let=E2=80=99s dig= into the specific bug you bring up in the strawman, because it=E2=80=99s i= nteresting: A JSON encoder that encodes numbers as strings, and not numbers= , is not compliant with the JSON definitions of the field in question. For = another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not e= quivalent to the boolean value true in JSON, and they shouldn=E2=80=99t be = treated the same by a parser implementation when mapping to a concrete obje= ct. It=E2=80=99s in this kind of automated guessing that this class of bugs= occur, and that=E2=80=99s going to be the case whether or not you take =C2= =A0advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into ca= ses where a parser library was trying to be overly =E2=80=9Chelpful=E2=80= =9D in doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers nee= d to be aware of and guard against in the design of the protocol to reduce = possible ambiguities. Within GNAP today, we generally have things that bran= ch whether they=E2=80=99re an object (for a rich description of something) = or some non-structured special value (for a reference or other item).=C2=A0=

    The design team created some simple JSON Schemas = for parts of the protocol during our discussion, but we didn=E2=80=99t incl= ude them in the design document due to both lack of time to keep it updated= with the rapid changes to the protocol during the design team discussion, = and not knowing if there would be interest in such material. I personally t= hink it would be helpful to include as an informative reference in the fina= l document, but that=E2=80=99s something for the working group to take up e= ventually.

    =C2=A0=E2=80=94 Justin

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6= m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org&g= t; wrote:

    Hello, everyone.
    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion= forum and when I made note about certain concerns, I was requested to send= my comments to this working group.

    In short, = I believe that the use of polymorphic JSON in the protocol invites subtle a= nd confusing implementation problems. I also searched through the WG archiv= es, and noticed that similar concerns were noted, briefly, in a thread in J= uly.

    The problem with polymorphic values, as = I see it, is that implementations will need to branch on the (inferred) typ= e of a given field. This isn't quite as bad if the types are strictly d= ifferent, but allows for subtle bugs when the value in question is a dictio= nary. What makes this unappealing is that "subtle bugs" in securi= ty protocols have a habit of turning into vulnerabilities.

    Let's say we have these imaginary payloads, both possible and = valid in the same protocol step:

    # payload 1
    =
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    = =C2=A0=C2=A0=C2=A0 "modulus": <BIGINT>
    =C2=A0 }
    }

    # payload 2
    {
    =C2= =A0 ...,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0= =C2=A0 "alg": "rsa",
    =C2=A0=C2=A0=C2=A0 "= ;modulus": "<encoded string>"
    =C2=A0 }
    =
    }

    In both cases, the type of "public_key= " field is a dictionary. In both cases, they even have the same keys. = However, the values in the dictionaries are entirely different, and an impl= ementation will have to branch to at least two possible decoding mechanisms= . To make things worse, some JSON implementations may choose to encode non-= dictionary values as strings, so it is possible for an originator to transm= it what they expect and believe to be payload 1 format, but which the recei= ver will interpret to be in payload 2 format. And if the encoded string con= tains only digits, it will even parse correctly as a bignum.
    =
    While the above is clearly a manufactured scenario, it nonet= heless demonstrates the potential for logic bugs with polymorphic JSON. Wit= h richer types and more complex dictionaries, there will surely be more roo= m for errors.

    Ambiguity in protocols is always a s= ource of implementation complexity and interoperability snags, but in an Au= thN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is inte= nded to supersede Oauth1/2, wouldn't it be in everyone's interest t= o keep implementation complexity and mistake potential to a minimum?

    Best regards,
    Mika

    --
    <= div>Mika Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mai= lman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth
    3D""= =E1=90=A7


    --
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth
    --0000000000002af25905b272613c-- From nobody Sun Oct 25 03:17:50 2020 Return-Path: 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 AE5C23A1585 for ; Sun, 25 Oct 2020 03:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 xog_q04va30m for ; Sun, 25 Oct 2020 03:17:45 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 7D5463A1584 for ; Sun, 25 Oct 2020 03:17:44 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id bc23so6324984edb.5 for ; Sun, 25 Oct 2020 03:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=PBaTjDCw+Mnz1LCCEkar3AvN4MjgKv9Td6t2TRMQC9U=; b=Tjgn28ryu4G11b2FxEIC2pUJaUSMfudW9mb9uOSs6lsv3eGYpU4rdUpucvucgPT+6y 90rC8TZWQJ8LkTHIpj25RA3IpzFoimAw50obHaQf5+Bq5Cp1fjMTYdl2w8zJrBtHcfpx 05QqlDohGI9zye1d/9IaaIKhnR1vJENC0S8wGT7saGkrmz+8xhZNmcm/4cqyzeZHzLmj /oaBh6bnEvm1HrnzaW+KIT6viDCrQ7zKJgihYRTEdE51KvzusQTOtBfXI58BX9BfEVjT 48wUcU/9v7Rj3F7nJWC4eh+mHY0+/UsPeJpD1n6TC10VwXYzoxyVxMBTj3rlHjOyZyea P+bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=PBaTjDCw+Mnz1LCCEkar3AvN4MjgKv9Td6t2TRMQC9U=; b=tRTLLCQ6gw6A13OmMR97+6W7S0oRqyotC2wlt8qlCZTum7SJGvLh/V3nn0gBsxaLE/ fp8NPIG4a7Nd0m04y3ya2TxAhqhWIGCyBmADMBM5hg11ztX0q3OncwCWcDDnsQcqbXXl CoHAeNkM9ybW4tHdYVB2LPm5HITUmbSSl/2O3y3tymYjWVlXfZdtRZV5JdPHV2jK6o+l IWEh98RVlNQDfIEzL0CrKSoEDymPFQ/FfCqTq8oqneQyTEu4lcUv2uyn9U7yijG3jgyb aL/TBa3gK2VSwJPTSxeMNMb9dT460QkpsApAWp6iYnQ8r7XU4MWA3ONoEyzXj7FGJANv LsSA== X-Gm-Message-State: AOAM530c2MCg32dn4UB0VOQUJML6LAQmW41ZzWFHw1hjPvCktMjduMAg e5Z/qCONreS0BwNP4Trnoc4= X-Google-Smtp-Source: ABdhPJz3SBTi8FfD89XgZh1xoWP7H4zlnjSPsUj54IshBUtHwDfGxpDtwo5KoI5uQy8XsbJoPoemWQ== X-Received: by 2002:aa7:c608:: with SMTP id h8mr10567444edq.16.1603621062515; Sun, 25 Oct 2020 03:17:42 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id o15sm3734190ejm.38.2020.10.25.03.17.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2020 03:17:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 25 Oct 2020 12:17:38 +0200 From: Yaron Sheffer To: Fabien Imbault , Dick Hardt CC: Mika =?UTF-8?B?Qm9zdHLDtm0=?= , GNAP Mailing List , Justin Richer Message-ID: <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> Thread-Topic: [GNAP] Feedback on polymorphism References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3686473060_674901544" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 10:17:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3686473060_674901544 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 I think your product management model has a lot of merit, but it does not c= apture the security issue well. =20 I agree that as we look at different customer personas, the =E2=80=9Cend user=E2=80=9D = (the developer that=E2=80=99s using the libraries) should be our highest priority.= But I disagree about end-user mistakes being the top *security* issue. Libr= aries are often open source in our space and used very widely. So they make = for tasty targets, and people are attacking them and are still finding secur= ity issues in libraries that we=E2=80=99ve been talking about forever [1]. =20 (Yes, my example is actually an app flaw, but I think it could have been pr= evented by a better designed library.) =20 In other words, we do need to care about how easy it is to implement the pr= otocol correctly by *library* developers. From Justin describing his own exp= erience and other people on the thread that Dick referred to, I would say th= at JSON polymorphism is painful for Java and Go developers. With all due res= pect, I care about them much more than I care about Haskell, as many more im= plementations are likely to use these languages. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing= -app/ =20 From: TXAuth on behalf of Fabien Imbault Date: Sunday, October 25, 2020 at 01:25 To: Dick Hardt Cc: Mika Bostr=C3=B6m , GNAP Mailin= g List , Justin Richer Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Dick, =20 Independantly from the debate on polyphormism, I beg to differ on your orde= r preference.=20 =20 Your assumption is that AS devs matter the most, because they're doing the = important security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spec= are unable to deal with the complexity that is passed onto them.=20 =20 99% of the people that will actually use the output of the work are applica= tion developers (client or RS) and their own users.=20 =20 Our intent as well as the protocol drive the usage. Client libraries may he= lp, but they're not a silver bullet, especially because GNAP ultimately has = no control about what people do there (for better or worse). And everything = we do here will help get to the better part.=20 =20 I'm not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't forget that a= nyway.=20 =20 Fabien=20 =20 =20 Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3=A9crit : I'm confused by your logic Fabien. =20 If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=20 =20 I differ on who our stakeholders are.=20 =20 I think our stakeholders are in least to most important: =20 AS developer RS developer client developer user =20 A client library developer can expose whatever interface they want to simpl= ify implementation. =20 I list the user so that we don't lose site of a critical role. =20 /Dick =20 =20 =E1=90=A7 =20 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault w= rote: Hi there,=20 =20 Let me try to approach the issue under a different light. More like a produ= ct manager would deal with feature selection to make it intuitive for its us= ers.=20 =20 For most people, riding a bike is far easier than using a unicycle. Feels m= ore stable. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chain rin= g, etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized.=20 =20 Back to the GNAP topic.=20 Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=20 (short answer: the priority should be simplicity for spec users, not spec i= mplementers and even less spec designers).=20 =20 The initial question that is asked is very interesting: isn't the design fl= awed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are look= ing for a global unique identifier? The argument stems of the fact that is s= till arguably harder and more error prone to implement. Fair enough.=20 =20 >From a spec implementer's perspective, it may well be more complex. It most= ly impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite not e= xactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I= mean, I wished it could be simpler, but it's manageable and there are other= ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still ea= sier from an implementation perspective than say, json-ld, which is massivel= y used in the SSI community.=20 =20 But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot? =20 The job to be done (JTBD), from the end-developer's perspective, is to effi= ciently ship an application. And provide authN/authZ capabilities for end-us= ers by relying on some well known implementation.=20 In turn, this spec implementer will rely on cryptographic utility libraries= that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts with= the title "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=20 Note that any decent flamewar will be efficiently fueled by people hating m= edium. Is it outrageous for blog posts to be behind a paywall? Maybe but it'= s even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the contrary = by to not paying a subscription if you believe that surveillance capitalism,= to reuse Zuboff's terms, should be eradicated.=20 What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, yo= u might not want to deal with hosting your own blog. But maybe as a reader y= ou'll find that annoying. Different audiences, different JTBD, different tra= deoffs.=20 =20 Polyphormism is a tool that enables the end-developer to have minimal knowl= edge of what it means to deal with a GNAP client library. You prepare the re= quest, send to the endpoint and you're good to go. Massively simpler than OA= uth2 or any similar protocol by the way (as anyone with teaching experience = on the subject might acknowledge). And there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-use= r.=20 =20 If we find a better way to deal with that simplicity balance, I'm all in. B= ut the arguments need to be way more convincing than just saying that it may= be difficult to implement or validate.=20 =20 Cheers. Fabien =20 =20 =20 =20 =20 Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9crit : =20 On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: =20 Justin =20 I did note that I was the one that argued for instance_id being in the obje= ct. Since it is in the object in the current draft, not including a pass by = reference option would be preferable.=20 =20 As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on =20 These are all attributes of the client that an AS may require on the initia= l grant request, and in future grant requests (which is when an instance_id)= would be used. =20 =20 This is where our interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattribu= tes of the client=E2=80=9D in the same way that the key, display information, clas= s identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t modify = the instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a sepa= rate object, so you=E2=80=99d have something like this strawman: =20 { =20 posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, =20 client: =E2=80=9Cclient-541-ab" =20 } =20 This is a more fundamental question about GNAP than whether the syntax uses= polymorphism: this is about GNAP being very explicit about the data model o= f its elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the ter= m =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. = We=E2=80=99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in GNAP w= ith explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be mo= re precise about what exactly a client instance includes, and what it does n= ot. =20 =E2=80=94 Justin =20 /Dick =20 =E1=90=A7 =20 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: Dick, =20 As you=E2=80=99ll recall, I argued against including the client instance identifi= er inside of the object as a mutually-exclusive field precisely because of t= he principle violation that you are pointing out here, and so it=E2=80=99s importa= nt to point out that the current text is a compromise that needs to be exami= ned in the wider experience of the working group. I am on the side of removi= ng the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored. =20 The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Cclient in= stance=E2=80=9D value itself but rather belong outside of that object in a another= part of the request. As stated in the editorial notes in this section, we n= eed to look carefully at how these concepts fit within the model and where w= e would want to put them. Without concrete examples of what these extensions= look like and how they=E2=80=99re generated, that is nearly impossible to do at t= his stage. I look forward to seeing examples of this kind of data and how it= can fit into the protocol. =20 =E2=80=94 Justin On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: =20 Hey Justin, =20 As the draft has evolved, I question the continued use of polymorphism. Not= e that I appreciate the elegance of using a string for pass-by-reference, an= d an object for pass-by-value. =20 In the current draft, the=20 =20 Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question.=20 =20 is violated in 2.3.1. Identifying the RC Instance =20 =20 instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. =20 "client": { "instance_id": "client-541-ab" } =20 If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. =20 "client": "client-541-ab" =20 The instance identifier can be sent two ways. Polymorphism is a convenience= for the client, but requires the server to have two code paths for "instanc= e_id". We discussed this in the design team, and I argued for having "insta= nce_id" in the "client" object so that any updates, such as new devices asse= rtions, could be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference. =20 In your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe: =20 {=20 "key": {=20 "proof": "bearer"=20 }=20 } =20 In your example, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "proof= " property. In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "key" object. =20 Not being a Java programmer, I don't know how this would work in a Java imp= lementation, but node.js, the processing would need to be done as above. =20 On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D= 24855750=20 =20 /Dick =20 =20 On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: Hi Mika, =20 Thanks for bringing this topic here =E2=80=94 I was able to see the forum discuss= ion that brought you here, and hopefully I can help clear up what I mean wit= h how polymorphism is used in the proposal. The short version is that the go= al is to avoid the kinds of ambiguity that make insecure protocols, and so i= n that goal we=E2=80=99re fully aligned. I think that using polymorphism in very s= pecific ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems. =20 Some background: I built out the XYZ protocol (one of the predecessors to t= he initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made an= y sense in the code. (My own open source implementation is at https://github= .com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the G= NAP spec). It was important to me that I be able to use the system-wide conf= igured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the hooks = into the right places (especially with the Jackson parser that I used), but = it is definitely possible to create a deterministic and strongly-typed parse= r and serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft document= (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name= -json-structures-and-polymor), but it=E2=80=99s still good to discuss this here as= the working group decides which approaches to take.=20 =20 The driving reason for using polymorphism at the protocol level was to simp= lify the protocol and make it :more: deterministic to create and process, no= t less. Every time you create or process a field it will mean only one thing= , and there=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fiel= ds, which is prone to failure and requires additional error checking. Take f= or example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way. = Without that, you=E2=80=99d need to have different fields for the options and incl= ude additional checks in your parser to make sure they weren=E2=80=99t sent simult= aneously, otherwise you could get hit with this potential security vulnerabi= lity in an object: =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } =20 This would be an illegal object as per this alternate proposal, but then yo= u=E2=80=99d have to check each field and make sure it wasn=E2=80=99t put next to others = in the same object. I=E2=80=99ve done this exercise with many other protocols and = it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples= would pass code that doesn=E2=80=99t check this. With the polymorphic approach to= this same field, each of these three mutually-exclusive states is written i= n a way that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s i= mpossible and enforced by the syntax of JSON itself. =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } =20 // bearer token =20 { key: false } =20 // bound to the RC=E2=80=99s presented key =20 { key: true } =20 If someone sends a different type for this field, like an array or number o= r a null, this doesn=E2=80=99t have a defined interpretation in the protocol and w= ould be a protocol level error. =20 While it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly typed= , it=E2=80=99s just that there are potentially different types that express meanin= g for the field. This applies to all members of all objects (dictionaries) a= s well as all members of an array (list). Every time you process a field val= ue or other element, you look at the type and then the value to determine wh= at to do with that typed value. =20 In your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its meaning= . To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be d= efined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what exactl= y the encoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number ther= e means exactly one interpretation and seeing a string means exactly one (di= fferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80= =9D, since that=E2=80=99s the field that determines the type. An implementation woul= d likely use an internal BigInteger type of object to represent the field va= lue after parsing, so the question is how to go from the JSON value (which i= s typed) into the BigInteger value.You don=E2=80=99t just apply the type rules on = the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object.=20 =20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take advantage of JSON=E2=80=99s polymorph= ic nature. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing er= rors in more strict components downstream. This is something that protocol d= esigners need to be aware of and guard against in the design of the protocol= to reduce possible ambiguities. Within GNAP today, we generally have things= that branch whether they=E2=80=99re an object (for a rich description of somethin= g) or some non-structured special value (for a reference or other item).=20 =20 The design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design document d= ue to both lack of time to keep it updated with the rapid changes to the pro= tocol during the design team discussion, and not knowing if there would be i= nterest in such material. I personally think it would be helpful to include = as an informative reference in the final document, but that=E2=80=99s something fo= r the working group to take up eventually. =20 =E2=80=94 Justin On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m wrote: =20 Hello, everyone. =20 For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments t= o this working group. =20 In short, I believe that the use of polymorphic JSON in the protocol invite= s subtle and confusing implementation problems. I also searched through the = WG archives, and noticed that similar concerns were noted, briefly, in a thr= ead in July.=20 =20 The problem with polymorphic values, as I see it, is that implementations w= ill need to branch on the (inferred) type of a given field. This isn't quite= as bad if the types are strictly different, but allows for subtle bugs when= the value in question is a dictionary. What makes this unappealing is that = "subtle bugs" in security protocols have a habit of turning into vulnerabili= ties. =20 Let's say we have these imaginary payloads, both possible and valid in the = same protocol step: =20 # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } =20 # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } =20 In both cases, the type of "public_key" field is a dictionary. In both case= s, they even have the same keys. However, the values in the dictionaries are= entirely different, and an implementation will have to branch to at least t= wo possible decoding mechanisms. To make things worse, some JSON implementat= ions may choose to encode non-dictionary values as strings, so it is possibl= e for an originator to transmit what they expect and believe to be payload 1= format, but which the receiver will interpret to be in payload 2 format. An= d if the encoded string contains only digits, it will even parse correctly a= s a bignum. =20 While the above is clearly a manufactured scenario, it nonetheless demonstr= ates the potential for logic bugs with polymorphic JSON. With richer types a= nd more complex dictionaries, there will surely be more room for errors. =20 Ambiguity in protocols is always a source of implementation complexity and = interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's ter= rifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in= everyone's interest to keep implementation complexity and mistake potential= to a minimum? =20 Best regards, Mika =20 --=20 Mika Bostr=C3=B6m Smarkets --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =E1=90=A7 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3686473060_674901544 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Hi Fabien,

     

    I think your product management model has a lot of merit, but it d= oes not capture the security issue well.

     

    I agree that as we look at different c= ustomer personas, the =E2=80=9Cend user=E2=80=9D (the developer that=E2=80=99s using the libra= ries) should be our highest priority. But I disagree about end-user mistakes= being the top *security* issue. Libraries are often open source in o= ur space and used very widely. So they make for tasty targets, and people ar= e attacking them and are still finding security issues in libraries that we=E2= =80=99ve been talking about forever [1].

    &= nbsp;

    (Yes, my example is actually an app flaw, = but I think it could have been prevented by a better designed library.)=

     

    In othe= r words, we do need to care about how easy it is to implement the protocol c= orrectly by *library* developers. From Justin describing his own expe= rience and other people on the thread that Dick referred to, I would say tha= t JSON polymorphism is painful for Java and Go developers. With all due resp= ect, I care about them much more than I care about Haskell, as many more imp= lementations are likely to use these languages.

     

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

     

    [1] https://www.zofrex.com/blog/= 2020/10/20/alg-none-jwt-nhs-contact-tracing-app/

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault <= ;fabien.imbault@gmail.com>
    Date: Sunday, October 25, 2020 at 01= :25
    To: Dick Hardt <dick.hardt@gmail.com>
    Cc: Mika= Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing L= ist <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
    Sub= ject: Re: [GNAP] Feedback on polymorphism

     

    Hi D= ick,

     

    <= p class=3DMsoNormal>Independantly from the debate on polyphormism, I beg to di= ffer on your order preference. 

     

    Your assumption is t= hat AS devs matter the most,&nb= sp;because they're doing the important security implementation. But eating o= ur own dogfood might help a lot to change that view. Most security issues oc= cur because users of the spec are unable to deal with the complexity that is= passed onto them. 

    =  

    99% of the people that wi= ll actually use the output of the work are application developers (client or= RS) and their own users. 

    =  

    Our intent as well as the protocol drive the usage. Clie= nt libraries may help, but they're not a silver bullet, especially because G= NAP ultimately has no control about what people do there (for better or wors= e). And everything we do here will help get to the better part. =

     

    I'm not saying we don't intend to also care about AS dev= elopers (beginning with ourselves) but it's a second order optimisation. And= since it's a tendancy we're leaning towards by default, I'm pretty sure we = won't forget that anyway. 

    =  

    Fabien 

     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    I'm confused by your logic Fabien.

     

    If a client librar= y developer wants to expose polymorphism, they can do that independent of wh= at is in the protocol. 

     

    I differ on who our stakehol= ders are. 

     

    I think our stakeholders are in least to = most important:

     

    • AS developer
    • RS developer
    • client developer
    • us= er

     

    A client library developer can expose whatever i= nterface they want to simplify implementation.

     

    I list the= user so that we don't lose site of a critical role.

     

    /Dic= k

     

     

    3D"Image=E1=90=A7

     

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi there, 

     

    Let me try to approach the= issue under a different light. More like a product manager would deal with = feature selection to make it intuitive for its users. 

     

    For most people, riding a bike is far easier than using a unicycle. Feels = more stable. And yet it's way easier to design for a single wheel than to bu= ild with 2. Because then you'll need a lot more accessories (chain, chain ri= ng, etc.). Even so producing a bike doesn't have to be a brittle process, it= can be industrialized. 

     

    Back to the GNAP topic.&nbs= p;

    Ultimately we should strive to make the spec as simple as can be. = But we need to ask: simple for whom? For the bike owner or for the bike vend= or? 

    (short answer: the priority should be simplici= ty for spec users, not spec implementers and even less spec designers). = ;

     

    The initial question that is asked is very inter= esting: isn't the design flawed if GNAP is using json polyphormism? Or if th= e AS needs to handle the state of the request? Or if we must handle token re= vocation? Or if we are looking for a global unique identifier? The argument = stems of the fact that is still arguably harder and more error prone to impl= ement. Fair enough. 

    &= nbsp;

    From a spec implementer's persp= ective, it may well be more complex. It mostly impacts the json library you'= ll end up using, plus a bit of input/output decoration around it. Even golan= g provides utilities for this, despite not exactly being made for this kind = of purpose.

    My practical experie= nce implementing it is that it's not that big a deal. I mean, I wished it co= uld be simpler, but it's manageable and there are other ways to reach levels= of insurance that it does work as intended (json schema, test cases to vali= date the implementation, etc.). Arguably it is still easier from an implemen= tation perspective than say, json-ld, which is massively used in the SSI com= munity. 

     <= /p>

    But ultimately who are we designing for? Ar= e we striving to go easy on the spec implementer? Or are we trying to make s= ure end-developers using the client libraries won't shoot themselves in the = foot?

     

    The job to be done (JTBD), from the end-developer's= perspective, is to efficiently ship an application. And provide authN/authZ= capabilities for end-users by relying on some well known implementation.&nb= sp;

    In turn, this spec implement= er will rely on cryptographic utility libraries that deals internally with t= he complexity of their own domain, so that we don't have to. And here we cou= ld launch another HN flame war that starts with the title "JWT sucks be= cause". Which does have its set of very real issues but that's beyond t= he point. 

    Note that any de= cent flamewar will be efficiently fueled by people hating medium. Is it outr= ageous for blog posts to be behind a paywall? Maybe but it's even more outra= geous to lack consistency, either by not knowing how to get around a paywall= if you're into a hacker punk movement, or on the contrary by to not paying = a subscription if you believe that surveillance capitalism, to reuse Zuboff'= s terms, should be eradicated. 

    What likely seems an unnecessary sidenote tries to illustrate the point= : for Justin it was easier to publish on medium, because as a blog publisher= , you might not want to deal with hosting your own blog. But maybe as a read= er you'll find that annoying. Different audiences, different JTBD, different= tradeoffs. 

     

    Polyphormism is a tool that enables the= end-developer to have minimal knowledge of what it means to deal with a GNA= P client library. You prepare the request, send to the endpoint and you're g= ood to go. Massively simpler than OAuth2 or any similar protocol by the way = (as anyone with teaching experience on the subject might acknowledge). And&n= bsp; there's a lot more to be done to make sure we indeed reduce the complex= ity for the end-developer and the end-user. 

    <= p class=3DMsoNormal> 

    If we f= ind a better way to deal with that simplicity balance, I'm all in. But the a= rguments need to be way more convincing than just saying that it may be diff= icult to implement or validate. 

     

    Cheers.<= /p>

    Fabien

     

     =

     

     

     

    Le ven. 23 oct. 2020 =C3=A0 22:35= , Justin Richer <jricher= @mit.edu> a =C3=A9crit :

     

    =



    On Oct 23, 2020, at 3:52 PM, = Dick Hardt <dick.ha= rdt@gmail.com> wrote:

    &nb= sp;

    Justin

     

    I did note tha= t I was the one that argued for instance_id being in the object. Since it is= in the object in the current draft, not including a pass by reference optio= n would be preferable. 

     

    As for concrete examples:

    - version of client

    =

    - version of OS

    - security attestation of OS / device

    - location of client device

    - network client is operating on

     

    These ar= e all attributes of the client that an AS may require on the initial gr= ant request, and in future grant requests (which is when an instance_id) wou= ld be used.

     

     

    This is where our interpretations differ: I d= on=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in the same way that the = key, display information, class identifiers, and other items currently repre= sented by an instance_id are attributes of the client instance. The attestat= ion components don=E2=80=99t modify the instance so much as present additional inf= ormation on top of the client instance itself. This is why I argue that they= ought to be handled in a separate object, so you=E2=80=99d have something like th= is strawman:

     

    {

     

      posture: {<= /o:p>

        software_version: 1.2.3= ,

        os_version: 14.3= .2

        device_attestat= ion: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }

        location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

      },

    =

     

     = client: =E2=80=9Cclient-541-ab"

    =  

    }

     

    This= is a more fundamental question about GNAP than whether the syntax uses poly= morphism: this is about GNAP being very explicit about the data model of its= elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80=9C= client=E2=80=9D is referring to, exactly, is deeply problematic in practice. We=E2=80=99= re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccredent= ialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the different as= pects that are out there. I think we=E2=80=99re getting closer here in GNAP with e= xplicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be more pr= ecise about what exactly a client instance includes, and what it does not.

     

    <= p class=3DMsoNormal> =E2=80=94 Justin

     



    /Dick

     

    3D"Image=E1=90=A7

    &nbs= p;

    On Fri, Oct 23, 2020 at 12:42 PM Ju= stin Richer <jricher@mit= .edu> wrote:

    Dick,

     

    As you=E2=80=99ll recall, = I argued against including the client instance identifier inside of the obje= ct as a mutually-exclusive field precisely because of the principle violatio= n that you are pointing out here, and so it=E2=80=99s important to point out that = the current text is a compromise that needs to be examined in the wider expe= rience of the working group. I am on the side of removing the mutually-exclu= sive =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to be explore= d.

     

    The crux of my argument is that is exactly a case of p= ass-by-reference vs pass-by-value, and that runtime attestations are not par= t of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside of tha= t object in a another part of the request. As stated in the editorial notes = in this section, we need to look carefully at how these concepts fit within = the model and where we would want to put them. Without concrete examples of = what these extensions look like and how they=E2=80=99re generated, that is nearly = impossible to do at this stage. I look forward to seeing examples of this ki= nd of data and how it can fit into the protocol.

     

     =E2=80= =94 Justin



    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

     

    Hey Justin,

     

    As the draft has evolved, I question the = continued use of polymorphism. Note that I appreciate the elegance of u= sing a string for pass-by-reference, and an object for pass-by-value.

     

    In the current draft, the 

     

    Every time you create or process= a field it will mean only one thing, and there=E2=80=99s only one field to look a= t to answer a question. 

     

    is violated in= 2.3.1.  Identifying the RC Instance<= /o:p>

     

     

       instance_id  = An identifier string that the AS can use to identify the

          particular instance of this RC= .  The content and structure of this

          identifier is opaque to the RC.

     

       "client": {

           "instance_id": "client-54= 1-ab"

       }

     

       If there are no additional fields to send, the RC = MAY send the

       instan= ce identifier as a direct reference value in lieu of the

       object.

     

      &nbs= p;"client": "client-541-ab"

     

    The instance identifier can be sent two ways. Polymorphism is a convenie= nce for the client, but requires the server to have two code paths= for "instance_id".  We discussed this in the design team, an= d I argued for having "instance_id" in the "client" obje= ct so that any updates, such as new devices assertions, could be in the= "client" object. As noted above, while I appreciate the elegance = of using a string (handle) to reference a previously provided object, it com= plicates how to update an existing object while providing the reference.

     

    In your example of the "key" object below, setting= "proof" to bearer would avoid the issue you describe:<= /p>

     

    { 
     "key": { 
         &qu= ot;proof": "bearer"
        }
    }

    <= /div>

     

    In your example, when processing the "key" object, code is hav= ing to check both the JSON type of the property, as well as check the value = of the "proof" property. In the example I provided, only the value= of "proof" needs to be checked. The "proof" property is= acting as a type for the "key" object.

    <= p class=3DMsoNormal> 

    Not bei= ng a Java programmer, I don't know how this would work in a Java implementat= ion, but node.js, the processing would need to be done as above.<= /p>

     

    On a related note, there was significant negative feedback on handle= s and polymorphism in the Hacker News article https://news.ycombinator.com/= item?id=3D24855750 

    =  

    /Dick

     

    =  

    On Fri, Oct 23, 202= 0 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

    =

     

    T= hanks for bringing this topic here =E2=80=94 I was able to see the forum discussio= n that brought you here, and hopefully I can help clear up what I mean with = how polymorphism is used in the proposal. The short version is that the goal= is to avoid the kinds of ambiguity that make insecure prot= ocols, and so in that goal we=E2=80=99re fully aligned. I think that using polymor= phism in very specific ways can help that goal =E2=80=94 just as I agree that misu= sing it or applying it sloppily can lead to ambiguous and insecure systems.<= o:p>

     

    =

    Some background: I built out the XYZ protocol (one of the= predecessors to the initial GNAP Draft) in Java using strongly typed parser= s and Java objects specifically to prove to myself that it could be done in = a way that made any sense in the code. (My own open source implementation is= at ht= tps://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to= date with the GNAP spec). It was important to me that I be able to use the = system-wide configured parsers to implement this and not have to resort to s= tepping through elements completely by hand. Java doesn=E2=80=99t make it simple t= o get the hooks into the right places (especially with the Jackson parser th= at I used), but it is definitely possible to create a deterministic and stro= ngly-typed parser and serializer for this kind of data structure. Some of th= e rationale for using polymorphism is covered in the trailing appendix of th= e draft document (https= ://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-s= tructures-and-polymor), but it=E2=80=99s still good to discuss this here as th= e working group decides which approaches to take. 

    =

     

    T= he driving reason for using polymorphism at the protocol level was to simpli= fy the protocol and make it :more: deterministic to create and process, not = less. Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question. Without polymo= rphic field values, you usually need to rely on mutual exclusivity of fields= , which is prone to failure and requires additional error checking. Take for= example the key binding of access tokens. An access token could be bound to= the RC=E2=80=99s key used during the request, to a different key chosen by the AS= , or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and objects a= nd express this set of mutually-exclusive options in a non-ambiguous way. Wi= thout that, you=E2=80=99d need to have different fields for the options and includ= e additional checks in your parser to make sure they weren=E2=80=99t sent simultan= eously, otherwise you could get hit with this potential security vulnerabili= ty in an object:

     

    { 

        key: {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

        },

        bearer_token: true,

        bind_to_rc_key: true

    }

     <= /p>

    This would be an illegal object as per this= alternate proposal, but then you=E2=80=99d have to check each field and make sure= it wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve done this exercis= e with many other protocols and it=E2=80=99s both error prone and easy to ignore s= ince all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t check this. = With the polymorphic approach to this same field, each of these three mutual= ly-exclusive states is written in a way that they cannot be sent together. I= t=E2=80=99s not just illegal, it=E2=80=99s impossible and enforced by the syntax of JSON= itself.

     

    { 

        key: {

    &n= bsp;     proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

    =

        }

    }

     

    =

    // bearer token

     

    {

    <= /div>

        key: false

    }

     

    // bound to the RC=E2=80=99s pres= ented key

     

    <= /div>

    {

    &= nbsp;   key: true

    }

     

    If someone sends a different type for this field, like an array = or number or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and would be a protocol level error.

     

    While it might= sound like polymorphism means that any field could have any type or value, = the opposite is true: each possible value is explicitly typed, it=E2=80=99s just t= hat there are potentially different types that express meaning for the field= . This applies to all members of all objects (dictionaries) as well as all m= embers of an array (list). Every time you process a field value or other ele= ment, you look at the type and then the value to determine what to do with t= hat typed value.

     

    In your example below, each field within= the dictionary would also need to be typed, and each type would need to hav= e a clear indication of its meaning. To take your strawman key format below,= the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as either a =E2=80=9Cbig= int=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The defin= ition would further say what exactly the encoding of the string would be. Th= at means that when you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any = confusion on what the value was or how it was represented, regardless of the= input format. Seeing a number there means exactly one interpretation and se= eing a string means exactly one (different) interpretation =E2=80=94 but important= ly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determin= es the type. An implementation would likely use an internal BigInteger type = of object to represent the field value after parsing, so the question is how= to go from the JSON value (which is typed) into the BigInteger value.You do= n=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it = to all sub-fields of that object. 

     

    So let=E2=80=99s dig in= to the specific bug you bring up in the strawman, because it=E2=80=99s interesting= : A JSON encoder that encodes numbers as strings, and not numbers, is not co= mpliant with the JSON definitions of the field in question. For another exam= ple, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a parser imp= lementation when mapping to a concrete object. It=E2=80=99s in this kind of automa= ted guessing that this class of bugs occur, and that=E2=80=99s going to be the cas= e whether or not you take  advantage of JSON=E2=80=99s polymorphic nature. I=E2= =80=99ve run into cases where a parser library was trying to be overly =E2=80=9Chelpfu= l=E2=80=9D in doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers need= to be aware of and guard against in the design of the protocol to reduce po= ssible ambiguities. Within GNAP today, we generally have things that branch = whether they=E2=80=99re an object (for a rich description of something) or some no= n-structured special value (for a reference or other item). =

     

    The design team created some simple JSON Schemas for parts of the p= rotocol during our discussion, but we didn=E2=80=99t include them in the design do= cument due to both lack of time to keep it updated with the rapid changes to= the protocol during the design team discussion, and not knowing if there wo= uld be interest in such material. I personally think it would be helpful to = include as an informative reference in the final document, but that=E2=80=99s some= thing for the working group to take up eventually.

    =

     

     = =E2=80=94 Justin



    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarke= ts.com@dmarc.ietf.org> wrote:

    =  

    Hello, everyone.=

     

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussio= n forum and when I made note about certain concerns, I was requested to send= my comments to this working group.

     

    In short, I believe t= hat the use of polymorphic JSON in the protocol invites subtle and confusing= implementation problems. I also searched through the WG archives, and notic= ed that similar concerns were noted, briefly, in a thread in July.

     

    The problem with polymorphic values, as I see it, is that impleme= ntations will need to branch on the (inferred) type of a given field. This i= sn't quite as bad if the types are strictly different, but allows for subtle= bugs when the value in question is a dictionary. What makes this unappealin= g is that "subtle bugs" in security protocols have a habit of turn= ing into vulnerabilities.

    &= nbsp;

    Let's say we have these imagina= ry payloads, both possible and valid in the same protocol step:

     

    # payload 1

    {<= /p>

      ...,

      "public_key": {

        "alg": "rsa",

        "modulus": &= lt;BIGINT>

      }

    }

     

    # payload 2

    {

      ...,

      "p= ublic_key": {

      &= nbsp; "alg": "rsa",

        "modulus": "<encoded string>= "

      }

    }

     

    In both cases, the type of = "public_key" field is a dictionary. In both cases, they even have = the same keys. However, the values in the dictionaries are entirely differen= t, and an implementation will have to branch to at least two possible decodi= ng mechanisms. To make things worse, some JSON implementations may choose to= encode non-dictionary values as strings, so it is possible for an originato= r to transmit what they expect and believe to be payload 1 format, but which= the receiver will interpret to be in payload 2 format. And if the encoded s= tring contains only digits, it will even parse correctly as a bignum.

     

    While the above is clearly a manufactured scenario, it nonethel= ess demonstrates the potential for logic bugs with polymorphic JSON. With ri= cher types and more complex dictionaries, there will surely be more room for= errors.

     

    Ambiguity in protocols is always a source of imp= lementation complexity and interoperability snags, but in an AuthN/AuthZ pro= tocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation compl= exity and mistake potential to a minimum?

     

    Best regards,

    Mika

     

    -- =

    Mika Bostr=C3=B6m=

    Smarkets

    =

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.= ietf.org/mailman/listinfo/txauth

    =

     

    --
    TXAu= th mailing list
    TXAuth@i= etf.org
    https://www.ietf.org/mailman/listinfo/txauth

    3D"Image=E1=90=A7

     

     

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>

    <= /div>

    -- TXAuth mailing list TXAuth@ietf.org https://www.i= etf.org/mailman/listinfo/txauth

    --B_3686473060_674901544-- From nobody Sun Oct 25 03:39:58 2020 Return-Path: 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 0E4093A1592 for ; Sun, 25 Oct 2020 03:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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=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 pfMvEtz8ZDVS for ; Sun, 25 Oct 2020 03:39:53 -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 08C163A1593 for ; Sun, 25 Oct 2020 03:39:53 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id q1so5531397ilt.6 for ; Sun, 25 Oct 2020 03:39:52 -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=u5ydvRygqRmyll9OKF0WsFg5ec2fgywdMx5w7vfo9YY=; b=h3/rJ1dgkQmKF1LN+bkili6oeCkfBoItdAYQuq9bxoBZRPKKUuXWCJ2dyjqU1TMy6S 0rUbSbY4MPcRrGyIJV3qM8IL8ckl/NEl72Na25WRYr+VkMJAMgHjMoj/IcgmYoP8cKm4 DXJbrvI1U7DvotnOJRnez+mLLG6oz73au0eRLRxEZttYxs+1Maeppe+Dy+lskTj8YX2y DTQTN1Rz6rIuL7YnA6xu0QH+Yq4bzn+udWZusnx0w3iizEQ1o8oT1dLGNYC1ku3puwl2 qlagKtYdTIVmmVT0R6czDikpVMpYhDrOF70UGS7AUn8HinhP6Eqjgj8jLSbDVr0qM/+A Nayw== 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=u5ydvRygqRmyll9OKF0WsFg5ec2fgywdMx5w7vfo9YY=; b=PpViCo9x5B54186X1cIQ5tnZpxBUDnFYCeCMuHKTsxNTBqfzkLE8flDvP8leruYbWK 600c2D4HTLU4J4xPt9fclL9fwz38sbUgVHkagejdcWA404geKsTzZXjcLUEloo+q4f0u XjN/Z7TnJjsvebK549zW7bIMynnM6/Dz6q/8BqpmPpBIfpDDABPGf9UpXxMcWfsqFplA aDJnKOoMvZWZvDZV2CvZob1yIYZfymIF4x32XGF3IGLaEC54fgpcbXJTwT6MVqgIVMWh YhQAVnDwdUYrZQtG4RiJvMfjMqRL5J0ICdU2+gfPNWYm30mCrCpmpW1XPFVzb61R2UiZ z3yA== X-Gm-Message-State: AOAM531zJcEyLGXnCbEI7WiWrtmY84WoBRd3Wqeuqv0srMMbVVsDcYVt gajfqur/SWVwK0/k90B+I2qpOisgwXOmftrYKPM= X-Google-Smtp-Source: ABdhPJzfO97R8cPQwKJU2pGHJDCHlPTtyubrH0EQTObaYtrkaXQIcdV+KcswkPgpXDFguw1SwNNZZ2FNV+5h6DHrnu8= X-Received: by 2002:a92:9106:: with SMTP id t6mr7816312ild.178.1603622391972; Sun, 25 Oct 2020 03:39:51 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> In-Reply-To: <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> From: Fabien Imbault Date: Sun, 25 Oct 2020 11:39:39 +0100 Message-ID: To: Yaron Sheffer Cc: Dick Hardt , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="0000000000000708c305b27c6f11" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 10:39:58 -0000 --0000000000000708c305b27c6f11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Thanks for the feedback. Regarding client libraries, I think we can indeed learn a great deal from cryptographic libraries. Cryptographic design provides a great amount of flexibility for the specialists (including many parameters that you really need to get right). We might think this is great to provide options but it actually increases the cognitive load of library users. Look instead at what Google has provided with tink as an alternative and you'll see it is a much easier way for cryptographic engineers (who aren't cryptographers) to avoid mistakes or misuses. That's the *security* issue I'm referring to (not the fact that being open they're tasty targets, although that may be related in some cases). And tink is the kind of design we should be trying to achieve. I agree that it should be applicable to a wide range of well known programming tools, including the likes of java and go. But I don't really see a limitation here. Might not be the most idiomatic feel, but it can be made to work. Just so I understand, what alternatives would you prefer to polymorphism? I can suggest json-ld but even Justin will Teel you it's even more complex :-) Cheers Fabien Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer a =C3=A9crit : > Hi Fabien, > > > > I think your product management model has a lot of merit, but it does not > capture the security issue well. > > > > I agree that as we look at different customer personas, the =E2=80=9Cend = user=E2=80=9D > (the developer that=E2=80=99s using the libraries) should be our highest = priority. > But I disagree about end-user mistakes being the top **security** issue. > Libraries are often open source in our space and used very widely. So the= y > make for tasty targets, and people are attacking them and are still findi= ng > security issues in libraries that we=E2=80=99ve been talking about foreve= r [1]. > > > > (Yes, my example is actually an app flaw, but I think it could have been > prevented by a better designed library.) > > > > In other words, we do need to care about how easy it is to implement the > protocol correctly by **library** developers. From Justin describing his > own experience and other people on the thread that Dick referred to, I > would say that JSON polymorphism is painful for Java and Go developers. > With all due respect, I care about them much more than I care about > Haskell, as many more implementations are likely to use these languages. > > > > Thanks, > > Yaron > > > > [1] > https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-a= pp/ > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Sunday, October 25, 2020 at 01:25 > *To: *Dick Hardt > *Cc: *Mika Bostr=C3=B6m , G= NAP > Mailing List , Justin Richer > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Hi Dick, > > > > Independantly from the debate on polyphormism, I beg to differ on your > order preference. > > > > Your assumption is that AS devs matter the most, because they're doing > the important security implementation. But eating our own dogfood might > help a lot to change that view. Most security issues occur because users = of > the spec are unable to deal with the complexity that is passed onto them. > > > > 99% of the people that will actually use the output of the work are > application developers (client or RS) and their own users. > > > > Our intent as well as the protocol drive the usage. Client libraries may > help, but they're not a silver bullet, especially because GNAP ultimately > has no control about what people do there (for better or worse). And > everything we do here will help get to the better part. > > > > I'm not saying we don't intend to also care about AS developers (beginnin= g > with ourselves) but it's a second order optimisation. And since it's a > tendancy we're leaning towards by default, I'm pretty sure we won't forge= t > that anyway. > > > > Fabien > > > > > > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : > > I'm confused by your logic Fabien. > > > > If a client library developer wants to expose polymorphism, they can do > that independent of what is in the protocol. > > > > I differ on who our stakeholders are. > > > > I think our stakeholders are in least to most important: > > > > - AS developer > - RS developer > - client developer > - user > > > > A client library developer can expose whatever interface they want to > simplify implementation. > > > > I list the user so that we don't lose site of a critical role. > > > > /Dick > > > > > > [image: Image removed by sender.]=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault > wrote: > > Hi there, > > > > Let me try to approach the issue under a different light. More like a > product manager would deal with feature selection to make it intuitive fo= r > its users. > > > > For most people, riding a bike is far easier than using a unicycle. Feels > more stable. And yet it's way easier to design for a single wheel than to > build with 2. Because then you'll need a lot more accessories (chain, cha= in > ring, etc.). Even so producing a bike doesn't have to be a brittle proces= s, > it can be industrialized. > > > > Back to the GNAP topic. > > Ultimately we should strive to make the spec as simple as can be. But we > need to ask: simple for whom? For the bike owner or for the bike vendor? > > (short answer: the priority should be simplicity for spec users, not spec > implementers and even less spec designers). > > > > The initial question that is asked is very interesting: isn't the design > flawed if GNAP is using json polyphormism? Or if the AS needs to handle t= he > state of the request? Or if we must handle token revocation? Or if we are > looking for a global unique identifier? The argument stems of the fact th= at > is still arguably harder and more error prone to implement. Fair enough. > > > > From a spec implementer's perspective, it may well be more complex. It > mostly impacts the json library you'll end up using, plus a bit of > input/output decoration around it. Even golang provides utilities for thi= s, > despite not exactly being made for this kind of purpose. > > My practical experience implementing it is that it's not that big a deal. > I mean, I wished it could be simpler, but it's manageable and there are > other ways to reach levels of insurance that it does work as intended (js= on > schema, test cases to validate the implementation, etc.). Arguably it is > still easier from an implementation perspective than say, json-ld, which = is > massively used in the SSI community. > > > > But ultimately who are we designing for? Are we striving to go easy on th= e > spec implementer? Or are we trying to make sure end-developers using the > client libraries won't shoot themselves in the foot? > > > > The job to be done (JTBD), from the end-developer's perspective, is to > efficiently ship an application. And provide authN/authZ capabilities for > end-users by relying on some well known implementation. > > In turn, this spec implementer will rely on cryptographic utility > libraries that deals internally with the complexity of their own domain, = so > that we don't have to. And here we could launch another HN flame war that > starts with the title "JWT sucks because". Which does have its set of ver= y > real issues but that's beyond the point. > > Note that any decent flamewar will be efficiently fueled by people hating > medium. Is it outrageous for blog posts to be behind a paywall? Maybe but > it's even more outrageous to lack consistency, either by not knowing how = to > get around a paywall if you're into a hacker punk movement, or on the > contrary by to not paying a subscription if you believe that surveillance > capitalism, to reuse Zuboff's terms, should be eradicated. > > What likely seems an unnecessary sidenote tries to illustrate the point: > for Justin it was easier to publish on medium, because as a blog publishe= r, > you might not want to deal with hosting your own blog. But maybe as a > reader you'll find that annoying. Different audiences, different JTBD, > different tradeoffs. > > > > Polyphormism is a tool that enables the end-developer to have minimal > knowledge of what it means to deal with a GNAP client library. You prepar= e > the request, send to the endpoint and you're good to go. Massively simple= r > than OAuth2 or any similar protocol by the way (as anyone with teaching > experience on the subject might acknowledge). And there's a lot more to = be > done to make sure we indeed reduce the complexity for the end-developer a= nd > the end-user. > > > > If we find a better way to deal with that simplicity balance, I'm all in. > But the arguments need to be way more convincing than just saying that it > may be difficult to implement or validate. > > > > Cheers. > > Fabien > > > > > > > > > > > > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : > > > > > > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: > > > > Justin > > > > I did note that I was the one that argued for instance_id being in the > object. Since it is in the object in the current draft, not including a > pass by reference option would be preferable. > > > > As for concrete examples: > > - version of client > > - version of OS > > - security attestation of OS / device > > - location of client device > > - network client is operating on > > > > These are all attributes of the client that an AS may require on the > initial grant request, and in future grant requests (which is when an > instance_id) would be used. > > > > > > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes > of the client=E2=80=9D in the same way that the key, display information,= class > identifiers, and other items currently represented by an instance_id are > attributes of the client instance. The attestation components don=E2=80= =99t modify > the instance so much as present additional information on top of the clie= nt > instance itself. This is why I argue that they ought to be handled in a > separate object, so you=E2=80=99d have something like this strawman: > > > > { > > > > posture: { > > software_version: 1.2.3, > > os_version: 14.3.2 > > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > > }, > > > > client: =E2=80=9Cclient-541-ab" > > > > } > > > > This is a more fundamental question about GNAP than whether the syntax > uses polymorphism: this is about GNAP being very explicit about the data > model of its elements. OAuth 2=E2=80=99s incredibly loose and broad model= of what > the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pro= blematic in > practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to > define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture > the different aspects that are out there. I think we=E2=80=99re getting c= loser here > in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, bu= t we still need to > be more precise about what exactly a client instance includes, and what i= t > does not. > > > > =E2=80=94 Justin > > > > > > /Dick > > > > [image: Image removed by sender.]=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > > Dick, > > > > As you=E2=80=99ll recall, I argued against including the client instance > identifier inside of the object as a mutually-exclusive field precisely > because of the principle violation that you are pointing out here, and so > it=E2=80=99s important to point out that the current text is a compromise= that > needs to be examined in the wider experience of the working group. I am o= n > the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D= option within an > object, but this needs to be explored. > > > > The crux of my argument is that is exactly a case of pass-by-reference vs > pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient > instance=E2=80=9D value itself but rather belong outside of that object i= n a > another part of the request. As stated in the editorial notes in this > section, we need to look carefully at how these concepts fit within the > model and where we would want to put them. Without concrete examples of > what these extensions look like and how they=E2=80=99re generated, that i= s nearly > impossible to do at this stage. I look forward to seeing examples of this > kind of data and how it can fit into the protocol. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: > > > > Hey Justin, > > > > As the draft has evolved, I question the continued use of polymorphism. > Note that I appreciate the elegance of using a string for > pass-by-reference, and an object for pass-by-value. > > > > In the current draft, the > > > > Every time you create or process a field it will mean only one thing, and > there=E2=80=99s only one field to look at to answer a question. > > > > is violated in 2.3.1. Identifying the RC Instance > > > > > > > instance_id An identifier string that the AS can use to identify the > > particular instance of this RC. The content and structure of this > > identifier is opaque to the RC. > > > > "client": { > > "instance_id": "client-541-ab" > > } > > > > If there are no additional fields to send, the RC MAY send the > > instance identifier as a direct reference value in lieu of the > > object. > > > > "client": "client-541-ab" > > > > The instance identifier can be sent two ways. Polymorphism is a > convenience for the client, but requires the server to have two code path= s > for "instance_id". We discussed this in the design team, and I argued fo= r > having "instance_id" in the "client" object so that any updates, such as > new devices assertions, could be in the "client" object. As noted above, > while I appreciate the elegance of using a string (handle) to reference a > previously provided object, it complicates how to update an existing obje= ct > while providing the reference. > > > > In your example of the "key" object below, setting "proof" to bearer woul= d > avoid the issue you describe: > > > > { > "key": { > "proof": "bearer" > } > } > > > > In your example, when processing the "key" object, code is having to chec= k > both the JSON type of the property, as well as check the value of the > "proof" property. In the example I provided, only the value of "proof" > needs to be checked. The "proof" property is acting as a type for the "ke= y" > object. > > > > Not being a Java programmer, I don't know how this would work in a Java > implementation, but node.js, the processing would need to be done as abov= e. > > > > On a related note, there was significant negative feedback on handles and > polymorphism in the Hacker News article > https://news.ycombinator.com/item?id=3D24855750 > > > > /Dick > > > > > > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > > Hi Mika, > > > > Thanks for bringing this topic here =E2=80=94 I was able to see the forum > discussion that brought you here, and hopefully I can help clear up what = I > mean with how polymorphism is used in the proposal. The short version is > that the goal is to *avoid* the kinds of ambiguity that make insecure > protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using > polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree > that misusing it or applying it sloppily can lead to ambiguous and insecu= re > systems. > > > > Some background: I built out the XYZ protocol (one of the predecessors to > the initial GNAP Draft) in Java using strongly typed parsers and Java > objects specifically to prove to myself that it could be done in a way th= at > made any sense in the code. (My own open source implementation is at > https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not ye= t up to > date with the GNAP spec). It was important to me that I be able to use th= e > system-wide configured parsers to implement this and not have to resort t= o > stepping through elements completely by hand. Java doesn=E2=80=99t make i= t simple > to get the hooks into the right places (especially with the Jackson parse= r > that I used), but it is definitely possible to create a deterministic and > strongly-typed parser and serializer for this kind of data structure. Som= e > of the rationale for using polymorphism is covered in the trailing append= ix > of the draft document ( > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), > but it=E2=80=99s still good to discuss this here as the working group dec= ides which > approaches to take. > > > > The driving reason for using polymorphism at the protocol level was to > simplify the protocol and make it :more: deterministic to create and > process, not less. Every time you create or process a field it will mean > only one thing, and there=E2=80=99s only one field to look at to answer a= question. > Without polymorphic field values, you usually need to rely on mutual > exclusivity of fields, which is prone to failure and requires additional > error checking. Take for example the key binding of access tokens. An > access token could be bound to the RC=E2=80=99s key used during the reque= st, to a > different key chosen by the AS, or it could be a bearer token with no key > at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of > boolean values and objects and express this set of mutually-exclusive > options in a non-ambiguous way. Without that, you=E2=80=99d need to have = different > fields for the options and include additional checks in your parser to ma= ke > sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with > this potential security vulnerability in an object: > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > }, > > bearer_token: true, > > bind_to_rc_key: true > > } > > > > This would be an illegal object as per this alternate proposal, but then > you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others > in the same object. I=E2=80=99ve done this exercise with many other proto= cols and > it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cg= ood=E2=80=9D examples > would pass code that doesn=E2=80=99t check this. With the polymorphic app= roach to > this same field, each of these three mutually-exclusive states is written > in a way that they cannot be sent together. It=E2=80=99s not just illegal= , it=E2=80=99s > impossible and enforced by the syntax of JSON itself. > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > } > > } > > > > // bearer token > > > > { > > key: false > > } > > > > // bound to the RC=E2=80=99s presented key > > > > { > > key: true > > } > > > > If someone sends a different type for this field, like an array or number > or a null, this doesn=E2=80=99t have a defined interpretation in the prot= ocol and > would be a protocol level error. > > > > While it might sound like polymorphism means that any field could have an= y > type or value, the opposite is true: each possible value is explicitly > typed, it=E2=80=99s just that there are potentially different types that = express > meaning for the field. This applies to all members of all objects > (dictionaries) as well as all members of an array (list). Every time you > process a field value or other element, you look at the type and then the > value to determine what to do with that typed value. > > > > In your example below, each field within the dictionary would also need t= o > be typed, and each type would need to have a clear indication of its > meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could > be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON n= umber) or an > =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would fu= rther say what > exactly the encoding of the string would be. That means that when you rea= d > the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was > or how it was represented, regardless of the input format. Seeing a numbe= r > there means exactly one interpretation and seeing a string means exactly > one (different) interpretation =E2=80=94 but importantly, both of them ar= e a > =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines= the type. An > implementation would likely use an internal BigInteger type of object to > represent the field value after parsing, so the question is how to go fro= m > the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just > apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply= it to all > sub-fields of that object. > > > > So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because > it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings,= and not > numbers, is not compliant with the JSON definitions of the field in > question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not > equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t = be treated > the same by a parser implementation when mapping to a concrete object. It= =E2=80=99s > in this kind of automated guessing that this class of bugs occur, and > that=E2=80=99s going to be the case whether or not you take advantage of= JSON=E2=80=99s > polymorphic nature. I=E2=80=99ve run into cases where a parser library wa= s trying > to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but= ended up > introducing errors in more strict components downstream. This is somethin= g > that protocol designers need to be aware of and guard against in the desi= gn > of the protocol to reduce possible ambiguities. Within GNAP today, we > generally have things that branch whether they=E2=80=99re an object (for = a rich > description of something) or some non-structured special value (for a > reference or other item). > > > > The design team created some simple JSON Schemas for parts of the protoco= l > during our discussion, but we didn=E2=80=99t include them in the design d= ocument > due to both lack of time to keep it updated with the rapid changes to the > protocol during the design team discussion, and not knowing if there woul= d > be interest in such material. I personally think it would be helpful to > include as an informative reference in the final document, but that=E2=80= =99s > something for the working group to take up eventually. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < > mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: > > > > Hello, everyone. > > > > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and > when I made note about certain concerns, I was requested to send my > comments to this working group. > > > > In short, I believe that the use of polymorphic JSON in the protocol > invites subtle and confusing implementation problems. I also searched > through the WG archives, and noticed that similar concerns were noted, > briefly, in a thread in July. > > > > The problem with polymorphic values, as I see it, is that implementations > will need to branch on the (inferred) type of a given field. This isn't > quite as bad if the types are strictly different, but allows for subtle > bugs when the value in question is a dictionary. What makes this > unappealing is that "subtle bugs" in security protocols have a habit of > turning into vulnerabilities. > > > > Let's say we have these imaginary payloads, both possible and valid in th= e > same protocol step: > > > > # payload 1 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": > > } > > } > > > > # payload 2 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": "" > > } > > } > > > > In both cases, the type of "public_key" field is a dictionary. In both > cases, they even have the same keys. However, the values in the > dictionaries are entirely different, and an implementation will have to > branch to at least two possible decoding mechanisms. To make things worse= , > some JSON implementations may choose to encode non-dictionary values as > strings, so it is possible for an originator to transmit what they expect > and believe to be payload 1 format, but which the receiver will interpret > to be in payload 2 format. And if the encoded string contains only digits= , > it will even parse correctly as a bignum. > > > > While the above is clearly a manufactured scenario, it nonetheless > demonstrates the potential for logic bugs with polymorphic JSON. With > richer types and more complex dictionaries, there will surely be more roo= m > for errors. > > > > Ambiguity in protocols is always a source of implementation complexity an= d > interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's > terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it > be in everyone's interest to keep implementation complexity and mistake > potential to a minimum? > > > > Best regards, > > Mika > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > [image: Image removed by sender.]=E1=90=A7 > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000000708c305b27c6f11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Yaron,

    Th= anks for the feedback.=C2=A0

    Regarding client libraries, I think we can indeed learn a great deal fro= m cryptographic libraries. Cryptographic design provides a great amount of = flexibility for the specialists (including many parameters that you really = need to get right). We might think this is great to provide options but it = actually increases the cognitive load of library users.

    Look instead at what Google has provided wi= th tink as an alternative and you'll see it is a much easier way for cr= yptographic engineers (who aren't cryptographers) to avoid mistakes or = misuses.=C2=A0

    That'= s the *security* issue I'm referring to (not the fact that being open t= hey're tasty targets, although that may be related in some cases). And = tink is the kind of design we should be trying to achieve.=C2=A0

    I agree that it should be applicab= le to a wide range of well known programming tools, including the likes of = java and go.=C2=A0
    But I don't really see a = limitation here. Might not be the most idiomatic feel, but it can be made t= o work.=C2=A0

    Just s= o I understand, what alternatives would you prefer to polymorphism? I can s= uggest json-ld but even Justin will Teel you it's even more complex :-)= =C2=A0

    Cheers
    Fabien=C2=A0


    Le dim. 25 oct. 2020 =C3=A0 11:17= , Yaron Sheffer <yaronf.ietf@gm= ail.com> a =C3=A9crit=C2=A0:

    Hi Fabien,

    =C2=A0

    I think your product management model has a lo= t of merit, but it does not capture the security issue well.<= /p>

    =C2=A0

    I = agree that as we look at different customer personas, the =E2=80=9Cend user= =E2=80=9D (the developer that=E2=80=99s using the libraries) should be our = highest priority. But I disagree about end-user mistakes being the top *= security* issue. Libraries are often open source in our space and used = very widely. So they make for tasty targets, and people are attacking them = and are still finding security issues in libraries that we=E2=80=99ve been = talking about forever [1].

    = =C2=A0

    (Yes, my example is actually an app= flaw, but I think it could have been prevented by a better designed librar= y.)

    =C2=A0

    In other words, we do need to care about how easy it is to = implement the protocol correctly by *library* developers. From Justi= n describing his own experience and other people on the thread that Dick re= ferred to, I would say that JSON polymorphism is painful for Java and Go de= velopers. With all due respect, I care about them much more than I care abo= ut Haskell, as many more implementations are likely to use these languages.=

    =C2=A0

    Thanks,

    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Yaron

    =C2=A0

    <= p class=3D"MsoNormal">[1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-a= pp/

    =C2=A0

    From: TXAuth <= txauth-bounces@ietf.org> on behalf of Fabien Imbault <= fabien.imbault@gmail.com>
    Date: Sunday, October 25, 2020 a= t 01:25
    To: Dick Hardt <dick.hardt@gmail.com>
    C= c: Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc= .ietf.org>, GNAP Mailing List <txauth@ietf.org>, Justin Riche= r <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on polymo= rphism

    =C2= =A0

    Hi Dick,

    <= div>

    =C2=A0

    Independantly from the debate on polyphormism, I beg to differ on= your order preference.=C2=A0

    =C2=A0

    Your assump= tion is that AS devs matter the most,=C2=A0because they're doing the important security i= mplementation. But eating our own dogfood might help a lot to change that v= iew. Most security issues occur because users of the spec are unable to dea= l with the complexity that is passed onto them.=C2=A0<= /p>

    =C2=A0

    99% of the people that will actually use the output of = the work are application developers (client or RS) and their own users.=C2= =A0

    =C2=A0=

    Our intent as well as the protocol drive the usage. Cli= ent libraries may help, but they're not a silver bullet, especially bec= ause GNAP ultimately has no control about what people do there (for better = or worse). And everything we do here will help get to the better part.=C2= =A0

    =C2=A0=

    I'm not saying we don'= t intend to also care about AS developers (beginning with ourselves) but it= 's a second order optimisation. And since it's a tendancy we're= leaning towards by default, I'm pretty sure we won't forget that a= nyway.=C2=A0

    =C2= =A0

    Fabien=C2=A0=

    =C2=A0

    =C2=A0

    Le sam. 24 oct. 2020 =C3=A0 23:50, D= ick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:<= /u>

    I'm confused by your logic Fabien.

    <= div>

    =C2=A0

    If a client library developer wants to expose polymorphism, they = can do that independent of what is in the protocol.=C2=A0

    =

    =C2=A0

    I differ on who our stakeholders are.=C2=A0<= /p>

    =C2=A0

    I think our stakeholders are in least to most important= :

    =C2=A0

    • AS developer<= u>
    • RS developer
    • client developer
    • u= ser

    =C2=A0<= u>

    A client library developer can = expose whatever interface they want to simplify implementation.

    =C2=A0

    =

    I list the user so that we don't lose site of a = critical role.

    = =C2=A0

    /Dick

    <= /div>

    =C2=A0

    =C2=A0

    3D"Image=E1=90=A7

    =C2=A0

    On Fri, Oct 23= , 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com>= wrote:

    Hi there,=C2=A0

    <= /div>

    =C2=A0

    Let me try to approach the issue under a different light. More l= ike a product manager would deal with feature selection to make it intuitiv= e for its users.=C2=A0

    = =C2=A0

    For most people, ri= ding a bike is far easier than using a unicycle. Feels more stable. And yet= it's way easier to design for a single wheel than to build with 2. Bec= ause then you'll need a lot more accessories (chain, chain ring, etc.).= Even so producing a bike doesn't have to be a brittle process, it can = be industrialized.=C2=A0

    =C2=A0

    Back to the GNAP= topic.=C2=A0

    Ultimately we should strive to mak= e the spec as simple as can be. But we need to ask: simple for whom? For th= e bike owner or for the bike vendor?=C2=A0

    (short answer: the priority should be simplicity for spec users, no= t spec implementers and even less spec designers).=C2=A0

    =C2=A0

    =

    The initial question that is asked is very interesti= ng: isn't the design flawed if GNAP is using json polyphormism? Or if t= he AS needs to handle the state of the request? Or if we must handle token = revocation? Or if we are looking for a global unique identifier? The argume= nt stems of the fact that is still arguably harder and more error prone to = implement. Fair enough.=C2=A0

    =C2=A0

    From a spec= implementer's perspective, it may well be more complex. It mostly impa= cts the json library you'll end up using, plus a bit of input/output de= coration around it. Even golang provides utilities for this, despite not ex= actly being made for this kind of purpose.

    My practical experience implementing it is that it's= not that big a deal. I mean, I wished it could be simpler, but it's ma= nageable and there are other ways to reach levels of insurance that it does= work as intended (json schema, test cases to validate the implementation, = etc.). Arguably it is still easier from an implementation perspective than = say, json-ld, which is massively used in the SSI community.=C2=A0=

    =C2=A0

    But ultimately who are we designing for? Are we st= riving to go easy on the spec implementer? Or are we trying to make sure en= d-developers using the client libraries won't shoot themselves in the f= oot?

    =C2=A0

    The job to be done (JTBD), from the = end-developer's perspective, is to efficiently ship an application. And= provide authN/authZ capabilities for end-users by relying on some well kno= wn implementation.=C2=A0

    In turn, this spec implementer will rely on cryptographic utility librarie= s that deals internally with the complexity of their own domain, so that we= don't have to. And here we could launch another HN flame war that star= ts with the title "JWT sucks because". Which does have its set of= very real issues but that's beyond the point.=C2=A0

    <= /div>

    Note that any decent flamewar will be effi= ciently fueled by people hating medium. Is it outrageous for blog posts to = be behind a paywall? Maybe but it's even more outrageous to lack consis= tency, either by not knowing how to get around a paywall if you're into= a hacker punk movement, or on the contrary by to not paying a subscription= if you believe that surveillance capitalism, to reuse Zuboff's terms, = should be eradicated.=C2=A0

    What likely seems an unnecessary sidenote tries to illustrate the point= : for Justin it was easier to publish on medium, because as a blog publishe= r, you might not want to deal with hosting your own blog. But maybe as a re= ader you'll find that annoying. Different audiences, different JTBD, di= fferent tradeoffs.=C2=A0

    =C2=A0

    Polyphormism is = a tool that enables the end-developer to have minimal knowledge of what it = means to deal with a GNAP client library. You prepare the request, send to = the endpoint and you're good to go. Massively simpler than OAuth2 or an= y similar protocol by the way (as anyone with teaching experience on the su= bject might acknowledge). And=C2=A0 there's a lot more to be done to ma= ke sure we indeed reduce the complexity for the end-developer and the end-u= ser.=C2=A0

    =C2=A0=

    If we find a better way to dea= l with that simplicity balance, I'm all in. But the arguments need to b= e way more convincing than just saying that it may be difficult to implemen= t or validate.=C2=A0

    = =C2=A0

    Cheers.

    Fabien

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0

    =C2= =A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = <jricher@mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0



    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gma= il.com> wrote:

    = =C2=A0

    Justin

    <= div>

    =C2=A0

    I did note that I was the one that argued for instance_id being i= n the object. Since it is in the object in the current draft, not including= a pass by reference option would be preferable.=C2=A0

    =C2=A0

    As for concrete examples:

    - version of client

    - version of OS

    - security attestation of OS / device

    - location of client device

    - network client is operating on

    =

    =C2=A0

    These are all attributes of the client that an AS may requ= ire=C2=A0on the initial grant request, and in future grant requests (which = is when an instance_id) would be used.

    =C2=A0

    =

    =C2=A0

    This is where our interpretations differ: I don=E2=80=99t see these a= s =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently represent= ed by an instance_id are attributes of the client instance. The attestation= components don=E2=80=99t modify the instance so much as present additional= information on top of the client instance itself. This is why I argue that= they ought to be handled in a separate object, so you=E2=80=99d have somet= hing like this strawman:

    =C2=A0

    {<= /p>

    =C2=A0

    =C2=A0 posture: {

    =C2=A0 =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2

    =C2=A0 =C2=A0 device_attestation: { = =E2=80=A6 some structure or signed blob? =E2=80=A6 }

    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon:= =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    = =C2=A0

    =C2=A0 client: =E2=80=9C= client-541-ab"

    <= /u>=C2=A0

    }

    =C2=A0

    This is a more fundamental question about GNAP than whether = the syntax uses polymorphism: this is about GNAP being very explicit about = the data model of its elements. OAuth 2=E2=80=99s incredibly loose and broa= d model of what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly,= is deeply problematic in practice. We=E2=80=99re even seeing that in the O= Auth 2.1 work with having to define a =E2=80=9Ccredentialed client=E2=80=9D= , and even then that doesn=E2=80=99t fully capture the different aspects th= at are out there. I think we=E2=80=99re getting closer here in GNAP with ex= plicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need t= o be more precise about what exactly a client instance includes, and what i= t does not.

    =C2= =A0

    =C2=A0=E2=80=94 Justin

    =C2=A0



    /D= ick

    =C2=A0=

    3D"Image=E1=90=A7

    =C2=A0

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <= jri= cher@mit.edu> wrote:

    Dick,=

    =C2=A0

    As you=E2=80=99ll recall, I argued against including the cli= ent instance identifier inside of the object as a mutually-exclusive field = precisely because of the principle violation that you are pointing out here= , and so it=E2=80=99s important to point out that the current text is a com= promise that needs to be examined in the wider experience of the working gr= oup. I am on the side of removing the mutually-exclusive =E2=80=9Cinstance_= id=E2=80=9D option within an object, but this needs to be explored.<= u>

    =C2=A0

    <= div>

    The crux of my argument is that is exactly a cas= e of pass-by-reference vs pass-by-value, and that runtime attestations are = not part of the =E2=80=9Cclient instance=E2=80=9D value itself but rather b= elong outside of that object in a another part of the request. As stated in= the editorial notes in this section, we need to look carefully at how thes= e concepts fit within the model and where we would want to put them. Withou= t concrete examples of what these extensions look like and how they=E2=80= =99re generated, that is nearly impossible to do at this stage. I look forw= ard to seeing examples of this kind of data and how it can fit into the pro= tocol.

    =C2=A0<= /u>

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:

    =C2=A0<= u>

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0i= nstance_id =C2=A0An identifier string that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 part= icular instance of this RC.=C2=A0 The content and structure of this<= u>

    =C2=A0 =C2=A0 =C2=A0 identifier= is opaque to the RC.

    =C2=A0

    =C2=A0 =C2=A0"= client": {

    =C2=A0 = =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541-ab"

    =C2=A0 =C2=A0}=

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fields to send= , the RC MAY send the

    = =C2=A0 =C2=A0instance identifier as a direct reference value in lieu of the=

    =C2=A0 =C2=A0object.=

    =C2=A0

    =C2=A0 =C2=A0"client": "clie= nt-541-ab"

    =C2=A0

    The instance= identifier can be sent two ways. Polymorphism is a convenience for the cli= ent, but requires the server=C2=A0to have two code=C2=A0paths for "ins= tance_id".=C2=A0 We discussed this in the design team, and I argued fo= r having "instance_id" in the "client" object=C2=A0so t= hat any updates, such as new devices assertions, could be in the "clie= nt" object. As noted above, while I appreciate the elegance of using a= string (handle) to reference a previously provided object, it complicates = how to update an existing object while providing the reference.

    =C2=A0

    =

    In your example of the "key" object below,= setting "proof" to bearer would avoid the issue you describe:=

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0=C2=A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2= =A0 }
    }

    =C2= =A0

    In your example, when proce= ssing the "key" object, code is having to check both the JSON typ= e of the property, as well as check the value of the "proof" prop= erty. In the example I provided, only the value of "proof" needs = to be checked. The "proof" property is acting as a type for the &= quot;key" object.

    <= u>=C2=A0

    Not being a Java p= rogrammer, I don't know how this would work in a Java implementation, b= ut node.js, the processing would need to be done as above.

    =C2=A0

    On a related note, there was significant negative feedbac= k on handles and polymorphism in the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24855750=C2=A0

    =C2=A0

    /Dick

    =C2=A0

    = =C2=A0

    On Fri, Oct 2= 3, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:=

    Hi Mika,

    =C2=A0

    Thanks for bringing= this topic here =E2=80=94 I was able to see the forum discussion that brou= ght you here, and hopefully I can help clear up what I mean with how polymo= rphism is used in the proposal. The short version is that the goal is to=C2= =A0avoid=C2=A0the kinds of ambiguity that make insecure protocols, a= nd so in that goal we=E2=80=99re fully aligned. I think that using polymorp= hism in very specific ways can help that goal =E2=80=94 just as I agree tha= t misusing it or applying it sloppily can lead to ambiguous and insecure sy= stems.

    =C2=A0<= /u>

    Some background: I built out the X= YZ protocol (one of the predecessors to the initial GNAP Draft) in Java usi= ng strongly typed parsers and Java objects specifically to prove to myself = that it could be done in a way that made any sense in the code. (My own ope= n source implementation is at=C2=A0https://github.com/bspk/oau= th.xyz-java, but note that it=E2=80=99s not yet up to date with the GNA= P spec). It was important to me that I be able to use the system-wide confi= gured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the= hooks into the right places (especially with the Jackson parser that I use= d), but it is definitely possible to create a deterministic and strongly-ty= ped parser and serializer for this kind of data structure. Some of the rati= onale for using polymorphism is covered in the trailing appendix of the dra= ft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protoc= ol-00.html#name-json-structures-and-polymor), but it=E2=80=99s still go= od to discuss this here as the working group decides which approaches to ta= ke.=C2=A0

    =C2=A0<= u>

    The driving reason for using po= lymorphism at the protocol level was to simplify the protocol and make it := more: deterministic to create and process, not less. Every time you create = or process a field it will mean only one thing, and there=E2=80=99s only on= e field to look at to answer a question. Without polymorphic field values, = you usually need to rely on mutual exclusivity of fields, which is prone to= failure and requires additional error checking. Take for example the key b= inding of access tokens. An access token could be bound to the RC=E2=80=99s= key used during the request, to a different key chosen by the AS, or it co= uld be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and obje= cts and express this set of mutually-exclusive options in a non-ambiguous w= ay. Without that, you=E2=80=99d need to have different fields for the optio= ns and include additional checks in your parser to make sure they weren=E2= =80=99t sent simultaneously, otherwise you could get hit with this potentia= l security vulnerability in an object:

    =C2=A0

    {= =C2=A0

    =C2=A0 =C2=A0 key= : {

    =C2=A0 =C2=A0 =C2=A0= proof: httpsig,

    =C2=A0 = =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0

    This would be an illegal object as per this alternate proposal, but the= n you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others in the same object. I=E2=80=99ve done this exercise with m= any other protocols and it=E2=80=99s both error prone and easy to ignore si= nce all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2= =80=99t check this. With the polymorphic approach to this same field, each = of these three mutually-exclusive states is written in a way that they cann= ot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible= and enforced by the syntax of JSON itself.

    =C2=A0

    {=C2=A0

    =C2=A0 = =C2=A0 key: {

    =C2=A0 =C2= =A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // beare= r token

    =C2=A0=

    {

    =C2=A0 =C2=A0 key: false

    }

    =C2=A0

    // bound to = the RC=E2=80=99s presented key

    =C2=A0

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0

    If someone sends a different type for this field, like an array or numb= er or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and would be a protocol level error.

    =C2=A0

    While it might sound like polymorphism means that any field could have an= y type or value, the opposite is true: each possible value is explicitly ty= ped, it=E2=80=99s just that there are potentially different types that expr= ess meaning for the field. This applies to all members of all objects (dict= ionaries) as well as all members of an array (list). Every time you process= a field value or other element, you look at the type and then the value to= determine what to do with that typed value.

    =C2=A0

    In your example below, each field within the dictionary would also need= to be typed, and each type would need to have a clear indication of its me= aning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON strin= g). The definition would further say what exactly the encoding of the strin= g would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D fie= ld there wouldn=E2=80=99t be any confusion on what the value was or how it = was represented, regardless of the input format. Seeing a number there mean= s exactly one interpretation and seeing a string means exactly one (differe= nt) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cm= odulus=E2=80=9D, since that=E2=80=99s the field that determines the type. A= n implementation would likely use an internal BigInteger type of object to = represent the field value after parsing, so the question is how to go from = the JSON value (which is typed) into the BigInteger value.You don=E2=80=99t= just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you a= pply it to all sub-fields of that object.=C2=A0

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up in the straw= man, because it=E2=80=99s interesting: A JSON encoder that encodes numbers = as strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of =E2= =80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON, an= d they shouldn=E2=80=99t be treated the same by a parser implementation whe= n mapping to a concrete object. It=E2=80=99s in this kind of automated gues= sing that this class of bugs occur, and that=E2=80=99s going to be the case= whether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic natu= re. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up i= ntroducing errors in more strict components downstream. This is something t= hat protocol designers need to be aware of and guard against in the design = of the protocol to reduce possible ambiguities. Within GNAP today, we gener= ally have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a refer= ence or other item).=C2=A0

    =C2=A0

    The design tea= m created some simple JSON Schemas for parts of the protocol during our dis= cussion, but we didn=E2=80=99t include them in the design document due to b= oth lack of time to keep it updated with the rapid changes to the protocol = during the design team discussion, and not knowing if there would be intere= st in such material. I personally think it would be helpful to include as a= n informative reference in the final document, but that=E2=80=99s something= for the working group to take up eventually.

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 10:18 AM, Mik= a Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@= dmarc.ietf.org> wrote:

    =C2=A0

    Hello, every= one.

    =C2=A0

    For background: GNAP/TxAuth/XYZ/Oaut= h3 came up on a discussion forum and when I made note about certain concern= s, I was requested to send my comments to this working group.=

    =C2=A0

    In short, I believe that the use of polymorphic JSON i= n the protocol invites subtle and confusing implementation problems. I also= searched through the WG archives, and noticed that similar concerns were n= oted, briefly, in a thread in July.

    =C2=A0

    Th= e problem with polymorphic values, as I see it, is that implementations wil= l need to branch on the (inferred) type of a given field. This isn't qu= ite as bad if the types are strictly different, but allows for subtle bugs = when the value in question is a dictionary. What makes this unappealing is = that "subtle bugs" in security protocols have a habit of turning = into vulnerabilities.

    =C2=A0

    Let's say we ha= ve these imaginary payloads, both possible and valid in the same protocol s= tep:

    =C2=A0

    # payload 1

    <= div>

    {

    =C2=A0 ...,

    =C2=A0 = "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": <= BIGINT>

    =C2=A0 }

    }

    =C2=A0

    # payload 2

    {=

    =C2=A0 ...,<= /p>

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg&= quot;: "rsa",

    = =C2=A0=C2=A0=C2=A0 "modulus": "<encoded string>"<= u>

    =C2=A0 }

    }

    =C2=A0

    In= both cases, the type of "public_key" field is a dictionary. In b= oth cases, they even have the same keys. However, the values in the diction= aries are entirely different, and an implementation will have to branch to = at least two possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, so i= t is possible for an originator to transmit what they expect and believe to= be payload 1 format, but which the receiver will interpret to be in payloa= d 2 format. And if the encoded string contains only digits, it will even pa= rse correctly as a bignum.

    =C2=A0

    While the abov= e is clearly a manufactured scenario, it nonetheless demonstrates the poten= tial for logic bugs with polymorphic JSON. With richer types and more compl= ex dictionaries, there will surely be more room for errors.

    =C2=A0

    Ambiguity in protocols is always a source of implementat= ion complexity and interoperability snags, but in an AuthN/AuthZ protocol i= t is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oa= uth1/2, wouldn't it be in everyone's interest to keep implementatio= n complexity and mistake potential to a minimum?

    =C2=A0

    Best regards,

    Mi= ka

    =C2=A0<= /p>

    --

    Mika Bostr=C3=B6m

    Smarkets

    =

    --
    TXAuth mailing list
    TXAuth@= ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth

    <= u>=C2=A0

    --
    TXAuth mailing l= ist
    TXAuth@ietf.org
    https://www.ietf.org/mailman/= listinfo/txauth

    =E1=90=A7

    =C2=A0

    <= /blockquote>

    = =C2=A0

    --
    TXAuth mailing listTX= Auth@ietf.org
    https://www.ietf.org/mailman/listin= fo/txauth

    -- TXAuth mailing list TXAuth@ietf.o= rg https://www.ietf.org/mailman/listinfo/txauth =

    --0000000000000708c305b27c6f11-- From nobody Sun Oct 25 05:36:34 2020 Return-Path: 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 EC1D23A02BC for ; Sun, 25 Oct 2020 05:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fTxNam47mV5f for ; Sun, 25 Oct 2020 05:36:28 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 537213A0147 for ; Sun, 25 Oct 2020 05:36:28 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id n15so9450127wrq.2 for ; Sun, 25 Oct 2020 05:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=skOEOLmSuxTmU9GPdG4dGkGzW5kdUz+AwQIvujaTIaU=; b=GfzFg0FMI4w1ZdhEasTRu/4n5iNPuygyWBXLGWhrqPOsmA77LpwJLbKBTA+GFAuBcF MANVxQpEd7ob90vK0nTjSs8wX3mm+BS+XTig8QBGg11B7Qiz37Wtf+TduGn+4gyhcQcS FY8dJN+3V/dDQX7wDvGYV5l6g6ampuu1rlE8Q82Y1Q+PfUVwOQsTOcua0bUilXz00FZO zru5Thbhh9bF+nI66c6Elj0ldJlAn19/38D3vqq6IULaoVO4aFpo0v8V1q6N+hBjukwV vOx1oaH3QQthwfJ2SOGRvOcRfXotTrnT3g4ercRIGOAB8CeTpHOQW0AQjx70muedyL3n udtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=skOEOLmSuxTmU9GPdG4dGkGzW5kdUz+AwQIvujaTIaU=; b=HpN6HljshoZDMtTX66ecjhWdXOwZlkV9HCojEYvuc/MtcXC6opOV/AbRK88mAv0/bZ gQKy3D0t1QjAb1oVkHk4MwUFOJ8Rivn8ymkQGbU48lBILLLPqWa/1CxDieBDw4PyxQT2 SIDUcSv4fSywGtaeBrOJLdFaP5NClRAfOAietpLkCztGOqDC3JYQSLNbnWyHBckjdtng 6zWMxXR6cYAthg/abIZDTdg/JHIu6BJHJvrQM0htHpKNVo1stFtVcsVx2VAacoxzB8yr /3DDAondJ1MWx/2s67R/3hG0+bUu1zAS5te1j5n9Tn2vDX9dKVUBey8cuzD92JaIFfSL pavQ== X-Gm-Message-State: AOAM53305bInywLyTBVo0O917ZC9vDiO13KZAevoajk28DGe/fg9PXCK Vugq1k2SDqOAHmxYQhQlfAg= X-Google-Smtp-Source: ABdhPJzOmpNKD/vVVTewveh6NDDw79OzQq406+Xf4oPCEDJp/ba9IJK/mmuD25KxzXNvKB2l3oa3sg== X-Received: by 2002:a5d:6cc8:: with SMTP id c8mr11939440wrc.233.1603629386424; Sun, 25 Oct 2020 05:36:26 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id h4sm17146647wrv.11.2020.10.25.05.36.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2020 05:36:25 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 25 Oct 2020 14:36:23 +0200 From: Yaron Sheffer To: Fabien Imbault CC: Dick Hardt , Mika =?UTF-8?B?Qm9zdHLDtm0=?= , GNAP Mailing List , Justin Richer Message-ID: Thread-Topic: [GNAP] Feedback on polymorphism References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3686481384_679982186" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 12:36:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3686481384_679982186 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Personally, I would support polymorphism in the protocol if it (the RFC) ca= me with a well-defined JSON Schema [1] document, so a recipient can automati= cally validate incoming messages at run-time. I would expect senders to also= validate messages as part of their testing. It=E2=80=99s not an ideal solution, b= ecause: =20 Some people at the IETF don=E2=80=99t like JSON Schema, for various reasons. JSON Schema is not a standard, so it=E2=80=99s painful to require it normatively. Even if it=E2=80=99s normative, some recipients will not validate messages anyway= . =20 This would be shifting some of the complexity from the library developer to= the spec developer, which is the right thing to do IMO. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://json-schema.org/ =20 =20 From: Fabien Imbault Date: Sunday, October 25, 2020 at 12:39 To: Yaron Sheffer Cc: Dick Hardt , Mika Bostr=C3=B6m , GNAP Mailing List , Justin Richer <= jricher@mit.edu> Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Yaron, =20 Thanks for the feedback.=20 =20 Regarding client libraries, I think we can indeed learn a great deal from c= ryptographic libraries. Cryptographic design provides a great amount of flex= ibility for the specialists (including many parameters that you really need = to get right). We might think this is great to provide options but it actual= ly increases the cognitive load of library users. =20 Look instead at what Google has provided with tink as an alternative and yo= u'll see it is a much easier way for cryptographic engineers (who aren't cry= ptographers) to avoid mistakes or misuses.=20 =20 That's the *security* issue I'm referring to (not the fact that being open = they're tasty targets, although that may be related in some cases). And tink= is the kind of design we should be trying to achieve.=20 =20 I agree that it should be applicable to a wide range of well known programm= ing tools, including the likes of java and go.=20 But I don't really see a limitation here. Might not be the most idiomatic f= eel, but it can be made to work.=20 =20 Just so I understand, what alternatives would you prefer to polymorphism? I= can suggest json-ld but even Justin will Teel you it's even more complex :-= )=20 =20 Cheers Fabien=20 =20 Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer a =C3=A9cr= it : Hi Fabien, =20 I think your product management model has a lot of merit, but it does not c= apture the security issue well. =20 I agree that as we look at different customer personas, the =E2=80=9Cend user=E2=80=9D = (the developer that=E2=80=99s using the libraries) should be our highest priority.= But I disagree about end-user mistakes being the top *security* issue. Libr= aries are often open source in our space and used very widely. So they make = for tasty targets, and people are attacking them and are still finding secur= ity issues in libraries that we=E2=80=99ve been talking about forever [1]. =20 (Yes, my example is actually an app flaw, but I think it could have been pr= evented by a better designed library.) =20 In other words, we do need to care about how easy it is to implement the pr= otocol correctly by *library* developers. From Justin describing his own exp= erience and other people on the thread that Dick referred to, I would say th= at JSON polymorphism is painful for Java and Go developers. With all due res= pect, I care about them much more than I care about Haskell, as many more im= plementations are likely to use these languages. =20 Thanks, Yaron =20 [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing= -app/ =20 From: TXAuth on behalf of Fabien Imbault Date: Sunday, October 25, 2020 at 01:25 To: Dick Hardt Cc: Mika Bostr=C3=B6m , GNAP Mailin= g List , Justin Richer Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Dick, =20 Independantly from the debate on polyphormism, I beg to differ on your orde= r preference.=20 =20 Your assumption is that AS devs matter the most, because they're doing the = important security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spec= are unable to deal with the complexity that is passed onto them.=20 =20 99% of the people that will actually use the output of the work are applica= tion developers (client or RS) and their own users.=20 =20 Our intent as well as the protocol drive the usage. Client libraries may he= lp, but they're not a silver bullet, especially because GNAP ultimately has = no control about what people do there (for better or worse). And everything = we do here will help get to the better part.=20 =20 I'm not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't forget that a= nyway.=20 =20 Fabien=20 =20 =20 Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3=A9crit : I'm confused by your logic Fabien. =20 If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=20 =20 I differ on who our stakeholders are.=20 =20 I think our stakeholders are in least to most important: =20 AS developer RS developer client developer user =20 A client library developer can expose whatever interface they want to simpl= ify implementation. =20 I list the user so that we don't lose site of a critical role. =20 /Dick =20 =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault w= rote: Hi there,=20 =20 Let me try to approach the issue under a different light. More like a produ= ct manager would deal with feature selection to make it intuitive for its us= ers.=20 =20 For most people, riding a bike is far easier than using a unicycle. Feels m= ore stable. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chain rin= g, etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized.=20 =20 Back to the GNAP topic.=20 Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=20 (short answer: the priority should be simplicity for spec users, not spec i= mplementers and even less spec designers).=20 =20 The initial question that is asked is very interesting: isn't the design fl= awed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are look= ing for a global unique identifier? The argument stems of the fact that is s= till arguably harder and more error prone to implement. Fair enough.=20 =20 >From a spec implementer's perspective, it may well be more complex. It most= ly impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite not e= xactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I= mean, I wished it could be simpler, but it's manageable and there are other= ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still ea= sier from an implementation perspective than say, json-ld, which is massivel= y used in the SSI community.=20 =20 But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot? =20 The job to be done (JTBD), from the end-developer's perspective, is to effi= ciently ship an application. And provide authN/authZ capabilities for end-us= ers by relying on some well known implementation.=20 In turn, this spec implementer will rely on cryptographic utility libraries= that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts with= the title "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=20 Note that any decent flamewar will be efficiently fueled by people hating m= edium. Is it outrageous for blog posts to be behind a paywall? Maybe but it'= s even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the contrary = by to not paying a subscription if you believe that surveillance capitalism,= to reuse Zuboff's terms, should be eradicated.=20 What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, yo= u might not want to deal with hosting your own blog. But maybe as a reader y= ou'll find that annoying. Different audiences, different JTBD, different tra= deoffs.=20 =20 Polyphormism is a tool that enables the end-developer to have minimal knowl= edge of what it means to deal with a GNAP client library. You prepare the re= quest, send to the endpoint and you're good to go. Massively simpler than OA= uth2 or any similar protocol by the way (as anyone with teaching experience = on the subject might acknowledge). And there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-use= r.=20 =20 If we find a better way to deal with that simplicity balance, I'm all in. B= ut the arguments need to be way more convincing than just saying that it may= be difficult to implement or validate.=20 =20 Cheers. Fabien =20 =20 =20 =20 =20 Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9crit : =20 =20 On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: =20 Justin =20 I did note that I was the one that argued for instance_id being in the obje= ct. Since it is in the object in the current draft, not including a pass by = reference option would be preferable.=20 =20 As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on =20 These are all attributes of the client that an AS may require on the initia= l grant request, and in future grant requests (which is when an instance_id)= would be used. =20 =20 This is where our interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattribu= tes of the client=E2=80=9D in the same way that the key, display information, clas= s identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t modify = the instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a sepa= rate object, so you=E2=80=99d have something like this strawman: =20 { =20 posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, =20 client: =E2=80=9Cclient-541-ab" =20 } =20 This is a more fundamental question about GNAP than whether the syntax uses= polymorphism: this is about GNAP being very explicit about the data model o= f its elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the ter= m =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. = We=E2=80=99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in GNAP w= ith explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be mo= re precise about what exactly a client instance includes, and what it does n= ot. =20 =E2=80=94 Justin =20 =20 /Dick =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: Dick, =20 As you=E2=80=99ll recall, I argued against including the client instance identifi= er inside of the object as a mutually-exclusive field precisely because of t= he principle violation that you are pointing out here, and so it=E2=80=99s importa= nt to point out that the current text is a compromise that needs to be exami= ned in the wider experience of the working group. I am on the side of removi= ng the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored. =20 The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Cclient in= stance=E2=80=9D value itself but rather belong outside of that object in a another= part of the request. As stated in the editorial notes in this section, we n= eed to look carefully at how these concepts fit within the model and where w= e would want to put them. Without concrete examples of what these extensions= look like and how they=E2=80=99re generated, that is nearly impossible to do at t= his stage. I look forward to seeing examples of this kind of data and how it= can fit into the protocol. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: =20 Hey Justin, =20 As the draft has evolved, I question the continued use of polymorphism. Not= e that I appreciate the elegance of using a string for pass-by-reference, an= d an object for pass-by-value. =20 In the current draft, the=20 =20 Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question.=20 =20 is violated in 2.3.1. Identifying the RC Instance =20 =20 instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. =20 "client": { "instance_id": "client-541-ab" } =20 If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. =20 "client": "client-541-ab" =20 The instance identifier can be sent two ways. Polymorphism is a convenience= for the client, but requires the server to have two code paths for "instanc= e_id". We discussed this in the design team, and I argued for having "insta= nce_id" in the "client" object so that any updates, such as new devices asse= rtions, could be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference. =20 In your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe: =20 {=20 "key": {=20 "proof": "bearer"=20 }=20 } =20 In your example, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "proof= " property. In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "key" object. =20 Not being a Java programmer, I don't know how this would work in a Java imp= lementation, but node.js, the processing would need to be done as above. =20 On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D= 24855750=20 =20 /Dick =20 =20 On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: Hi Mika, =20 Thanks for bringing this topic here =E2=80=94 I was able to see the forum discuss= ion that brought you here, and hopefully I can help clear up what I mean wit= h how polymorphism is used in the proposal. The short version is that the go= al is to avoid the kinds of ambiguity that make insecure protocols, and so i= n that goal we=E2=80=99re fully aligned. I think that using polymorphism in very s= pecific ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems. =20 Some background: I built out the XYZ protocol (one of the predecessors to t= he initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made an= y sense in the code. (My own open source implementation is at https://github= .com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the G= NAP spec). It was important to me that I be able to use the system-wide conf= igured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the hooks = into the right places (especially with the Jackson parser that I used), but = it is definitely possible to create a deterministic and strongly-typed parse= r and serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft document= (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name= -json-structures-and-polymor), but it=E2=80=99s still good to discuss this here as= the working group decides which approaches to take.=20 =20 The driving reason for using polymorphism at the protocol level was to simp= lify the protocol and make it :more: deterministic to create and process, no= t less. Every time you create or process a field it will mean only one thing= , and there=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fiel= ds, which is prone to failure and requires additional error checking. Take f= or example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way. = Without that, you=E2=80=99d need to have different fields for the options and incl= ude additional checks in your parser to make sure they weren=E2=80=99t sent simult= aneously, otherwise you could get hit with this potential security vulnerabi= lity in an object: =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } =20 This would be an illegal object as per this alternate proposal, but then yo= u=E2=80=99d have to check each field and make sure it wasn=E2=80=99t put next to others = in the same object. I=E2=80=99ve done this exercise with many other protocols and = it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples= would pass code that doesn=E2=80=99t check this. With the polymorphic approach to= this same field, each of these three mutually-exclusive states is written i= n a way that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s i= mpossible and enforced by the syntax of JSON itself. =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } =20 // bearer token =20 { key: false } =20 // bound to the RC=E2=80=99s presented key =20 { key: true } =20 If someone sends a different type for this field, like an array or number o= r a null, this doesn=E2=80=99t have a defined interpretation in the protocol and w= ould be a protocol level error. =20 While it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly typed= , it=E2=80=99s just that there are potentially different types that express meanin= g for the field. This applies to all members of all objects (dictionaries) a= s well as all members of an array (list). Every time you process a field val= ue or other element, you look at the type and then the value to determine wh= at to do with that typed value. =20 In your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its meaning= . To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be d= efined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what exactl= y the encoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number ther= e means exactly one interpretation and seeing a string means exactly one (di= fferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80= =9D, since that=E2=80=99s the field that determines the type. An implementation woul= d likely use an internal BigInteger type of object to represent the field va= lue after parsing, so the question is how to go from the JSON value (which i= s typed) into the BigInteger value.You don=E2=80=99t just apply the type rules on = the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object.=20 =20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take advantage of JSON=E2=80=99s polymorph= ic nature. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing er= rors in more strict components downstream. This is something that protocol d= esigners need to be aware of and guard against in the design of the protocol= to reduce possible ambiguities. Within GNAP today, we generally have things= that branch whether they=E2=80=99re an object (for a rich description of somethin= g) or some non-structured special value (for a reference or other item).=20 =20 The design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design document d= ue to both lack of time to keep it updated with the rapid changes to the pro= tocol during the design team discussion, and not knowing if there would be i= nterest in such material. I personally think it would be helpful to include = as an informative reference in the final document, but that=E2=80=99s something fo= r the working group to take up eventually. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m wrote: =20 Hello, everyone. =20 For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments t= o this working group. =20 In short, I believe that the use of polymorphic JSON in the protocol invite= s subtle and confusing implementation problems. I also searched through the = WG archives, and noticed that similar concerns were noted, briefly, in a thr= ead in July.=20 =20 The problem with polymorphic values, as I see it, is that implementations w= ill need to branch on the (inferred) type of a given field. This isn't quite= as bad if the types are strictly different, but allows for subtle bugs when= the value in question is a dictionary. What makes this unappealing is that = "subtle bugs" in security protocols have a habit of turning into vulnerabili= ties. =20 Let's say we have these imaginary payloads, both possible and valid in the = same protocol step: =20 # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } =20 # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } =20 In both cases, the type of "public_key" field is a dictionary. In both case= s, they even have the same keys. However, the values in the dictionaries are= entirely different, and an implementation will have to branch to at least t= wo possible decoding mechanisms. To make things worse, some JSON implementat= ions may choose to encode non-dictionary values as strings, so it is possibl= e for an originator to transmit what they expect and believe to be payload 1= format, but which the receiver will interpret to be in payload 2 format. An= d if the encoded string contains only digits, it will even parse correctly a= s a bignum. =20 While the above is clearly a manufactured scenario, it nonetheless demonstr= ates the potential for logic bugs with polymorphic JSON. With richer types a= nd more complex dictionaries, there will surely be more room for errors. =20 Ambiguity in protocols is always a source of implementation complexity and = interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's ter= rifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in= everyone's interest to keep implementation complexity and mistake potential= to a minimum? =20 Best regards, Mika =20 --=20 Mika Bostr=C3=B6m Smarkets --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth Error! Filename not specified.=E1=90=A7 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3686481384_679982186 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Personally, I would s= upport polymorphism in the protocol if it (the RFC) came with a well-defined= JSON Schema [1] document, so a recipient can automatically validate incomin= g messages at run-time. I would expect senders to also validate messages as = part of their testing. It=E2=80=99s not an ideal solution, because:

    =

     

    • = Some people at the IETF don=E2=80=99t like JSON Schema, for various reasons.<= /o:p>
    • JSON Schema is not a standard, so it=E2=80=99s painful to require it norm= atively.
    • Even if it=E2=80=99s normative, some recipients will not va= lidate messages anyway.

     

    This would be shifting some of the complexity fro= m the library developer to the spec developer, which is the right thing to d= o IMO.

     

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Yaron

     

    [1] https://json-schema.org/

     =

     

    <= b>From: Fabien Imbault <fabien.imbault@gmail.com>=
    Date: Sunday, October 25, 2020 at 12:39
    To: Yaron Sheff= er <yaronf.ietf@gmail.com>
    Cc: Dick Hardt <dick.hardt@gma= il.com>, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>= , GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.e= du>
    Subject: Re: [GNAP] Feedback on polymorphism

     

    Hi Yaron,

     

    Thanks for the feedback. =

     

    Regarding client libraries, I think we can indeed learn a great deal from= cryptographic libraries. Cryptographic design provides a great amount of fl= exibility for the specialists (including many parameters that you really nee= d to get right). We might think this is great to provide options but it actu= ally increases the cognitive load of library users.

     

    Look = instead at what Google has provided with tink as an alternative and you'll s= ee it is a much easier way for cryptographic engineers (who aren't cryptogra= phers) to avoid mistakes or misuses. 

     

    That's the *se= curity* issue I'm referring to (not the fact that being open they're tasty t= argets, although that may be related in some cases). And tink is the kind of= design we should be trying to achieve. 

     

    I agree tha= t it should be applicable to a wide range of well known programming tools, i= ncluding the likes of java and go. 

    But I don't really see a limitation here. Might not be the most idi= omatic feel, but it can be made to work. 

     

    Just so I = understand, what alternatives would you prefer to polymorphism? I can sugges= t json-ld but even Justin will Teel you it's even more complex :-) 

     

    Cheers

    Fabien&nb= sp;

     

    Le dim. 25 oct. 2020 =C3=A0 11:17,= Yaron Sheffer <yaronf.ietf@gmail.= com> a =C3=A9crit :

    Hi Fabien,

     

    I think your product management model has a lot of merit, but it does= not capture the security issue well.

     

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >I agree that as we look at different customer personas, the =E2=80=9Cend user=E2=80=9D = (the developer that=E2=80=99s using the libraries) should be our highest priority.= But I disagree about end-user mistakes being the top *security* issu= e. Libraries are often open source in our space and used very widely. So the= y make for tasty targets, and people are attacking them and are still findin= g security issues in libraries that we=E2=80=99ve been talking about forever [1].<= o:p>

     

    (Yes, my example is actually an app f= law, but I think it could have been prevented by a better designed library.)=

     

    In other words, we do need to care a= bout how easy it is to implement the protocol correctly by *library* = developers. From Justin describing his own experience and other people on th= e thread that Dick referred to, I would say that JSON polymorphism is painfu= l for Java and Go developers. With all due respect, I care about them much m= ore than I care about Haskell, as many more implementations are likely to us= e these languages.

     

    Thanks,=

               &nbs= p;    Yaron

     

    [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs= -contact-tracing-app/

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault= <fabien.imbaul= t@gmail.com>
    Date: Sunday, October 25, 2020 at 01:25
    = To: Dick Hardt <dick.hardt@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom=3D<= a href=3D"mailto:40smarkets.com@dmarc.ietf.org" target=3D"_blank">40smarkets.com= @dmarc.ietf.org>, GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
    Subject: <= /b>Re: [GNAP] Feedback on polymorphism

    &nb= sp;

    Hi Dick,

     

    Independantly from the debate on polyphormism, I beg to d= iffer on your order preference. 

     =

    Your assumption is that AS devs matter the most, because they're doing the impo= rtant security implementation. But eating our own dogfood might help a lot t= o change that view. Most security issues occur because users of the spec are= unable to deal with the complexity that is passed onto them. 

     

    99% of the peopl= e that will actually use the output of the work are application developers (= client or RS) and their own users. 

     

    Our i= ntent as well as the protocol drive the usage. Client libraries may help, bu= t they're not a silver bullet, especially because GNAP ultimately has no con= trol about what people do there (for better or worse). And everything we do = here will help get to the better part. 

     

    I'm not saying we don't intend to also = care about AS developers (beginning with ourselves) but it's a second order = optimisation. And since it's a tendancy we're leaning towards by default, I'= m pretty sure we won't forget that anyway. 

    =  

    Fabien 

     

     

    Le sam. 24 = oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    I'm confused by your logic Fabien.

    &= nbsp;

    If a client library developer wants to expo= se polymorphism, they can do that independent of what is in the protocol.&nb= sp;

     

    I differ on= who our stakeholders are. 

     

    I think our stakeholders are in least to most important:

     

    • AS developer
    • client developer
    • user
    =

     

    A client library developer can expose wh= atever interface they want to simplify implementation.

    <= div>

     

    I list the user so that we don't los= e site of a critical role.

     

    <= /div>

    /Dick

     

     

    Error! Filename not specified.=E1=90=A7<= o:p>

     

    On Fri, Oct 23, 2020 = at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi there, 

     

    Let me try to approach the issue under a different light. More= like a product manager would deal with feature selection to make it intuiti= ve for its users. 

     

    For most people, riding a bike is far easier than using a unicycle. = Feels more stable. And yet it's way easier to design for a single wheel than= to build with 2. Because then you'll need a lot more accessories (chain, ch= ain ring, etc.). Even so producing a bike doesn't have to be a brittle proce= ss, it can be industrialized. 

     

    Back to the GNAP topic. 

    Ultimately we should strive to make= the spec as simple as can be. But we need to ask: simple for whom? For the = bike owner or for the bike vendor? 

    <= span style=3D'font-family:"Arial",sans-serif'>(short answer: the priority shou= ld be simplicity for spec users, not spec implementers and even less spec de= signers). 

     

    The initial question that is asked is very interesting: isn't the de= sign flawed if GNAP is using json polyphormism? Or if the AS needs to handle= the state of the request? Or if we must handle token revocation? Or if we a= re looking for a global unique identifier? The argument stems of the fact th= at is still arguably harder and more error prone to implement. Fair enough.&= nbsp;

     

    From a sp= ec implementer's perspective, it may well be more complex. It mostly impacts= the json library you'll end up using, plus a bit of input/output decoration= around it. Even golang provides utilities for this, despite not exactly bei= ng made for this kind of purpose.

    My practical ex= perience implementing it is that it's not that big a deal. I mean, I wished = it could be simpler, but it's manageable and there are other ways to reach l= evels of insurance that it does work as intended (json schema, test cases to= validate the implementation, etc.). Arguably it is still easier from an imp= lementation perspective than say, json-ld, which is massively used in the SS= I community. 

     

    But ultimately who are we designing for? Are we striving to go easy on t= he spec implementer? Or are we trying to make sure end-developers using the = client libraries won't shoot themselves in the foot?

     

    The job to be done (JTBD), from the en= d-developer's perspective, is to efficiently ship an application. And provid= e authN/authZ capabilities for end-users by relying on some well known imple= mentation. 

    In turn, this spec implementer w= ill rely on cryptographic utility libraries that deals internally with the c= omplexity of their own domain, so that we don't have to. And here we could l= aunch another HN flame war that starts with the title "JWT sucks becaus= e". Which does have its set of very real issues but that's beyond the p= oint. 

    Note that any decent flamewar will be= efficiently fueled by people hating medium. Is it outrageous for blog posts= to be behind a paywall? Maybe but it's even more outrageous to lack consist= ency, either by not knowing how to get around a paywall if you're into a hac= ker punk movement, or on the contrary by to not paying a subscription if you= believe that surveillance capitalism, to reuse Zuboff's terms, should be er= adicated. 

    What likely seems an unnecessary = sidenote tries to illustrate the point: for Justin it was easier to publish = on medium, because as a blog publisher, you might not want to deal with host= ing your own blog. But maybe as a reader you'll find that annoying. Differen= t audiences, different JTBD, different tradeoffs. 

    =

     

    Polyphormism is a tool that enables= the end-developer to have minimal knowledge of what it means to deal with a= GNAP client library. You prepare the request, send to the endpoint and you'= re good to go. Massively simpler than OAuth2 or any similar protocol by the = way (as anyone with teaching experience on the subject might acknowledge). A= nd  there's a lot more to be done to make sure we indeed reduce the com= plexity for the end-developer and the end-user. 

     

    If we find a better way to deal with = that simplicity balance, I'm all in. But the arguments need to be way more c= onvincing than just saying that it may be difficult to implement or validate= . 

     

    Cheers.=

    Fabien

     

     

     

    <= /div>

     

     =

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit = :

     

     

    On Oct= 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    &n= bsp;

    Justin

     =

    I did note that I was the one that argued for instance_id b= eing in the object. Since it is in the object in the current draft, not incl= uding a pass by reference option would be preferable. 

     

    As for concrete examples:<= /o:p>

    - version of client

    - versi= on of OS

    - security attestation of OS / device

    - location of client device

    - network client is operating on

     <= /o:p>

    These are all attributes of the client that an AS may = require on the initial grant request, and in future grant requests (whi= ch is when an instance_id) would be used.

     <= o:p>

     

    This is where our interpretations differ: I don=E2=80=99t see these as =E2= =80=9Cattributes of the client=E2=80=9D in the same way that the key, display informat= ion, class identifiers, and other items currently represented by an instance= _id are attributes of the client instance. The attestation components don=E2=80=99= t modify the instance so much as present additional information on top of th= e client instance itself. This is why I argue that they ought to be handled = in a separate object, so you=E2=80=99d have something like this strawman:

     

    {

    <= div>

     

      posture: {

        software_version: 1.2.3,

    &= nbsp;   os_version: 14.3.2

        dev= ice_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }

        location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

      },

     

      client: =E2=80=9Cclient-541-ab"

     

    }

     

    This is a more fundamental question about GNAP than = whether the syntax uses polymorphism: this is about GNAP being very explicit= about the data model of its elements. OAuth 2=E2=80=99s incredibly loose and broa= d model of what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pr= oblematic in practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with h= aving to define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t fu= lly capture the different aspects that are out there. I think we=E2=80=99re gettin= g closer here in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, but= we still need to be more precise about what exactly a client instance inclu= des, and what it does not.

     

    <= /div>

     =E2=80=94 Justin

     

     

    /Dick

     

    =

    <= b>Error! Filename not specified.=E1=90=A7

    &n= bsp;

    On Fri, Oct 23, 2020 at 12:42 PM Justin Riche= r <jricher@mit.edu&g= t; wrote:

    Dick,

    &n= bsp;

    As you=E2=80=99ll recall, I argued against includi= ng the client instance identifier inside of the object as a mutually-exclusi= ve field precisely because of the principle violation that you are pointing = out here, and so it=E2=80=99s important to point out that the current text is a co= mpromise that needs to be examined in the wider experience of the working gr= oup. I am on the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D o= ption within an object, but this needs to be explored.

    <= div>

     

    The crux of my argument is that is e= xactly a case of pass-by-reference vs pass-by-value, and that runtime attest= ations are not part of the =E2=80=9Cclient instance=E2=80=9D value itself but rather bel= ong outside of that object in a another part of the request. As stated in th= e editorial notes in this section, we need to look carefully at how these co= ncepts fit within the model and where we would want to put them. Without con= crete examples of what these extensions look like and how they=E2=80=99re generate= d, that is nearly impossible to do at this stage. I look forward to seeing e= xamples of this kind of data and how it can fit into the protocol.

     

     =E2=80=94 Justin

     

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com&g= t; wrote:

     

    Hey Ju= stin,

     

    As the draft ha= s evolved, I question the continued use of polymorphism. Note that I appreci= ate the elegance of using a string for pass-by-reference, and an object= for pass-by-value.

     

    In the current draft, the 

     <= /o:p>

    Every time you create or process a fi= eld it will mean only one thing, and there=E2=80=99s only one field to look at to = answer a question. 

     =

     =

     

      &= nbsp;instance_id  An identifier string that the AS can use to identify = the

          particular instance of t= his RC.  The content and structure of this

    &= nbsp;     identifier is opaque to the RC.

     

       "client": {=

           "instance_id": &= quot;client-541-ab"

       }

     

       If there ar= e no additional fields to send, the RC MAY send the

       instance identifier as a direct reference value in lieu of t= he

       object.

    =

     

       "client": "c= lient-541-ab"

     =

    The instance identifier can be sent two ways. Polymorphism = is a convenience for the client, but requires the server to have two co= de paths for "instance_id".  We discussed this in the de= sign team, and I argued for having "instance_id" in the "clie= nt" object so that any updates, such as new devices assertions, co= uld be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference.

     

    In yo= ur example of the "key" object below, setting "proof" to= bearer would avoid the issue you describe:

     = ;

    { 
     "key": { 
    &n= bsp;    "proof": "bearer"
        } =
    }

     

    In your e= xample, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "= proof" property. In the example I provided, only the value of "pro= of" needs to be checked. The "proof" property is acting as a = type for the "key" object.

     <= /o:p>

    Not being a Java programmer, I don't know how this wou= ld work in a Java implementation, but node.js, the processing would need to = be done as above.

     

    On a related note, there was significant negative feedback on handles and= polymorphism in the Hacker News article https://news.ycombinator.com/item?= id=3D24855750 

     

    =

    /Dick

     

    &n= bsp;

    On Fri, Oct 23, 2020 at 10:20 AM = Justin Richer <jricher@m= it.edu> wrote:

    Hi Mika,

     

    Thanks for bringing this topi= c here =E2=80=94 I was able to see the forum discussion that brought you here, and= hopefully I can help clear up what I mean with how polymorphism is used in = the proposal. The short version is that the goal is to avoid&nbs= p;the kinds of ambiguity that make insecure protocols, and so in that goal w= e=E2=80=99re fully aligned. I think that using polymorphism in very specific ways = can help that goal =E2=80=94 just as I agree that misusing it or applying it slopp= ily can lead to ambiguous and insecure systems.

    &= nbsp;

    Some background: I built out the XYZ protoc= ol (one of the predecessors to the initial GNAP Draft) in Java using strongl= y typed parsers and Java objects specifically to prove to myself that it cou= ld be done in a way that made any sense in the code. (My own open source imp= lementation is at https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s= not yet up to date with the GNAP spec). It was important to me that I be ab= le to use the system-wide configured parsers to implement this and not have = to resort to stepping through elements completely by hand. Java doesn=E2=80=99t ma= ke it simple to get the hooks into the right places (especially with the Jac= kson parser that I used), but it is definitely possible to create a determin= istic and strongly-typed parser and serializer for this kind of data structu= re. Some of the rationale for using polymorphism is covered in the trailing = appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.ht= ml#name-json-structures-and-polymor), but it=E2=80=99s still good to discuss t= his here as the working group decides which approaches to take. 

     

    The driving reason fo= r using polymorphism at the protocol level was to simplify the protocol and = make it :more: deterministic to create and process, not less. Every time you= create or process a field it will mean only one thing, and there=E2=80=99s only o= ne field to look at to answer a question. Without polymorphic field values, = you usually need to rely on mutual exclusivity of fields, which is prone to = failure and requires additional error checking. Take for example the key bin= ding of access tokens. An access token could be bound to the RC=E2=80=99s key used= during the request, to a different key chosen by the AS, or it could be a b= earer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, w= e can define it in terms of boolean values and objects and express this set = of mutually-exclusive options in a non-ambiguous way. Without that, you=E2=80=99d = need to have different fields for the options and include additional checks = in your parser to make sure they weren=E2=80=99t sent simultaneously, otherwise yo= u could get hit with this potential security vulnerability in an object:

     

    { =

        key: {

      &nbs= p;   proof: httpsig,

          jw= k: { =E2=80=A6 key value =E2=80=A6 }

        },

        bearer_token: true,

        bind_to_rc_key: true

    }

     

    This would be an illeg= al object as per this alternate proposal, but then you=E2=80=99d have to check eac= h field and make sure it wasn=E2=80=99t put next to others in the same object. I=E2=80= =99ve done this exercise with many other protocols and it=E2=80=99s both error prone= and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code that d= oesn=E2=80=99t check this. With the polymorphic approach to this same field, each = of these three mutually-exclusive states is written in a way that they canno= t be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and enforced = by the syntax of JSON itself.

     

    { 

        key: {<= o:p>

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

        }

    }

     

    // bearer token

     

    {

    &n= bsp;   key: false

    }

     

    // bound to the RC=E2=80=99s presented = key

     

    {

        key: true

    }<= /o:p>

     

    If someone sends a d= ifferent type for this field, like an array or number or a null, this doesn=E2= =80=99t have a defined interpretation in the protocol and would be a protocol le= vel error.

     

    Whil= e it might sound like polymorphism means that any field could have any type = or value, the opposite is true: each possible value is explicitly typed, it=E2= =80=99s just that there are potentially different types that express meaning for= the field. This applies to all members of all objects (dictionaries) as wel= l as all members of an array (list). Every time you process a field value or= other element, you look at the type and then the value to determine what to= do with that typed value.

     

    <= /div>

    In your example below, each field within the dictionary would al= so need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field= could be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) o= r an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would further say = what exactly the encoding of the string would be. That means that when you r= ead the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the va= lue was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means exac= tly one (different) interpretation =E2=80=94 but importantly, both of them are a =E2= =80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines the type. An implemen= tation would likely use an internal BigInteger type of object to represent t= he field value after parsing, so the question is how to go from the JSON val= ue (which is typed) into the BigInteger value.You don=E2=80=99t just apply the typ= e rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of tha= t object. 

     

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take  advantage of JSON=E2=80=99s poly= morphic nature. I=E2=80=99ve run into cases where a parser library was trying to b= e overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introduci= ng errors in more strict components downstream. This is something that proto= col designers need to be aware of and guard against in the design of the pro= tocol to reduce possible ambiguities. Within GNAP today, we generally have t= hings that branch whether they=E2=80=99re an object (for a rich description of som= ething) or some non-structured special value (for a reference or other item)= . 

     

    The des= ign team created some simple JSON Schemas for parts of the protocol during o= ur discussion, but we didn=E2=80=99t include them in the design document due to bo= th lack of time to keep it updated with the rapid changes to the protocol du= ring the design team discussion, and not knowing if there would be interest = in such material. I personally think it would be helpful to include as an in= formative reference in the final document, but that=E2=80=99s something for the wo= rking group to take up eventually.

     

     =E2=80=94 Justin

     <= /p>

    On Oct 23= , 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.iet= f.org> wrote:

     

    Hello, everyone.

     

    =

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my comm= ents to this working group.

     

    =

    In short, I believe that the use of polymorphic JSON in the pro= tocol invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, brief= ly, in a thread in July.

     

    The problem with polymorphic values, as I see it, is that impleme= ntations will need to branch on the (inferred) type of a given field. This i= sn't quite as bad if the types are strictly different, but allows for subtle= bugs when the value in question is a dictionary. What makes this unappealin= g is that "subtle bugs" in security protocols have a habit of turn= ing into vulnerabilities.

     

    Let's say we have these imaginary payloads, both possible and val= id in the same protocol step:

     

    # payload 1

    {

    =

      ...,

      "public_key":= {

        "alg": "rsa&= quot;,

        "modulus": &l= t;BIGINT>

      }

    = }

     

    # payload 2

    {

      ...,

      "public_key": {

    =

        "alg": "rsa",

    <= div>

        "modulus": "<encoded string>&q= uot;

      }

    }

     

    In both cases, the ty= pe of "public_key" field is a dictionary. In both cases, they even= have the same keys. However, the values in the dictionaries are entirely di= fferent, and an implementation will have to branch to at least two possible = decoding mechanisms. To make things worse, some JSON implementations may cho= ose to encode non-dictionary values as strings, so it is possible for an ori= ginator to transmit what they expect and believe to be payload 1 format, but= which the receiver will interpret to be in payload 2 format. And if the enc= oded string contains only digits, it will even parse correctly as a bignum.<= o:p>

     

    While the above= is clearly a manufactured scenario, it nonetheless demonstrates the potenti= al for logic bugs with polymorphic JSON. With richer types and more complex = dictionaries, there will surely be more room for errors.

     

    Ambiguity in protocols is always a= source of implementation complexity and interoperability snags, but in an A= uthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is intended= to supersede Oauth1/2, wouldn't it be in everyone's interest to keep implem= entation complexity and mistake potential to a minimum?

    =

     

    Best regards,

    <= div>

    Mika

     

    -- <= /o:p>

    Mika Bostr=C3=B6m

    Smarkets

    -- =
    TXAuth mailing list
    = TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

     

    --
    TXAuth m= ailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth

    Error! Filename not specified.=E1=90=A7

     

    <= /div>

     

    --
    TXAuth m= ailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth

    -- TXAuth mailing = list TXAuth@ietf.org https:/= /www.ietf.org/mailman/listinfo/txauth

    --B_3686481384_679982186-- From nobody Sun Oct 25 05:48:13 2020 Return-Path: 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 6C38A3A03F3 for ; Sun, 25 Oct 2020 05:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 fvLQlTmqE7V8 for ; Sun, 25 Oct 2020 05:48:06 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 AB0943A03F2 for ; Sun, 25 Oct 2020 05:48:06 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id q1so5686068ilt.6 for ; Sun, 25 Oct 2020 05:48:06 -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=OXlfpjsFodkgkPsqp9f5cPYQF+br8eOfS+uCKgN26SE=; b=TwKiXyb9G910r+EsTs8ctBIF82GK3WQZCWwXeIgijv6mTnv/wyNDTzCVBHBjLqPPRY scaOVT7x3DynP1vbXD4u8id2CQ0JDAKA3NFzErYXjZ4aezTsEJhWMlXvEmTeWvCHfVSX 3Cym9HMZD5zNX1eNWgy4LiU+so2REhfdDVBBe6uEYB4BTu76NWmQZ4UABJHibmieWnx0 2POKI06bKJa1R5H8u6YoZWSkb1E0meQdD3NM1hioeqZtVprUqcNvFk6QAa99oEJssXHo /C4UEusPVeCERXXgHxFv32RKDXtNVqn/NnfisZRSOGnURArRNlMhmnqZYu+Pz33H0LWK YroA== 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=OXlfpjsFodkgkPsqp9f5cPYQF+br8eOfS+uCKgN26SE=; b=IcooMyWQCJuubuVroHg8XjtXlXu5aDK797isFp2Bz0PlQLh55SFMdFrGHdD0w4tbrh a0mVtTayRDWzRjeU4fHlNzPB3FUTZ20RoqAk25/Yw+ny/2yvCWrEOPK9eM4lfY0FZoi6 V10/gkXQtcRM6aOOuswTE+Q0wmb10niv48X93UO5ZXcjE2bDjHNpd5fG4f9j3ztuR6JS h6kbXxjZqBdaQO3b0nWWe0+bV8kHNSeTH8Mb60dCM/LDD7GO+pVpWlH9lyxDCrKFXDQZ Es0Vfo14n/yyNGtOHOGeiUMxBbWv7CKKE/FxzvgtIt6pIXrJIA4rXnyQFcSyUK+hPZNU odgQ== X-Gm-Message-State: AOAM5319y8syEu1XwZGz4O8agulMIR3N+5cC9Blv1HSLZ1Vl+RfaV3LN 4wSYSYHY3rZ8eBMWO4LD7KW8q947EyxYgnNT3wfKPC53 X-Google-Smtp-Source: ABdhPJzBH8C2Ipp6gQQYWJSK7BQOlxugJG4G2cJgEBpDFzCDZS2atcyUL+KTi14j1hw8TqPcXi4GKkInU7Gy5BIFsdQ= X-Received: by 2002:a92:1548:: with SMTP id v69mr2975266ilk.68.1603630085617; Sun, 25 Oct 2020 05:48:05 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> In-Reply-To: From: Fabien Imbault Date: Sun, 25 Oct 2020 13:47:53 +0100 Message-ID: To: Yaron Sheffer Cc: Dick Hardt , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="0000000000009abc8605b27e3995" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 12:48:12 -0000 --0000000000009abc8605b27e3995 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, As Justin explained that's the kind of idea we tested. For instance https://github.com/fimbault/test_gnap_schema (in rust). Cheers Fabien Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer a =C3=A9crit : > Personally, I would support polymorphism in the protocol if it (the RFC) > came with a well-defined JSON Schema [1] document, so a recipient can > automatically validate incoming messages at run-time. I would expect > senders to also validate messages as part of their testing. It=E2=80=99s = not an > ideal solution, because: > > > > - Some people at the IETF don=E2=80=99t like JSON Schema, for various = reasons. > - JSON Schema is not a standard, so it=E2=80=99s painful to require it > normatively. > - Even if it=E2=80=99s normative, some recipients will not validate me= ssages > anyway. > > > > This would be shifting some of the complexity from the library developer > to the spec developer, which is the right thing to do IMO. > > > > Thanks, > > Yaron > > > > [1] https://json-schema.org/ > > > > > > *From: *Fabien Imbault > *Date: *Sunday, October 25, 2020 at 12:39 > *To: *Yaron Sheffer > *Cc: *Dick Hardt , Mika Bostr=C3=B6m 40smarkets.com@dmarc.ietf.org>, GNAP Mailing List , > Justin Richer > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Hi Yaron, > > > > Thanks for the feedback. > > > > Regarding client libraries, I think we can indeed learn a great deal from > cryptographic libraries. Cryptographic design provides a great amount of > flexibility for the specialists (including many parameters that you reall= y > need to get right). We might think this is great to provide options but i= t > actually increases the cognitive load of library users. > > > > Look instead at what Google has provided with tink as an alternative and > you'll see it is a much easier way for cryptographic engineers (who aren'= t > cryptographers) to avoid mistakes or misuses. > > > > That's the *security* issue I'm referring to (not the fact that being ope= n > they're tasty targets, although that may be related in some cases). And > tink is the kind of design we should be trying to achieve. > > > > I agree that it should be applicable to a wide range of well known > programming tools, including the likes of java and go. > > But I don't really see a limitation here. Might not be the most idiomatic > feel, but it can be made to work. > > > > Just so I understand, what alternatives would you prefer to polymorphism? > I can suggest json-ld but even Justin will Teel you it's even more comple= x > :-) > > > > Cheers > > Fabien > > > > Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer = a > =C3=A9crit : > > Hi Fabien, > > > > I think your product management model has a lot of merit, but it does not > capture the security issue well. > > > > I agree that as we look at different customer personas, the =E2=80=9Cend = user=E2=80=9D > (the developer that=E2=80=99s using the libraries) should be our highest = priority. > But I disagree about end-user mistakes being the top **security** issue. > Libraries are often open source in our space and used very widely. So the= y > make for tasty targets, and people are attacking them and are still findi= ng > security issues in libraries that we=E2=80=99ve been talking about foreve= r [1]. > > > > (Yes, my example is actually an app flaw, but I think it could have been > prevented by a better designed library.) > > > > In other words, we do need to care about how easy it is to implement the > protocol correctly by **library** developers. From Justin describing his > own experience and other people on the thread that Dick referred to, I > would say that JSON polymorphism is painful for Java and Go developers. > With all due respect, I care about them much more than I care about > Haskell, as many more implementations are likely to use these languages. > > > > Thanks, > > Yaron > > > > [1] > https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-a= pp/ > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Sunday, October 25, 2020 at 01:25 > *To: *Dick Hardt > *Cc: *Mika Bostr=C3=B6m , G= NAP > Mailing List , Justin Richer > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Hi Dick, > > > > Independantly from the debate on polyphormism, I beg to differ on your > order preference. > > > > Your assumption is that AS devs matter the most, because they're doing > the important security implementation. But eating our own dogfood might > help a lot to change that view. Most security issues occur because users = of > the spec are unable to deal with the complexity that is passed onto them. > > > > 99% of the people that will actually use the output of the work are > application developers (client or RS) and their own users. > > > > Our intent as well as the protocol drive the usage. Client libraries may > help, but they're not a silver bullet, especially because GNAP ultimately > has no control about what people do there (for better or worse). And > everything we do here will help get to the better part. > > > > I'm not saying we don't intend to also care about AS developers (beginnin= g > with ourselves) but it's a second order optimisation. And since it's a > tendancy we're leaning towards by default, I'm pretty sure we won't forge= t > that anyway. > > > > Fabien > > > > > > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : > > I'm confused by your logic Fabien. > > > > If a client library developer wants to expose polymorphism, they can do > that independent of what is in the protocol. > > > > I differ on who our stakeholders are. > > > > I think our stakeholders are in least to most important: > > > > - AS developer > - RS developer > - client developer > - user > > > > A client library developer can expose whatever interface they want to > simplify implementation. > > > > I list the user so that we don't lose site of a critical role. > > > > /Dick > > > > > > *Error! Filename not specified.*=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault > wrote: > > Hi there, > > > > Let me try to approach the issue under a different light. More like a > product manager would deal with feature selection to make it intuitive fo= r > its users. > > > > For most people, riding a bike is far easier than using a unicycle. Feels > more stable. And yet it's way easier to design for a single wheel than to > build with 2. Because then you'll need a lot more accessories (chain, cha= in > ring, etc.). Even so producing a bike doesn't have to be a brittle proces= s, > it can be industrialized. > > > > Back to the GNAP topic. > > Ultimately we should strive to make the spec as simple as can be. But we > need to ask: simple for whom? For the bike owner or for the bike vendor? > > (short answer: the priority should be simplicity for spec users, not spec > implementers and even less spec designers). > > > > The initial question that is asked is very interesting: isn't the design > flawed if GNAP is using json polyphormism? Or if the AS needs to handle t= he > state of the request? Or if we must handle token revocation? Or if we are > looking for a global unique identifier? The argument stems of the fact th= at > is still arguably harder and more error prone to implement. Fair enough. > > > > From a spec implementer's perspective, it may well be more complex. It > mostly impacts the json library you'll end up using, plus a bit of > input/output decoration around it. Even golang provides utilities for thi= s, > despite not exactly being made for this kind of purpose. > > My practical experience implementing it is that it's not that big a deal. > I mean, I wished it could be simpler, but it's manageable and there are > other ways to reach levels of insurance that it does work as intended (js= on > schema, test cases to validate the implementation, etc.). Arguably it is > still easier from an implementation perspective than say, json-ld, which = is > massively used in the SSI community. > > > > But ultimately who are we designing for? Are we striving to go easy on th= e > spec implementer? Or are we trying to make sure end-developers using the > client libraries won't shoot themselves in the foot? > > > > The job to be done (JTBD), from the end-developer's perspective, is to > efficiently ship an application. And provide authN/authZ capabilities for > end-users by relying on some well known implementation. > > In turn, this spec implementer will rely on cryptographic utility > libraries that deals internally with the complexity of their own domain, = so > that we don't have to. And here we could launch another HN flame war that > starts with the title "JWT sucks because". Which does have its set of ver= y > real issues but that's beyond the point. > > Note that any decent flamewar will be efficiently fueled by people hating > medium. Is it outrageous for blog posts to be behind a paywall? Maybe but > it's even more outrageous to lack consistency, either by not knowing how = to > get around a paywall if you're into a hacker punk movement, or on the > contrary by to not paying a subscription if you believe that surveillance > capitalism, to reuse Zuboff's terms, should be eradicated. > > What likely seems an unnecessary sidenote tries to illustrate the point: > for Justin it was easier to publish on medium, because as a blog publishe= r, > you might not want to deal with hosting your own blog. But maybe as a > reader you'll find that annoying. Different audiences, different JTBD, > different tradeoffs. > > > > Polyphormism is a tool that enables the end-developer to have minimal > knowledge of what it means to deal with a GNAP client library. You prepar= e > the request, send to the endpoint and you're good to go. Massively simple= r > than OAuth2 or any similar protocol by the way (as anyone with teaching > experience on the subject might acknowledge). And there's a lot more to = be > done to make sure we indeed reduce the complexity for the end-developer a= nd > the end-user. > > > > If we find a better way to deal with that simplicity balance, I'm all in. > But the arguments need to be way more convincing than just saying that it > may be difficult to implement or validate. > > > > Cheers. > > Fabien > > > > > > > > > > > > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : > > > > > > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: > > > > Justin > > > > I did note that I was the one that argued for instance_id being in the > object. Since it is in the object in the current draft, not including a > pass by reference option would be preferable. > > > > As for concrete examples: > > - version of client > > - version of OS > > - security attestation of OS / device > > - location of client device > > - network client is operating on > > > > These are all attributes of the client that an AS may require on the > initial grant request, and in future grant requests (which is when an > instance_id) would be used. > > > > > > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes > of the client=E2=80=9D in the same way that the key, display information,= class > identifiers, and other items currently represented by an instance_id are > attributes of the client instance. The attestation components don=E2=80= =99t modify > the instance so much as present additional information on top of the clie= nt > instance itself. This is why I argue that they ought to be handled in a > separate object, so you=E2=80=99d have something like this strawman: > > > > { > > > > posture: { > > software_version: 1.2.3, > > os_version: 14.3.2 > > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > > }, > > > > client: =E2=80=9Cclient-541-ab" > > > > } > > > > This is a more fundamental question about GNAP than whether the syntax > uses polymorphism: this is about GNAP being very explicit about the data > model of its elements. OAuth 2=E2=80=99s incredibly loose and broad model= of what > the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pro= blematic in > practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to > define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture > the different aspects that are out there. I think we=E2=80=99re getting c= loser here > in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, bu= t we still need to > be more precise about what exactly a client instance includes, and what i= t > does not. > > > > =E2=80=94 Justin > > > > > > /Dick > > > > *Error! Filename not specified.*=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > > Dick, > > > > As you=E2=80=99ll recall, I argued against including the client instance > identifier inside of the object as a mutually-exclusive field precisely > because of the principle violation that you are pointing out here, and so > it=E2=80=99s important to point out that the current text is a compromise= that > needs to be examined in the wider experience of the working group. I am o= n > the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D= option within an > object, but this needs to be explored. > > > > The crux of my argument is that is exactly a case of pass-by-reference vs > pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient > instance=E2=80=9D value itself but rather belong outside of that object i= n a > another part of the request. As stated in the editorial notes in this > section, we need to look carefully at how these concepts fit within the > model and where we would want to put them. Without concrete examples of > what these extensions look like and how they=E2=80=99re generated, that i= s nearly > impossible to do at this stage. I look forward to seeing examples of this > kind of data and how it can fit into the protocol. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: > > > > Hey Justin, > > > > As the draft has evolved, I question the continued use of polymorphism. > Note that I appreciate the elegance of using a string for > pass-by-reference, and an object for pass-by-value. > > > > In the current draft, the > > > > Every time you create or process a field it will mean only one thing, and > there=E2=80=99s only one field to look at to answer a question. > > > > is violated in 2.3.1. Identifying the RC Instance > > > > > > > instance_id An identifier string that the AS can use to identify the > > particular instance of this RC. The content and structure of this > > identifier is opaque to the RC. > > > > "client": { > > "instance_id": "client-541-ab" > > } > > > > If there are no additional fields to send, the RC MAY send the > > instance identifier as a direct reference value in lieu of the > > object. > > > > "client": "client-541-ab" > > > > The instance identifier can be sent two ways. Polymorphism is a > convenience for the client, but requires the server to have two code path= s > for "instance_id". We discussed this in the design team, and I argued fo= r > having "instance_id" in the "client" object so that any updates, such as > new devices assertions, could be in the "client" object. As noted above, > while I appreciate the elegance of using a string (handle) to reference a > previously provided object, it complicates how to update an existing obje= ct > while providing the reference. > > > > In your example of the "key" object below, setting "proof" to bearer woul= d > avoid the issue you describe: > > > > { > "key": { > "proof": "bearer" > } > } > > > > In your example, when processing the "key" object, code is having to chec= k > both the JSON type of the property, as well as check the value of the > "proof" property. In the example I provided, only the value of "proof" > needs to be checked. The "proof" property is acting as a type for the "ke= y" > object. > > > > Not being a Java programmer, I don't know how this would work in a Java > implementation, but node.js, the processing would need to be done as abov= e. > > > > On a related note, there was significant negative feedback on handles and > polymorphism in the Hacker News article > https://news.ycombinator.com/item?id=3D24855750 > > > > /Dick > > > > > > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > > Hi Mika, > > > > Thanks for bringing this topic here =E2=80=94 I was able to see the forum > discussion that brought you here, and hopefully I can help clear up what = I > mean with how polymorphism is used in the proposal. The short version is > that the goal is to *avoid* the kinds of ambiguity that make insecure > protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using > polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree > that misusing it or applying it sloppily can lead to ambiguous and insecu= re > systems. > > > > Some background: I built out the XYZ protocol (one of the predecessors to > the initial GNAP Draft) in Java using strongly typed parsers and Java > objects specifically to prove to myself that it could be done in a way th= at > made any sense in the code. (My own open source implementation is at > https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not ye= t up to > date with the GNAP spec). It was important to me that I be able to use th= e > system-wide configured parsers to implement this and not have to resort t= o > stepping through elements completely by hand. Java doesn=E2=80=99t make i= t simple > to get the hooks into the right places (especially with the Jackson parse= r > that I used), but it is definitely possible to create a deterministic and > strongly-typed parser and serializer for this kind of data structure. Som= e > of the rationale for using polymorphism is covered in the trailing append= ix > of the draft document ( > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), > but it=E2=80=99s still good to discuss this here as the working group dec= ides which > approaches to take. > > > > The driving reason for using polymorphism at the protocol level was to > simplify the protocol and make it :more: deterministic to create and > process, not less. Every time you create or process a field it will mean > only one thing, and there=E2=80=99s only one field to look at to answer a= question. > Without polymorphic field values, you usually need to rely on mutual > exclusivity of fields, which is prone to failure and requires additional > error checking. Take for example the key binding of access tokens. An > access token could be bound to the RC=E2=80=99s key used during the reque= st, to a > different key chosen by the AS, or it could be a bearer token with no key > at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of > boolean values and objects and express this set of mutually-exclusive > options in a non-ambiguous way. Without that, you=E2=80=99d need to have = different > fields for the options and include additional checks in your parser to ma= ke > sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with > this potential security vulnerability in an object: > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > }, > > bearer_token: true, > > bind_to_rc_key: true > > } > > > > This would be an illegal object as per this alternate proposal, but then > you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others > in the same object. I=E2=80=99ve done this exercise with many other proto= cols and > it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cg= ood=E2=80=9D examples > would pass code that doesn=E2=80=99t check this. With the polymorphic app= roach to > this same field, each of these three mutually-exclusive states is written > in a way that they cannot be sent together. It=E2=80=99s not just illegal= , it=E2=80=99s > impossible and enforced by the syntax of JSON itself. > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > } > > } > > > > // bearer token > > > > { > > key: false > > } > > > > // bound to the RC=E2=80=99s presented key > > > > { > > key: true > > } > > > > If someone sends a different type for this field, like an array or number > or a null, this doesn=E2=80=99t have a defined interpretation in the prot= ocol and > would be a protocol level error. > > > > While it might sound like polymorphism means that any field could have an= y > type or value, the opposite is true: each possible value is explicitly > typed, it=E2=80=99s just that there are potentially different types that = express > meaning for the field. This applies to all members of all objects > (dictionaries) as well as all members of an array (list). Every time you > process a field value or other element, you look at the type and then the > value to determine what to do with that typed value. > > > > In your example below, each field within the dictionary would also need t= o > be typed, and each type would need to have a clear indication of its > meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could > be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON n= umber) or an > =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would fu= rther say what > exactly the encoding of the string would be. That means that when you rea= d > the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was > or how it was represented, regardless of the input format. Seeing a numbe= r > there means exactly one interpretation and seeing a string means exactly > one (different) interpretation =E2=80=94 but importantly, both of them ar= e a > =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines= the type. An > implementation would likely use an internal BigInteger type of object to > represent the field value after parsing, so the question is how to go fro= m > the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just > apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply= it to all > sub-fields of that object. > > > > So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because > it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings,= and not > numbers, is not compliant with the JSON definitions of the field in > question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not > equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t = be treated > the same by a parser implementation when mapping to a concrete object. It= =E2=80=99s > in this kind of automated guessing that this class of bugs occur, and > that=E2=80=99s going to be the case whether or not you take advantage of= JSON=E2=80=99s > polymorphic nature. I=E2=80=99ve run into cases where a parser library wa= s trying > to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but= ended up > introducing errors in more strict components downstream. This is somethin= g > that protocol designers need to be aware of and guard against in the desi= gn > of the protocol to reduce possible ambiguities. Within GNAP today, we > generally have things that branch whether they=E2=80=99re an object (for = a rich > description of something) or some non-structured special value (for a > reference or other item). > > > > The design team created some simple JSON Schemas for parts of the protoco= l > during our discussion, but we didn=E2=80=99t include them in the design d= ocument > due to both lack of time to keep it updated with the rapid changes to the > protocol during the design team discussion, and not knowing if there woul= d > be interest in such material. I personally think it would be helpful to > include as an informative reference in the final document, but that=E2=80= =99s > something for the working group to take up eventually. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < > mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: > > > > Hello, everyone. > > > > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and > when I made note about certain concerns, I was requested to send my > comments to this working group. > > > > In short, I believe that the use of polymorphic JSON in the protocol > invites subtle and confusing implementation problems. I also searched > through the WG archives, and noticed that similar concerns were noted, > briefly, in a thread in July. > > > > The problem with polymorphic values, as I see it, is that implementations > will need to branch on the (inferred) type of a given field. This isn't > quite as bad if the types are strictly different, but allows for subtle > bugs when the value in question is a dictionary. What makes this > unappealing is that "subtle bugs" in security protocols have a habit of > turning into vulnerabilities. > > > > Let's say we have these imaginary payloads, both possible and valid in th= e > same protocol step: > > > > # payload 1 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": > > } > > } > > > > # payload 2 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": "" > > } > > } > > > > In both cases, the type of "public_key" field is a dictionary. In both > cases, they even have the same keys. However, the values in the > dictionaries are entirely different, and an implementation will have to > branch to at least two possible decoding mechanisms. To make things worse= , > some JSON implementations may choose to encode non-dictionary values as > strings, so it is possible for an originator to transmit what they expect > and believe to be payload 1 format, but which the receiver will interpret > to be in payload 2 format. And if the encoded string contains only digits= , > it will even parse correctly as a bignum. > > > > While the above is clearly a manufactured scenario, it nonetheless > demonstrates the potential for logic bugs with polymorphic JSON. With > richer types and more complex dictionaries, there will surely be more roo= m > for errors. > > > > Ambiguity in protocols is always a source of implementation complexity an= d > interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's > terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it > be in everyone's interest to keep implementation complexity and mistake > potential to a minimum? > > > > Best regards, > > Mika > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > *Error! Filename not specified.*=E1=90=A7 > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000009abc8605b27e3995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Yaron,

    As= Justin explained that's the kind of idea we tested. For instance=C2=A0= https://github.com= /fimbault/test_gnap_schema (in rust).

    =
    Cheers
    Fabien=C2=A0
    Le dim. 2= 5 oct. 2020 =C3=A0 13:36, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:

    Personally, I would support polymorphism in th= e protocol if it (the RFC) came with a well-defined JSON Schema [1] documen= t, so a recipient can automatically validate incoming messages at run-time.= I would expect senders to also validate messages as part of their testing.= It=E2=80=99s not an ideal solution, because:

    =C2=A0

    • Some people at the IETF don=E2=80=99t like JSON Schema, for various r= easons.
    • JSON Schema is not a standard, so it=E2=80=99s= painful to require it normatively.
    • Even if it=E2=80= =99s normative, some recipients will not validate messages anyway.

    =C2=A0

    This would be shifting some of the complexity from the library de= veloper to the spec developer, which is the right thing to do IMO.

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

    =C2=A0

    [1] https://json-schema.org/

    =C2=A0

    =C2=A0=

    From: = Fabien Imbault <fabien.imbault@gmail.com>
    Date: S= unday, October 25, 2020 at 12:39
    To: Yaron Sheffer <yaronf.= ietf@gmail.com>
    Cc: Dick Hardt <dick.hardt@gmail.com<= /a>>, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dma= rc.ietf.org>, GNAP Mailing List <txauth@ietf.org>, Justin Ric= her <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on poly= morphism

    = =C2=A0

    Hi Yaron,<= /p>

    =C2=A0

    Thanks for the feedback.=C2=A0

    =C2=A0

    R= egarding client libraries, I think we can indeed learn a great deal from cr= yptographic libraries. Cryptographic design provides a great amount of flex= ibility for the specialists (including many parameters that you really need= to get right). We might think this is great to provide options but it actu= ally increases the cognitive load of library users.

    =

    =C2=A0

    Look instead at what Google has provided with tink as an alterna= tive and you'll see it is a much easier way for cryptographic engineers= (who aren't cryptographers) to avoid mistakes or misuses.=C2=A0=

    =C2=A0

    =

    That's the *security* issue I'm referri= ng to (not the fact that being open they're tasty targets, although tha= t may be related in some cases). And tink is the kind of design we should b= e trying to achieve.=C2=A0

    =C2=A0

    I agree that i= t should be applicable to a wide range of well known programming tools, inc= luding the likes of java and go.=C2=A0

    But I don't really see a limitation here. Might not be t= he most idiomatic feel, but it can be made to work.=C2=A0

    =

    =C2=A0

    Just so I understand, what alternatives would you prefer t= o polymorphism? I can suggest json-ld but even Justin will Teel you it'= s even more complex :-)=C2=A0

    =C2=A0

    Cheers

    Fabien=C2=A0

    =C2=A0=

    Le dim. 25 oct. 2020 =C3=A0 11:= 17, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:<= u>

    =

    Hi Fabien,

    =C2=A0

    I think your produc= t management model has a lot of merit, but it does not capture the security= issue well.

    =C2=A0

    I agree that as we look at different customer pers= onas, the =E2=80=9Cend user=E2=80=9D (the developer that=E2=80=99s using th= e libraries) should be our highest priority. But I disagree about end-user = mistakes being the top *security* issue. Libraries are often open so= urce in our space and used very widely. So they make for tasty targets, and= people are attacking them and are still finding security issues in librari= es that we=E2=80=99ve been talking about forever [1].

    =C2=A0

    (Yes, my = example is actually an app flaw, but I think it could have been prevented b= y a better designed library.)

    =C2= =A0

    In other words, we do need to c= are about how easy it is to implement the protocol correctly by *library= * developers. From Justin describing his own experience and other peopl= e on the thread that Dick referred to, I would say that JSON polymorphism i= s painful for Java and Go developers. With all due respect, I care about th= em much more than I care about Haskell, as many more implementations are li= kely to use these languages.

    =C2=A0=

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    =C2=A0

    [1] https://www.zofrex.com/blog/2020/10/20/alg-n= one-jwt-nhs-contact-tracing-app/

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf= of Fabien Imbault <fabien.imbault@gmail.com>
    Date:= Sunday, October 25, 2020 at 01:25
    To: Dick Hardt <dick.= hardt@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom=3D= 40smarkets.com@dmarc.ietf.org>, GNAP Mailing List <txauth= @ietf.org>, Justin Richer <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on polymorphism

    =C2=A0

    Hi Dick,

    =C2=A0<= /u>

    Independantly from the debate on p= olyphormism, I beg to differ on your order preference.=C2=A0<= /p>

    =C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're= doing the important security implementation. But eating our own dogfood mi= ght help a lot to change that view. Most security issues occur because user= s of the spec are unable to deal with the complexity that is passed onto th= em.=C2=A0

    =C2=A0<= u>

    99% of the people that w= ill actually use the output of the work are application developers (client = or RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the= protocol drive the usage. Client libraries may help, but they're not a= silver bullet, especially because GNAP ultimately has no control about wha= t people do there (for better or worse). And everything we do here will hel= p get to the better part.=C2=A0

    =C2=A0

    I&= #39;m not saying we don't intend to also care about AS developers (begi= nning with ourselves) but it's a second order optimisation. And since i= t's a tendancy we're leaning towards by default, I'm pretty sur= e we won't forget that anyway.=C2=A0

    =C2=A0

    Fabien=C2=A0

    =C2=A0=

    =C2=A0

    Le sam. 2= 4 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a = =C3=A9crit=C2=A0:

    I'm confused by your logic Fabien.

    =C2=A0

    = If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=C2=A0

    =C2=A0

    I differ on who our stakeholders are.=C2=A0

    <= div>

    =C2=A0

    I think our stakeholders are in least to most important:

    =C2=A0

    • AS developer
    • RS developer
    • client developer
    • user=

    =C2=A0

    =

    A client library developer can expose wha= tever interface they want to simplify implementation.

    =C2=A0

    I list the user so that we don't lose site of a critical= role.

    =C2=A0<= /u>

    /Dick

    =

    =C2=A0

    =C2=A0

    Error! Filename not= specified.=E1=90=A7

    =C2=A0

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@= gmail.com> wrote:

    Hi there,=C2=A0

    =C2=A0

    Let me try= to approach the issue under a different light. More like a product manager= would deal with feature selection to make it intuitive for its users.=C2= =A0

    =C2=A0

    For most people, riding a bike is far = easier than using a unicycle. Feels more stable. And yet it's way easie= r to design for a single wheel than to build with 2. Because then you'l= l need a lot more accessories (chain, chain ring, etc.). Even so producing = a bike doesn't have to be a brittle process, it can be industrialized.= =C2=A0

    =C2=A0<= /u>

    Back to the GNAP topic.=C2=A0

    Ultimately we should strive to make the spec as simp= le as can be. But we need to ask: simple for whom? For the bike owner or fo= r the bike vendor?=C2=A0

    (short ans= wer: the priority should be simplicity for spec users, not spec implementer= s and even less spec designers).=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to han= dle the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the fa= ct that is still arguably harder and more error prone to implement. Fair en= ough.=C2=A0

    =C2=A0

    From a spec implementer's= perspective, it may well be more complex. It mostly impacts the json libra= ry you'll end up using, plus a bit of input/output decoration around it= . Even golang provides utilities for this, despite not exactly being made f= or this kind of purpose.

    My practical experience implementing it is that it's not that big a de= al. I mean, I wished it could be simpler, but it's manageable and there= are other ways to reach levels of insurance that it does work as intended = (json schema, test cases to validate the implementation, etc.). Arguably it= is still easier from an implementation perspective than say, json-ld, whic= h is massively used in the SSI community.=C2=A0

    =C2=A0

    But ultimately who are we designing for? Are we striving to go easy = on the spec implementer? Or are we trying to make sure end-developers using= the client libraries won't shoot themselves in the foot?=

    =C2=A0

    The job to be done (JTBD), from the end-developer'= s perspective, is to efficiently ship an application. And provide authN/aut= hZ capabilities for end-users by relying on some well known implementation.= =C2=A0

    In turn, this spe= c implementer will rely on cryptographic utility libraries that deals inter= nally with the complexity of their own domain, so that we don't have to= . And here we could launch another HN flame war that starts with the title = "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=C2=A0

    Note that any decent flamewar will be efficiently fueled by = people hating medium. Is it outrageous for blog posts to be behind a paywal= l? Maybe but it's even more outrageous to lack consistency, either by n= ot knowing how to get around a paywall if you're into a hacker punk mov= ement, or on the contrary by to not paying a subscription if you believe th= at surveillance capitalism, to reuse Zuboff's terms, should be eradicat= ed.=C2=A0

    What likely se= ems an unnecessary sidenote tries to illustrate the point: for Justin it wa= s easier to publish on medium, because as a blog publisher, you might not w= ant to deal with hosting your own blog. But maybe as a reader you'll fi= nd that annoying. Different audiences, different JTBD, different tradeoffs.= =C2=A0

    =C2=A0<= /u>

    Polyphormism is a tool that enable= s the end-developer to have minimal knowledge of what it means to deal with= a GNAP client library. You prepare the request, send to the endpoint and y= ou're good to go. Massively simpler than OAuth2 or any similar protocol= by the way (as anyone with teaching experience on the subject might acknow= ledge). And=C2=A0 there's a lot more to be done to make sure we indeed = reduce the complexity for the end-developer and the end-user.=C2=A0<= u>

    =C2=A0

    <= div>

    If we find a better way to deal with that simpli= city balance, I'm all in. But the arguments need to be way more convinc= ing than just saying that it may be difficult to implement or validate.=C2= =A0

    =C2=A0=

    Cheers.

    <= p class=3D"MsoNormal">Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0

    =C2=A0

    =C2=A0

    <= p class=3D"MsoNormal">Justin

    = =C2=A0

    I did note that I= was the one that argued for instance_id being in the object. Since it is i= n the object in the current draft, not including a pass by reference option= would be preferable.=C2=A0

    =C2=A0

    As for concre= te examples:

    - version o= f client

    - version of OS=

    - security attestation = of OS / device

    - locatio= n of client device

    - net= work client is operating on

    =C2=A0

    These are all= attributes of the client that an AS may require=C2=A0on the initial grant = request, and in future grant requests (which is when an instance_id) would = be used.

    =C2=A0

    =C2=A0<= u>

    This is where our interp= retations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the c= lient=E2=80=9D in the same way that the key, display information, class ide= ntifiers, and other items currently represented by an instance_id are attri= butes of the client instance. The attestation components don=E2=80=99t modi= fy the instance so much as present additional information on top of the cli= ent instance itself. This is why I argue that they ought to be handled in a= separate object, so you=E2=80=99d have something like this strawman:

    =C2=A0

    {

    =C2=A0

    =C2=A0 pos= ture: {

    =C2=A0 =C2=A0 so= ftware_version: 1.2.3,

    = =C2=A0 =C2=A0 os_version: 14.3.2

    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some structure or si= gned blob? =E2=80=A6 }

    = =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }<= u>

    =C2=A0 },<= /p>

    =C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"

    =C2=A0

    =

    }

    =C2=A0

    This is a more f= undamental question about GNAP than whether the syntax uses polymorphism: t= his is about GNAP being very explicit about the data model of its elements.= OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80= =9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in pract= ice. We=E2=80=99re even seeing that in the OAuth 2.1 work with having to de= fine a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2= =80=99t fully capture the different aspects that are out there. I think we= =E2=80=99re getting closer here in GNAP with explicit definition of =E2=80= =9Cclient instance=E2=80=9D, but we still need to be more precise about wha= t exactly a client instance includes, and what it does not.

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    =C2=A0

    /D= ick

    =C2=A0=

    Error! Filename not specified.=E1=90=A7

    =C2= =A0

    On Fri, Oct 23, 2020 = at 12:42 PM Justin Richer <jricher@mit.edu> wrote:

    =

    Dick,

    =C2=A0

    As you=E2=80=99ll recall, I argued against including the client inst= ance identifier inside of the object as a mutually-exclusive field precisel= y because of the principle violation that you are pointing out here, and so= it=E2=80=99s important to point out that the current text is a compromise = that needs to be examined in the wider experience of the working group. I a= m on the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an object, but this needs to be explored.

    =C2=A0

    The crux of my argument is that is exactly a case of pas= s-by-reference vs pass-by-value, and that runtime attestations are not part= of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong ou= tside of that object in a another part of the request. As stated in the edi= torial notes in this section, we need to look carefully at how these concep= ts fit within the model and where we would want to put them. Without concre= te examples of what these extensions look like and how they=E2=80=99re gene= rated, that is nearly impossible to do at this stage. I look forward to see= ing examples of this kind of data and how it can fit into the protocol.<= /u>

    =C2=A0

    =C2=A0=E2=80=94 Justin

    = =C2=A0

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <= dick.hardt@gmail.com> wrote:

    =C2=A0

    Hey Ju= stin,

    =C2=A0

    =

    As the draft has evolved, I question the = continued use of polymorphism. Note that I appreciate the elegance=C2=A0of = using a string for pass-by-reference, and an object for pass-by-value.

    =C2=A0

    In the current draft, the=C2=A0=

    =C2=A0

    Every time you create or process a= field it will mean only one thing, and there=E2=80=99s only one field to l= ook at to answer a question.=C2=A0

    =C2=A0

    =C2=A0

    = =C2=A0

    =C2=A0 =C2=A0instance_id =C2=A0An identifier string that the AS can use = to identify the

    =C2=A0 = =C2=A0 =C2=A0 particular instance of this RC.=C2=A0 The content and structu= re of this

    =C2=A0 =C2=A0= =C2=A0 identifier is opaque to the RC.

    =C2=A0

    = =C2=A0 =C2=A0"client": {

    =C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "client= -541-ab"

    =C2=A0 =C2= =A0}

    =C2=A0

    =C2=A0 =C2=A0If there are no additio= nal fields to send, the RC MAY send the

    =C2=A0 =C2=A0instance identifier as a direct reference valu= e in lieu of the

    =C2=A0 = =C2=A0object.

    =C2=A0<= /u>

    =C2=A0 =C2=A0"client&q= uot;: "client-541-ab"

    =C2=A0

    The instance identifier can be sent two ways. Polymorphism is a conveni= ence for the client, but requires the server=C2=A0to have two code=C2=A0pat= hs for "instance_id".=C2=A0 We discussed this in the design team,= and I argued for having "instance_id" in the "client" = object=C2=A0so that any updates, such as new devices assertions, could be i= n the "client" object. As noted above, while I appreciate the ele= gance of using a string (handle) to reference a previously provided object,= it complicates how to update an existing object while providing the refere= nce.

    =C2=A0

    In your example of the "key&quo= t; object below, setting "proof" to bearer would avoid the issue = you describe:

    =C2=A0<= /u>

    {=C2=A0
    =C2=A0"key&= quot;: {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"proof": "bearer"=
    =C2=A0 =C2=A0 }
    }

    =C2=A0

    In your exampl= e, when processing the "key" object, code is having to check both= the JSON type of the property, as well as check the value of the "pro= of" property. In the example I provided, only the value of "proof= " needs to be checked. The "proof" property is acting as a t= ype for the "key" object.

    =C2=A0

    Not b= eing a Java programmer, I don't know how this would work in a Java impl= ementation, but node.js, the processing would need to be done as above.<= /u>

    =C2=A0

    On a related note, there was significant neg= ative feedback on handles and polymorphism in the Hacker News article=C2=A0= https://news.ycombinator.com/item?id=3D24855750= =C2=A0

    =C2=A0<= /u>

    /Dick

    =

    =C2=A0

    =C2=A0

    = On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wro= te:

    Hi Mik= a,

    =C2=A0

    Thanks for bringing this topic here =E2=80= =94 I was able to see the forum discussion that brought you here, and hopef= ully I can help clear up what I mean with how polymorphism is used in the p= roposal. The short version is that the goal is to=C2=A0avoid=C2=A0th= e kinds of ambiguity that make insecure protocols, and so in that goal we= =E2=80=99re fully aligned. I think that using polymorphism in very specific= ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems.<= /p>

    =C2=A0

    Some background: I built out the XYZ protocol (one of t= he predecessors to the initial GNAP Draft) in Java using strongly typed par= sers and Java objects specifically to prove to myself that it could be done= in a way that made any sense in the code. (My own open source implementati= on is at=C2=A0https://github.com/bspk/oauth.xyz-java, but = note that it=E2=80=99s not yet up to date with the GNAP spec). It was impor= tant to me that I be able to use the system-wide configured parsers to impl= ement this and not have to resort to stepping through elements completely b= y hand. Java doesn=E2=80=99t make it simple to get the hooks into the right= places (especially with the Jackson parser that I used), but it is definit= ely possible to create a deterministic and strongly-typed parser and serial= izer for this kind of data structure. Some of the rationale for using polym= orphism is covered in the trailing appendix of the draft document (https= ://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-= structures-and-polymor), but it=E2=80=99s still good to discuss this he= re as the working group decides which approaches to take.=C2=A0

    =C2=A0

    =

    The driving reason for using polymorphism at the pro= tocol level was to simplify the protocol and make it :more: deterministic t= o create and process, not less. Every time you create or process a field it= will mean only one thing, and there=E2=80=99s only one field to look at to= answer a question. Without polymorphic field values, you usually need to r= ely on mutual exclusivity of fields, which is prone to failure and requires= additional error checking. Take for example the key binding of access toke= ns. An access token could be bound to the RC=E2=80=99s key used during the = request, to a different key chosen by the AS, or it could be a bearer token= with no key at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic,= we can define it in terms of boolean values and objects and express this s= et of mutually-exclusive options in a non-ambiguous way. Without that, you= =E2=80=99d need to have different fields for the options and include additi= onal checks in your parser to make sure they weren=E2=80=99t sent simultane= ously, otherwise you could get hit with this potential security vulnerabili= ty in an object:

    =C2=A0<= u>

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,=

    =C2=A0 =C2=A0 =C2=A0 jwk: { = =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    =C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    <= p class=3D"MsoNormal">}

    = =C2=A0

    This would be an = illegal object as per this alternate proposal, but then you=E2=80=99d have = to check each field and make sure it wasn=E2=80=99t put next to others in t= he same object. I=E2=80=99ve done this exercise with many other protocols a= nd it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9C= good=E2=80=9D examples would pass code that doesn=E2=80=99t check this. Wit= h the polymorphic approach to this same field, each of these three mutually= -exclusive states is written in a way that they cannot be sent together. It= =E2=80=99s not just illegal, it=E2=80=99s impossible and enforced by the sy= ntax of JSON itself.

    =C2= =A0

    {=C2=A0<= u>

    =C2=A0 =C2=A0 key: {<= /u>

    =C2=A0 =C2=A0 =C2=A0 proof: httpsi= g,

    =C2=A0 =C2=A0 =C2=A0 = jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // bearer token

    =C2=A0

    {

    =C2= =A0 =C2=A0 key: false

    }<= u>

    =C2=A0

    // bound to the RC=E2=80=99s presen= ted key

    =C2=A0=

    {

    =C2=A0 =C2=A0 key: true

    }

    = =C2=A0

    If someone sends = a different type for this field, like an array or number or a null, this do= esn=E2=80=99t have a defined interpretation in the protocol and would be a = protocol level error.

    = =C2=A0

    While it might so= und like polymorphism means that any field could have any type or value, th= e opposite is true: each possible value is explicitly typed, it=E2=80=99s j= ust that there are potentially different types that express meaning for the= field. This applies to all members of all objects (dictionaries) as well a= s all members of an array (list). Every time you process a field value or o= ther element, you look at the type and then the value to determine what to = do with that typed value.

    =C2=A0

    In your example= below, each field within the dictionary would also need to be typed, and e= ach type would need to have a clear indication of its meaning. To take your= strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be de= fined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) = or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition woul= d further say what exactly the encoding of the string would be. That means = that when you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80= =99t be any confusion on what the value was or how it was represented, rega= rdless of the input format. Seeing a number there means exactly one interpr= etation and seeing a string means exactly one (different) interpretation = =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, si= nce that=E2=80=99s the field that determines the type. An implementation wo= uld likely use an internal BigInteger type of object to represent the field= value after parsing, so the question is how to go from the JSON value (whi= ch is typed) into the BigInteger value.You don=E2=80=99t just apply the typ= e rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-= fields of that object.=C2=A0

    =C2=A0

    So let=E2=80= =99s dig into the specific bug you bring up in the strawman, because it=E2= =80=99s interesting: A JSON encoder that encodes numbers as strings, and no= t numbers, is not compliant with the JSON definitions of the field in quest= ion. For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D= is not equivalent to the boolean value true in JSON, and they shouldn=E2= =80=99t be treated the same by a parser implementation when mapping to a co= ncrete object. It=E2=80=99s in this kind of automated guessing that this cl= ass of bugs occur, and that=E2=80=99s going to be the case whether or not y= ou take =C2=A0advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve = run into cases where a parser library was trying to be overly =E2=80=9Chelp= ful=E2=80=9D in doing this kind of mapping, but ended up introducing errors= in more strict components downstream. This is something that protocol desi= gners need to be aware of and guard against in the design of the protocol t= o reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of so= mething) or some non-structured special value (for a reference or other ite= m).=C2=A0

    =C2=A0<= u>

    The design team created some si= mple JSON Schemas for parts of the protocol during our discussion, but we d= idn=E2=80=99t include them in the design document due to both lack of time = to keep it updated with the rapid changes to the protocol during the design= team discussion, and not knowing if there would be interest in such materi= al. I personally think it would be helpful to include as an informative ref= erence in the final document, but that=E2=80=99s something for the working = group to take up eventually.

    =C2=A0

    =C2=A0=E2=80= =94 Justin

    =C2=A0

    On Oct 23, 2020, at 1= 0:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40s= markets.com@dmarc.ietf.org> wrote:

    =C2=A0

    Hello, everyone.

    =C2= =A0

    For background: GNAP= /TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made note about= certain concerns, I was requested to send my comments to this working grou= p.

    =C2=A0<= /p>

    In short, I believe that the use of po= lymorphic JSON in the protocol invites subtle and confusing implementation = problems. I also searched through the WG archives, and noticed that similar= concerns were noted, briefly, in a thread in July.

    =C2=A0

    The problem with polymorphic values, as I see it, is that imple= mentations will need to branch on the (inferred) type of a given field. Thi= s isn't quite as bad if the types are strictly different, but allows fo= r subtle bugs when the value in question is a dictionary. What makes this u= nappealing is that "subtle bugs" in security protocols have a hab= it of turning into vulnerabilities.

    =C2=A0

    Let&#= 39;s say we have these imaginary payloads, both possible and valid in the s= ame protocol step:

    =C2= =A0

    # payload 1

    {

    =C2=A0 ...,

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "mod= ulus": <BIGINT>

    =C2=A0 }

    }<= /u>

    =C2=A0

    # payload 2

    {

    =C2=A0 ...= ,

    =C2=A0 "public_ke= y": {

    =C2=A0=C2=A0= =C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<encoded = string>"

    =C2=A0 = }

    }

    =C2=A0

    In both cases, the type of "public_key" field is a= dictionary. In both cases, they even have the same keys. However, the valu= es in the dictionaries are entirely different, and an implementation will h= ave to branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary values= as strings, so it is possible for an originator to transmit what they expe= ct and believe to be payload 1 format, but which the receiver will interpre= t to be in payload 2 format. And if the encoded string contains only digits= , it will even parse correctly as a bignum.

    =C2=A0

    While the above is clearly a manufactured scenario, it nonetheless demon= strates the potential for logic bugs with polymorphic JSON. With richer typ= es and more complex dictionaries, there will surely be more room for errors= .

    =C2=A0

    Ambiguity in protocols is always a sour= ce of implementation complexity and interoperability snags, but in an AuthN= /AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is intende= d to supersede Oauth1/2, wouldn't it be in everyone's interest to k= eep implementation complexity and mistake potential to a minimum?=

    =C2=A0

    Best regards,

    Mika

    =C2= =A0

    --

    Mika Bostr=C3=B6m<= /u>

    Smarkets

    =

    --
    TXAuth ma= iling list
    TXAuth@ietf.org
    https://www.ietf.org/m= ailman/listinfo/txauth

    =C2=A0

    -- TXAuth mailing list
    TXAuth@ietf.org
    https://www= .ietf.org/mailman/listinfo/txauth

    <= /div>

    Error! Filename not specified.=E1= =90=A7

    =C2=A0

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /p>

    -- TXAuth mailing list TXAuth@ietf.org h= ttps://www.ietf.org/mailman/listinfo/txauth

    --0000000000009abc8605b27e3995-- From nobody Sun Oct 25 09:06:25 2020 Return-Path: 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 4F92A3A0AB6 for ; Sun, 25 Oct 2020 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=hpe.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 pezHGPUJlJ9X for ; Sun, 25 Oct 2020 09:06:19 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054143A0AB5 for ; Sun, 25 Oct 2020 09:06:18 -0700 (PDT) Received: from pps.filterd (m0150245.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09PG2hKw015382 for ; Sun, 25 Oct 2020 16:06:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pps0720; bh=mQCYiBpnvNfzBRisOz6WPo+N3wJSVtiEb4bXVhHE0iQ=; b=gFoLtd3Qg2QfGyuchCc4B8LaQmFCUfUnquqUtwfqV4N27te/Vi8wCGOneTlfvle0zNgr hWUQSLlocscTnBj3+74gyYUcGgdYPyDx9DJ3M75xOsDwQLtN32xrupsTvrR3rQJBORF5 5kC3xoCou5W7UNxBAWtqxf6HvMniOnj0UBKpyMCmmz0/TWCg3KoMfyoBkYTUfBbEFiT+ mD3pnu/DW+gwM1IjMCNA9isrINH013fDPnlAirgn0ObjfWHVi9b0Ch9cMal2EF7GaPA1 0LFhH9Y7AMxNodu6sNRxJFcWYdLjWiQT4LKWxYuir55hKpFj0NB6fqh/kIErfT3/4ZwO Hw== Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) by mx0b-002e3701.pphosted.com with ESMTP id 34cdfeyrkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 25 Oct 2020 16:06:17 +0000 Received: from G1W8108.americas.hpqcorp.net (g1w8108.austin.hp.com [16.193.72.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3425.houston.hpe.com (Postfix) with ESMTPS id 0DED68D for ; Sun, 25 Oct 2020 16:06:17 +0000 (UTC) Received: from G9W8453.americas.hpqcorp.net (2002:10d8:a0d3::10d8:a0d3) by G1W8108.americas.hpqcorp.net (2002:10c1:483c::10c1:483c) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 25 Oct 2020 16:06:16 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (15.241.52.12) by G9W8453.americas.hpqcorp.net (16.216.160.211) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 25 Oct 2020 16:06:16 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V4tWtxprT60K1zQX7bhoygO2RRSf7mURJz0EG6dKGkgHSLYay8rTzX2/gb5YRwAKsgLOhfw5DMDQEqRwsG2Gx8mF6LyYlUV2PNJgCbmlrPe15J1tDHgvx5jBrSWCGeOHEG57asusC0v3vGFFx9/97Ix6apcgeo+hbGsYWoKsKbI+FWOils7Q95tVNPEpV1QL/xuKwvhEIli/ZE26AaVQDYEvz3x3OAumbKC1d9PnQevdPmQLr2mEX77yezIq2+2+1C5EbnKvjRmdTYoIispMQB6BrYlAlMJS9W9NpHbUdwjt+fp19F1XGtt4VbNH8H5g4WfWxSljcF4eIcrEi/f0AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AcpwMEFAsY9ToOrzvUgo41UxQEhWpfzPgX8OpUeUrQM=; b=PguZSg4blooySEA7Dk1hEYHMYUMlqEzbGdNjmYHnqEYZh6+TCXR209aFSVdHQJiQjFIOY/Wmt5OKTrvMbZr3z8Kyd/MGiVE88YtDfavPiYjZIz3Ukkh/pj0onOPbLS8X/occXI9SzPOsMsbCo4OB6MXFRuHW2W6VssUFBQrBhCb8PvHo4w8cM9fv4Fmvi4drcbyuLllF9porgZ2laTWTOi3+SpbPfO3IrUG+sImh8nnPsM557lcp41DPBjgU/V+XqQJWVANr8/f3zBWbiYma6RSV408JoYGi3+J3BJUwTq+g7BYg4a4f+1rlF0GO15YMJSMeSaYbbjOyCWjmL0V3Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from DF4PR8401MB1177.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7610::17) by DF4PR8401MB0698.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7611::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Sun, 25 Oct 2020 16:06:13 +0000 Received: from DF4PR8401MB1177.NAMPRD84.PROD.OUTLOOK.COM ([fe80::1024:a23c:56c6:debe]) by DF4PR8401MB1177.NAMPRD84.PROD.OUTLOOK.COM ([fe80::1024:a23c:56c6:debe%2]) with mapi id 15.20.3477.028; Sun, 25 Oct 2020 16:06:13 +0000 From: "Huang, Peter (HPE HQ)" To: "txauth@ietf.org" Thread-Topic: [GNAP] Feedback on polymorphism Thread-Index: AQHWqrs38s/NFWIshECBGa3fOhUPaamocSoF Date: Sun, 25 Oct 2020 16:06:13 +0000 Message-ID: References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hpe.com; x-originating-ip: [2600:1700:1150:ad80::6fe] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ae9298ec-45eb-40d3-fd6e-08d878ffe58e x-ms-traffictypediagnostic: DF4PR8401MB0698: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:632; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nyLMd/nnmmnM1Wcyps0XF2o8FwdJK5UmkK/nxG3JoIHe1jgSxt6lkrRxb1j6kKDNLm3MbOPoLXshML4swYVbBIJ70fDegkvEheiMM6JG8PfM4T3yGs7/BWa5CEHbecs4uqsqlO39ETwYnyEsOmLjt7OGPZgwm0/WlIjoaVLLcJ19j/iFPqJZc3UDlOMn8bKzYt7XDAYT0hENPAbod2ifyQsC71HIctAKwGqovEh9+2td5cMGeUoPQ1HkGiKpoW+jhQ5W+Bl9SHC+o8C8/iKwGHTZTI6NwVxvgBp1j7nt/hWOp4YAccz84Yf3w1y4ZclNbw9a4HhYDjNFAjwOe7CAJZ5XkMkW6B82zA3saY57VkDuME8HrRMJy1QZ4YxVHC880bJRLsrpw/zm3X4e8gphXQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DF4PR8401MB1177.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(366004)(376002)(346002)(396003)(136003)(316002)(9686003)(86362001)(7696005)(66574015)(19627235002)(966005)(52536014)(6506007)(30864003)(8936002)(66446008)(53546011)(66946007)(64756008)(8676002)(83380400001)(66556008)(66476007)(5660300002)(76116006)(33656002)(2906002)(55016002)(6916009)(19627405001)(71200400001)(478600001)(166002)(186003)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HN6aQahhnX4zWPoWLFZRRje04mdhea/4nnztBMIz5QcAnwnQsBaHPtnRcInjsjGFgXM5BA3Ci1biU7QNWc2Z5eDKaAZXEIKnArAvDFCm3BOD3OKqQOyRU+wHTx0seOlRm95lUonf1v3BYVOhpTLxnpblzrw8d/4wkpVJC1wEvaylabQjjPsjR0p82B1UsLQosd9akkgmmDhq/30dEIVphKlgrruZIKeVnP62V9cBJfF8wknvmY9MthRcDsyrsGJdrIFoWICt+ruKSg87zI2SJXxV3I1hr0UBJT150oD95drCK5vF3glE3z4uuVhAxGTJohgWlpiwlHAhKAsn974ndFk4+yKa02ZqFZFAOmjbuwpWvDB1+ezBO261Uv+uOeZyr1rxEQOPtavuTibEEobhZj8PAIsXN2BChkzKQv4nhhWC1GjjkDMmcwtYS4Hxdq4pfzzbQHMMcVaf46foxVWZoTUHL5WYDux3d3iK6WO90uptAylNtEaGJeHNUMyzMjIV6mOSTmpKuuoc1w3V0BdkbGGk0UvMyhSm3IwF1BEkZGZM0Ms9m2KFWUyyje2fS0MyRxdc8fwPDmUdGnfqV6NMJZee1FEZ3fXWGYMSjE08gNheLR4cKItZ74t2JK+OF1pKx8RBRhQ4VRuziuOJO+fs9BvESladEvzkgwnUTA/Ls58= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DF4PR8401MB1177F1FE6807DAB3690AAC13E5180DF4PR8401MB1177_" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DF4PR8401MB1177.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ae9298ec-45eb-40d3-fd6e-08d878ffe58e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2020 16:06:13.5182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fIyxE1grocB9gWAlepcp8TiyHcpbscdnb9S3OmxNLeq9p0h66MzGJE/G7X75uPmh1xz5EnIaO5b/duAdP7NJWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0698 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 16 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-25_11:2020-10-23, 2020-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 phishscore=0 impostorscore=0 spamscore=0 adultscore=0 bulkscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010250119 Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 16:06:24 -0000 --_000_DF4PR8401MB1177F1FE6807DAB3690AAC13E5180DF4PR8401MB1177_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGJlZW4gcmVhZGluZyBidXQgbm90IGNvbW1lbnRlZCBiZWZvcmUsIGJ1dCBJIHdpbGwg YWRkIG15IGNvbW1lbnRzIGhlcmUuDQoNCjEpIGluIHJlbGF0ZWQgdG8gcG9seW1vcnBoaXNtLCBi ZWVuIGEgc29mdHdhcmUgZGV2ZWxvcGVyIG1hbnkgeWVhcnMsIHRoZW4gYSBkaXJlY3RvcnkgKGxk YXAsIElBTSkgYW5kIGEgc2VjdXJpdHkgZW5naW5lZXIgKFBLSSwga2VyYmVyb3MpLiAgSSB0aGlu ayB0aGlzIG9uZSBoYXMgbWVyaXQuICBteSBleHBlcmllbmNlcyBhcmUgZnJvbSBkb2luZyBSUywg UkMgYW5kIHVzZXIgZGV2ZWxvcG1lbnQgYmFja2dyb3VuZC4gIEZyb20gbXkgdmlldywgIHRoaXMg KEpTT04pICBpcyBsaWtlIEFTTjEgYnV0IG11Y2ggc2ltcGxlci4gIEkgbGlrZSBKdXN0aW4ncyBh cHByb2FjaCB0byB2ZXJpZnkgaXQgMXN0IHNpbmNlIGJlZm9yZSBhIHJlZmVyZW5jZSBpbXBsZW1l bnRhdGlvbiwgaXQganVzdCBhIGNvbmNlcHQuDQoNCjIpIEknbSBzb21ld2hhdCBwdXp6bGUgb2Yg bm8gZGlzY3Vzc2lvbiBhcm91bmQgbXVsdGlwbGUgdG9rZW5zIGFuZCB0aGUgY29tcGxpY2F0aW9u IGl0IGJyaW5ncy4gIFdoZW4gSSB0cnkgdG8gZ2V0IE9BVVRIMi9PSURDIGFkb3B0ZWQgd2l0aGlu IG91ciBjb21wYW55LCB0aGF0IGhhcyBiZWVuIHRoZSBtb3N0IGRpZmZpY3VsdCBjb252ZXJzYXRp b25zIHdpdGggb3RoZXIgdGVhbXMuIEkgaGF2ZSB0byByZWFjaCBvdXQgdG8gSm9obiBCIGZvciBj bGFyaWZpY2F0aW9uIG9mIHVzZSBvZiBhenAuIEFtIEkgbWlzc2luZyBzb21lIGRpc2N1c3Npb25z IHRoZXJlPw0KDQozKSBJJ20gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgdGhlIHNwZWMgaGFzIGdy b3duIHRvIGJlIHNvbWUgY29tcGxleCB0byBtaXNzIHRoZSBvcmlnaW5hbCBpbnRlbmQuICB0aGUg ZGlzY3Vzc2lvbiBoYXMgYmVlbiByZWFsbHkgZ29vZCBlc3BlY2lhbGx5IGZyb20gb3RoZXJzIG5v dCBpbiB0aGUgZGVzaWduIHRlYW0gKGUuZy4gRGljayksIEkgd291bGQgZGVmaW5pdGVseSBsaWtl IHRvIGhlYXIgbW9yZSBmcm9tIEpvaG4sIE1pa2UgSiwgQnJpYW4gQyBhbmQgb3RoZXJzIG9uIHRo aXMuDQoNCiBteSAyIGNlbnRzLg0KDQpwZXRlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IEZhYmllbiBJbWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+DQpT ZW50OiBTdW5kYXksIE9jdG9iZXIgMjUsIDIwMjAgMzozOSBBTQ0KVG86IFlhcm9uIFNoZWZmZXIg PHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4NCkNjOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls LmNvbT47IE1pa2EgQm9zdHLDtm0gPG1pa2EuYm9zdHJvbT00MHNtYXJrZXRzLmNvbUBkbWFyYy5p ZXRmLm9yZz47IEdOQVAgTWFpbGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc+OyBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW0dOQVBdIEZlZWRiYWNrIG9uIHBv bHltb3JwaGlzbQ0KDQpIaSBZYXJvbiwNCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQoNClJl Z2FyZGluZyBjbGllbnQgbGlicmFyaWVzLCBJIHRoaW5rIHdlIGNhbiBpbmRlZWQgbGVhcm4gYSBn cmVhdCBkZWFsIGZyb20gY3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMuIENyeXB0b2dyYXBoaWMgZGVz aWduIHByb3ZpZGVzIGEgZ3JlYXQgYW1vdW50IG9mIGZsZXhpYmlsaXR5IGZvciB0aGUgc3BlY2lh bGlzdHMgKGluY2x1ZGluZyBtYW55IHBhcmFtZXRlcnMgdGhhdCB5b3UgcmVhbGx5IG5lZWQgdG8g Z2V0IHJpZ2h0KS4gV2UgbWlnaHQgdGhpbmsgdGhpcyBpcyBncmVhdCB0byBwcm92aWRlIG9wdGlv bnMgYnV0IGl0IGFjdHVhbGx5IGluY3JlYXNlcyB0aGUgY29nbml0aXZlIGxvYWQgb2YgbGlicmFy eSB1c2Vycy4NCg0KTG9vayBpbnN0ZWFkIGF0IHdoYXQgR29vZ2xlIGhhcyBwcm92aWRlZCB3aXRo IHRpbmsgYXMgYW4gYWx0ZXJuYXRpdmUgYW5kIHlvdSdsbCBzZWUgaXQgaXMgYSBtdWNoIGVhc2ll ciB3YXkgZm9yIGNyeXB0b2dyYXBoaWMgZW5naW5lZXJzICh3aG8gYXJlbid0IGNyeXB0b2dyYXBo ZXJzKSB0byBhdm9pZCBtaXN0YWtlcyBvciBtaXN1c2VzLg0KDQpUaGF0J3MgdGhlICpzZWN1cml0 eSogaXNzdWUgSSdtIHJlZmVycmluZyB0byAobm90IHRoZSBmYWN0IHRoYXQgYmVpbmcgb3BlbiB0 aGV5J3JlIHRhc3R5IHRhcmdldHMsIGFsdGhvdWdoIHRoYXQgbWF5IGJlIHJlbGF0ZWQgaW4gc29t ZSBjYXNlcykuIEFuZCB0aW5rIGlzIHRoZSBraW5kIG9mIGRlc2lnbiB3ZSBzaG91bGQgYmUgdHJ5 aW5nIHRvIGFjaGlldmUuDQoNCkkgYWdyZWUgdGhhdCBpdCBzaG91bGQgYmUgYXBwbGljYWJsZSB0 byBhIHdpZGUgcmFuZ2Ugb2Ygd2VsbCBrbm93biBwcm9ncmFtbWluZyB0b29scywgaW5jbHVkaW5n IHRoZSBsaWtlcyBvZiBqYXZhIGFuZCBnby4NCkJ1dCBJIGRvbid0IHJlYWxseSBzZWUgYSBsaW1p dGF0aW9uIGhlcmUuIE1pZ2h0IG5vdCBiZSB0aGUgbW9zdCBpZGlvbWF0aWMgZmVlbCwgYnV0IGl0 IGNhbiBiZSBtYWRlIHRvIHdvcmsuDQoNCkp1c3Qgc28gSSB1bmRlcnN0YW5kLCB3aGF0IGFsdGVy bmF0aXZlcyB3b3VsZCB5b3UgcHJlZmVyIHRvIHBvbHltb3JwaGlzbT8gSSBjYW4gc3VnZ2VzdCBq c29uLWxkIGJ1dCBldmVuIEp1c3RpbiB3aWxsIFRlZWwgeW91IGl0J3MgZXZlbiBtb3JlIGNvbXBs ZXggOi0pDQoNCkNoZWVycw0KRmFiaWVuDQoNCg0KTGUgZGltLiAyNSBvY3QuIDIwMjAgw6AgMTE6 MTcsIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0KDQpIaSBGYWJpZW4sDQoNCg0KDQpJIHRoaW5rIHlv dXIgcHJvZHVjdCBtYW5hZ2VtZW50IG1vZGVsIGhhcyBhIGxvdCBvZiBtZXJpdCwgYnV0IGl0IGRv ZXMgbm90IGNhcHR1cmUgdGhlIHNlY3VyaXR5IGlzc3VlIHdlbGwuDQoNCg0KDQpJIGFncmVlIHRo YXQgYXMgd2UgbG9vayBhdCBkaWZmZXJlbnQgY3VzdG9tZXIgcGVyc29uYXMsIHRoZSDigJxlbmQg dXNlcuKAnSAodGhlIGRldmVsb3BlciB0aGF04oCZcyB1c2luZyB0aGUgbGlicmFyaWVzKSBzaG91 bGQgYmUgb3VyIGhpZ2hlc3QgcHJpb3JpdHkuIEJ1dCBJIGRpc2FncmVlIGFib3V0IGVuZC11c2Vy IG1pc3Rha2VzIGJlaW5nIHRoZSB0b3AgKnNlY3VyaXR5KiBpc3N1ZS4gTGlicmFyaWVzIGFyZSBv ZnRlbiBvcGVuIHNvdXJjZSBpbiBvdXIgc3BhY2UgYW5kIHVzZWQgdmVyeSB3aWRlbHkuIFNvIHRo ZXkgbWFrZSBmb3IgdGFzdHkgdGFyZ2V0cywgYW5kIHBlb3BsZSBhcmUgYXR0YWNraW5nIHRoZW0g YW5kIGFyZSBzdGlsbCBmaW5kaW5nIHNlY3VyaXR5IGlzc3VlcyBpbiBsaWJyYXJpZXMgdGhhdCB3 ZeKAmXZlIGJlZW4gdGFsa2luZyBhYm91dCBmb3JldmVyIFsxXS4NCg0KDQoNCihZZXMsIG15IGV4 YW1wbGUgaXMgYWN0dWFsbHkgYW4gYXBwIGZsYXcsIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGhhdmUg YmVlbiBwcmV2ZW50ZWQgYnkgYSBiZXR0ZXIgZGVzaWduZWQgbGlicmFyeS4pDQoNCg0KDQpJbiBv dGhlciB3b3Jkcywgd2UgZG8gbmVlZCB0byBjYXJlIGFib3V0IGhvdyBlYXN5IGl0IGlzIHRvIGlt cGxlbWVudCB0aGUgcHJvdG9jb2wgY29ycmVjdGx5IGJ5ICpsaWJyYXJ5KiBkZXZlbG9wZXJzLiBG cm9tIEp1c3RpbiBkZXNjcmliaW5nIGhpcyBvd24gZXhwZXJpZW5jZSBhbmQgb3RoZXIgcGVvcGxl IG9uIHRoZSB0aHJlYWQgdGhhdCBEaWNrIHJlZmVycmVkIHRvLCBJIHdvdWxkIHNheSB0aGF0IEpT T04gcG9seW1vcnBoaXNtIGlzIHBhaW5mdWwgZm9yIEphdmEgYW5kIEdvIGRldmVsb3BlcnMuIFdp dGggYWxsIGR1ZSByZXNwZWN0LCBJIGNhcmUgYWJvdXQgdGhlbSBtdWNoIG1vcmUgdGhhbiBJIGNh cmUgYWJvdXQgSGFza2VsbCwgYXMgbWFueSBtb3JlIGltcGxlbWVudGF0aW9ucyBhcmUgbGlrZWx5 IHRvIHVzZSB0aGVzZSBsYW5ndWFnZXMuDQoNCg0KDQpUaGFua3MsDQoNCiAgICAgICAgICAgICAg ICBZYXJvbg0KDQoNCg0KWzFdIGh0dHBzOi8vd3d3LnpvZnJleC5jb20vYmxvZy8yMDIwLzEwLzIw L2FsZy1ub25lLWp3dC1uaHMtY29udGFjdC10cmFjaW5nLWFwcC88aHR0cHM6Ly93d3cuem9mcmV4 LmNvbS9ibG9nLzIwMjAvMTAvMjAvYWxnLW5vbmUtand0LW5ocy1jb250YWN0LXRyYWNpbmctYXBw Lz4NCg0KDQoNCkZyb206IFRYQXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4 YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEZhYmllbiBJbWJhdWx0IDxmYWJp ZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT4+DQpE YXRlOiBTdW5kYXksIE9jdG9iZXIgMjUsIDIwMjAgYXQgMDE6MjUNClRvOiBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6IE1p a2EgQm9zdHLDtm0gPG1pa2EuYm9zdHJvbT00MHNtYXJrZXRzLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBzbWFya2V0cy5jb21AZG1hcmMuaWV0Zi5vcmc+PiwgR05BUCBNYWlsaW5nIExpc3Qg PHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4sIEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4NClN1YmplY3Q6IFJlOiBb R05BUF0gRmVlZGJhY2sgb24gcG9seW1vcnBoaXNtDQoNCg0KDQpIaSBEaWNrLA0KDQoNCg0KSW5k ZXBlbmRhbnRseSBmcm9tIHRoZSBkZWJhdGUgb24gcG9seXBob3JtaXNtLCBJIGJlZyB0byBkaWZm ZXIgb24geW91ciBvcmRlciBwcmVmZXJlbmNlLg0KDQoNCg0KWW91ciBhc3N1bXB0aW9uIGlzIHRo YXQgQVMgZGV2cyBtYXR0ZXIgdGhlIG1vc3QsIGJlY2F1c2UgdGhleSdyZSBkb2luZyB0aGUgaW1w b3J0YW50IHNlY3VyaXR5IGltcGxlbWVudGF0aW9uLiBCdXQgZWF0aW5nIG91ciBvd24gZG9nZm9v ZCBtaWdodCBoZWxwIGEgbG90IHRvIGNoYW5nZSB0aGF0IHZpZXcuIE1vc3Qgc2VjdXJpdHkgaXNz dWVzIG9jY3VyIGJlY2F1c2UgdXNlcnMgb2YgdGhlIHNwZWMgYXJlIHVuYWJsZSB0byBkZWFsIHdp dGggdGhlIGNvbXBsZXhpdHkgdGhhdCBpcyBwYXNzZWQgb250byB0aGVtLg0KDQoNCg0KOTklIG9m IHRoZSBwZW9wbGUgdGhhdCB3aWxsIGFjdHVhbGx5IHVzZSB0aGUgb3V0cHV0IG9mIHRoZSB3b3Jr IGFyZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIChjbGllbnQgb3IgUlMpIGFuZCB0aGVpciBvd24g dXNlcnMuDQoNCg0KDQpPdXIgaW50ZW50IGFzIHdlbGwgYXMgdGhlIHByb3RvY29sIGRyaXZlIHRo ZSB1c2FnZS4gQ2xpZW50IGxpYnJhcmllcyBtYXkgaGVscCwgYnV0IHRoZXkncmUgbm90IGEgc2ls dmVyIGJ1bGxldCwgZXNwZWNpYWxseSBiZWNhdXNlIEdOQVAgdWx0aW1hdGVseSBoYXMgbm8gY29u dHJvbCBhYm91dCB3aGF0IHBlb3BsZSBkbyB0aGVyZSAoZm9yIGJldHRlciBvciB3b3JzZSkuIEFu ZCBldmVyeXRoaW5nIHdlIGRvIGhlcmUgd2lsbCBoZWxwIGdldCB0byB0aGUgYmV0dGVyIHBhcnQu DQoNCg0KDQpJJ20gbm90IHNheWluZyB3ZSBkb24ndCBpbnRlbmQgdG8gYWxzbyBjYXJlIGFib3V0 IEFTIGRldmVsb3BlcnMgKGJlZ2lubmluZyB3aXRoIG91cnNlbHZlcykgYnV0IGl0J3MgYSBzZWNv bmQgb3JkZXIgb3B0aW1pc2F0aW9uLiBBbmQgc2luY2UgaXQncyBhIHRlbmRhbmN5IHdlJ3JlIGxl YW5pbmcgdG93YXJkcyBieSBkZWZhdWx0LCBJJ20gcHJldHR5IHN1cmUgd2Ugd29uJ3QgZm9yZ2V0 IHRoYXQgYW55d2F5Lg0KDQoNCg0KRmFiaWVuDQoNCg0KDQoNCg0KTGUgc2FtLiAyNCBvY3QuIDIw MjAgw6AgMjM6NTAsIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCg0KSSdtIGNvbmZ1c2VkIGJ5IHlvdXIgbG9n aWMgRmFiaWVuLg0KDQoNCg0KSWYgYSBjbGllbnQgbGlicmFyeSBkZXZlbG9wZXIgd2FudHMgdG8g ZXhwb3NlIHBvbHltb3JwaGlzbSwgdGhleSBjYW4gZG8gdGhhdCBpbmRlcGVuZGVudCBvZiB3aGF0 IGlzIGluIHRoZSBwcm90b2NvbC4NCg0KDQoNCkkgZGlmZmVyIG9uIHdobyBvdXIgc3Rha2Vob2xk ZXJzIGFyZS4NCg0KDQoNCkkgdGhpbmsgb3VyIHN0YWtlaG9sZGVycyBhcmUgaW4gbGVhc3QgdG8g bW9zdCBpbXBvcnRhbnQ6DQoNCg0KDQogICogICBBUyBkZXZlbG9wZXINCiAgKiAgIFJTIGRldmVs b3Blcg0KICAqICAgY2xpZW50IGRldmVsb3Blcg0KICAqICAgdXNlcg0KDQoNCg0KQSBjbGllbnQg bGlicmFyeSBkZXZlbG9wZXIgY2FuIGV4cG9zZSB3aGF0ZXZlciBpbnRlcmZhY2UgdGhleSB3YW50 IHRvIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9uLg0KDQoNCg0KSSBsaXN0IHRoZSB1c2VyIHNvIHRo YXQgd2UgZG9uJ3QgbG9zZSBzaXRlIG9mIGEgY3JpdGljYWwgcm9sZS4NCg0KDQoNCi9EaWNrDQoN Cg0KDQoNCg0KW0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLl3hkKcNCg0KDQoNCk9uIEZyaSwgT2N0 IDIzLCAyMDIwIGF0IDY6MjcgUE0gRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWls LmNvbTxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIHRoZXJl LA0KDQoNCg0KTGV0IG1lIHRyeSB0byBhcHByb2FjaCB0aGUgaXNzdWUgdW5kZXIgYSBkaWZmZXJl bnQgbGlnaHQuIE1vcmUgbGlrZSBhIHByb2R1Y3QgbWFuYWdlciB3b3VsZCBkZWFsIHdpdGggZmVh dHVyZSBzZWxlY3Rpb24gdG8gbWFrZSBpdCBpbnR1aXRpdmUgZm9yIGl0cyB1c2Vycy4NCg0KDQoN CkZvciBtb3N0IHBlb3BsZSwgcmlkaW5nIGEgYmlrZSBpcyBmYXIgZWFzaWVyIHRoYW4gdXNpbmcg YSB1bmljeWNsZS4gRmVlbHMgbW9yZSBzdGFibGUuIEFuZCB5ZXQgaXQncyB3YXkgZWFzaWVyIHRv IGRlc2lnbiBmb3IgYSBzaW5nbGUgd2hlZWwgdGhhbiB0byBidWlsZCB3aXRoIDIuIEJlY2F1c2Ug dGhlbiB5b3UnbGwgbmVlZCBhIGxvdCBtb3JlIGFjY2Vzc29yaWVzIChjaGFpbiwgY2hhaW4gcmlu ZywgZXRjLikuIEV2ZW4gc28gcHJvZHVjaW5nIGEgYmlrZSBkb2Vzbid0IGhhdmUgdG8gYmUgYSBi cml0dGxlIHByb2Nlc3MsIGl0IGNhbiBiZSBpbmR1c3RyaWFsaXplZC4NCg0KDQoNCkJhY2sgdG8g dGhlIEdOQVAgdG9waWMuDQoNClVsdGltYXRlbHkgd2Ugc2hvdWxkIHN0cml2ZSB0byBtYWtlIHRo ZSBzcGVjIGFzIHNpbXBsZSBhcyBjYW4gYmUuIEJ1dCB3ZSBuZWVkIHRvIGFzazogc2ltcGxlIGZv ciB3aG9tPyBGb3IgdGhlIGJpa2Ugb3duZXIgb3IgZm9yIHRoZSBiaWtlIHZlbmRvcj8NCg0KKHNo b3J0IGFuc3dlcjogdGhlIHByaW9yaXR5IHNob3VsZCBiZSBzaW1wbGljaXR5IGZvciBzcGVjIHVz ZXJzLCBub3Qgc3BlYyBpbXBsZW1lbnRlcnMgYW5kIGV2ZW4gbGVzcyBzcGVjIGRlc2lnbmVycyku DQoNCg0KDQpUaGUgaW5pdGlhbCBxdWVzdGlvbiB0aGF0IGlzIGFza2VkIGlzIHZlcnkgaW50ZXJl c3Rpbmc6IGlzbid0IHRoZSBkZXNpZ24gZmxhd2VkIGlmIEdOQVAgaXMgdXNpbmcganNvbiBwb2x5 cGhvcm1pc20/IE9yIGlmIHRoZSBBUyBuZWVkcyB0byBoYW5kbGUgdGhlIHN0YXRlIG9mIHRoZSBy ZXF1ZXN0PyBPciBpZiB3ZSBtdXN0IGhhbmRsZSB0b2tlbiByZXZvY2F0aW9uPyBPciBpZiB3ZSBh cmUgbG9va2luZyBmb3IgYSBnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXI/IFRoZSBhcmd1bWVudCBz dGVtcyBvZiB0aGUgZmFjdCB0aGF0IGlzIHN0aWxsIGFyZ3VhYmx5IGhhcmRlciBhbmQgbW9yZSBl cnJvciBwcm9uZSB0byBpbXBsZW1lbnQuIEZhaXIgZW5vdWdoLg0KDQoNCg0KRnJvbSBhIHNwZWMg aW1wbGVtZW50ZXIncyBwZXJzcGVjdGl2ZSwgaXQgbWF5IHdlbGwgYmUgbW9yZSBjb21wbGV4LiBJ dCBtb3N0bHkgaW1wYWN0cyB0aGUganNvbiBsaWJyYXJ5IHlvdSdsbCBlbmQgdXAgdXNpbmcsIHBs dXMgYSBiaXQgb2YgaW5wdXQvb3V0cHV0IGRlY29yYXRpb24gYXJvdW5kIGl0LiBFdmVuIGdvbGFu ZyBwcm92aWRlcyB1dGlsaXRpZXMgZm9yIHRoaXMsIGRlc3BpdGUgbm90IGV4YWN0bHkgYmVpbmcg bWFkZSBmb3IgdGhpcyBraW5kIG9mIHB1cnBvc2UuDQoNCk15IHByYWN0aWNhbCBleHBlcmllbmNl IGltcGxlbWVudGluZyBpdCBpcyB0aGF0IGl0J3Mgbm90IHRoYXQgYmlnIGEgZGVhbC4gSSBtZWFu LCBJIHdpc2hlZCBpdCBjb3VsZCBiZSBzaW1wbGVyLCBidXQgaXQncyBtYW5hZ2VhYmxlIGFuZCB0 aGVyZSBhcmUgb3RoZXIgd2F5cyB0byByZWFjaCBsZXZlbHMgb2YgaW5zdXJhbmNlIHRoYXQgaXQg ZG9lcyB3b3JrIGFzIGludGVuZGVkIChqc29uIHNjaGVtYSwgdGVzdCBjYXNlcyB0byB2YWxpZGF0 ZSB0aGUgaW1wbGVtZW50YXRpb24sIGV0Yy4pLiBBcmd1YWJseSBpdCBpcyBzdGlsbCBlYXNpZXIg ZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSB0aGFuIHNheSwganNvbi1sZCwgd2hp Y2ggaXMgbWFzc2l2ZWx5IHVzZWQgaW4gdGhlIFNTSSBjb21tdW5pdHkuDQoNCg0KDQpCdXQgdWx0 aW1hdGVseSB3aG8gYXJlIHdlIGRlc2lnbmluZyBmb3I/IEFyZSB3ZSBzdHJpdmluZyB0byBnbyBl YXN5IG9uIHRoZSBzcGVjIGltcGxlbWVudGVyPyBPciBhcmUgd2UgdHJ5aW5nIHRvIG1ha2Ugc3Vy ZSBlbmQtZGV2ZWxvcGVycyB1c2luZyB0aGUgY2xpZW50IGxpYnJhcmllcyB3b24ndCBzaG9vdCB0 aGVtc2VsdmVzIGluIHRoZSBmb290Pw0KDQoNCg0KVGhlIGpvYiB0byBiZSBkb25lIChKVEJEKSwg ZnJvbSB0aGUgZW5kLWRldmVsb3BlcidzIHBlcnNwZWN0aXZlLCBpcyB0byBlZmZpY2llbnRseSBz aGlwIGFuIGFwcGxpY2F0aW9uLiBBbmQgcHJvdmlkZSBhdXRoTi9hdXRoWiBjYXBhYmlsaXRpZXMg Zm9yIGVuZC11c2VycyBieSByZWx5aW5nIG9uIHNvbWUgd2VsbCBrbm93biBpbXBsZW1lbnRhdGlv bi4NCg0KSW4gdHVybiwgdGhpcyBzcGVjIGltcGxlbWVudGVyIHdpbGwgcmVseSBvbiBjcnlwdG9n cmFwaGljIHV0aWxpdHkgbGlicmFyaWVzIHRoYXQgZGVhbHMgaW50ZXJuYWxseSB3aXRoIHRoZSBj b21wbGV4aXR5IG9mIHRoZWlyIG93biBkb21haW4sIHNvIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0by4g QW5kIGhlcmUgd2UgY291bGQgbGF1bmNoIGFub3RoZXIgSE4gZmxhbWUgd2FyIHRoYXQgc3RhcnRz IHdpdGggdGhlIHRpdGxlICJKV1Qgc3Vja3MgYmVjYXVzZSIuIFdoaWNoIGRvZXMgaGF2ZSBpdHMg c2V0IG9mIHZlcnkgcmVhbCBpc3N1ZXMgYnV0IHRoYXQncyBiZXlvbmQgdGhlIHBvaW50Lg0KDQpO b3RlIHRoYXQgYW55IGRlY2VudCBmbGFtZXdhciB3aWxsIGJlIGVmZmljaWVudGx5IGZ1ZWxlZCBi eSBwZW9wbGUgaGF0aW5nIG1lZGl1bS4gSXMgaXQgb3V0cmFnZW91cyBmb3IgYmxvZyBwb3N0cyB0 byBiZSBiZWhpbmQgYSBwYXl3YWxsPyBNYXliZSBidXQgaXQncyBldmVuIG1vcmUgb3V0cmFnZW91 cyB0byBsYWNrIGNvbnNpc3RlbmN5LCBlaXRoZXIgYnkgbm90IGtub3dpbmcgaG93IHRvIGdldCBh cm91bmQgYSBwYXl3YWxsIGlmIHlvdSdyZSBpbnRvIGEgaGFja2VyIHB1bmsgbW92ZW1lbnQsIG9y IG9uIHRoZSBjb250cmFyeSBieSB0byBub3QgcGF5aW5nIGEgc3Vic2NyaXB0aW9uIGlmIHlvdSBi ZWxpZXZlIHRoYXQgc3VydmVpbGxhbmNlIGNhcGl0YWxpc20sIHRvIHJldXNlIFp1Ym9mZidzIHRl cm1zLCBzaG91bGQgYmUgZXJhZGljYXRlZC4NCg0KV2hhdCBsaWtlbHkgc2VlbXMgYW4gdW5uZWNl c3Nhcnkgc2lkZW5vdGUgdHJpZXMgdG8gaWxsdXN0cmF0ZSB0aGUgcG9pbnQ6IGZvciBKdXN0aW4g aXQgd2FzIGVhc2llciB0byBwdWJsaXNoIG9uIG1lZGl1bSwgYmVjYXVzZSBhcyBhIGJsb2cgcHVi bGlzaGVyLCB5b3UgbWlnaHQgbm90IHdhbnQgdG8gZGVhbCB3aXRoIGhvc3RpbmcgeW91ciBvd24g YmxvZy4gQnV0IG1heWJlIGFzIGEgcmVhZGVyIHlvdSdsbCBmaW5kIHRoYXQgYW5ub3lpbmcuIERp ZmZlcmVudCBhdWRpZW5jZXMsIGRpZmZlcmVudCBKVEJELCBkaWZmZXJlbnQgdHJhZGVvZmZzLg0K DQoNCg0KUG9seXBob3JtaXNtIGlzIGEgdG9vbCB0aGF0IGVuYWJsZXMgdGhlIGVuZC1kZXZlbG9w ZXIgdG8gaGF2ZSBtaW5pbWFsIGtub3dsZWRnZSBvZiB3aGF0IGl0IG1lYW5zIHRvIGRlYWwgd2l0 aCBhIEdOQVAgY2xpZW50IGxpYnJhcnkuIFlvdSBwcmVwYXJlIHRoZSByZXF1ZXN0LCBzZW5kIHRv IHRoZSBlbmRwb2ludCBhbmQgeW91J3JlIGdvb2QgdG8gZ28uIE1hc3NpdmVseSBzaW1wbGVyIHRo YW4gT0F1dGgyIG9yIGFueSBzaW1pbGFyIHByb3RvY29sIGJ5IHRoZSB3YXkgKGFzIGFueW9uZSB3 aXRoIHRlYWNoaW5nIGV4cGVyaWVuY2Ugb24gdGhlIHN1YmplY3QgbWlnaHQgYWNrbm93bGVkZ2Up LiBBbmQgIHRoZXJlJ3MgYSBsb3QgbW9yZSB0byBiZSBkb25lIHRvIG1ha2Ugc3VyZSB3ZSBpbmRl ZWQgcmVkdWNlIHRoZSBjb21wbGV4aXR5IGZvciB0aGUgZW5kLWRldmVsb3BlciBhbmQgdGhlIGVu ZC11c2VyLg0KDQoNCg0KSWYgd2UgZmluZCBhIGJldHRlciB3YXkgdG8gZGVhbCB3aXRoIHRoYXQg c2ltcGxpY2l0eSBiYWxhbmNlLCBJJ20gYWxsIGluLiBCdXQgdGhlIGFyZ3VtZW50cyBuZWVkIHRv IGJlIHdheSBtb3JlIGNvbnZpbmNpbmcgdGhhbiBqdXN0IHNheWluZyB0aGF0IGl0IG1heSBiZSBk aWZmaWN1bHQgdG8gaW1wbGVtZW50IG9yIHZhbGlkYXRlLg0KDQoNCg0KQ2hlZXJzLg0KDQpGYWJp ZW4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZSB2ZW4uIDIzIG9jdC4gMjAyMCDDoCAyMjozNSwg SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiBh IMOpY3JpdCA6DQoNCg0KDQoNCg0KT24gT2N0IDIzLCAyMDIwLCBhdCAzOjUyIFBNLCBEaWNrIEhh cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3 cm90ZToNCg0KDQoNCkp1c3Rpbg0KDQoNCg0KSSBkaWQgbm90ZSB0aGF0IEkgd2FzIHRoZSBvbmUg dGhhdCBhcmd1ZWQgZm9yIGluc3RhbmNlX2lkIGJlaW5nIGluIHRoZSBvYmplY3QuIFNpbmNlIGl0 IGlzIGluIHRoZSBvYmplY3QgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIG5vdCBpbmNsdWRpbmcgYSBw YXNzIGJ5IHJlZmVyZW5jZSBvcHRpb24gd291bGQgYmUgcHJlZmVyYWJsZS4NCg0KDQoNCkFzIGZv ciBjb25jcmV0ZSBleGFtcGxlczoNCg0KLSB2ZXJzaW9uIG9mIGNsaWVudA0KDQotIHZlcnNpb24g b2YgT1MNCg0KLSBzZWN1cml0eSBhdHRlc3RhdGlvbiBvZiBPUyAvIGRldmljZQ0KDQotIGxvY2F0 aW9uIG9mIGNsaWVudCBkZXZpY2UNCg0KLSBuZXR3b3JrIGNsaWVudCBpcyBvcGVyYXRpbmcgb24N Cg0KDQoNClRoZXNlIGFyZSBhbGwgYXR0cmlidXRlcyBvZiB0aGUgY2xpZW50IHRoYXQgYW4gQVMg bWF5IHJlcXVpcmUgb24gdGhlIGluaXRpYWwgZ3JhbnQgcmVxdWVzdCwgYW5kIGluIGZ1dHVyZSBn cmFudCByZXF1ZXN0cyAod2hpY2ggaXMgd2hlbiBhbiBpbnN0YW5jZV9pZCkgd291bGQgYmUgdXNl ZC4NCg0KDQoNCg0KDQpUaGlzIGlzIHdoZXJlIG91ciBpbnRlcnByZXRhdGlvbnMgZGlmZmVyOiBJ IGRvbuKAmXQgc2VlIHRoZXNlIGFzIOKAnGF0dHJpYnV0ZXMgb2YgdGhlIGNsaWVudOKAnSBpbiB0 aGUgc2FtZSB3YXkgdGhhdCB0aGUga2V5LCBkaXNwbGF5IGluZm9ybWF0aW9uLCBjbGFzcyBpZGVu dGlmaWVycywgYW5kIG90aGVyIGl0ZW1zIGN1cnJlbnRseSByZXByZXNlbnRlZCBieSBhbiBpbnN0 YW5jZV9pZCBhcmUgYXR0cmlidXRlcyBvZiB0aGUgY2xpZW50IGluc3RhbmNlLiBUaGUgYXR0ZXN0 YXRpb24gY29tcG9uZW50cyBkb27igJl0IG1vZGlmeSB0aGUgaW5zdGFuY2Ugc28gbXVjaCBhcyBw cmVzZW50IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gb24gdG9wIG9mIHRoZSBjbGllbnQgaW5zdGFu Y2UgaXRzZWxmLiBUaGlzIGlzIHdoeSBJIGFyZ3VlIHRoYXQgdGhleSBvdWdodCB0byBiZSBoYW5k bGVkIGluIGEgc2VwYXJhdGUgb2JqZWN0LCBzbyB5b3XigJlkIGhhdmUgc29tZXRoaW5nIGxpa2Ug dGhpcyBzdHJhd21hbjoNCg0KDQoNCnsNCg0KDQoNCiAgcG9zdHVyZTogew0KDQogICAgc29mdHdh cmVfdmVyc2lvbjogMS4yLjMsDQoNCiAgICBvc192ZXJzaW9uOiAxNC4zLjINCg0KICAgIGRldmlj ZV9hdHRlc3RhdGlvbjogeyDigKYgc29tZSBzdHJ1Y3R1cmUgb3Igc2lnbmVkIGJsb2I/IOKApiB9 DQoNCiAgICBsb2NhdGlvbjogeyBsYXQ6IOKApiwgbG9uOiDigKYsIGFsdDog4oCmIH0NCg0KICB9 LA0KDQoNCg0KICBjbGllbnQ6IOKAnGNsaWVudC01NDEtYWIiDQoNCg0KDQp9DQoNCg0KDQpUaGlz IGlzIGEgbW9yZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBhYm91dCBHTkFQIHRoYW4gd2hldGhlciB0 aGUgc3ludGF4IHVzZXMgcG9seW1vcnBoaXNtOiB0aGlzIGlzIGFib3V0IEdOQVAgYmVpbmcgdmVy eSBleHBsaWNpdCBhYm91dCB0aGUgZGF0YSBtb2RlbCBvZiBpdHMgZWxlbWVudHMuIE9BdXRoIDLi gJlzIGluY3JlZGlibHkgbG9vc2UgYW5kIGJyb2FkIG1vZGVsIG9mIHdoYXQgdGhlIHRlcm0g4oCc Y2xpZW504oCdIGlzIHJlZmVycmluZyB0bywgZXhhY3RseSwgaXMgZGVlcGx5IHByb2JsZW1hdGlj IGluIHByYWN0aWNlLiBXZeKAmXJlIGV2ZW4gc2VlaW5nIHRoYXQgaW4gdGhlIE9BdXRoIDIuMSB3 b3JrIHdpdGggaGF2aW5nIHRvIGRlZmluZSBhIOKAnGNyZWRlbnRpYWxlZCBjbGllbnTigJ0sIGFu ZCBldmVuIHRoZW4gdGhhdCBkb2VzbuKAmXQgZnVsbHkgY2FwdHVyZSB0aGUgZGlmZmVyZW50IGFz cGVjdHMgdGhhdCBhcmUgb3V0IHRoZXJlLiBJIHRoaW5rIHdl4oCZcmUgZ2V0dGluZyBjbG9zZXIg aGVyZSBpbiBHTkFQIHdpdGggZXhwbGljaXQgZGVmaW5pdGlvbiBvZiDigJxjbGllbnQgaW5zdGFu Y2XigJ0sIGJ1dCB3ZSBzdGlsbCBuZWVkIHRvIGJlIG1vcmUgcHJlY2lzZSBhYm91dCB3aGF0IGV4 YWN0bHkgYSBjbGllbnQgaW5zdGFuY2UgaW5jbHVkZXMsIGFuZCB3aGF0IGl0IGRvZXMgbm90Lg0K DQoNCg0KIOKAlCBKdXN0aW4NCg0KDQoNCg0KDQovRGljaw0KDQoNCg0KW0ltYWdlIHJlbW92ZWQg Ynkgc2VuZGVyLl3hkKcNCg0KDQoNCk9uIEZyaSwgT2N0IDIzLCAyMDIwIGF0IDEyOjQyIFBNIEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3Jv dGU6DQoNCkRpY2ssDQoNCg0KDQpBcyB5b3XigJlsbCByZWNhbGwsIEkgYXJndWVkIGFnYWluc3Qg aW5jbHVkaW5nIHRoZSBjbGllbnQgaW5zdGFuY2UgaWRlbnRpZmllciBpbnNpZGUgb2YgdGhlIG9i amVjdCBhcyBhIG11dHVhbGx5LWV4Y2x1c2l2ZSBmaWVsZCBwcmVjaXNlbHkgYmVjYXVzZSBvZiB0 aGUgcHJpbmNpcGxlIHZpb2xhdGlvbiB0aGF0IHlvdSBhcmUgcG9pbnRpbmcgb3V0IGhlcmUsIGFu ZCBzbyBpdOKAmXMgaW1wb3J0YW50IHRvIHBvaW50IG91dCB0aGF0IHRoZSBjdXJyZW50IHRleHQg aXMgYSBjb21wcm9taXNlIHRoYXQgbmVlZHMgdG8gYmUgZXhhbWluZWQgaW4gdGhlIHdpZGVyIGV4 cGVyaWVuY2Ugb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIEkgYW0gb24gdGhlIHNpZGUgb2YgcmVtb3Zp bmcgdGhlIG11dHVhbGx5LWV4Y2x1c2l2ZSDigJxpbnN0YW5jZV9pZOKAnSBvcHRpb24gd2l0aGlu IGFuIG9iamVjdCwgYnV0IHRoaXMgbmVlZHMgdG8gYmUgZXhwbG9yZWQuDQoNCg0KDQpUaGUgY3J1 eCBvZiBteSBhcmd1bWVudCBpcyB0aGF0IGlzIGV4YWN0bHkgYSBjYXNlIG9mIHBhc3MtYnktcmVm ZXJlbmNlIHZzIHBhc3MtYnktdmFsdWUsIGFuZCB0aGF0IHJ1bnRpbWUgYXR0ZXN0YXRpb25zIGFy ZSBub3QgcGFydCBvZiB0aGUg4oCcY2xpZW50IGluc3RhbmNl4oCdIHZhbHVlIGl0c2VsZiBidXQg cmF0aGVyIGJlbG9uZyBvdXRzaWRlIG9mIHRoYXQgb2JqZWN0IGluIGEgYW5vdGhlciBwYXJ0IG9m IHRoZSByZXF1ZXN0LiBBcyBzdGF0ZWQgaW4gdGhlIGVkaXRvcmlhbCBub3RlcyBpbiB0aGlzIHNl Y3Rpb24sIHdlIG5lZWQgdG8gbG9vayBjYXJlZnVsbHkgYXQgaG93IHRoZXNlIGNvbmNlcHRzIGZp dCB3aXRoaW4gdGhlIG1vZGVsIGFuZCB3aGVyZSB3ZSB3b3VsZCB3YW50IHRvIHB1dCB0aGVtLiBX aXRob3V0IGNvbmNyZXRlIGV4YW1wbGVzIG9mIHdoYXQgdGhlc2UgZXh0ZW5zaW9ucyBsb29rIGxp a2UgYW5kIGhvdyB0aGV54oCZcmUgZ2VuZXJhdGVkLCB0aGF0IGlzIG5lYXJseSBpbXBvc3NpYmxl IHRvIGRvIGF0IHRoaXMgc3RhZ2UuIEkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyBleGFtcGxlcyBv ZiB0aGlzIGtpbmQgb2YgZGF0YSBhbmQgaG93IGl0IGNhbiBmaXQgaW50byB0aGUgcHJvdG9jb2wu DQoNCg0KDQog4oCUIEp1c3Rpbg0KDQoNCg0KT24gT2N0IDIzLCAyMDIwLCBhdCAzOjA3IFBNLCBE aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20+PiB3cm90ZToNCg0KDQoNCkhleSBKdXN0aW4sDQoNCg0KDQpBcyB0aGUgZHJhZnQgaGFzIGV2 b2x2ZWQsIEkgcXVlc3Rpb24gdGhlIGNvbnRpbnVlZCB1c2Ugb2YgcG9seW1vcnBoaXNtLiBOb3Rl IHRoYXQgSSBhcHByZWNpYXRlIHRoZSBlbGVnYW5jZSBvZiB1c2luZyBhIHN0cmluZyBmb3IgcGFz cy1ieS1yZWZlcmVuY2UsIGFuZCBhbiBvYmplY3QgZm9yIHBhc3MtYnktdmFsdWUuDQoNCg0KDQpJ biB0aGUgY3VycmVudCBkcmFmdCwgdGhlDQoNCg0KDQpFdmVyeSB0aW1lIHlvdSBjcmVhdGUgb3Ig cHJvY2VzcyBhIGZpZWxkIGl0IHdpbGwgbWVhbiBvbmx5IG9uZSB0aGluZywgYW5kIHRoZXJl4oCZ cyBvbmx5IG9uZSBmaWVsZCB0byBsb29rIGF0IHRvIGFuc3dlciBhIHF1ZXN0aW9uLg0KDQoNCg0K aXMgdmlvbGF0ZWQgaW4gMi4zLjEuICBJZGVudGlmeWluZyB0aGUgUkMgSW5zdGFuY2U8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ25hcC1jb3JlLXByb3RvY29sLTAwI3Nl Y3Rpb24tMi4zLjE+DQoNCg0KDQoNCg0KICAgaW5zdGFuY2VfaWQgIEFuIGlkZW50aWZpZXIgc3Ry aW5nIHRoYXQgdGhlIEFTIGNhbiB1c2UgdG8gaWRlbnRpZnkgdGhlDQoNCiAgICAgIHBhcnRpY3Vs YXIgaW5zdGFuY2Ugb2YgdGhpcyBSQy4gIFRoZSBjb250ZW50IGFuZCBzdHJ1Y3R1cmUgb2YgdGhp cw0KDQogICAgICBpZGVudGlmaWVyIGlzIG9wYXF1ZSB0byB0aGUgUkMuDQoNCg0KDQogICAiY2xp ZW50Ijogew0KDQogICAgICAgImluc3RhbmNlX2lkIjogImNsaWVudC01NDEtYWIiDQoNCiAgIH0N Cg0KDQoNCiAgIElmIHRoZXJlIGFyZSBubyBhZGRpdGlvbmFsIGZpZWxkcyB0byBzZW5kLCB0aGUg UkMgTUFZIHNlbmQgdGhlDQoNCiAgIGluc3RhbmNlIGlkZW50aWZpZXIgYXMgYSBkaXJlY3QgcmVm ZXJlbmNlIHZhbHVlIGluIGxpZXUgb2YgdGhlDQoNCiAgIG9iamVjdC4NCg0KDQoNCiAgICJjbGll bnQiOiAiY2xpZW50LTU0MS1hYiINCg0KDQoNClRoZSBpbnN0YW5jZSBpZGVudGlmaWVyIGNhbiBi ZSBzZW50IHR3byB3YXlzLiBQb2x5bW9ycGhpc20gaXMgYSBjb252ZW5pZW5jZSBmb3IgdGhlIGNs aWVudCwgYnV0IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgdG8gaGF2ZSB0d28gY29kZSBwYXRocyBmb3Ig Imluc3RhbmNlX2lkIi4gIFdlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBkZXNpZ24gdGVhbSwgYW5k IEkgYXJndWVkIGZvciBoYXZpbmcgImluc3RhbmNlX2lkIiBpbiB0aGUgImNsaWVudCIgb2JqZWN0 IHNvIHRoYXQgYW55IHVwZGF0ZXMsIHN1Y2ggYXMgbmV3IGRldmljZXMgYXNzZXJ0aW9ucywgY291 bGQgYmUgaW4gdGhlICJjbGllbnQiIG9iamVjdC4gQXMgbm90ZWQgYWJvdmUsIHdoaWxlIEkgYXBw cmVjaWF0ZSB0aGUgZWxlZ2FuY2Ugb2YgdXNpbmcgYSBzdHJpbmcgKGhhbmRsZSkgdG8gcmVmZXJl bmNlIGEgcHJldmlvdXNseSBwcm92aWRlZCBvYmplY3QsIGl0IGNvbXBsaWNhdGVzIGhvdyB0byB1 cGRhdGUgYW4gZXhpc3Rpbmcgb2JqZWN0IHdoaWxlIHByb3ZpZGluZyB0aGUgcmVmZXJlbmNlLg0K DQoNCg0KSW4geW91ciBleGFtcGxlIG9mIHRoZSAia2V5IiBvYmplY3QgYmVsb3csIHNldHRpbmcg InByb29mIiB0byBiZWFyZXIgd291bGQgYXZvaWQgdGhlIGlzc3VlIHlvdSBkZXNjcmliZToNCg0K DQoNCnsNCiAia2V5Ijogew0KICAgICAicHJvb2YiOiAiYmVhcmVyIg0KICAgIH0NCn0NCg0KDQoN CkluIHlvdXIgZXhhbXBsZSwgd2hlbiBwcm9jZXNzaW5nIHRoZSAia2V5IiBvYmplY3QsIGNvZGUg aXMgaGF2aW5nIHRvIGNoZWNrIGJvdGggdGhlIEpTT04gdHlwZSBvZiB0aGUgcHJvcGVydHksIGFz IHdlbGwgYXMgY2hlY2sgdGhlIHZhbHVlIG9mIHRoZSAicHJvb2YiIHByb3BlcnR5LiBJbiB0aGUg ZXhhbXBsZSBJIHByb3ZpZGVkLCBvbmx5IHRoZSB2YWx1ZSBvZiAicHJvb2YiIG5lZWRzIHRvIGJl IGNoZWNrZWQuIFRoZSAicHJvb2YiIHByb3BlcnR5IGlzIGFjdGluZyBhcyBhIHR5cGUgZm9yIHRo ZSAia2V5IiBvYmplY3QuDQoNCg0KDQpOb3QgYmVpbmcgYSBKYXZhIHByb2dyYW1tZXIsIEkgZG9u J3Qga25vdyBob3cgdGhpcyB3b3VsZCB3b3JrIGluIGEgSmF2YSBpbXBsZW1lbnRhdGlvbiwgYnV0 IG5vZGUuanMsIHRoZSBwcm9jZXNzaW5nIHdvdWxkIG5lZWQgdG8gYmUgZG9uZSBhcyBhYm92ZS4N Cg0KDQoNCk9uIGEgcmVsYXRlZCBub3RlLCB0aGVyZSB3YXMgc2lnbmlmaWNhbnQgbmVnYXRpdmUg ZmVlZGJhY2sgb24gaGFuZGxlcyBhbmQgcG9seW1vcnBoaXNtIGluIHRoZSBIYWNrZXIgTmV3cyBh cnRpY2xlIGh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRlbT9pZD0yNDg1NTc1MDxodHRw czovL25ld3MueWNvbWJpbmF0b3IuY29tL2l0ZW0/aWQ9MjQ4NTU3NTA+DQoNCg0KDQovRGljaw0K DQoNCg0KDQoNCk9uIEZyaSwgT2N0IDIzLCAyMDIwIGF0IDEwOjIwIEFNIEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQoNCkhpIE1p a2EsDQoNCg0KDQpUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdG9waWMgaGVyZSDigJQgSSB3YXMg YWJsZSB0byBzZWUgdGhlIGZvcnVtIGRpc2N1c3Npb24gdGhhdCBicm91Z2h0IHlvdSBoZXJlLCBh bmQgaG9wZWZ1bGx5IEkgY2FuIGhlbHAgY2xlYXIgdXAgd2hhdCBJIG1lYW4gd2l0aCBob3cgcG9s eW1vcnBoaXNtIGlzIHVzZWQgaW4gdGhlIHByb3Bvc2FsLiBUaGUgc2hvcnQgdmVyc2lvbiBpcyB0 aGF0IHRoZSBnb2FsIGlzIHRvIGF2b2lkIHRoZSBraW5kcyBvZiBhbWJpZ3VpdHkgdGhhdCBtYWtl IGluc2VjdXJlIHByb3RvY29scywgYW5kIHNvIGluIHRoYXQgZ29hbCB3ZeKAmXJlIGZ1bGx5IGFs aWduZWQuIEkgdGhpbmsgdGhhdCB1c2luZyBwb2x5bW9ycGhpc20gaW4gdmVyeSBzcGVjaWZpYyB3 YXlzIGNhbiBoZWxwIHRoYXQgZ29hbCDigJQganVzdCBhcyBJIGFncmVlIHRoYXQgbWlzdXNpbmcg aXQgb3IgYXBwbHlpbmcgaXQgc2xvcHBpbHkgY2FuIGxlYWQgdG8gYW1iaWd1b3VzIGFuZCBpbnNl Y3VyZSBzeXN0ZW1zLg0KDQoNCg0KU29tZSBiYWNrZ3JvdW5kOiBJIGJ1aWx0IG91dCB0aGUgWFla IHByb3RvY29sIChvbmUgb2YgdGhlIHByZWRlY2Vzc29ycyB0byB0aGUgaW5pdGlhbCBHTkFQIERy YWZ0KSBpbiBKYXZhIHVzaW5nIHN0cm9uZ2x5IHR5cGVkIHBhcnNlcnMgYW5kIEphdmEgb2JqZWN0 cyBzcGVjaWZpY2FsbHkgdG8gcHJvdmUgdG8gbXlzZWxmIHRoYXQgaXQgY291bGQgYmUgZG9uZSBp biBhIHdheSB0aGF0IG1hZGUgYW55IHNlbnNlIGluIHRoZSBjb2RlLiAoTXkgb3duIG9wZW4gc291 cmNlIGltcGxlbWVudGF0aW9uIGlzIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9ic3BrL29hdXRoLnh5 ei1qYXZhLCBidXQgbm90ZSB0aGF0IGl04oCZcyBub3QgeWV0IHVwIHRvIGRhdGUgd2l0aCB0aGUg R05BUCBzcGVjKS4gSXQgd2FzIGltcG9ydGFudCB0byBtZSB0aGF0IEkgYmUgYWJsZSB0byB1c2Ug dGhlIHN5c3RlbS13aWRlIGNvbmZpZ3VyZWQgcGFyc2VycyB0byBpbXBsZW1lbnQgdGhpcyBhbmQg bm90IGhhdmUgdG8gcmVzb3J0IHRvIHN0ZXBwaW5nIHRocm91Z2ggZWxlbWVudHMgY29tcGxldGVs eSBieSBoYW5kLiBKYXZhIGRvZXNu4oCZdCBtYWtlIGl0IHNpbXBsZSB0byBnZXQgdGhlIGhvb2tz IGludG8gdGhlIHJpZ2h0IHBsYWNlcyAoZXNwZWNpYWxseSB3aXRoIHRoZSBKYWNrc29uIHBhcnNl ciB0aGF0IEkgdXNlZCksIGJ1dCBpdCBpcyBkZWZpbml0ZWx5IHBvc3NpYmxlIHRvIGNyZWF0ZSBh IGRldGVybWluaXN0aWMgYW5kIHN0cm9uZ2x5LXR5cGVkIHBhcnNlciBhbmQgc2VyaWFsaXplciBm b3IgdGhpcyBraW5kIG9mIGRhdGEgc3RydWN0dXJlLiBTb21lIG9mIHRoZSByYXRpb25hbGUgZm9y IHVzaW5nIHBvbHltb3JwaGlzbSBpcyBjb3ZlcmVkIGluIHRoZSB0cmFpbGluZyBhcHBlbmRpeCBv ZiB0aGUgZHJhZnQgZG9jdW1lbnQgKGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJh ZnQtaWV0Zi1nbmFwLWNvcmUtcHJvdG9jb2wtMDAuaHRtbCNuYW1lLWpzb24tc3RydWN0dXJlcy1h bmQtcG9seW1vcjxodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtZ25h cC1jb3JlLXByb3RvY29sLTAwLmh0bWwjbmFtZS1qc29uLXN0cnVjdHVyZXMtYW5kLXBvbHltb3I+ KSwgYnV0IGl04oCZcyBzdGlsbCBnb29kIHRvIGRpc2N1c3MgdGhpcyBoZXJlIGFzIHRoZSB3b3Jr aW5nIGdyb3VwIGRlY2lkZXMgd2hpY2ggYXBwcm9hY2hlcyB0byB0YWtlLg0KDQoNCg0KVGhlIGRy aXZpbmcgcmVhc29uIGZvciB1c2luZyBwb2x5bW9ycGhpc20gYXQgdGhlIHByb3RvY29sIGxldmVs IHdhcyB0byBzaW1wbGlmeSB0aGUgcHJvdG9jb2wgYW5kIG1ha2UgaXQgOm1vcmU6IGRldGVybWlu aXN0aWMgdG8gY3JlYXRlIGFuZCBwcm9jZXNzLCBub3QgbGVzcy4gRXZlcnkgdGltZSB5b3UgY3Jl YXRlIG9yIHByb2Nlc3MgYSBmaWVsZCBpdCB3aWxsIG1lYW4gb25seSBvbmUgdGhpbmcsIGFuZCB0 aGVyZeKAmXMgb25seSBvbmUgZmllbGQgdG8gbG9vayBhdCB0byBhbnN3ZXIgYSBxdWVzdGlvbi4g V2l0aG91dCBwb2x5bW9ycGhpYyBmaWVsZCB2YWx1ZXMsIHlvdSB1c3VhbGx5IG5lZWQgdG8gcmVs eSBvbiBtdXR1YWwgZXhjbHVzaXZpdHkgb2YgZmllbGRzLCB3aGljaCBpcyBwcm9uZSB0byBmYWls dXJlIGFuZCByZXF1aXJlcyBhZGRpdGlvbmFsIGVycm9yIGNoZWNraW5nLiBUYWtlIGZvciBleGFt cGxlIHRoZSBrZXkgYmluZGluZyBvZiBhY2Nlc3MgdG9rZW5zLiBBbiBhY2Nlc3MgdG9rZW4gY291 bGQgYmUgYm91bmQgdG8gdGhlIFJD4oCZcyBrZXkgdXNlZCBkdXJpbmcgdGhlIHJlcXVlc3QsIHRv IGEgZGlmZmVyZW50IGtleSBjaG9zZW4gYnkgdGhlIEFTLCBvciBpdCBjb3VsZCBiZSBhIGJlYXJl ciB0b2tlbiB3aXRoIG5vIGtleSBhdCBhbGwuIEJ5IG1ha2luZyB0aGUg4oCca2V54oCdIGZpZWxk IHBvbHltb3JwaGljLCB3ZSBjYW4gZGVmaW5lIGl0IGluIHRlcm1zIG9mIGJvb2xlYW4gdmFsdWVz IGFuZCBvYmplY3RzIGFuZCBleHByZXNzIHRoaXMgc2V0IG9mIG11dHVhbGx5LWV4Y2x1c2l2ZSBv cHRpb25zIGluIGEgbm9uLWFtYmlndW91cyB3YXkuIFdpdGhvdXQgdGhhdCwgeW914oCZZCBuZWVk IHRvIGhhdmUgZGlmZmVyZW50IGZpZWxkcyBmb3IgdGhlIG9wdGlvbnMgYW5kIGluY2x1ZGUgYWRk aXRpb25hbCBjaGVja3MgaW4geW91ciBwYXJzZXIgdG8gbWFrZSBzdXJlIHRoZXkgd2VyZW7igJl0 IHNlbnQgc2ltdWx0YW5lb3VzbHksIG90aGVyd2lzZSB5b3UgY291bGQgZ2V0IGhpdCB3aXRoIHRo aXMgcG90ZW50aWFsIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdHkgaW4gYW4gb2JqZWN0Og0KDQoNCg0K ew0KDQogICAga2V5OiB7DQoNCiAgICAgIHByb29mOiBodHRwc2lnLA0KDQogICAgICBqd2s6IHsg 4oCmIGtleSB2YWx1ZSDigKYgfQ0KDQogICAgfSwNCg0KICAgIGJlYXJlcl90b2tlbjogdHJ1ZSwN Cg0KICAgIGJpbmRfdG9fcmNfa2V5OiB0cnVlDQoNCn0NCg0KDQoNClRoaXMgd291bGQgYmUgYW4g aWxsZWdhbCBvYmplY3QgYXMgcGVyIHRoaXMgYWx0ZXJuYXRlIHByb3Bvc2FsLCBidXQgdGhlbiB5 b3XigJlkIGhhdmUgdG8gY2hlY2sgZWFjaCBmaWVsZCBhbmQgbWFrZSBzdXJlIGl0IHdhc27igJl0 IHB1dCBuZXh0IHRvIG90aGVycyBpbiB0aGUgc2FtZSBvYmplY3QuIEnigJl2ZSBkb25lIHRoaXMg ZXhlcmNpc2Ugd2l0aCBtYW55IG90aGVyIHByb3RvY29scyBhbmQgaXTigJlzIGJvdGggZXJyb3Ig cHJvbmUgYW5kIGVhc3kgdG8gaWdub3JlIHNpbmNlIGFsbCB0aGUg4oCcZ29vZOKAnSBleGFtcGxl cyB3b3VsZCBwYXNzIGNvZGUgdGhhdCBkb2VzbuKAmXQgY2hlY2sgdGhpcy4gV2l0aCB0aGUgcG9s eW1vcnBoaWMgYXBwcm9hY2ggdG8gdGhpcyBzYW1lIGZpZWxkLCBlYWNoIG9mIHRoZXNlIHRocmVl IG11dHVhbGx5LWV4Y2x1c2l2ZSBzdGF0ZXMgaXMgd3JpdHRlbiBpbiBhIHdheSB0aGF0IHRoZXkg Y2Fubm90IGJlIHNlbnQgdG9nZXRoZXIuIEl04oCZcyBub3QganVzdCBpbGxlZ2FsLCBpdOKAmXMg aW1wb3NzaWJsZSBhbmQgZW5mb3JjZWQgYnkgdGhlIHN5bnRheCBvZiBKU09OIGl0c2VsZi4NCg0K DQoNCnsNCg0KICAgIGtleTogew0KDQogICAgICBwcm9vZjogaHR0cHNpZywNCg0KICAgICAgandr OiB7IOKApiBrZXkgdmFsdWUg4oCmIH0NCg0KICAgIH0NCg0KfQ0KDQoNCg0KLy8gYmVhcmVyIHRv a2VuDQoNCg0KDQp7DQoNCiAgICBrZXk6IGZhbHNlDQoNCn0NCg0KDQoNCi8vIGJvdW5kIHRvIHRo ZSBSQ+KAmXMgcHJlc2VudGVkIGtleQ0KDQoNCg0Kew0KDQogICAga2V5OiB0cnVlDQoNCn0NCg0K DQoNCklmIHNvbWVvbmUgc2VuZHMgYSBkaWZmZXJlbnQgdHlwZSBmb3IgdGhpcyBmaWVsZCwgbGlr ZSBhbiBhcnJheSBvciBudW1iZXIgb3IgYSBudWxsLCB0aGlzIGRvZXNu4oCZdCBoYXZlIGEgZGVm aW5lZCBpbnRlcnByZXRhdGlvbiBpbiB0aGUgcHJvdG9jb2wgYW5kIHdvdWxkIGJlIGEgcHJvdG9j b2wgbGV2ZWwgZXJyb3IuDQoNCg0KDQpXaGlsZSBpdCBtaWdodCBzb3VuZCBsaWtlIHBvbHltb3Jw aGlzbSBtZWFucyB0aGF0IGFueSBmaWVsZCBjb3VsZCBoYXZlIGFueSB0eXBlIG9yIHZhbHVlLCB0 aGUgb3Bwb3NpdGUgaXMgdHJ1ZTogZWFjaCBwb3NzaWJsZSB2YWx1ZSBpcyBleHBsaWNpdGx5IHR5 cGVkLCBpdOKAmXMganVzdCB0aGF0IHRoZXJlIGFyZSBwb3RlbnRpYWxseSBkaWZmZXJlbnQgdHlw ZXMgdGhhdCBleHByZXNzIG1lYW5pbmcgZm9yIHRoZSBmaWVsZC4gVGhpcyBhcHBsaWVzIHRvIGFs bCBtZW1iZXJzIG9mIGFsbCBvYmplY3RzIChkaWN0aW9uYXJpZXMpIGFzIHdlbGwgYXMgYWxsIG1l bWJlcnMgb2YgYW4gYXJyYXkgKGxpc3QpLiBFdmVyeSB0aW1lIHlvdSBwcm9jZXNzIGEgZmllbGQg dmFsdWUgb3Igb3RoZXIgZWxlbWVudCwgeW91IGxvb2sgYXQgdGhlIHR5cGUgYW5kIHRoZW4gdGhl IHZhbHVlIHRvIGRldGVybWluZSB3aGF0IHRvIGRvIHdpdGggdGhhdCB0eXBlZCB2YWx1ZS4NCg0K DQoNCkluIHlvdXIgZXhhbXBsZSBiZWxvdywgZWFjaCBmaWVsZCB3aXRoaW4gdGhlIGRpY3Rpb25h cnkgd291bGQgYWxzbyBuZWVkIHRvIGJlIHR5cGVkLCBhbmQgZWFjaCB0eXBlIHdvdWxkIG5lZWQg dG8gaGF2ZSBhIGNsZWFyIGluZGljYXRpb24gb2YgaXRzIG1lYW5pbmcuIFRvIHRha2UgeW91ciBz dHJhd21hbiBrZXkgZm9ybWF0IGJlbG93LCB0aGUg4oCcbW9kdWx1c+KAnSBmaWVsZCBjb3VsZCBi ZSBkZWZpbmVkIHBvbHltb3JwaGljYWxseSBhcyBlaXRoZXIgYSDigJxiaWdpbnTigJ0gKGEgSlNP TiBudW1iZXIpIG9yIGFuIOKAnGVuY29kZWQgc3RyaW5n4oCdIChhIEpTT04gc3RyaW5nKS4gVGhl IGRlZmluaXRpb24gd291bGQgZnVydGhlciBzYXkgd2hhdCBleGFjdGx5IHRoZSBlbmNvZGluZyBv ZiB0aGUgc3RyaW5nIHdvdWxkIGJlLiBUaGF0IG1lYW5zIHRoYXQgd2hlbiB5b3UgcmVhZCB0aGUg 4oCcbW9kdWx1c+KAnSBmaWVsZCB0aGVyZSB3b3VsZG7igJl0IGJlIGFueSBjb25mdXNpb24gb24g d2hhdCB0aGUgdmFsdWUgd2FzIG9yIGhvdyBpdCB3YXMgcmVwcmVzZW50ZWQsIHJlZ2FyZGxlc3Mg b2YgdGhlIGlucHV0IGZvcm1hdC4gU2VlaW5nIGEgbnVtYmVyIHRoZXJlIG1lYW5zIGV4YWN0bHkg b25lIGludGVycHJldGF0aW9uIGFuZCBzZWVpbmcgYSBzdHJpbmcgbWVhbnMgZXhhY3RseSBvbmUg KGRpZmZlcmVudCkgaW50ZXJwcmV0YXRpb24g4oCUIGJ1dCBpbXBvcnRhbnRseSwgYm90aCBvZiB0 aGVtIGFyZSBhIOKAnG1vZHVsdXPigJ0sIHNpbmNlIHRoYXTigJlzIHRoZSBmaWVsZCB0aGF0IGRl dGVybWluZXMgdGhlIHR5cGUuIEFuIGltcGxlbWVudGF0aW9uIHdvdWxkIGxpa2VseSB1c2UgYW4g aW50ZXJuYWwgQmlnSW50ZWdlciB0eXBlIG9mIG9iamVjdCB0byByZXByZXNlbnQgdGhlIGZpZWxk IHZhbHVlIGFmdGVyIHBhcnNpbmcsIHNvIHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gZ28gZnJvbSB0 aGUgSlNPTiB2YWx1ZSAod2hpY2ggaXMgdHlwZWQpIGludG8gdGhlIEJpZ0ludGVnZXIgdmFsdWUu WW91IGRvbuKAmXQganVzdCBhcHBseSB0aGUgdHlwZSBydWxlcyBvbiB0aGUg4oCccHVibGljX2tl eeKAnSBmaWVsZCwgeW91IGFwcGx5IGl0IHRvIGFsbCBzdWItZmllbGRzIG9mIHRoYXQgb2JqZWN0 Lg0KDQoNCg0KU28gbGV04oCZcyBkaWcgaW50byB0aGUgc3BlY2lmaWMgYnVnIHlvdSBicmluZyB1 cCBpbiB0aGUgc3RyYXdtYW4sIGJlY2F1c2UgaXTigJlzIGludGVyZXN0aW5nOiBBIEpTT04gZW5j b2RlciB0aGF0IGVuY29kZXMgbnVtYmVycyBhcyBzdHJpbmdzLCBhbmQgbm90IG51bWJlcnMsIGlz IG5vdCBjb21wbGlhbnQgd2l0aCB0aGUgSlNPTiBkZWZpbml0aW9ucyBvZiB0aGUgZmllbGQgaW4g cXVlc3Rpb24uIEZvciBhbm90aGVyIGV4YW1wbGUsIHRoZSBxdW90ZWQgc3RyaW5nIHZhbHVlIG9m IOKAnHRydWXigJ0gaXMgbm90IGVxdWl2YWxlbnQgdG8gdGhlIGJvb2xlYW4gdmFsdWUgdHJ1ZSBp biBKU09OLCBhbmQgdGhleSBzaG91bGRu4oCZdCBiZSB0cmVhdGVkIHRoZSBzYW1lIGJ5IGEgcGFy c2VyIGltcGxlbWVudGF0aW9uIHdoZW4gbWFwcGluZyB0byBhIGNvbmNyZXRlIG9iamVjdC4gSXTi gJlzIGluIHRoaXMga2luZCBvZiBhdXRvbWF0ZWQgZ3Vlc3NpbmcgdGhhdCB0aGlzIGNsYXNzIG9m IGJ1Z3Mgb2NjdXIsIGFuZCB0aGF04oCZcyBnb2luZyB0byBiZSB0aGUgY2FzZSB3aGV0aGVyIG9y IG5vdCB5b3UgdGFrZSAgYWR2YW50YWdlIG9mIEpTT07igJlzIHBvbHltb3JwaGljIG5hdHVyZS4g SeKAmXZlIHJ1biBpbnRvIGNhc2VzIHdoZXJlIGEgcGFyc2VyIGxpYnJhcnkgd2FzIHRyeWluZyB0 byBiZSBvdmVybHkg4oCcaGVscGZ1bOKAnSBpbiBkb2luZyB0aGlzIGtpbmQgb2YgbWFwcGluZywg YnV0IGVuZGVkIHVwIGludHJvZHVjaW5nIGVycm9ycyBpbiBtb3JlIHN0cmljdCBjb21wb25lbnRz IGRvd25zdHJlYW0uIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgcHJvdG9jb2wgZGVzaWduZXJzIG5l ZWQgdG8gYmUgYXdhcmUgb2YgYW5kIGd1YXJkIGFnYWluc3QgaW4gdGhlIGRlc2lnbiBvZiB0aGUg cHJvdG9jb2wgdG8gcmVkdWNlIHBvc3NpYmxlIGFtYmlndWl0aWVzLiBXaXRoaW4gR05BUCB0b2Rh eSwgd2UgZ2VuZXJhbGx5IGhhdmUgdGhpbmdzIHRoYXQgYnJhbmNoIHdoZXRoZXIgdGhleeKAmXJl IGFuIG9iamVjdCAoZm9yIGEgcmljaCBkZXNjcmlwdGlvbiBvZiBzb21ldGhpbmcpIG9yIHNvbWUg bm9uLXN0cnVjdHVyZWQgc3BlY2lhbCB2YWx1ZSAoZm9yIGEgcmVmZXJlbmNlIG9yIG90aGVyIGl0 ZW0pLg0KDQoNCg0KVGhlIGRlc2lnbiB0ZWFtIGNyZWF0ZWQgc29tZSBzaW1wbGUgSlNPTiBTY2hl bWFzIGZvciBwYXJ0cyBvZiB0aGUgcHJvdG9jb2wgZHVyaW5nIG91ciBkaXNjdXNzaW9uLCBidXQg d2UgZGlkbuKAmXQgaW5jbHVkZSB0aGVtIGluIHRoZSBkZXNpZ24gZG9jdW1lbnQgZHVlIHRvIGJv dGggbGFjayBvZiB0aW1lIHRvIGtlZXAgaXQgdXBkYXRlZCB3aXRoIHRoZSByYXBpZCBjaGFuZ2Vz IHRvIHRoZSBwcm90b2NvbCBkdXJpbmcgdGhlIGRlc2lnbiB0ZWFtIGRpc2N1c3Npb24sIGFuZCBu b3Qga25vd2luZyBpZiB0aGVyZSB3b3VsZCBiZSBpbnRlcmVzdCBpbiBzdWNoIG1hdGVyaWFsLiBJ IHBlcnNvbmFsbHkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIGFzIGFuIGlu Zm9ybWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUgZmluYWwgZG9jdW1lbnQsIGJ1dCB0aGF04oCZcyBz b21ldGhpbmcgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIHRha2UgdXAgZXZlbnR1YWxseS4NCg0K DQoNCiDigJQgSnVzdGluDQoNCg0KDQpPbiBPY3QgMjMsIDIwMjAsIGF0IDEwOjE4IEFNLCBNaWth IEJvc3Ryw7ZtIDxtaWthLmJvc3Ryb209NDBzbWFya2V0cy5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOm1pa2EuYm9zdHJvbT00MHNtYXJrZXRzLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K DQoNCg0KSGVsbG8sIGV2ZXJ5b25lLg0KDQoNCg0KRm9yIGJhY2tncm91bmQ6IEdOQVAvVHhBdXRo L1hZWi9PYXV0aDMgY2FtZSB1cCBvbiBhIGRpc2N1c3Npb24gZm9ydW0gYW5kIHdoZW4gSSBtYWRl IG5vdGUgYWJvdXQgY2VydGFpbiBjb25jZXJucywgSSB3YXMgcmVxdWVzdGVkIHRvIHNlbmQgbXkg Y29tbWVudHMgdG8gdGhpcyB3b3JraW5nIGdyb3VwLg0KDQoNCg0KSW4gc2hvcnQsIEkgYmVsaWV2 ZSB0aGF0IHRoZSB1c2Ugb2YgcG9seW1vcnBoaWMgSlNPTiBpbiB0aGUgcHJvdG9jb2wgaW52aXRl cyBzdWJ0bGUgYW5kIGNvbmZ1c2luZyBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtcy4gSSBhbHNvIHNl YXJjaGVkIHRocm91Z2ggdGhlIFdHIGFyY2hpdmVzLCBhbmQgbm90aWNlZCB0aGF0IHNpbWlsYXIg Y29uY2VybnMgd2VyZSBub3RlZCwgYnJpZWZseSwgaW4gYSB0aHJlYWQgaW4gSnVseS4NCg0KDQoN ClRoZSBwcm9ibGVtIHdpdGggcG9seW1vcnBoaWMgdmFsdWVzLCBhcyBJIHNlZSBpdCwgaXMgdGhh dCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBuZWVkIHRvIGJyYW5jaCBvbiB0aGUgKGluZmVycmVkKSB0 eXBlIG9mIGEgZ2l2ZW4gZmllbGQuIFRoaXMgaXNuJ3QgcXVpdGUgYXMgYmFkIGlmIHRoZSB0eXBl cyBhcmUgc3RyaWN0bHkgZGlmZmVyZW50LCBidXQgYWxsb3dzIGZvciBzdWJ0bGUgYnVncyB3aGVu IHRoZSB2YWx1ZSBpbiBxdWVzdGlvbiBpcyBhIGRpY3Rpb25hcnkuIFdoYXQgbWFrZXMgdGhpcyB1 bmFwcGVhbGluZyBpcyB0aGF0ICJzdWJ0bGUgYnVncyIgaW4gc2VjdXJpdHkgcHJvdG9jb2xzIGhh dmUgYSBoYWJpdCBvZiB0dXJuaW5nIGludG8gdnVsbmVyYWJpbGl0aWVzLg0KDQoNCg0KTGV0J3Mg c2F5IHdlIGhhdmUgdGhlc2UgaW1hZ2luYXJ5IHBheWxvYWRzLCBib3RoIHBvc3NpYmxlIGFuZCB2 YWxpZCBpbiB0aGUgc2FtZSBwcm90b2NvbCBzdGVwOg0KDQoNCg0KIyBwYXlsb2FkIDENCg0Kew0K DQogIC4uLiwNCg0KICAicHVibGljX2tleSI6IHsNCg0KICAgICJhbGciOiAicnNhIiwNCg0KICAg ICJtb2R1bHVzIjogPEJJR0lOVD4NCg0KICB9DQoNCn0NCg0KDQoNCiMgcGF5bG9hZCAyDQoNCnsN Cg0KICAuLi4sDQoNCiAgInB1YmxpY19rZXkiOiB7DQoNCiAgICAiYWxnIjogInJzYSIsDQoNCiAg ICAibW9kdWx1cyI6ICI8ZW5jb2RlZCBzdHJpbmc+Ig0KDQogIH0NCg0KfQ0KDQoNCg0KSW4gYm90 aCBjYXNlcywgdGhlIHR5cGUgb2YgInB1YmxpY19rZXkiIGZpZWxkIGlzIGEgZGljdGlvbmFyeS4g SW4gYm90aCBjYXNlcywgdGhleSBldmVuIGhhdmUgdGhlIHNhbWUga2V5cy4gSG93ZXZlciwgdGhl IHZhbHVlcyBpbiB0aGUgZGljdGlvbmFyaWVzIGFyZSBlbnRpcmVseSBkaWZmZXJlbnQsIGFuZCBh biBpbXBsZW1lbnRhdGlvbiB3aWxsIGhhdmUgdG8gYnJhbmNoIHRvIGF0IGxlYXN0IHR3byBwb3Nz aWJsZSBkZWNvZGluZyBtZWNoYW5pc21zLiBUbyBtYWtlIHRoaW5ncyB3b3JzZSwgc29tZSBKU09O IGltcGxlbWVudGF0aW9ucyBtYXkgY2hvb3NlIHRvIGVuY29kZSBub24tZGljdGlvbmFyeSB2YWx1 ZXMgYXMgc3RyaW5ncywgc28gaXQgaXMgcG9zc2libGUgZm9yIGFuIG9yaWdpbmF0b3IgdG8gdHJh bnNtaXQgd2hhdCB0aGV5IGV4cGVjdCBhbmQgYmVsaWV2ZSB0byBiZSBwYXlsb2FkIDEgZm9ybWF0 LCBidXQgd2hpY2ggdGhlIHJlY2VpdmVyIHdpbGwgaW50ZXJwcmV0IHRvIGJlIGluIHBheWxvYWQg MiBmb3JtYXQuIEFuZCBpZiB0aGUgZW5jb2RlZCBzdHJpbmcgY29udGFpbnMgb25seSBkaWdpdHMs IGl0IHdpbGwgZXZlbiBwYXJzZSBjb3JyZWN0bHkgYXMgYSBiaWdudW0uDQoNCg0KDQpXaGlsZSB0 aGUgYWJvdmUgaXMgY2xlYXJseSBhIG1hbnVmYWN0dXJlZCBzY2VuYXJpbywgaXQgbm9uZXRoZWxl c3MgZGVtb25zdHJhdGVzIHRoZSBwb3RlbnRpYWwgZm9yIGxvZ2ljIGJ1Z3Mgd2l0aCBwb2x5bW9y cGhpYyBKU09OLiBXaXRoIHJpY2hlciB0eXBlcyBhbmQgbW9yZSBjb21wbGV4IGRpY3Rpb25hcmll cywgdGhlcmUgd2lsbCBzdXJlbHkgYmUgbW9yZSByb29tIGZvciBlcnJvcnMuDQoNCg0KDQpBbWJp Z3VpdHkgaW4gcHJvdG9jb2xzIGlzIGFsd2F5cyBhIHNvdXJjZSBvZiBpbXBsZW1lbnRhdGlvbiBj b21wbGV4aXR5IGFuZCBpbnRlcm9wZXJhYmlsaXR5IHNuYWdzLCBidXQgaW4gYW4gQXV0aE4vQXV0 aFogcHJvdG9jb2wgaXQgaXMgd29yc2U6IGl0J3MgdGVycmlmeWluZy4gSWYgR05BUC9PYXV0aDMg aXMgaW50ZW5kZWQgdG8gc3VwZXJzZWRlIE9hdXRoMS8yLCB3b3VsZG4ndCBpdCBiZSBpbiBldmVy eW9uZSdzIGludGVyZXN0IHRvIGtlZXAgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBhbmQgbWlz dGFrZSBwb3RlbnRpYWwgdG8gYSBtaW5pbXVtPw0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpNaWth DQoNCg0KDQotLQ0KDQpNaWthIEJvc3Ryw7ZtDQoNClNtYXJrZXRzDQoNCi0tDQpUWEF1dGggbWFp bGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPg0KDQoNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxp c3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90eGF1dGg+DQoNCltJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci5d4ZCnDQoN Cg0KDQoNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86 VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg+DQoNCi0t IFRYQXV0aCBtYWlsaW5nIGxpc3QgVFhBdXRoQGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPg0K --_000_DF4PR8401MB1177F1FE6807DAB3690AAC13E5180DF4PR8401MB1177_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi Pg0KSSBoYXZlIGJlZW4gcmVhZGluZyBidXQgbm90IGNvbW1lbnRlZCBiZWZvcmUsIGJ1dCBJIHdp bGwgYWRkIG15IGNvbW1lbnRzIGhlcmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQoxKSBpbiByZWxh dGVkIHRvIHBvbHltb3JwaGlzbSwgYmVlbiBhIHNvZnR3YXJlIGRldmVsb3BlciBtYW55IHllYXJz LCB0aGVuIGEgZGlyZWN0b3J5IChsZGFwLCBJQU0pIGFuZCBhIHNlY3VyaXR5IGVuZ2luZWVyIChQ S0ksIGtlcmJlcm9zKS4mbmJzcDsgSSB0aGluayB0aGlzIG9uZSBoYXMgbWVyaXQuJm5ic3A7IG15 IGV4cGVyaWVuY2VzIGFyZSBmcm9tIGRvaW5nIFJTLCBSQyBhbmQgdXNlciBkZXZlbG9wbWVudCBi YWNrZ3JvdW5kLiZuYnNwOyBGcm9tIG15IHZpZXcsJm5ic3A7IHRoaXMNCiAoSlNPTikmbmJzcDsg aXMgbGlrZSBBU04xIGJ1dCBtdWNoIHNpbXBsZXIuJm5ic3A7IEkgbGlrZSBKdXN0aW4ncyBhcHBy b2FjaCB0byB2ZXJpZnkgaXQgMXN0IHNpbmNlIGJlZm9yZSBhIHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbiwgaXQganVzdCBhIGNvbmNlcHQuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx MnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDI1NSk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQoyKSBJ J20gc29tZXdoYXQgcHV6emxlIG9mIG5vIGRpc2N1c3Npb24gYXJvdW5kIG11bHRpcGxlIHRva2Vu cyBhbmQgdGhlIGNvbXBsaWNhdGlvbiBpdCBicmluZ3MuJm5ic3A7IFdoZW4gSSB0cnkgdG8gZ2V0 IE9BVVRIMi9PSURDIGFkb3B0ZWQgd2l0aGluIG91ciBjb21wYW55LCB0aGF0IGhhcyBiZWVuIHRo ZSBtb3N0IGRpZmZpY3VsdCBjb252ZXJzYXRpb25zIHdpdGggb3RoZXIgdGVhbXMuIEkgaGF2ZSB0 byByZWFjaCBvdXQgdG8gSm9obiBCIGZvciBjbGFyaWZpY2F0aW9uDQogb2YgdXNlIG9mIGF6cC4g QW0gSSBtaXNzaW5nIHNvbWUgZGlzY3Vzc2lvbnMgdGhlcmU/PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29s b3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ DQozKSBJJ20gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgdGhlIHNwZWMgaGFzIGdyb3duIHRvIGJl IHNvbWUgY29tcGxleCB0byBtaXNzIHRoZSBvcmlnaW5hbCBpbnRlbmQuJm5ic3A7IHRoZSBkaXNj dXNzaW9uIGhhcyBiZWVuIHJlYWxseSBnb29kIGVzcGVjaWFsbHkgZnJvbSBvdGhlcnMgbm90IGlu IHRoZSBkZXNpZ24gdGVhbSAoZS5nLiBEaWNrKSwgSSB3b3VsZCBkZWZpbml0ZWx5IGxpa2UgdG8g aGVhciBtb3JlIGZyb20gSm9obiwgTWlrZSBKLCBCcmlhbiBDDQogYW5kIG90aGVycyBvbiB0aGlz LiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigw LCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KJm5ic3A7bXkgMiBjZW50cy4mbmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCnBldGVyPC9kaXY+DQo8ZGl2Pg0KPGhyIHRhYmluZGV4 PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrOyB3aWR0aDo5OCUiPg0KPGRpdiBpZD0i ZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYi IGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyI+PGI+RnJvbTo8L2I+IEZh YmllbiBJbWJhdWx0ICZsdDtmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U2Vu dDo8L2I+IFN1bmRheSwgT2N0b2JlciAyNSwgMjAyMCAzOjM5IEFNPGJyPg0KPGI+VG86PC9iPiBZ YXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IE1pa2EgQm9zdHLDtm0g Jmx0O21pa2EuYm9zdHJvbT00MHNtYXJrZXRzLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IEdOQVAg TWFpbGluZyBMaXN0ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7OyBKdXN0aW4gUmljaGVyICZsdDtq cmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbR05BUF0gRmVlZGJh Y2sgb24gcG9seW1vcnBoaXNtPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgZGlyPSJhdXRvIj5IaSBZYXJvbiwNCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rp dj4NCjxkaXYgZGlyPSJhdXRvIj5UaGFua3MgZm9yIHRoZSBmZWVkYmFjay4mbmJzcDs8YnI+DQo8 ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+UmVnYXJkaW5nIGNs aWVudCBsaWJyYXJpZXMsIEkgdGhpbmsgd2UgY2FuIGluZGVlZCBsZWFybiBhIGdyZWF0IGRlYWwg ZnJvbSBjcnlwdG9ncmFwaGljIGxpYnJhcmllcy4gQ3J5cHRvZ3JhcGhpYyBkZXNpZ24gcHJvdmlk ZXMgYSBncmVhdCBhbW91bnQgb2YgZmxleGliaWxpdHkgZm9yIHRoZSBzcGVjaWFsaXN0cyAoaW5j bHVkaW5nIG1hbnkgcGFyYW1ldGVycyB0aGF0IHlvdSByZWFsbHkgbmVlZCB0byBnZXQgcmlnaHQp Lg0KIFdlIG1pZ2h0IHRoaW5rIHRoaXMgaXMgZ3JlYXQgdG8gcHJvdmlkZSBvcHRpb25zIGJ1dCBp dCBhY3R1YWxseSBpbmNyZWFzZXMgdGhlIGNvZ25pdGl2ZSBsb2FkIG9mIGxpYnJhcnkgdXNlcnMu PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+TG9v ayBpbnN0ZWFkIGF0IHdoYXQgR29vZ2xlIGhhcyBwcm92aWRlZCB3aXRoIHRpbmsgYXMgYW4gYWx0 ZXJuYXRpdmUgYW5kIHlvdSdsbCBzZWUgaXQgaXMgYSBtdWNoIGVhc2llciB3YXkgZm9yIGNyeXB0 b2dyYXBoaWMgZW5naW5lZXJzICh3aG8gYXJlbid0IGNyeXB0b2dyYXBoZXJzKSB0byBhdm9pZCBt aXN0YWtlcyBvciBtaXN1c2VzLiZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwv ZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPlRoYXQncyB0aGUgKnNlY3VyaXR5KiBpc3N1ZSBJJ20gcmVm ZXJyaW5nIHRvIChub3QgdGhlIGZhY3QgdGhhdCBiZWluZyBvcGVuIHRoZXkncmUgdGFzdHkgdGFy Z2V0cywgYWx0aG91Z2ggdGhhdCBtYXkgYmUgcmVsYXRlZCBpbiBzb21lIGNhc2VzKS4gQW5kIHRp bmsgaXMgdGhlIGtpbmQgb2YgZGVzaWduIHdlIHNob3VsZCBiZSB0cnlpbmcgdG8gYWNoaWV2ZS4m bmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRv Ij5JIGFncmVlIHRoYXQgaXQgc2hvdWxkIGJlIGFwcGxpY2FibGUgdG8gYSB3aWRlIHJhbmdlIG9m IHdlbGwga25vd24gcHJvZ3JhbW1pbmcgdG9vbHMsIGluY2x1ZGluZyB0aGUgbGlrZXMgb2YgamF2 YSBhbmQgZ28uJm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+QnV0IEkgZG9uJ3Qg cmVhbGx5IHNlZSBhIGxpbWl0YXRpb24gaGVyZS4gTWlnaHQgbm90IGJlIHRoZSBtb3N0IGlkaW9t YXRpYyBmZWVsLCBidXQgaXQgY2FuIGJlIG1hZGUgdG8gd29yay4mbmJzcDs8YnI+DQo8L2Rpdj4N CjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5KdXN0IHNvIEkg dW5kZXJzdGFuZCwgd2hhdCBhbHRlcm5hdGl2ZXMgd291bGQgeW91IHByZWZlciB0byBwb2x5bW9y cGhpc20/IEkgY2FuIHN1Z2dlc3QganNvbi1sZCBidXQgZXZlbiBKdXN0aW4gd2lsbCBUZWVsIHlv dSBpdCdzIGV2ZW4gbW9yZSBjb21wbGV4IDotKSZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPkNoZWVyczwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPkZhYmllbiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ieF9nbWFpbF9x dW90ZSIgZGlyPSJhdXRvIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPkxl IGRpbS4gMjUgb2N0LiAyMDIwIMOgIDExOjE3LCBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJ4X21fLTIxNzAzMjc5NzYwMDYyMTEwOTdXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5IaSBGYWJpZW4sPHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj5JIHRoaW5rIHlvdXIgcHJvZHVjdCBtYW5hZ2VtZW50IG1v ZGVsIGhhcyBhIGxvdCBvZiBtZXJpdCwgYnV0IGl0IGRvZXMgbm90IGNhcHR1cmUgdGhlIHNlY3Vy aXR5IGlzc3VlIHdlbGwuPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5JIGFncmVl IHRoYXQgYXMgd2UgbG9vayBhdCBkaWZmZXJlbnQgY3VzdG9tZXIgcGVyc29uYXMsIHRoZSDigJxl bmQgdXNlcuKAnSAodGhlIGRldmVsb3BlciB0aGF04oCZcyB1c2luZyB0aGUgbGlicmFyaWVzKSBz aG91bGQgYmUgb3VyIGhpZ2hlc3QgcHJpb3JpdHkuIEJ1dCBJIGRpc2FncmVlIGFib3V0IGVuZC11 c2VyIG1pc3Rha2VzIGJlaW5nIHRoZSB0b3AgKjxiPnNlY3VyaXR5PC9iPiogaXNzdWUuIExpYnJh cmllcw0KIGFyZSBvZnRlbiBvcGVuIHNvdXJjZSBpbiBvdXIgc3BhY2UgYW5kIHVzZWQgdmVyeSB3 aWRlbHkuIFNvIHRoZXkgbWFrZSBmb3IgdGFzdHkgdGFyZ2V0cywgYW5kIHBlb3BsZSBhcmUgYXR0 YWNraW5nIHRoZW0gYW5kIGFyZSBzdGlsbCBmaW5kaW5nIHNlY3VyaXR5IGlzc3VlcyBpbiBsaWJy YXJpZXMgdGhhdCB3ZeKAmXZlIGJlZW4gdGFsa2luZyBhYm91dCBmb3JldmVyIFsxXS48dT48L3U+ PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPihZZXMsIG15IGV4YW1wbGUgaXMgYWN0dWFsbHkg YW4gYXBwIGZsYXcsIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGhhdmUgYmVlbiBwcmV2ZW50ZWQgYnkg YSBiZXR0ZXIgZGVzaWduZWQgbGlicmFyeS4pPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj5JbiBvdGhlciB3b3Jkcywgd2UgZG8gbmVlZCB0byBjYXJlIGFib3V0IGhvdyBlYXN5IGl0 IGlzIHRvIGltcGxlbWVudCB0aGUgcHJvdG9jb2wgY29ycmVjdGx5IGJ5ICo8Yj5saWJyYXJ5PC9i PiogZGV2ZWxvcGVycy4gRnJvbSBKdXN0aW4gZGVzY3JpYmluZyBoaXMgb3duIGV4cGVyaWVuY2Ug YW5kIG90aGVyIHBlb3BsZSBvbiB0aGUgdGhyZWFkIHRoYXQgRGljayByZWZlcnJlZCB0bywgSSB3 b3VsZCBzYXkgdGhhdA0KIEpTT04gcG9seW1vcnBoaXNtIGlzIHBhaW5mdWwgZm9yIEphdmEgYW5k IEdvIGRldmVsb3BlcnMuIFdpdGggYWxsIGR1ZSByZXNwZWN0LCBJIGNhcmUgYWJvdXQgdGhlbSBt dWNoIG1vcmUgdGhhbiBJIGNhcmUgYWJvdXQgSGFza2VsbCwgYXMgbWFueSBtb3JlIGltcGxlbWVu dGF0aW9ucyBhcmUgbGlrZWx5IHRvIHVzZSB0aGVzZSBsYW5ndWFnZXMuPHU+PC91Pjx1PjwvdT48 L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj5UaGFua3MsPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZYXJvbjx1Pjwv dT48dT48L3U+PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vd3d3Lnpv ZnJleC5jb20vYmxvZy8yMDIwLzEwLzIwL2FsZy1ub25lLWp3dC1uaHMtY29udGFjdC10cmFjaW5n LWFwcC8iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vd3d3LnpvZnJl eC5jb20vYmxvZy8yMDIwLzEwLzIwL2FsZy1ub25lLWp3dC1uaHMtY29udGFjdC10cmFjaW5nLWFw cC88L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29s aWQgI2I1YzRkZiAxLjBwdDsgcGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGNvbG9yOiBibGFj azsiPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBjb2xv cjogYmxhY2s7Ij5UWEF1dGggJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1h aWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVm ZXJyZXIiPmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlN1bmRheSwgT2N0b2JlciAyNSwgMjAyMCBhdCAwMToyNTxicj4NCjxiPlRvOiA8L2I+RGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayIgcmVsPSJub3JlZmVycmVyIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj5NaWthIEJvc3Ryw7ZtICZsdDttaWthLmJvc3Ryb209PGEgaHJlZj0ibWFpbHRv OjQwc21hcmtldHMuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3Jl ZmVycmVyIj40MHNtYXJrZXRzLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7LCBHTkFQIE1haWxp bmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIHJlbD0ibm9yZWZlcnJlciI+dHhhdXRoQGlldGYub3JnPC9hPiZndDssDQogSnVzdGluIFJp Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsi IHJlbD0ibm9yZWZlcnJlciI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtHTkFQXSBGZWVkYmFjayBvbiBwb2x5bW9ycGhpc208dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5I aSBEaWNrLDx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPkluZGVwZW5kYW50bHkgZnJvbSB0aGUgZGViYXRlIG9uIHBvbHlwaG9ybWlzbSwgSSBi ZWcgdG8gZGlmZmVyIG9uIHlvdXIgb3JkZXIgcHJlZmVyZW5jZS4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPllvdXIg YXNzdW1wdGlvbiBpcyB0aGF0IEFTIGRldnMgbWF0dGVyIHRoZSBtb3N0LDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDtiZWNhdXNlIHRo ZXkncmUgZG9pbmcgdGhlIGltcG9ydGFudCBzZWN1cml0eSBpbXBsZW1lbnRhdGlvbi4gQnV0IGVh dGluZyBvdXIgb3duIGRvZ2Zvb2QgbWlnaHQgaGVscCBhIGxvdCB0byBjaGFuZ2UgdGhhdCB2aWV3 LiBNb3N0IHNlY3VyaXR5DQogaXNzdWVzIG9jY3VyIGJlY2F1c2UgdXNlcnMgb2YgdGhlIHNwZWMg YXJlIHVuYWJsZSB0byBkZWFsIHdpdGggdGhlIGNvbXBsZXhpdHkgdGhhdCBpcyBwYXNzZWQgb250 byB0aGVtLiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjk5JSBvZiB0aGUgcGVvcGxlIHRoYXQgd2lsbCBh Y3R1YWxseSB1c2UgdGhlIG91dHB1dCBvZiB0aGUgd29yayBhcmUgYXBwbGljYXRpb24gZGV2ZWxv cGVycyAoY2xpZW50IG9yIFJTKSBhbmQgdGhlaXIgb3duIHVzZXJzLiZuYnNwOzx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5i c3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk91ciBp bnRlbnQgYXMgd2VsbCBhcyB0aGUgcHJvdG9jb2wgZHJpdmUgdGhlIHVzYWdlLiBDbGllbnQgbGli cmFyaWVzIG1heSBoZWxwLCBidXQgdGhleSdyZSBub3QgYSBzaWx2ZXIgYnVsbGV0LCBlc3BlY2lh bGx5IGJlY2F1c2UgR05BUCB1bHRpbWF0ZWx5IGhhcyBubyBjb250cm9sIGFib3V0IHdoYXQgcGVv cGxlIGRvIHRoZXJlDQogKGZvciBiZXR0ZXIgb3Igd29yc2UpLiBBbmQgZXZlcnl0aGluZyB3ZSBk byBoZXJlIHdpbGwgaGVscCBnZXQgdG8gdGhlIGJldHRlciBwYXJ0LiZuYnNwOzwvc3Bhbj48dT48 L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+ PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3Jt YWwiPkknbSBub3Qgc2F5aW5nIHdlIGRvbid0IGludGVuZCB0byBhbHNvIGNhcmUgYWJvdXQgQVMg ZGV2ZWxvcGVycyAoYmVnaW5uaW5nIHdpdGggb3Vyc2VsdmVzKSBidXQgaXQncyBhIHNlY29uZCBv cmRlciBvcHRpbWlzYXRpb24uIEFuZCBzaW5jZSBpdCdzIGEgdGVuZGFuY3kgd2UncmUgbGVhbmlu ZyB0b3dhcmRzIGJ5IGRlZmF1bHQsIEknbSBwcmV0dHkgc3VyZSB3ZSB3b24ndCBmb3JnZXQgdGhh dCBhbnl3YXkuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+RmFiaWVuJm5ic3A7PHU+PC91Pjx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5MZSBzYW0uIDI0IG9jdC4gMjAyMCDDoCAyMzo1 MCwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4m Z3Q7IGEgw6ljcml0Jm5ic3A7Ojx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci1sZWZ0OnNvbGlkICNjY2NjY2MgMS4wcHQ7IHBh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7IG1hcmdpbi1sZWZ0OjQuOHB0OyBtYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkknbSBjb25mdXNlZCBieSB5b3Vy IGxvZ2ljIEZhYmllbi48dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj5JZiBhIGNsaWVudCBsaWJyYXJ5IGRldmVsb3BlciB3YW50cyB0byBleHBv c2UgcG9seW1vcnBoaXNtLCB0aGV5IGNhbiBkbyB0aGF0IGluZGVwZW5kZW50IG9mIHdoYXQgaXMg aW4gdGhlIHByb3RvY29sLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SSBkaWZmZXIgb24gd2hvIG91ciBzdGFrZWhv bGRlcnMgYXJlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SSB0aGluayBvdXIgc3Rha2Vob2xkZXJzIGFyZSBpbiBs ZWFzdCB0byBtb3N0IGltcG9ydGFudDo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9InhfTXNvTm9ybWFsIj5BUyBkZXZl bG9wZXI8dT48L3U+PHU+PC91PjwvbGk+PGxpIGNsYXNzPSJ4X01zb05vcm1hbCI+UlMgZGV2ZWxv cGVyPHU+PC91Pjx1PjwvdT48L2xpPjxsaSBjbGFzcz0ieF9Nc29Ob3JtYWwiPmNsaWVudCBkZXZl bG9wZXI8dT48L3U+PHU+PC91PjwvbGk+PGxpIGNsYXNzPSJ4X01zb05vcm1hbCI+dXNlcjx1Pjwv dT48dT48L3U+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+QSBjbGllbnQgbGlicmFyeSBkZXZlbG9wZXIgY2FuIGV4cG9zZSB3aGF0ZXZlciBp bnRlcmZhY2UgdGhleSB3YW50IHRvIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9uLjx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5i c3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SSBs aXN0IHRoZSB1c2VyIHNvIHRoYXQgd2UgZG9uJ3QgbG9zZSBzaXRlIG9mIGEgY3JpdGljYWwgcm9s ZS48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPi9EaWNrPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iYm9yZGVy OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7IHBhZGRpbmc6MGluIj48aW1nIGJvcmRlcj0iMCIgd2lk dGg9IjMyIiBoZWlnaHQ9IjMyIiBpZD0ieF9tXy0yMTcwMzI3OTc2MDA2MjExMDk3X3gwMDAwX2kx MDI3IiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiIgc3R5bGU9IndpZHRoOi4zMzMzaW47 IGhlaWdodDouMzMzM2luIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGZv bnQtZmFtaWx5OiBHYWR1Z2ksIHNhbnMtc2VyaWY7IGNvbG9yOiB3aGl0ZTsiPuGQpzwvc3Bhbj48 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+ Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5P biBGcmksIE9jdCAyMywgMjAyMCBhdCA2OjI3IFBNIEZhYmllbiBJbWJhdWx0ICZsdDs8YSBocmVm PSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu b3JlZmVycmVyIj5mYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lOyBib3Jk ZXItbGVmdDpzb2xpZCAjY2NjY2NjIDEuMHB0OyBwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0OyBt YXJnaW4tbGVmdDo0LjhwdDsgbWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+SGkgdGhlcmUsJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkxldCBtZSB0cnkgdG8gYXBwcm9hY2gg dGhlIGlzc3VlIHVuZGVyIGEgZGlmZmVyZW50IGxpZ2h0LiBNb3JlIGxpa2UgYSBwcm9kdWN0IG1h bmFnZXIgd291bGQgZGVhbCB3aXRoIGZlYXR1cmUgc2VsZWN0aW9uIHRvIG1ha2UgaXQgaW50dWl0 aXZlIGZvciBpdHMgdXNlcnMuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkZvciBtb3N0IHBlb3BsZSwgcmlkaW5nIGEg YmlrZSBpcyBmYXIgZWFzaWVyIHRoYW4gdXNpbmcgYSB1bmljeWNsZS4gRmVlbHMgbW9yZSBzdGFi bGUuIEFuZCB5ZXQgaXQncyB3YXkgZWFzaWVyIHRvIGRlc2lnbiBmb3IgYSBzaW5nbGUgd2hlZWwg dGhhbiB0byBidWlsZCB3aXRoIDIuIEJlY2F1c2UgdGhlbiB5b3UnbGwgbmVlZCBhIGxvdCBtb3Jl IGFjY2Vzc29yaWVzIChjaGFpbiwgY2hhaW4gcmluZywgZXRjLikuDQogRXZlbiBzbyBwcm9kdWNp bmcgYSBiaWtlIGRvZXNuJ3QgaGF2ZSB0byBiZSBhIGJyaXR0bGUgcHJvY2VzcywgaXQgY2FuIGJl IGluZHVzdHJpYWxpemVkLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+QmFjayB0byB0aGUgR05BUCB0b3BpYy4mbmJz cDs8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5VbHRpbWF0 ZWx5IHdlIHNob3VsZCBzdHJpdmUgdG8gbWFrZSB0aGUgc3BlYyBhcyBzaW1wbGUgYXMgY2FuIGJl LiBCdXQgd2UgbmVlZCB0byBhc2s6IHNpbXBsZSBmb3Igd2hvbT8gRm9yIHRoZSBiaWtlIG93bmVy IG9yIGZvciB0aGUgYmlrZSB2ZW5kb3I/Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+KHNob3J0IGFuc3dlcjogdGhlIHBy aW9yaXR5IHNob3VsZCBiZSBzaW1wbGljaXR5IGZvciBzcGVjIHVzZXJzLCBub3Qgc3BlYyBpbXBs ZW1lbnRlcnMgYW5kIGV2ZW4gbGVzcyBzcGVjIGRlc2lnbmVycykuJm5ic3A7PC9zcGFuPjx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+VGhlIGluaXRpYWwgcXVlc3Rpb24gdGhhdCBpcyBhc2tlZCBpcyB2ZXJ5IGludGVyZXN0aW5n OiBpc24ndCB0aGUgZGVzaWduIGZsYXdlZCBpZiBHTkFQIGlzIHVzaW5nIGpzb24gcG9seXBob3Jt aXNtPyBPciBpZiB0aGUgQVMgbmVlZHMgdG8gaGFuZGxlIHRoZSBzdGF0ZSBvZiB0aGUgcmVxdWVz dD8gT3IgaWYgd2UgbXVzdCBoYW5kbGUgdG9rZW4gcmV2b2NhdGlvbj8gT3IgaWYgd2UgYXJlIGxv b2tpbmcgZm9yDQogYSBnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXI/IFRoZSBhcmd1bWVudCBzdGVt cyBvZiB0aGUgZmFjdCB0aGF0IGlzIHN0aWxsIGFyZ3VhYmx5IGhhcmRlciBhbmQgbW9yZSBlcnJv ciBwcm9uZSB0byBpbXBsZW1lbnQuIEZhaXIgZW5vdWdoLiZuYnNwOzx1PjwvdT48dT48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+RnJvbSBhIHNw ZWMgaW1wbGVtZW50ZXIncyBwZXJzcGVjdGl2ZSwgaXQgbWF5IHdlbGwgYmUgbW9yZSBjb21wbGV4 LiBJdCBtb3N0bHkgaW1wYWN0cyB0aGUganNvbiBsaWJyYXJ5IHlvdSdsbCBlbmQgdXAgdXNpbmcs IHBsdXMgYSBiaXQgb2YgaW5wdXQvb3V0cHV0IGRlY29yYXRpb24gYXJvdW5kIGl0LiBFdmVuIGdv bGFuZyBwcm92aWRlcyB1dGlsaXRpZXMgZm9yIHRoaXMsIGRlc3BpdGUgbm90IGV4YWN0bHkNCiBi ZWluZyBtYWRlIGZvciB0aGlzIGtpbmQgb2YgcHVycG9zZS48dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+TXkgcHJhY3RpY2FsIGV4cGVyaWVu Y2UgaW1wbGVtZW50aW5nIGl0IGlzIHRoYXQgaXQncyBub3QgdGhhdCBiaWcgYSBkZWFsLiBJIG1l YW4sIEkgd2lzaGVkIGl0IGNvdWxkIGJlIHNpbXBsZXIsIGJ1dCBpdCdzIG1hbmFnZWFibGUgYW5k IHRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIHJlYWNoIGxldmVscyBvZiBpbnN1cmFuY2UgdGhhdCBp dCBkb2VzIHdvcmsgYXMgaW50ZW5kZWQgKGpzb24gc2NoZW1hLCB0ZXN0DQogY2FzZXMgdG8gdmFs aWRhdGUgdGhlIGltcGxlbWVudGF0aW9uLCBldGMuKS4gQXJndWFibHkgaXQgaXMgc3RpbGwgZWFz aWVyIGZyb20gYW4gaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUgdGhhbiBzYXksIGpzb24tbGQs IHdoaWNoIGlzIG1hc3NpdmVseSB1c2VkIGluIHRoZSBTU0kgY29tbXVuaXR5LiZuYnNwOzx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+QnV0IHVsdGltYXRlbHkgd2hvIGFyZSB3ZSBkZXNpZ25pbmcgZm9yPyBBcmUgd2Ugc3RyaXZp bmcgdG8gZ28gZWFzeSBvbiB0aGUgc3BlYyBpbXBsZW1lbnRlcj8gT3IgYXJlIHdlIHRyeWluZyB0 byBtYWtlIHN1cmUgZW5kLWRldmVsb3BlcnMgdXNpbmcgdGhlIGNsaWVudCBsaWJyYXJpZXMgd29u J3Qgc2hvb3QgdGhlbXNlbHZlcyBpbiB0aGUgZm9vdD88dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPlRoZSBqb2IgdG8gYmUgZG9u ZSAoSlRCRCksIGZyb20gdGhlIGVuZC1kZXZlbG9wZXIncyBwZXJzcGVjdGl2ZSwgaXMgdG8gZWZm aWNpZW50bHkgc2hpcCBhbiBhcHBsaWNhdGlvbi4gQW5kIHByb3ZpZGUgYXV0aE4vYXV0aFogY2Fw YWJpbGl0aWVzIGZvciBlbmQtdXNlcnMgYnkgcmVseWluZyBvbiBzb21lIHdlbGwga25vd24gaW1w bGVtZW50YXRpb24uJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiPkluIHR1cm4sIHRoaXMgc3BlYyBpbXBsZW1lbnRlciB3aWxsIHJl bHkgb24gY3J5cHRvZ3JhcGhpYyB1dGlsaXR5IGxpYnJhcmllcyB0aGF0IGRlYWxzIGludGVybmFs bHkgd2l0aCB0aGUgY29tcGxleGl0eSBvZiB0aGVpciBvd24gZG9tYWluLCBzbyB0aGF0IHdlIGRv bid0IGhhdmUgdG8uIEFuZCBoZXJlIHdlIGNvdWxkIGxhdW5jaCBhbm90aGVyIEhOIGZsYW1lIHdh ciB0aGF0IHN0YXJ0cyB3aXRoIHRoZSB0aXRsZQ0KICZxdW90O0pXVCBzdWNrcyBiZWNhdXNlJnF1 b3Q7LiBXaGljaCBkb2VzIGhhdmUgaXRzIHNldCBvZiB2ZXJ5IHJlYWwgaXNzdWVzIGJ1dCB0aGF0 J3MgYmV5b25kIHRoZSBwb2ludC4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Tm90ZSB0aGF0IGFueSBkZWNlbnQgZmxhbWV3YXIg d2lsbCBiZSBlZmZpY2llbnRseSBmdWVsZWQgYnkgcGVvcGxlIGhhdGluZyBtZWRpdW0uIElzIGl0 IG91dHJhZ2VvdXMgZm9yIGJsb2cgcG9zdHMgdG8gYmUgYmVoaW5kIGEgcGF5d2FsbD8gTWF5YmUg YnV0IGl0J3MgZXZlbiBtb3JlIG91dHJhZ2VvdXMgdG8gbGFjayBjb25zaXN0ZW5jeSwgZWl0aGVy IGJ5IG5vdCBrbm93aW5nIGhvdyB0byBnZXQgYXJvdW5kDQogYSBwYXl3YWxsIGlmIHlvdSdyZSBp bnRvIGEgaGFja2VyIHB1bmsgbW92ZW1lbnQsIG9yIG9uIHRoZSBjb250cmFyeSBieSB0byBub3Qg cGF5aW5nIGEgc3Vic2NyaXB0aW9uIGlmIHlvdSBiZWxpZXZlIHRoYXQgc3VydmVpbGxhbmNlIGNh cGl0YWxpc20sIHRvIHJldXNlIFp1Ym9mZidzIHRlcm1zLCBzaG91bGQgYmUgZXJhZGljYXRlZC4m bmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+V2hhdCBsaWtlbHkgc2VlbXMgYW4gdW5uZWNlc3Nhcnkgc2lkZW5vdGUgdHJpZXMgdG8g aWxsdXN0cmF0ZSB0aGUgcG9pbnQ6IGZvciBKdXN0aW4gaXQgd2FzIGVhc2llciB0byBwdWJsaXNo IG9uIG1lZGl1bSwgYmVjYXVzZSBhcyBhIGJsb2cgcHVibGlzaGVyLCB5b3UgbWlnaHQgbm90IHdh bnQgdG8gZGVhbCB3aXRoIGhvc3RpbmcgeW91ciBvd24gYmxvZy4gQnV0IG1heWJlIGFzIGEgcmVh ZGVyIHlvdSdsbCBmaW5kDQogdGhhdCBhbm5veWluZy4gRGlmZmVyZW50IGF1ZGllbmNlcywgZGlm ZmVyZW50IEpUQkQsIGRpZmZlcmVudCB0cmFkZW9mZnMuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5Qb2x5cGhvcm1p c20gaXMgYSB0b29sIHRoYXQgZW5hYmxlcyB0aGUgZW5kLWRldmVsb3BlciB0byBoYXZlIG1pbmlt YWwga25vd2xlZGdlIG9mIHdoYXQgaXQgbWVhbnMgdG8gZGVhbCB3aXRoIGEgR05BUCBjbGllbnQg bGlicmFyeS4gWW91IHByZXBhcmUgdGhlIHJlcXVlc3QsIHNlbmQgdG8gdGhlIGVuZHBvaW50IGFu ZCB5b3UncmUgZ29vZCB0byBnby4gTWFzc2l2ZWx5IHNpbXBsZXIgdGhhbiBPQXV0aDIgb3INCiBh bnkgc2ltaWxhciBwcm90b2NvbCBieSB0aGUgd2F5IChhcyBhbnlvbmUgd2l0aCB0ZWFjaGluZyBl eHBlcmllbmNlIG9uIHRoZSBzdWJqZWN0IG1pZ2h0IGFja25vd2xlZGdlKS4gQW5kJm5ic3A7IHRo ZXJlJ3MgYSBsb3QgbW9yZSB0byBiZSBkb25lIHRvIG1ha2Ugc3VyZSB3ZSBpbmRlZWQgcmVkdWNl IHRoZSBjb21wbGV4aXR5IGZvciB0aGUgZW5kLWRldmVsb3BlciBhbmQgdGhlIGVuZC11c2VyLiZu YnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+SWYgd2UgZmluZCBhIGJldHRlciB3YXkgdG8gZGVhbCB3aXRoIHRoYXQgc2lt cGxpY2l0eSBiYWxhbmNlLCBJJ20gYWxsIGluLiBCdXQgdGhlIGFyZ3VtZW50cyBuZWVkIHRvIGJl IHdheSBtb3JlIGNvbnZpbmNpbmcgdGhhbiBqdXN0IHNheWluZyB0aGF0IGl0IG1heSBiZSBkaWZm aWN1bHQgdG8gaW1wbGVtZW50IG9yIHZhbGlkYXRlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Q2hlZXJzLjx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5GYWJp ZW48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+TGUg dmVuLiAyMyBvY3QuIDIwMjAgw6AgMjI6MzUsIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmpy aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci1sZWZ0OnNvbGlk ICNjY2NjY2MgMS4wcHQ7IHBhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7IG1hcmdpbi1sZWZ0OjQu OHB0OyBtYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj5PbiBPY3QgMjMsIDIwMjAsIGF0IDM6NTIgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9 Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZl cnJlciI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5KdXN0aW48dT48L3U+PHU+ PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5JIGRpZCBub3Rl IHRoYXQgSSB3YXMgdGhlIG9uZSB0aGF0IGFyZ3VlZCBmb3IgaW5zdGFuY2VfaWQgYmVpbmcgaW4g dGhlIG9iamVjdC4gU2luY2UgaXQgaXMgaW4gdGhlIG9iamVjdCBpbiB0aGUgY3VycmVudCBkcmFm dCwgbm90IGluY2x1ZGluZyBhIHBhc3MgYnkgcmVmZXJlbmNlIG9wdGlvbiB3b3VsZCBiZSBwcmVm ZXJhYmxlLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+QXMgZm9yIGNvbmNyZXRlIGV4YW1wbGVzOjx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4tIHZlcnNpb24g b2YgY2xpZW50PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPi0gdmVyc2lvbiBvZiBPUzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4tIHNlY3VyaXR5IGF0dGVzdGF0aW9uIG9mIE9TIC8g ZGV2aWNlPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPi0gbG9jYXRpb24gb2YgY2xpZW50IGRldmljZTx1PjwvdT48dT48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4tIG5ldHdvcmsgY2xpZW50IGlzIG9w ZXJhdGluZyBvbjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhf TXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+VGhlc2UgYXJlIGFsbCBhdHRyaWJ1dGVzIG9mIHRoZSBjbGllbnQg dGhhdCBhbiBBUyBtYXkgcmVxdWlyZSZuYnNwO29uIHRoZSBpbml0aWFsIGdyYW50IHJlcXVlc3Qs IGFuZCBpbiBmdXR1cmUgZ3JhbnQgcmVxdWVzdHMgKHdoaWNoIGlzIHdoZW4gYW4gaW5zdGFuY2Vf aWQpIHdvdWxkIGJlIHVzZWQuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPlRoaXMgaXMgd2hlcmUgb3VyIGludGVycHJldGF0aW9ucyBkaWZmZXI6IEkgZG9u4oCZ dCBzZWUgdGhlc2UgYXMg4oCcYXR0cmlidXRlcyBvZiB0aGUgY2xpZW504oCdIGluIHRoZSBzYW1l IHdheSB0aGF0IHRoZSBrZXksIGRpc3BsYXkgaW5mb3JtYXRpb24sIGNsYXNzIGlkZW50aWZpZXJz LCBhbmQgb3RoZXIgaXRlbXMgY3VycmVudGx5IHJlcHJlc2VudGVkIGJ5IGFuIGluc3RhbmNlX2lk IGFyZSBhdHRyaWJ1dGVzIG9mDQogdGhlIGNsaWVudCBpbnN0YW5jZS4gVGhlIGF0dGVzdGF0aW9u IGNvbXBvbmVudHMgZG9u4oCZdCBtb2RpZnkgdGhlIGluc3RhbmNlIHNvIG11Y2ggYXMgcHJlc2Vu dCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG9uIHRvcCBvZiB0aGUgY2xpZW50IGluc3RhbmNlIGl0 c2VsZi4gVGhpcyBpcyB3aHkgSSBhcmd1ZSB0aGF0IHRoZXkgb3VnaHQgdG8gYmUgaGFuZGxlZCBp biBhIHNlcGFyYXRlIG9iamVjdCwgc28geW914oCZZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoaXMN CiBzdHJhd21hbjo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiPns8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyBwb3N0dXJlOiB7PHU+PC91Pjx1Pjwv dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgc29mdHdhcmVfdmVyc2lvbjogMS4yLjMsPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgb3NfdmVyc2lvbjogMTQu My4yPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgZGV2aWNlX2F0dGVzdGF0aW9uOiB7IOKApiBzb21lIHN0cnVjdHVy ZSBvciBzaWduZWQgYmxvYj8g4oCmIH08dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBsb2NhdGlvbjogeyBsYXQ6IOKA piwgbG9uOiDigKYsIGFsdDog4oCmIH08dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7IH0sPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgY2xpZW50OiDi gJxjbGllbnQtNTQxLWFiJnF1b3Q7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj59PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5UaGlzIGlzIGEgbW9yZSBmdW5k YW1lbnRhbCBxdWVzdGlvbiBhYm91dCBHTkFQIHRoYW4gd2hldGhlciB0aGUgc3ludGF4IHVzZXMg cG9seW1vcnBoaXNtOiB0aGlzIGlzIGFib3V0IEdOQVAgYmVpbmcgdmVyeSBleHBsaWNpdCBhYm91 dCB0aGUgZGF0YSBtb2RlbCBvZiBpdHMgZWxlbWVudHMuIE9BdXRoIDLigJlzIGluY3JlZGlibHkg bG9vc2UgYW5kIGJyb2FkIG1vZGVsIG9mIHdoYXQgdGhlIHRlcm0g4oCcY2xpZW504oCdDQogaXMg cmVmZXJyaW5nIHRvLCBleGFjdGx5LCBpcyBkZWVwbHkgcHJvYmxlbWF0aWMgaW4gcHJhY3RpY2Uu IFdl4oCZcmUgZXZlbiBzZWVpbmcgdGhhdCBpbiB0aGUgT0F1dGggMi4xIHdvcmsgd2l0aCBoYXZp bmcgdG8gZGVmaW5lIGEg4oCcY3JlZGVudGlhbGVkIGNsaWVudOKAnSwgYW5kIGV2ZW4gdGhlbiB0 aGF0IGRvZXNu4oCZdCBmdWxseSBjYXB0dXJlIHRoZSBkaWZmZXJlbnQgYXNwZWN0cyB0aGF0IGFy ZSBvdXQgdGhlcmUuIEkgdGhpbmsgd2XigJlyZSBnZXR0aW5nDQogY2xvc2VyIGhlcmUgaW4gR05B UCB3aXRoIGV4cGxpY2l0IGRlZmluaXRpb24gb2Yg4oCcY2xpZW50IGluc3RhbmNl4oCdLCBidXQg d2Ugc3RpbGwgbmVlZCB0byBiZSBtb3JlIHByZWNpc2UgYWJvdXQgd2hhdCBleGFjdGx5IGEgY2xp ZW50IGluc3RhbmNlIGluY2x1ZGVzLCBhbmQgd2hhdCBpdCBkb2VzIG5vdC48dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNw O+KAlCBKdXN0aW48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+PGJyPg0KPGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPi9EaWNrPHU+PC91Pjx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDsgcGFkZGluZzowaW4iPjxp bWcgYm9yZGVyPSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGlkPSJ4X21fLTIxNzAzMjc5NzYw MDYyMTEwOTdfeDAwMDBfaTEwMjYiIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIiBzdHls ZT0id2lkdGg6LjMzMzNpbjsgaGVpZ2h0Oi4zMzMzaW4iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA3LjVwdDsgZm9udC1mYW1pbHk6IEdhZHVnaSwgc2Fucy1zZXJpZjsgY29sb3I6IHdo aXRlOyI+4ZCnPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDIzLCAyMDIwIGF0IDEyOjQyIFBNIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5r IiByZWw9Im5vcmVmZXJyZXIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48 dT48L3U+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRl ci1sZWZ0OnNvbGlkICNjY2NjY2MgMS4wcHQ7IHBhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7IG1h cmdpbi1sZWZ0OjQuOHB0OyBtYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPkRpY2ssPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJ4X01zb05vcm1hbCI+QXMgeW914oCZbGwgcmVjYWxsLCBJIGFyZ3VlZCBhZ2FpbnN0IGluY2x1 ZGluZyB0aGUgY2xpZW50IGluc3RhbmNlIGlkZW50aWZpZXIgaW5zaWRlIG9mIHRoZSBvYmplY3Qg YXMgYSBtdXR1YWxseS1leGNsdXNpdmUgZmllbGQgcHJlY2lzZWx5IGJlY2F1c2Ugb2YgdGhlIHBy aW5jaXBsZSB2aW9sYXRpb24gdGhhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBoZXJlLCBhbmQgc28g aXTigJlzIGltcG9ydGFudCB0byBwb2ludA0KIG91dCB0aGF0IHRoZSBjdXJyZW50IHRleHQgaXMg YSBjb21wcm9taXNlIHRoYXQgbmVlZHMgdG8gYmUgZXhhbWluZWQgaW4gdGhlIHdpZGVyIGV4cGVy aWVuY2Ugb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIEkgYW0gb24gdGhlIHNpZGUgb2YgcmVtb3Zpbmcg dGhlIG11dHVhbGx5LWV4Y2x1c2l2ZSDigJxpbnN0YW5jZV9pZOKAnSBvcHRpb24gd2l0aGluIGFu IG9iamVjdCwgYnV0IHRoaXMgbmVlZHMgdG8gYmUgZXhwbG9yZWQuPHU+PC91Pjx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5UaGUgY3J1eCBv ZiBteSBhcmd1bWVudCBpcyB0aGF0IGlzIGV4YWN0bHkgYSBjYXNlIG9mIHBhc3MtYnktcmVmZXJl bmNlIHZzIHBhc3MtYnktdmFsdWUsIGFuZCB0aGF0IHJ1bnRpbWUgYXR0ZXN0YXRpb25zIGFyZSBu b3QgcGFydCBvZiB0aGUg4oCcY2xpZW50IGluc3RhbmNl4oCdIHZhbHVlIGl0c2VsZiBidXQgcmF0 aGVyIGJlbG9uZyBvdXRzaWRlIG9mIHRoYXQgb2JqZWN0IGluIGEgYW5vdGhlciBwYXJ0IG9mIHRo ZQ0KIHJlcXVlc3QuIEFzIHN0YXRlZCBpbiB0aGUgZWRpdG9yaWFsIG5vdGVzIGluIHRoaXMgc2Vj dGlvbiwgd2UgbmVlZCB0byBsb29rIGNhcmVmdWxseSBhdCBob3cgdGhlc2UgY29uY2VwdHMgZml0 IHdpdGhpbiB0aGUgbW9kZWwgYW5kIHdoZXJlIHdlIHdvdWxkIHdhbnQgdG8gcHV0IHRoZW0uIFdp dGhvdXQgY29uY3JldGUgZXhhbXBsZXMgb2Ygd2hhdCB0aGVzZSBleHRlbnNpb25zIGxvb2sgbGlr ZSBhbmQgaG93IHRoZXnigJlyZSBnZW5lcmF0ZWQsIHRoYXQNCiBpcyBuZWFybHkgaW1wb3NzaWJs ZSB0byBkbyBhdCB0aGlzIHN0YWdlLiBJIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcgZXhhbXBsZXMg b2YgdGhpcyBraW5kIG9mIGRhdGEgYW5kIGhvdyBpdCBjYW4gZml0IGludG8gdGhlIHByb3RvY29s Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+Jm5ic3A74oCUIEp1c3Rpbjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PGJyPg0KPGJyPg0KPHU+PC91Pjx1Pjwv dT48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5PbiBPY3QgMjMsIDIwMjAs IGF0IDM6MDcgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+ZGljay5oYXJkdEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SGV5IEp1c3Rpbiw8dT48L3U+PHU+PC91PjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5BcyB0aGUgZHJhZnQgaGFzIGV2 b2x2ZWQsIEkgcXVlc3Rpb24gdGhlIGNvbnRpbnVlZCB1c2Ugb2YgcG9seW1vcnBoaXNtLiBOb3Rl IHRoYXQgSSBhcHByZWNpYXRlIHRoZSBlbGVnYW5jZSZuYnNwO29mIHVzaW5nIGEgc3RyaW5nIGZv ciBwYXNzLWJ5LXJlZmVyZW5jZSwgYW5kIGFuIG9iamVjdCBmb3IgcGFzcy1ieS12YWx1ZS48dT48 L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+ PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3Jt YWwiPkluIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGUmbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7IG1hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+RXZlcnkgdGltZSB5 b3UgY3JlYXRlIG9yIHByb2Nlc3MgYSBmaWVsZCBpdCB3aWxsIG1lYW4gb25seSBvbmUgdGhpbmcs IGFuZCB0aGVyZeKAmXMgb25seSBvbmUgZmllbGQgdG8gbG9vayBhdCB0byBhbnN3ZXIgYSBxdWVz dGlvbi4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPmlzIHZpb2xhdGVkIGluIDxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWduYXAtY29yZS1wcm90b2Nv bC0wMCNzZWN0aW9uLTIuMy4xIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj4yLjMu MS4mbmJzcDsgSWRlbnRpZnlpbmcgdGhlIFJDIEluc3RhbmNlPC9hPjx1PjwvdT48dT48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDoz MC4wcHQ7IG1hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO2luc3RhbmNlX2lkICZuYnNwO0FuIGlkZW50aWZpZXIgc3RyaW5nIHRoYXQg dGhlIEFTIGNhbiB1c2UgdG8gaWRlbnRpZnkgdGhlPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhcnRp Y3VsYXIgaW5zdGFuY2Ugb2YgdGhpcyBSQy4mbmJzcDsgVGhlIGNvbnRlbnQgYW5kIHN0cnVjdHVy ZSBvZiB0aGlzPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkZW50aWZpZXIgaXMgb3BhcXVlIHRvIHRo ZSBSQy48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmcXVvdDtjbGllbnQmcXVvdDs6IHs8dT48L3U+PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7aW5zdGFuY2VfaWQmcXVvdDs6ICZxdW90O2NsaWVudC01 NDEtYWImcXVvdDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO308dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJZiB0aGVyZSBh cmUgbm8gYWRkaXRpb25hbCBmaWVsZHMgdG8gc2VuZCwgdGhlIFJDIE1BWSBzZW5kIHRoZTx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7aW5zdGFuY2UgaWRlbnRpZmllciBhcyBhIGRpcmVjdCByZWZlcmVuY2UgdmFsdWUg aW4gbGlldSBvZiB0aGU8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO29iamVjdC48dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsm cXVvdDtjbGllbnQmcXVvdDs6ICZxdW90O2NsaWVudC01NDEtYWImcXVvdDs8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPlRoZSBpbnN0YW5jZSBpZGVudGlmaWVyIGNhbiBiZSBzZW50IHR3byB3YXlzLiBQ b2x5bW9ycGhpc20gaXMgYSBjb252ZW5pZW5jZSBmb3IgdGhlIGNsaWVudCwgYnV0IHJlcXVpcmVz IHRoZSBzZXJ2ZXImbmJzcDt0byBoYXZlIHR3byBjb2RlJm5ic3A7cGF0aHMgZm9yICZxdW90O2lu c3RhbmNlX2lkJnF1b3Q7LiZuYnNwOyBXZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgZGVzaWduIHRl YW0sIGFuZCBJIGFyZ3VlZCBmb3IgaGF2aW5nICZxdW90O2luc3RhbmNlX2lkJnF1b3Q7DQogaW4g dGhlICZxdW90O2NsaWVudCZxdW90OyBvYmplY3QmbmJzcDtzbyB0aGF0IGFueSB1cGRhdGVzLCBz dWNoIGFzIG5ldyBkZXZpY2VzIGFzc2VydGlvbnMsIGNvdWxkIGJlIGluIHRoZSAmcXVvdDtjbGll bnQmcXVvdDsgb2JqZWN0LiBBcyBub3RlZCBhYm92ZSwgd2hpbGUgSSBhcHByZWNpYXRlIHRoZSBl bGVnYW5jZSBvZiB1c2luZyBhIHN0cmluZyAoaGFuZGxlKSB0byByZWZlcmVuY2UgYSBwcmV2aW91 c2x5IHByb3ZpZGVkIG9iamVjdCwgaXQgY29tcGxpY2F0ZXMgaG93IHRvIHVwZGF0ZQ0KIGFuIGV4 aXN0aW5nIG9iamVjdCB3aGlsZSBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZS48dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkluIHlv dXIgZXhhbXBsZSBvZiB0aGUgJnF1b3Q7a2V5JnF1b3Q7IG9iamVjdCBiZWxvdywgc2V0dGluZyAm cXVvdDtwcm9vZiZxdW90OyB0byBiZWFyZXIgd291bGQgYXZvaWQgdGhlIGlzc3VlIHlvdSBkZXNj cmliZTo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i eF9Nc29Ob3JtYWwiPnsmbmJzcDs8YnI+DQombmJzcDsmcXVvdDtrZXkmcXVvdDs6IHsmbmJzcDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3Byb29mJnF1b3Q7OiAmcXVvdDtiZWFyZXIm cXVvdDsgPGJyPg0KJm5ic3A7ICZuYnNwOyB9IDxicj4NCn08dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkluIHlvdXIgZXhhbXBs ZSwgd2hlbiBwcm9jZXNzaW5nIHRoZSAmcXVvdDtrZXkmcXVvdDsgb2JqZWN0LCBjb2RlIGlzIGhh dmluZyB0byBjaGVjayBib3RoIHRoZSBKU09OIHR5cGUgb2YgdGhlIHByb3BlcnR5LCBhcyB3ZWxs IGFzIGNoZWNrIHRoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7cHJvb2YmcXVvdDsgcHJvcGVydHkuIElu IHRoZSBleGFtcGxlIEkgcHJvdmlkZWQsIG9ubHkgdGhlIHZhbHVlIG9mICZxdW90O3Byb29mJnF1 b3Q7IG5lZWRzIHRvIGJlIGNoZWNrZWQuDQogVGhlICZxdW90O3Byb29mJnF1b3Q7IHByb3BlcnR5 IGlzIGFjdGluZyBhcyBhIHR5cGUgZm9yIHRoZSAmcXVvdDtrZXkmcXVvdDsgb2JqZWN0Ljx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+Tm90IGJlaW5nIGEgSmF2YSBwcm9ncmFtbWVyLCBJIGRvbid0IGtub3cgaG93IHRoaXMgd291 bGQgd29yayBpbiBhIEphdmEgaW1wbGVtZW50YXRpb24sIGJ1dCBub2RlLmpzLCB0aGUgcHJvY2Vz c2luZyB3b3VsZCBuZWVkIHRvIGJlIGRvbmUgYXMgYWJvdmUuPHU+PC91Pjx1PjwvdT48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5PbiBhIHJlbGF0ZWQg bm90ZSwgdGhlcmUgd2FzIHNpZ25pZmljYW50IG5lZ2F0aXZlIGZlZWRiYWNrIG9uIGhhbmRsZXMg YW5kIHBvbHltb3JwaGlzbSBpbiB0aGUgSGFja2VyIE5ld3MgYXJ0aWNsZSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRlbT9pZD0yNDg1NTc1MCIgdGFyZ2V0PSJf YmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aHR0cHM6Ly9uZXdzLnljb21iaW5hdG9yLmNvbS9pdGVt P2lkPTI0ODU1NzUwPC9hPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+L0RpY2s8dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj5PbiBGcmksIE9jdCAyMywgMjAyMCBhdCAxMDoyMCBBTSBKdXN0aW4gUmljaGVyICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJu b3JlZmVycmVyIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItbGVmdDpz b2xpZCAjY2NjY2NjIDEuMHB0OyBwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0OyBtYXJnaW4tbGVm dDo0LjhwdDsgbWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij5IaSBNaWthLDx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPlRoYW5rcyBmb3IgYnJpbmdpbmcgdGhpcyB0b3BpYyBoZXJlIOKAlCBJIHdhcyBh YmxlIHRvIHNlZSB0aGUgZm9ydW0gZGlzY3Vzc2lvbiB0aGF0IGJyb3VnaHQgeW91IGhlcmUsIGFu ZCBob3BlZnVsbHkgSSBjYW4gaGVscCBjbGVhciB1cCB3aGF0IEkgbWVhbiB3aXRoIGhvdyBwb2x5 bW9ycGhpc20gaXMgdXNlZCBpbiB0aGUgcHJvcG9zYWwuIFRoZSBzaG9ydCB2ZXJzaW9uIGlzIHRo YXQgdGhlIGdvYWwgaXMgdG8mbmJzcDs8Yj5hdm9pZDwvYj4mbmJzcDt0aGUNCiBraW5kcyBvZiBh bWJpZ3VpdHkgdGhhdCBtYWtlIGluc2VjdXJlIHByb3RvY29scywgYW5kIHNvIGluIHRoYXQgZ29h bCB3ZeKAmXJlIGZ1bGx5IGFsaWduZWQuIEkgdGhpbmsgdGhhdCB1c2luZyBwb2x5bW9ycGhpc20g aW4gdmVyeSBzcGVjaWZpYyB3YXlzIGNhbiBoZWxwIHRoYXQgZ29hbCDigJQganVzdCBhcyBJIGFn cmVlIHRoYXQgbWlzdXNpbmcgaXQgb3IgYXBwbHlpbmcgaXQgc2xvcHBpbHkgY2FuIGxlYWQgdG8g YW1iaWd1b3VzIGFuZCBpbnNlY3VyZQ0KIHN5c3RlbXMuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5Tb21lIGJhY2tncm91bmQ6 IEkgYnVpbHQgb3V0IHRoZSBYWVogcHJvdG9jb2wgKG9uZSBvZiB0aGUgcHJlZGVjZXNzb3JzIHRv IHRoZSBpbml0aWFsIEdOQVAgRHJhZnQpIGluIEphdmEgdXNpbmcgc3Ryb25nbHkgdHlwZWQgcGFy c2VycyBhbmQgSmF2YSBvYmplY3RzIHNwZWNpZmljYWxseSB0byBwcm92ZSB0byBteXNlbGYgdGhh dCBpdCBjb3VsZCBiZSBkb25lIGluIGEgd2F5IHRoYXQgbWFkZSBhbnkgc2Vuc2UNCiBpbiB0aGUg Y29kZS4gKE15IG93biBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiBpcyBhdCZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ic3BrL29hdXRoLnh5ei1qYXZhIiB0YXJnZXQ9Il9ibGFu ayIgcmVsPSJub3JlZmVycmVyIj5odHRwczovL2dpdGh1Yi5jb20vYnNway9vYXV0aC54eXotamF2 YTwvYT4sIGJ1dCBub3RlIHRoYXQgaXTigJlzIG5vdCB5ZXQgdXAgdG8gZGF0ZSB3aXRoIHRoZSBH TkFQIHNwZWMpLiBJdCB3YXMgaW1wb3J0YW50DQogdG8gbWUgdGhhdCBJIGJlIGFibGUgdG8gdXNl IHRoZSBzeXN0ZW0td2lkZSBjb25maWd1cmVkIHBhcnNlcnMgdG8gaW1wbGVtZW50IHRoaXMgYW5k IG5vdCBoYXZlIHRvIHJlc29ydCB0byBzdGVwcGluZyB0aHJvdWdoIGVsZW1lbnRzIGNvbXBsZXRl bHkgYnkgaGFuZC4gSmF2YSBkb2VzbuKAmXQgbWFrZSBpdCBzaW1wbGUgdG8gZ2V0IHRoZSBob29r cyBpbnRvIHRoZSByaWdodCBwbGFjZXMgKGVzcGVjaWFsbHkgd2l0aCB0aGUgSmFja3NvbiBwYXJz ZXINCiB0aGF0IEkgdXNlZCksIGJ1dCBpdCBpcyBkZWZpbml0ZWx5IHBvc3NpYmxlIHRvIGNyZWF0 ZSBhIGRldGVybWluaXN0aWMgYW5kIHN0cm9uZ2x5LXR5cGVkIHBhcnNlciBhbmQgc2VyaWFsaXpl ciBmb3IgdGhpcyBraW5kIG9mIGRhdGEgc3RydWN0dXJlLiBTb21lIG9mIHRoZSByYXRpb25hbGUg Zm9yIHVzaW5nIHBvbHltb3JwaGlzbSBpcyBjb3ZlcmVkIGluIHRoZSB0cmFpbGluZyBhcHBlbmRp eCBvZiB0aGUgZHJhZnQgZG9jdW1lbnQgKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2Fy Y2hpdmUvaWQvZHJhZnQtaWV0Zi1nbmFwLWNvcmUtcHJvdG9jb2wtMDAuaHRtbCNuYW1lLWpzb24t c3RydWN0dXJlcy1hbmQtcG9seW1vciIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWduYXAtY29yZS1wcm90 b2NvbC0wMC5odG1sI25hbWUtanNvbi1zdHJ1Y3R1cmVzLWFuZC1wb2x5bW9yPC9hPiksDQogYnV0 IGl04oCZcyBzdGlsbCBnb29kIHRvIGRpc2N1c3MgdGhpcyBoZXJlIGFzIHRoZSB3b3JraW5nIGdy b3VwIGRlY2lkZXMgd2hpY2ggYXBwcm9hY2hlcyB0byB0YWtlLiZuYnNwOzx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7 PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+VGhlIGRy aXZpbmcgcmVhc29uIGZvciB1c2luZyBwb2x5bW9ycGhpc20gYXQgdGhlIHByb3RvY29sIGxldmVs IHdhcyB0byBzaW1wbGlmeSB0aGUgcHJvdG9jb2wgYW5kIG1ha2UgaXQgOm1vcmU6IGRldGVybWlu aXN0aWMgdG8gY3JlYXRlIGFuZCBwcm9jZXNzLCBub3QgbGVzcy4gRXZlcnkgdGltZSB5b3UgY3Jl YXRlIG9yIHByb2Nlc3MgYSBmaWVsZCBpdCB3aWxsIG1lYW4gb25seSBvbmUgdGhpbmcsIGFuZCB0 aGVyZeKAmXMNCiBvbmx5IG9uZSBmaWVsZCB0byBsb29rIGF0IHRvIGFuc3dlciBhIHF1ZXN0aW9u LiBXaXRob3V0IHBvbHltb3JwaGljIGZpZWxkIHZhbHVlcywgeW91IHVzdWFsbHkgbmVlZCB0byBy ZWx5IG9uIG11dHVhbCBleGNsdXNpdml0eSBvZiBmaWVsZHMsIHdoaWNoIGlzIHByb25lIHRvIGZh aWx1cmUgYW5kIHJlcXVpcmVzIGFkZGl0aW9uYWwgZXJyb3IgY2hlY2tpbmcuIFRha2UgZm9yIGV4 YW1wbGUgdGhlIGtleSBiaW5kaW5nIG9mIGFjY2VzcyB0b2tlbnMuDQogQW4gYWNjZXNzIHRva2Vu IGNvdWxkIGJlIGJvdW5kIHRvIHRoZSBSQ+KAmXMga2V5IHVzZWQgZHVyaW5nIHRoZSByZXF1ZXN0 LCB0byBhIGRpZmZlcmVudCBrZXkgY2hvc2VuIGJ5IHRoZSBBUywgb3IgaXQgY291bGQgYmUgYSBi ZWFyZXIgdG9rZW4gd2l0aCBubyBrZXkgYXQgYWxsLiBCeSBtYWtpbmcgdGhlIOKAnGtleeKAnSBm aWVsZCBwb2x5bW9ycGhpYywgd2UgY2FuIGRlZmluZSBpdCBpbiB0ZXJtcyBvZiBib29sZWFuIHZh bHVlcyBhbmQgb2JqZWN0cyBhbmQNCiBleHByZXNzIHRoaXMgc2V0IG9mIG11dHVhbGx5LWV4Y2x1 c2l2ZSBvcHRpb25zIGluIGEgbm9uLWFtYmlndW91cyB3YXkuIFdpdGhvdXQgdGhhdCwgeW914oCZ ZCBuZWVkIHRvIGhhdmUgZGlmZmVyZW50IGZpZWxkcyBmb3IgdGhlIG9wdGlvbnMgYW5kIGluY2x1 ZGUgYWRkaXRpb25hbCBjaGVja3MgaW4geW91ciBwYXJzZXIgdG8gbWFrZSBzdXJlIHRoZXkgd2Vy ZW7igJl0IHNlbnQgc2ltdWx0YW5lb3VzbHksIG90aGVyd2lzZSB5b3UgY291bGQgZ2V0IGhpdA0K IHdpdGggdGhpcyBwb3RlbnRpYWwgc2VjdXJpdHkgdnVsbmVyYWJpbGl0eSBpbiBhbiBvYmplY3Q6 PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj57Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsga2V5OiB7PHU+PC91Pjx1PjwvdT48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHByb29mOiBodHRwc2lnLDx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBqd2s6IHsg4oCmIGtleSB2YWx1 ZSDigKYgfTx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7IH0sPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgYmVhcmVyX3Rva2VuOiB0cnVl LDx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7IGJpbmRfdG9fcmNfa2V5OiB0cnVlPHU+PC91Pjx1PjwvdT48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPn08dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPlRoaXMgd291bGQg YmUgYW4gaWxsZWdhbCBvYmplY3QgYXMgcGVyIHRoaXMgYWx0ZXJuYXRlIHByb3Bvc2FsLCBidXQg dGhlbiB5b3XigJlkIGhhdmUgdG8gY2hlY2sgZWFjaCBmaWVsZCBhbmQgbWFrZSBzdXJlIGl0IHdh c27igJl0IHB1dCBuZXh0IHRvIG90aGVycyBpbiB0aGUgc2FtZSBvYmplY3QuIEnigJl2ZSBkb25l IHRoaXMgZXhlcmNpc2Ugd2l0aCBtYW55IG90aGVyIHByb3RvY29scyBhbmQgaXTigJlzIGJvdGgg ZXJyb3INCiBwcm9uZSBhbmQgZWFzeSB0byBpZ25vcmUgc2luY2UgYWxsIHRoZSDigJxnb29k4oCd IGV4YW1wbGVzIHdvdWxkIHBhc3MgY29kZSB0aGF0IGRvZXNu4oCZdCBjaGVjayB0aGlzLiBXaXRo IHRoZSBwb2x5bW9ycGhpYyBhcHByb2FjaCB0byB0aGlzIHNhbWUgZmllbGQsIGVhY2ggb2YgdGhl c2UgdGhyZWUgbXV0dWFsbHktZXhjbHVzaXZlIHN0YXRlcyBpcyB3cml0dGVuIGluIGEgd2F5IHRo YXQgdGhleSBjYW5ub3QgYmUgc2VudCB0b2dldGhlci4gSXTigJlzIG5vdA0KIGp1c3QgaWxsZWdh bCwgaXTigJlzIGltcG9zc2libGUgYW5kIGVuZm9yY2VkIGJ5IHRoZSBzeW50YXggb2YgSlNPTiBp dHNlbGYuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+eyZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGtleTogezx1PjwvdT48 dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBwcm9vZjogaHR0cHNpZyw8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgandrOiB7 IOKApiBrZXkgdmFsdWUg4oCmIH08dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB9PHU+PC91Pjx1PjwvdT48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPn08dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPi8vIGJlYXJlciB0 b2tlbjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+ezx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGtleTogZmFsc2U8dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+fTx1PjwvdT48dT48L3U+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4v LyBib3VuZCB0byB0aGUgUkPigJlzIHByZXNlbnRlZCBrZXk8dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPns8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyBrZXk6IHRydWU8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+fTx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+SWYgc29tZW9uZSBzZW5kcyBhIGRpZmZlcmVudCB0eXBlIGZv ciB0aGlzIGZpZWxkLCBsaWtlIGFuIGFycmF5IG9yIG51bWJlciBvciBhIG51bGwsIHRoaXMgZG9l c27igJl0IGhhdmUgYSBkZWZpbmVkIGludGVycHJldGF0aW9uIGluIHRoZSBwcm90b2NvbCBhbmQg d291bGQgYmUgYSBwcm90b2NvbCBsZXZlbCBlcnJvci48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPldoaWxlIGl0IG1pZ2h0IHNv dW5kIGxpa2UgcG9seW1vcnBoaXNtIG1lYW5zIHRoYXQgYW55IGZpZWxkIGNvdWxkIGhhdmUgYW55 IHR5cGUgb3IgdmFsdWUsIHRoZSBvcHBvc2l0ZSBpcyB0cnVlOiBlYWNoIHBvc3NpYmxlIHZhbHVl IGlzIGV4cGxpY2l0bHkgdHlwZWQsIGl04oCZcyBqdXN0IHRoYXQgdGhlcmUgYXJlIHBvdGVudGlh bGx5IGRpZmZlcmVudCB0eXBlcyB0aGF0IGV4cHJlc3MgbWVhbmluZyBmb3IgdGhlDQogZmllbGQu IFRoaXMgYXBwbGllcyB0byBhbGwgbWVtYmVycyBvZiBhbGwgb2JqZWN0cyAoZGljdGlvbmFyaWVz KSBhcyB3ZWxsIGFzIGFsbCBtZW1iZXJzIG9mIGFuIGFycmF5IChsaXN0KS4gRXZlcnkgdGltZSB5 b3UgcHJvY2VzcyBhIGZpZWxkIHZhbHVlIG9yIG90aGVyIGVsZW1lbnQsIHlvdSBsb29rIGF0IHRo ZSB0eXBlIGFuZCB0aGVuIHRoZSB2YWx1ZSB0byBkZXRlcm1pbmUgd2hhdCB0byBkbyB3aXRoIHRo YXQgdHlwZWQgdmFsdWUuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj5JbiB5b3VyIGV4YW1wbGUgYmVsb3csIGVhY2ggZmllbGQg d2l0aGluIHRoZSBkaWN0aW9uYXJ5IHdvdWxkIGFsc28gbmVlZCB0byBiZSB0eXBlZCwgYW5kIGVh Y2ggdHlwZSB3b3VsZCBuZWVkIHRvIGhhdmUgYSBjbGVhciBpbmRpY2F0aW9uIG9mIGl0cyBtZWFu aW5nLiBUbyB0YWtlIHlvdXIgc3RyYXdtYW4ga2V5IGZvcm1hdCBiZWxvdywgdGhlIOKAnG1vZHVs dXPigJ0gZmllbGQgY291bGQgYmUgZGVmaW5lZCBwb2x5bW9ycGhpY2FsbHkNCiBhcyBlaXRoZXIg YSDigJxiaWdpbnTigJ0gKGEgSlNPTiBudW1iZXIpIG9yIGFuIOKAnGVuY29kZWQgc3RyaW5n4oCd IChhIEpTT04gc3RyaW5nKS4gVGhlIGRlZmluaXRpb24gd291bGQgZnVydGhlciBzYXkgd2hhdCBl eGFjdGx5IHRoZSBlbmNvZGluZyBvZiB0aGUgc3RyaW5nIHdvdWxkIGJlLiBUaGF0IG1lYW5zIHRo YXQgd2hlbiB5b3UgcmVhZCB0aGUg4oCcbW9kdWx1c+KAnSBmaWVsZCB0aGVyZSB3b3VsZG7igJl0 IGJlIGFueSBjb25mdXNpb24gb24gd2hhdCB0aGUgdmFsdWUNCiB3YXMgb3IgaG93IGl0IHdhcyBy ZXByZXNlbnRlZCwgcmVnYXJkbGVzcyBvZiB0aGUgaW5wdXQgZm9ybWF0LiBTZWVpbmcgYSBudW1i ZXIgdGhlcmUgbWVhbnMgZXhhY3RseSBvbmUgaW50ZXJwcmV0YXRpb24gYW5kIHNlZWluZyBhIHN0 cmluZyBtZWFucyBleGFjdGx5IG9uZSAoZGlmZmVyZW50KSBpbnRlcnByZXRhdGlvbiDigJQgYnV0 IGltcG9ydGFudGx5LCBib3RoIG9mIHRoZW0gYXJlIGEg4oCcbW9kdWx1c+KAnSwgc2luY2UgdGhh dOKAmXMgdGhlIGZpZWxkIHRoYXQNCiBkZXRlcm1pbmVzIHRoZSB0eXBlLiBBbiBpbXBsZW1lbnRh dGlvbiB3b3VsZCBsaWtlbHkgdXNlIGFuIGludGVybmFsIEJpZ0ludGVnZXIgdHlwZSBvZiBvYmpl Y3QgdG8gcmVwcmVzZW50IHRoZSBmaWVsZCB2YWx1ZSBhZnRlciBwYXJzaW5nLCBzbyB0aGUgcXVl c3Rpb24gaXMgaG93IHRvIGdvIGZyb20gdGhlIEpTT04gdmFsdWUgKHdoaWNoIGlzIHR5cGVkKSBp bnRvIHRoZSBCaWdJbnRlZ2VyIHZhbHVlLllvdSBkb27igJl0IGp1c3QgYXBwbHkgdGhlIHR5cGUN CiBydWxlcyBvbiB0aGUg4oCccHVibGljX2tleeKAnSBmaWVsZCwgeW91IGFwcGx5IGl0IHRvIGFs bCBzdWItZmllbGRzIG9mIHRoYXQgb2JqZWN0LiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+U28gbGV04oCZcyBkaWcg aW50byB0aGUgc3BlY2lmaWMgYnVnIHlvdSBicmluZyB1cCBpbiB0aGUgc3RyYXdtYW4sIGJlY2F1 c2UgaXTigJlzIGludGVyZXN0aW5nOiBBIEpTT04gZW5jb2RlciB0aGF0IGVuY29kZXMgbnVtYmVy cyBhcyBzdHJpbmdzLCBhbmQgbm90IG51bWJlcnMsIGlzIG5vdCBjb21wbGlhbnQgd2l0aCB0aGUg SlNPTiBkZWZpbml0aW9ucyBvZiB0aGUgZmllbGQgaW4gcXVlc3Rpb24uIEZvciBhbm90aGVyDQog ZXhhbXBsZSwgdGhlIHF1b3RlZCBzdHJpbmcgdmFsdWUgb2Yg4oCcdHJ1ZeKAnSBpcyBub3QgZXF1 aXZhbGVudCB0byB0aGUgYm9vbGVhbiB2YWx1ZSB0cnVlIGluIEpTT04sIGFuZCB0aGV5IHNob3Vs ZG7igJl0IGJlIHRyZWF0ZWQgdGhlIHNhbWUgYnkgYSBwYXJzZXIgaW1wbGVtZW50YXRpb24gd2hl biBtYXBwaW5nIHRvIGEgY29uY3JldGUgb2JqZWN0LiBJdOKAmXMgaW4gdGhpcyBraW5kIG9mIGF1 dG9tYXRlZCBndWVzc2luZyB0aGF0IHRoaXMgY2xhc3Mgb2YNCiBidWdzIG9jY3VyLCBhbmQgdGhh dOKAmXMgZ29pbmcgdG8gYmUgdGhlIGNhc2Ugd2hldGhlciBvciBub3QgeW91IHRha2UgJm5ic3A7 YWR2YW50YWdlIG9mIEpTT07igJlzIHBvbHltb3JwaGljIG5hdHVyZS4gSeKAmXZlIHJ1biBpbnRv IGNhc2VzIHdoZXJlIGEgcGFyc2VyIGxpYnJhcnkgd2FzIHRyeWluZyB0byBiZSBvdmVybHkg4oCc aGVscGZ1bOKAnSBpbiBkb2luZyB0aGlzIGtpbmQgb2YgbWFwcGluZywgYnV0IGVuZGVkIHVwIGlu dHJvZHVjaW5nIGVycm9ycyBpbiBtb3JlDQogc3RyaWN0IGNvbXBvbmVudHMgZG93bnN0cmVhbS4g VGhpcyBpcyBzb21ldGhpbmcgdGhhdCBwcm90b2NvbCBkZXNpZ25lcnMgbmVlZCB0byBiZSBhd2Fy ZSBvZiBhbmQgZ3VhcmQgYWdhaW5zdCBpbiB0aGUgZGVzaWduIG9mIHRoZSBwcm90b2NvbCB0byBy ZWR1Y2UgcG9zc2libGUgYW1iaWd1aXRpZXMuIFdpdGhpbiBHTkFQIHRvZGF5LCB3ZSBnZW5lcmFs bHkgaGF2ZSB0aGluZ3MgdGhhdCBicmFuY2ggd2hldGhlciB0aGV54oCZcmUgYW4gb2JqZWN0IChm b3INCiBhIHJpY2ggZGVzY3JpcHRpb24gb2Ygc29tZXRoaW5nKSBvciBzb21lIG5vbi1zdHJ1Y3R1 cmVkIHNwZWNpYWwgdmFsdWUgKGZvciBhIHJlZmVyZW5jZSBvciBvdGhlciBpdGVtKS4mbmJzcDs8 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29O b3JtYWwiPlRoZSBkZXNpZ24gdGVhbSBjcmVhdGVkIHNvbWUgc2ltcGxlIEpTT04gU2NoZW1hcyBm b3IgcGFydHMgb2YgdGhlIHByb3RvY29sIGR1cmluZyBvdXIgZGlzY3Vzc2lvbiwgYnV0IHdlIGRp ZG7igJl0IGluY2x1ZGUgdGhlbSBpbiB0aGUgZGVzaWduIGRvY3VtZW50IGR1ZSB0byBib3RoIGxh Y2sgb2YgdGltZSB0byBrZWVwIGl0IHVwZGF0ZWQgd2l0aCB0aGUgcmFwaWQgY2hhbmdlcyB0byB0 aGUgcHJvdG9jb2wgZHVyaW5nDQogdGhlIGRlc2lnbiB0ZWFtIGRpc2N1c3Npb24sIGFuZCBub3Qg a25vd2luZyBpZiB0aGVyZSB3b3VsZCBiZSBpbnRlcmVzdCBpbiBzdWNoIG1hdGVyaWFsLiBJIHBl cnNvbmFsbHkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIGFzIGFuIGluZm9y bWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUgZmluYWwgZG9jdW1lbnQsIGJ1dCB0aGF04oCZcyBzb21l dGhpbmcgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIHRha2UgdXAgZXZlbnR1YWxseS48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi PiZuYnNwO+KAlCBKdXN0aW48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+PGJyPg0KPGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5PbiBPY3QgMjMsIDIwMjAsIGF0IDEwOjE4IEFNLCBN aWthIEJvc3Ryw7ZtICZsdDs8YSBocmVmPSJtYWlsdG86bWlrYS5ib3N0cm9tPTQwc21hcmtldHMu Y29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5taWth LmJvc3Ryb209NDBzbWFya2V0cy5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8dT48 L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5i c3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1h bCI+SGVsbG8sIGV2ZXJ5b25lLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Rm9yIGJhY2tncm91bmQ6IEdOQVAvVHhBdXRoL1hZ Wi9PYXV0aDMgY2FtZSB1cCBvbiBhIGRpc2N1c3Npb24gZm9ydW0gYW5kIHdoZW4gSSBtYWRlIG5v dGUgYWJvdXQgY2VydGFpbiBjb25jZXJucywgSSB3YXMgcmVxdWVzdGVkIHRvIHNlbmQgbXkgY29t bWVudHMgdG8gdGhpcyB3b3JraW5nIGdyb3VwLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SW4gc2hvcnQsIEkgYmVsaWV2ZSB0 aGF0IHRoZSB1c2Ugb2YgcG9seW1vcnBoaWMgSlNPTiBpbiB0aGUgcHJvdG9jb2wgaW52aXRlcyBz dWJ0bGUgYW5kIGNvbmZ1c2luZyBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtcy4gSSBhbHNvIHNlYXJj aGVkIHRocm91Z2ggdGhlIFdHIGFyY2hpdmVzLCBhbmQgbm90aWNlZCB0aGF0IHNpbWlsYXIgY29u Y2VybnMgd2VyZSBub3RlZCwgYnJpZWZseSwgaW4gYSB0aHJlYWQgaW4NCiBKdWx5LiA8dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi PlRoZSBwcm9ibGVtIHdpdGggcG9seW1vcnBoaWMgdmFsdWVzLCBhcyBJIHNlZSBpdCwgaXMgdGhh dCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBuZWVkIHRvIGJyYW5jaCBvbiB0aGUgKGluZmVycmVkKSB0 eXBlIG9mIGEgZ2l2ZW4gZmllbGQuIFRoaXMgaXNuJ3QgcXVpdGUgYXMgYmFkIGlmIHRoZSB0eXBl cyBhcmUgc3RyaWN0bHkgZGlmZmVyZW50LCBidXQgYWxsb3dzIGZvciBzdWJ0bGUgYnVncyB3aGVu IHRoZSB2YWx1ZQ0KIGluIHF1ZXN0aW9uIGlzIGEgZGljdGlvbmFyeS4gV2hhdCBtYWtlcyB0aGlz IHVuYXBwZWFsaW5nIGlzIHRoYXQgJnF1b3Q7c3VidGxlIGJ1Z3MmcXVvdDsgaW4gc2VjdXJpdHkg cHJvdG9jb2xzIGhhdmUgYSBoYWJpdCBvZiB0dXJuaW5nIGludG8gdnVsbmVyYWJpbGl0aWVzLjx1 PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48 dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+TGV0J3Mgc2F5IHdlIGhhdmUgdGhlc2UgaW1hZ2luYXJ5IHBheWxvYWRzLCBib3RoIHBv c3NpYmxlIGFuZCB2YWxpZCBpbiB0aGUgc2FtZSBwcm90b2NvbCBzdGVwOjx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7 PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+IyBwYXls b2FkIDE8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+ezx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj4mbmJzcDsgLi4uLDx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgJnF1b3Q7cHVibGljX2tleSZxdW90Ozogezx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWxnJnF1b3Q7OiAmcXVvdDtyc2EmcXVvdDssPHU+PC91Pjx1 PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDttb2R1bHVzJnF1b3Q7OiAmbHQ7QklHSU5UJmd0Ozx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgfTx1 PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj59 PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj4jIHBheWxvYWQgMjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj57PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAuLi4sPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyAmcXVvdDtwdWJsaWNfa2V5 JnF1b3Q7OiB7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9N c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDthbGcmcXVvdDs6ICZxdW90O3JzYSZx dW90Oyw8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O21vZHVsdXMmcXVvdDs6ICZxdW90OyZsdDtl bmNvZGVkIHN0cmluZyZndDsmcXVvdDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7IH08dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+fTx1PjwvdT48dT48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SW4gYm90aCBjYXNlcywg dGhlIHR5cGUgb2YgJnF1b3Q7cHVibGljX2tleSZxdW90OyBmaWVsZCBpcyBhIGRpY3Rpb25hcnku IEluIGJvdGggY2FzZXMsIHRoZXkgZXZlbiBoYXZlIHRoZSBzYW1lIGtleXMuIEhvd2V2ZXIsIHRo ZSB2YWx1ZXMgaW4gdGhlIGRpY3Rpb25hcmllcyBhcmUgZW50aXJlbHkgZGlmZmVyZW50LCBhbmQg YW4gaW1wbGVtZW50YXRpb24gd2lsbCBoYXZlIHRvIGJyYW5jaCB0byBhdCBsZWFzdCB0d28gcG9z c2libGUNCiBkZWNvZGluZyBtZWNoYW5pc21zLiBUbyBtYWtlIHRoaW5ncyB3b3JzZSwgc29tZSBK U09OIGltcGxlbWVudGF0aW9ucyBtYXkgY2hvb3NlIHRvIGVuY29kZSBub24tZGljdGlvbmFyeSB2 YWx1ZXMgYXMgc3RyaW5ncywgc28gaXQgaXMgcG9zc2libGUgZm9yIGFuIG9yaWdpbmF0b3IgdG8g dHJhbnNtaXQgd2hhdCB0aGV5IGV4cGVjdCBhbmQgYmVsaWV2ZSB0byBiZSBwYXlsb2FkIDEgZm9y bWF0LCBidXQgd2hpY2ggdGhlIHJlY2VpdmVyIHdpbGwgaW50ZXJwcmV0DQogdG8gYmUgaW4gcGF5 bG9hZCAyIGZvcm1hdC4gQW5kIGlmIHRoZSBlbmNvZGVkIHN0cmluZyBjb250YWlucyBvbmx5IGRp Z2l0cywgaXQgd2lsbCBldmVuIHBhcnNlIGNvcnJlY3RseSBhcyBhIGJpZ251bS48dT48L3U+PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPldo aWxlIHRoZSBhYm92ZSBpcyBjbGVhcmx5IGEgbWFudWZhY3R1cmVkIHNjZW5hcmlvLCBpdCBub25l dGhlbGVzcyBkZW1vbnN0cmF0ZXMgdGhlIHBvdGVudGlhbCBmb3IgbG9naWMgYnVncyB3aXRoIHBv bHltb3JwaGljIEpTT04uIFdpdGggcmljaGVyIHR5cGVzIGFuZCBtb3JlIGNvbXBsZXggZGljdGlv bmFyaWVzLCB0aGVyZSB3aWxsIHN1cmVseSBiZSBtb3JlIHJvb20gZm9yIGVycm9ycy48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi PkFtYmlndWl0eSBpbiBwcm90b2NvbHMgaXMgYWx3YXlzIGEgc291cmNlIG9mIGltcGxlbWVudGF0 aW9uIGNvbXBsZXhpdHkgYW5kIGludGVyb3BlcmFiaWxpdHkgc25hZ3MsIGJ1dCBpbiBhbiBBdXRo Ti9BdXRoWiBwcm90b2NvbCBpdCBpcyB3b3JzZTogaXQncyB0ZXJyaWZ5aW5nLiBJZiBHTkFQL09h dXRoMyBpcyBpbnRlbmRlZCB0byBzdXBlcnNlZGUgT2F1dGgxLzIsIHdvdWxkbid0IGl0IGJlIGlu IGV2ZXJ5b25lJ3MNCiBpbnRlcmVzdCB0byBrZWVwIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkg YW5kIG1pc3Rha2UgcG90ZW50aWFsIHRvIGEgbWluaW11bT88dT48L3U+PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ TWlrYTx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj4tLSA8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPk1pa2EgQm9zdHLDtm08 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5TbWFya2V0 czx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPi0tIDxicj4NClRYQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VFhBdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdl dD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHhhdXRoPC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+LS0gPGJyPg0KVFhBdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIiByZWw9Im5vcmVmZXJyZXIiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxh bmsiIHJlbD0ibm9yZWZlcnJlciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGg8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJvcmRlcjpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0OyBwYWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRo PSIzMiIgaGVpZ2h0PSIzMiIgaWQ9InhfbV8tMjE3MDMyNzk3NjAwNjIxMTA5N194MDAwMF9pMTAy NSIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iIHN0eWxlPSJ3aWR0aDouMzMzM2luOyBo ZWlnaHQ6LjMzMzNpbiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDcuNXB0OyBmb250 LWZhbWlseTogR2FkdWdpLCBzYW5zLXNlcmlmOyBjb2xvcjogd2hpdGU7Ij7hkKc8L3NwYW4+PHU+ PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+LS0gPGJyPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiByZWw9 Im5vcmVmZXJyZXIiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0i bm9yZWZlcnJlciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8 L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+LS0gVFhBdXRoIG1haWxpbmcgbGlzdCA8YSBocmVmPSJtYWlsdG86VFhBdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5UWEF1dGhAaWV0Zi5vcmc8 L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo IiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT4gPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DF4PR8401MB1177F1FE6807DAB3690AAC13E5180DF4PR8401MB1177_-- From nobody Sun Oct 25 09:33:34 2020 Return-Path: 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 6A2B33A0AF9 for ; Sun, 25 Oct 2020 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 jfdRL4_OtBIx for ; Sun, 25 Oct 2020 09:33:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8FA3A0AFA for ; Sun, 25 Oct 2020 09:33:28 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09PGXNB3009649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 Oct 2020 12:33:23 -0400 From: Justin Richer Message-Id: <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_33D51033-EB88-44AB-A408-B3B3C2F9969E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 25 Oct 2020 12:33:22 -0400 In-Reply-To: Cc: Yaron Sheffer , Dick Hardt , =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List To: Fabien Imbault References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 16:33:34 -0000 --Apple-Mail=_33D51033-EB88-44AB-A408-B3B3C2F9969E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree fully with Fabien=E2=80=99s statements on who we=E2=80=99re = making things easy for. If this security protocol isn=E2=80=99t easy and = straightforward for client developers =E2=80=94 with or without a = library =E2=80=94 then it simply will not be adopted. It might be hard = to see when looking at the whole protocol, but this goal is actually one = of the drivers for the way polymorphism is used in the current draft. = The driving philosophy of OpenID Connect=E2=80=99s development was = =E2=80=9Ckeep the simple things simple, make the complex things = possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly believe we = need to continue here in GNAP. Importantly, a client developer shouldn=E2=80=99t need to have to = support all possible permutations in order to get something right. OAuth = has shown us that even when a protocol has a lot of options, client = software is going to be coded to use only one set of options. If the = protocol can support that reality, I think we are doing well. In the = current draft, generally speaking it=E2=80=99s the AS that needs to = handle different options, not the client. Take for example requesting = resources: a very simple client might just send an array of strings, = like OAuth scopes. The AS needs to be able to handle the string inputs = as well as the rich object descriptors, but the client software = doesn=E2=80=99t even need to know that the object format exists in order = to create compliant JSON. The client developer can do this without any = special libraries, it can just bang out the JSON directly. Such a client = won=E2=80=99t be able to do the more fancy stuff that the request = objects allow, but for this client, that=E2=80=99s fine since all it = needs to do is produce an array with strings that the AS will accept. = The same is true across the various other options, like requesting = multiple access tokens vs a single one, or providing an instance = identifier vs. a set of information for the client instance itself. = Client developers should be fully able to ignore parts of the protocol = that they aren=E2=80=99t using, especially the more advanced stuff. An = AS shouldn=E2=80=99t get to have such a choice, but as the AS is the = lynchpin of the security model, I am OK with things being slightly more = complex to support, especially if it shifts that complexity away from = clients. I am in favor of including JSON Schema in the draft in a non-normative = way, and you can see an earlier version of that experiment that Fabien = and I undertook as part of the Design Team. The schema will be available = for developers who want to / can use it, but even for people who = aren=E2=80=99t using the schema directly it can provide additional = context and information. I am willing to put some cycles into creating = schemas for the main request and response messages and put those into a = pull request to create an appendix in the draft. I=E2=80=99d also be = fine with a non-normative JSON-LD reference for LD processors =E2=80=94 = but (1) I=E2=80=99m not going to write that :) and (2) it can=E2=80=99t = be required for the protocol to be understood. =E2=80=94 Justin > On Oct 25, 2020, at 8:47 AM, Fabien Imbault = wrote: >=20 > Hi Yaron, >=20 > As Justin explained that's the kind of idea we tested. For instance = https://github.com/fimbault/test_gnap_schema = (in rust). >=20 > Cheers > Fabien=20 >=20 > Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer = > a =C3=A9crit : > Personally, I would support polymorphism in the protocol if it (the = RFC) came with a well-defined JSON Schema [1] document, so a recipient = can automatically validate incoming messages at run-time. I would expect = senders to also validate messages as part of their testing. It=E2=80=99s = not an ideal solution, because: >=20 > =20 >=20 > Some people at the IETF don=E2=80=99t like JSON Schema, for various = reasons. > JSON Schema is not a standard, so it=E2=80=99s painful to require it = normatively. > Even if it=E2=80=99s normative, some recipients will not validate = messages anyway. > =20 >=20 > This would be shifting some of the complexity from the library = developer to the spec developer, which is the right thing to do IMO. >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > [1] https://json-schema.org/ > =20 >=20 > =20 >=20 > From: Fabien Imbault > > Date: Sunday, October 25, 2020 at 12:39 > To: Yaron Sheffer > > Cc: Dick Hardt >, = Mika Bostr=C3=B6m >, GNAP Mailing List = >, Justin Richer = > > Subject: Re: [GNAP] Feedback on polymorphism >=20 > =20 >=20 > Hi Yaron, >=20 > =20 >=20 > Thanks for the feedback.=20 >=20 > =20 >=20 > Regarding client libraries, I think we can indeed learn a great deal = from cryptographic libraries. Cryptographic design provides a great = amount of flexibility for the specialists (including many parameters = that you really need to get right). We might think this is great to = provide options but it actually increases the cognitive load of library = users. >=20 > =20 >=20 > Look instead at what Google has provided with tink as an alternative = and you'll see it is a much easier way for cryptographic engineers (who = aren't cryptographers) to avoid mistakes or misuses.=20 >=20 > =20 >=20 > That's the *security* issue I'm referring to (not the fact that being = open they're tasty targets, although that may be related in some cases). = And tink is the kind of design we should be trying to achieve.=20 >=20 > =20 >=20 > I agree that it should be applicable to a wide range of well known = programming tools, including the likes of java and go.=20 >=20 > But I don't really see a limitation here. Might not be the most = idiomatic feel, but it can be made to work.=20 >=20 > =20 >=20 > Just so I understand, what alternatives would you prefer to = polymorphism? I can suggest json-ld but even Justin will Teel you it's = even more complex :-)=20 >=20 > =20 >=20 > Cheers >=20 > Fabien=20 >=20 > =20 >=20 > Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer = > a =C3=A9crit : >=20 > Hi Fabien, >=20 > =20 >=20 > I think your product management model has a lot of merit, but it does = not capture the security issue well. >=20 > =20 >=20 > I agree that as we look at different customer personas, the =E2=80=9Cend= user=E2=80=9D (the developer that=E2=80=99s using the libraries) should = be our highest priority. But I disagree about end-user mistakes being = the top *security* issue. Libraries are often open source in our space = and used very widely. So they make for tasty targets, and people are = attacking them and are still finding security issues in libraries that = we=E2=80=99ve been talking about forever [1]. >=20 > =20 >=20 > (Yes, my example is actually an app flaw, but I think it could have = been prevented by a better designed library.) >=20 > =20 >=20 > In other words, we do need to care about how easy it is to implement = the protocol correctly by *library* developers. =46rom Justin describing = his own experience and other people on the thread that Dick referred to, = I would say that JSON polymorphism is painful for Java and Go = developers. With all due respect, I care about them much more than I = care about Haskell, as many more implementations are likely to use these = languages. >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > [1] = https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-ap= p/ = > =20 >=20 > From: TXAuth > on behalf of Fabien Imbault = > > Date: Sunday, October 25, 2020 at 01:25 > To: Dick Hardt > > Cc: Mika Bostr=C3=B6m >, GNAP Mailing List = >, Justin Richer = > > Subject: Re: [GNAP] Feedback on polymorphism >=20 > =20 >=20 > Hi Dick, >=20 > =20 >=20 > Independantly from the debate on polyphormism, I beg to differ on your = order preference.=20 >=20 > =20 >=20 > Your assumption is that AS devs matter the most, because they're doing = the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users = of the spec are unable to deal with the complexity that is passed onto = them.=20 >=20 > =20 >=20 > 99% of the people that will actually use the output of the work are = application developers (client or RS) and their own users.=20 >=20 > =20 >=20 > Our intent as well as the protocol drive the usage. Client libraries = may help, but they're not a silver bullet, especially because GNAP = ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >=20 > =20 >=20 > I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >=20 > =20 >=20 > Fabien=20 >=20 > =20 >=20 > =20 >=20 > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt > a =C3=A9crit : >=20 > I'm confused by your logic Fabien. >=20 > =20 >=20 > If a client library developer wants to expose polymorphism, they can = do that independent of what is in the protocol.=20 >=20 > =20 >=20 > I differ on who our stakeholders are.=20 >=20 > =20 >=20 > I think our stakeholders are in least to most important: >=20 > =20 >=20 > AS developer > RS developer > client developer > user > =20 >=20 > A client library developer can expose whatever interface they want to = simplify implementation. >=20 > =20 >=20 > I list the user so that we don't lose site of a critical role. >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > =20 >=20 > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: >=20 > Hi there,=20 >=20 > =20 >=20 > Let me try to approach the issue under a different light. More like a = product manager would deal with feature selection to make it intuitive = for its users.=20 >=20 > =20 >=20 > For most people, riding a bike is far easier than using a unicycle. = Feels more stable. And yet it's way easier to design for a single wheel = than to build with 2. Because then you'll need a lot more accessories = (chain, chain ring, etc.). Even so producing a bike doesn't have to be a = brittle process, it can be industrialized.=20 >=20 > =20 >=20 > Back to the GNAP topic.=20 >=20 > Ultimately we should strive to make the spec as simple as can be. But = we need to ask: simple for whom? For the bike owner or for the bike = vendor?=20 >=20 > (short answer: the priority should be simplicity for spec users, not = spec implementers and even less spec designers).=20 >=20 > =20 >=20 > The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to = handle the state of the request? Or if we must handle token revocation? = Or if we are looking for a global unique identifier? The argument stems = of the fact that is still arguably harder and more error prone to = implement. Fair enough.=20 >=20 > =20 >=20 > =46rom a spec implementer's perspective, it may well be more complex. = It mostly impacts the json library you'll end up using, plus a bit of = input/output decoration around it. Even golang provides utilities for = this, despite not exactly being made for this kind of purpose. >=20 > My practical experience implementing it is that it's not that big a = deal. I mean, I wished it could be simpler, but it's manageable and = there are other ways to reach levels of insurance that it does work as = intended (json schema, test cases to validate the implementation, etc.). = Arguably it is still easier from an implementation perspective than say, = json-ld, which is massively used in the SSI community.=20 >=20 > =20 >=20 > But ultimately who are we designing for? Are we striving to go easy on = the spec implementer? Or are we trying to make sure end-developers using = the client libraries won't shoot themselves in the foot? >=20 > =20 >=20 > The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation.=20 >=20 > In turn, this spec implementer will rely on cryptographic utility = libraries that deals internally with the complexity of their own domain, = so that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have its set = of very real issues but that's beyond the point.=20 >=20 > Note that any decent flamewar will be efficiently fueled by people = hating medium. Is it outrageous for blog posts to be behind a paywall? = Maybe but it's even more outrageous to lack consistency, either by not = knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 >=20 > What likely seems an unnecessary sidenote tries to illustrate the = point: for Justin it was easier to publish on medium, because as a blog = publisher, you might not want to deal with hosting your own blog. But = maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >=20 > =20 >=20 > Polyphormism is a tool that enables the end-developer to have minimal = knowledge of what it means to deal with a GNAP client library. You = prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >=20 > =20 >=20 > If we find a better way to deal with that simplicity balance, I'm all = in. But the arguments need to be way more convincing than just saying = that it may be difficult to implement or validate.=20 >=20 > =20 >=20 > Cheers. >=20 > Fabien >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer > a =C3=A9crit : >=20 > =20 >=20 > =20 >=20 > On Oct 23, 2020, at 3:52 PM, Dick Hardt > wrote: >=20 > =20 >=20 > Justin >=20 > =20 >=20 > I did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable.=20 >=20 > =20 >=20 > As for concrete examples: >=20 > - version of client >=20 > - version of OS >=20 > - security attestation of OS / device >=20 > - location of client device >=20 > - network client is operating on >=20 > =20 >=20 > These are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used. >=20 > =20 >=20 > =20 >=20 > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman: >=20 > =20 >=20 > { >=20 > =20 >=20 > posture: { >=20 > software_version: 1.2.3, >=20 > os_version: 14.3.2 >=20 > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } >=20 > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >=20 > }, >=20 > =20 >=20 > client: =E2=80=9Cclient-541-ab" >=20 > =20 >=20 > } >=20 > =20 >=20 > This is a more fundamental question about GNAP than whether the syntax = uses polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer > wrote: >=20 > Dick, >=20 > =20 >=20 > As you=E2=80=99ll recall, I argued against including the client = instance identifier inside of the object as a mutually-exclusive field = precisely because of the principle violation that you are pointing out = here, and so it=E2=80=99s important to point out that the current text = is a compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored. >=20 > =20 >=20 > The crux of my argument is that is exactly a case of pass-by-reference = vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Oct 23, 2020, at 3:07 PM, Dick Hardt > wrote: >=20 > =20 >=20 > Hey Justin, >=20 > =20 >=20 > As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >=20 > =20 >=20 > In the current draft, the=20 >=20 > =20 >=20 > Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question.=20 >=20 > =20 >=20 > is violated in 2.3.1.=C2=A0 Identifying the RC Instance = > =20 >=20 > =20 >=20 > instance_id An identifier string that the AS can use to identify = the >=20 > particular instance of this RC. The content and structure of = this >=20 > identifier is opaque to the RC. >=20 > =20 >=20 > "client": { >=20 > "instance_id": "client-541-ab" >=20 > } >=20 > =20 >=20 > If there are no additional fields to send, the RC MAY send the >=20 > instance identifier as a direct reference value in lieu of the >=20 > object. >=20 > =20 >=20 > "client": "client-541-ab" >=20 > =20 >=20 > The instance identifier can be sent two ways. Polymorphism is a = convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >=20 > =20 >=20 > In your example of the "key" object below, setting "proof" to bearer = would avoid the issue you describe: >=20 > =20 >=20 > {=20 > "key": {=20 > "proof": "bearer"=20 > }=20 > } >=20 > =20 >=20 > In your example, when processing the "key" object, code is having to = check both the JSON type of the property, as well as check the value of = the "proof" property. In the example I provided, only the value of = "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >=20 > =20 >=20 > Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done = as above. >=20 > =20 >=20 > On a related note, there was significant negative feedback on handles = and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer > wrote: >=20 > Hi Mika, >=20 > =20 >=20 > Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. >=20 > =20 >=20 > Some background: I built out the XYZ protocol (one of the predecessors = to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >=20 > =20 >=20 > The driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >=20 > =20 >=20 > {=20 >=20 > key: { >=20 > proof: httpsig, >=20 > jwk: { =E2=80=A6 key value =E2=80=A6 } >=20 > }, >=20 > bearer_token: true, >=20 > bind_to_rc_key: true >=20 > } >=20 > =20 >=20 > This would be an illegal object as per this alternate proposal, but = then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. >=20 > =20 >=20 > {=20 >=20 > key: { >=20 > proof: httpsig, >=20 > jwk: { =E2=80=A6 key value =E2=80=A6 } >=20 > } >=20 > } >=20 > =20 >=20 > // bearer token >=20 > =20 >=20 > { >=20 > key: false >=20 > } >=20 > =20 >=20 > // bound to the RC=E2=80=99s presented key >=20 > =20 >=20 > { >=20 > key: true >=20 > } >=20 > =20 >=20 > If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. >=20 > =20 >=20 > While it might sound like polymorphism means that any field could have = any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. >=20 > =20 >=20 > In your example below, each field within the dictionary would also = need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 >=20 > =20 >=20 > So let=E2=80=99s dig into the specific bug you bring up in the = strawman, because it=E2=80=99s interesting: A JSON encoder that encodes = numbers as strings, and not numbers, is not compliant with the JSON = definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in = this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where = a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item).=20 >=20 > =20 >=20 > The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >=20 > =20 >=20 > Hello, everyone. >=20 > =20 >=20 > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my = comments to this working group. >=20 > =20 >=20 > In short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July. >=20 > =20 >=20 > The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >=20 > =20 >=20 > Let's say we have these imaginary payloads, both possible and valid in = the same protocol step: >=20 > =20 >=20 > # payload 1 >=20 > { >=20 > ..., >=20 > "public_key": { >=20 > "alg": "rsa", >=20 > "modulus": >=20 > } >=20 > } >=20 > =20 >=20 > # payload 2 >=20 > { >=20 > ..., >=20 > "public_key": { >=20 > "alg": "rsa", >=20 > "modulus": "" >=20 > } >=20 > } >=20 > =20 >=20 > In both cases, the type of "public_key" field is a dictionary. In both = cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >=20 > =20 >=20 > While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >=20 > =20 >=20 > Ambiguity in protocols is always a source of implementation complexity = and interoperability snags, but in an AuthN/AuthZ protocol it is worse: = it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, = wouldn't it be in everyone's interest to keep implementation complexity = and mistake potential to a minimum? >=20 > =20 >=20 > Best regards, >=20 > Mika >=20 > =20 >=20 > -- >=20 > Mika Bostr=C3=B6m >=20 > Smarkets >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > -- TXAuth mailing list TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_33D51033-EB88-44AB-A408-B3B3C2F9969E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree fully with Fabien=E2=80=99s statements on who we=E2=80=99re making = things easy for. If this security protocol isn=E2=80=99t easy and = straightforward for client developers =E2=80=94 with or without a = library =E2=80=94 then it simply will not be adopted. It might be hard = to see when looking at the whole protocol, but this goal is actually one = of the drivers for the way polymorphism is used in the current draft. = The driving philosophy of OpenID Connect=E2=80=99s development was = =E2=80=9Ckeep the simple things simple, make the complex things = possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly believe we = need to continue here in GNAP.

    Importantly, a client developer shouldn=E2=80=99t need to = have to support all possible permutations in order to get something = right. OAuth has shown us that even when a protocol has a lot of = options, client software is going to be coded to use only one set of = options. If the protocol can support that reality, I think we are doing = well. In the current draft, generally speaking it=E2=80=99s the AS that = needs to handle different options, not the client. Take for example = requesting resources: a very simple client might just send an array of = strings, like OAuth scopes. The AS needs to be able to handle the string = inputs as well as the rich object descriptors, but the client software = doesn=E2=80=99t even need to know that the object format exists in order = to create compliant JSON.  The client developer can do this = without any special libraries, it can just bang out the JSON = directly. Such a client won=E2=80=99t be able to do the more fancy = stuff that the request objects allow, but for this client, that=E2=80=99s = fine since all it needs to do is produce an array with strings that the = AS will accept. The same is true across the various other options, like = requesting multiple access tokens vs a single one, or providing an = instance identifier vs. a set of information for the client instance = itself. Client developers should be fully able to ignore parts of the = protocol that they aren=E2=80=99t using, especially the more advanced = stuff. An AS shouldn=E2=80=99t get to have such a choice, but as the AS = is the lynchpin of the security model, I am OK with things being = slightly more complex to support, especially if it shifts that = complexity away from clients.

    I am in favor of including JSON Schema = in the draft in a non-normative way, and you can see an earlier version = of that experiment that Fabien and I undertook as part of the Design = Team. The schema will be available for developers who want to / can use = it, but even for people who aren=E2=80=99t using the schema directly it = can provide additional context and information. I am willing to put some = cycles into creating schemas for the main request and response messages = and put those into a pull request to create an appendix in the draft. = I=E2=80=99d also be fine with a non-normative JSON-LD reference for LD = processors =E2=80=94 but (1) I=E2=80=99m not going to write that :) and = (2) it can=E2=80=99t be required for the protocol to be = understood.

     =E2=80=94 Justin

    On Oct = 25, 2020, at 8:47 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Yaron,

    As Justin = explained that's the kind of idea we tested. For instance https://github.com/fimbault/test_gnap_schema (in = rust).

    Cheers
    Fabien 

    Le dim. 25 = oct. 2020 =C3=A0 13:36, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit :

    Personally, I would support polymorphism in the = protocol if it (the RFC) came with a well-defined JSON Schema [1] = document, so a recipient can automatically validate incoming messages at = run-time. I would expect senders to also validate messages as part of = their testing. It=E2=80=99s not an ideal solution, because:

     

    • Some people at the IETF don=E2=80=99t like = JSON Schema, for various reasons.
    • JSON Schema is not a standard, so it=E2=80=99s = painful to require it normatively.
    • Even if it=E2=80=99s normative, some = recipients will not validate messages anyway.

     

    This would be shifting some = of the complexity from the library developer to the spec developer, = which is the right thing to do IMO.

     

    Thanks,

             =        Yaron

     

    [1] https://json-schema.org/

     

     

    From: = Fabien Imbault = <fabien.imbault@gmail.com>
    Date: Sunday, October 25, 2020 at 12:39
    To: Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: = Dick Hardt <dick.hardt@gmail.com>, Mika Bostr=C3=B6m = <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List = <txauth@ietf.org>, Justin Richer = <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on polymorphism

     

    Hi = Yaron,

     

    Thanks = for the feedback. 

     

    Regarding = client libraries, I think we can indeed learn a great deal from = cryptographic libraries. Cryptographic design provides a great amount of = flexibility for the specialists (including many parameters that you = really need to get right). We might think this is great to provide = options but it actually increases the cognitive load of library users.

     

    Look = instead at what Google has provided with tink as an alternative and = you'll see it is a much easier way for cryptographic engineers (who = aren't cryptographers) to avoid mistakes or misuses. 

     

    That's = the *security* issue I'm referring to (not the fact that being open = they're tasty targets, although that may be related in some cases). And = tink is the kind of design we should be trying to achieve. 

     

    I agree = that it should be applicable to a wide range of well known programming = tools, including the likes of java and go. 

    But I = don't really see a limitation here. Might not be the most idiomatic = feel, but it can be made to work. 

     

    Just so I understand, what alternatives would you = prefer to polymorphism? I can suggest json-ld but even Justin will Teel = you it's even more complex :-) 

     

    Cheers

    Fabien 

     

    Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer = <yaronf.ietf@gmail.com> a = =C3=A9crit :

    Hi Fabien,

     

    I think your = product management model has a lot of merit, but it does not capture the = security issue well.

     

    I agree that as we look at different customer = personas, the =E2=80=9Cend user=E2=80=9D (the developer that=E2=80=99s = using the libraries) should be our highest priority. But I disagree = about end-user mistakes being the top *security* = issue. Libraries are often open source in our space and used very = widely. So they make for tasty targets, and people are attacking them = and are still finding security issues in libraries that we=E2=80=99ve = been talking about forever [1].

     

    (Yes, my example is actually an app flaw, but I = think it could have been prevented by a better designed library.)

     

    In other = words, we do need to care about how easy it is to implement the protocol = correctly by *library* developers. =46rom Justin = describing his own experience and other people on the thread that Dick = referred to, I would say that JSON polymorphism is painful for Java and = Go developers. With all due respect, I care about them much more than I = care about Haskell, as many more implementations are likely to use these = languages.

     

    Thanks,

             =        Yaron

     

    [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact= -tracing-app/

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf = of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Sunday, October 25, 2020 at 01:25
    To: Dick Hardt <dick.hardt@gmail.com>
    Cc: = Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, = GNAP Mailing List <txauth@ietf.org>, Justin Richer = <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on polymorphism

     

    Hi = Dick,

     

    Independantly from the debate on polyphormism, I beg = to differ on your order preference. 

     

    Your assumption is that AS devs matter the = most, because they're doing the important security = implementation. But eating our own dogfood might help a lot to change = that view. Most security issues occur because users of the spec are = unable to deal with the complexity that is passed onto = them. 

     

    99% of = the people that will actually use the output of the work are application = developers (client or RS) and their own users. 

     

    Our intent = as well as the protocol drive the usage. Client libraries may help, but = they're not a silver bullet, especially because GNAP ultimately has no = control about what people do there (for better or worse). And everything = we do here will help get to the better part. 

     

    I'm not = saying we don't intend to also care about AS developers (beginning with = ourselves) but it's a second order optimisation. And since it's a = tendancy we're leaning towards by default, I'm pretty sure we won't = forget that anyway. 

     

    Fabien 

     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    I'm confused by = your logic Fabien.

     

    If a = client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol. 

     

    I differ on who our stakeholders are. 

     

    I think = our stakeholders are in least to most important:

     

    • AS developer
    • RS = developer
    • client developer
    • user

     

    A client = library developer can expose whatever interface they want to simplify = implementation.

     

    I list = the user so that we don't lose site of a critical role.

     

    /Dick

     

     

    Error! Filename not = specified.=E1=90=A7

     

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:

    Hi = there, 

     

    Let me try to approach = the issue under a different light. More like a product manager would = deal with feature selection to make it intuitive for its users. 

     

    For most people, riding a bike is far easier than = using a unicycle. Feels more stable. And yet it's way easier to design = for a single wheel than to build with 2. Because then you'll need a lot = more accessories (chain, chain ring, etc.). Even so producing a bike = doesn't have to be a brittle process, it can be industrialized. 

     

    Back to = the GNAP topic. 

    Ultimately = we should strive to make the spec as simple as can be. But we need to = ask: simple for whom? For the bike owner or for the bike = vendor? 

    (short = answer: the priority should be simplicity for spec users, not spec = implementers and even less spec designers). 

     

    The = initial question that is asked is very interesting: isn't the design = flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the = fact that is still arguably harder and more error prone to implement. = Fair enough. 

     

    =46rom a = spec implementer's perspective, it may well be more complex. It mostly = impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite = not exactly being made for this kind of purpose.

    My = practical experience implementing it is that it's not that big a deal. I = mean, I wished it could be simpler, but it's manageable and there are = other ways to reach levels of insurance that it does work as intended = (json schema, test cases to validate the implementation, etc.). Arguably = it is still easier from an implementation perspective than say, json-ld, = which is massively used in the SSI community. 

     

    But ultimately who are we designing for? Are we = striving to go easy on the spec implementer? Or are we trying to make = sure end-developers using the client libraries won't shoot themselves in = the foot?

     

    The job = to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation. 

    In turn, this spec implementer will rely on = cryptographic utility libraries that deals internally with the = complexity of their own domain, so that we don't have to. And here we = could launch another HN flame war that starts with the title "JWT sucks = because". Which does have its set of very real issues but that's beyond = the point. 

    Note that any decent flamewar will be = efficiently fueled by people hating medium. Is it outrageous for blog = posts to be behind a paywall? Maybe but it's even more outrageous to = lack consistency, either by not knowing how to get around a paywall if = you're into a hacker punk movement, or on the contrary by to not paying = a subscription if you believe that surveillance capitalism, to reuse = Zuboff's terms, should be eradicated. 

    What = likely seems an unnecessary sidenote tries to illustrate the point: for = Justin it was easier to publish on medium, because as a blog publisher, = you might not want to deal with hosting your own blog. But maybe as a = reader you'll find that annoying. Different audiences, different JTBD, = different tradeoffs. 

     

    Polyphormism is a tool that enables the = end-developer to have minimal knowledge of what it means to deal with a = GNAP client library. You prepare the request, send to the endpoint and = you're good to go. Massively simpler than OAuth2 or any similar protocol = by the way (as anyone with teaching experience on the subject might = acknowledge). And  there's a lot more to be done to make sure we = indeed reduce the complexity for the end-developer and the = end-user. 

     

    If we = find a better way to deal with that simplicity balance, I'm all in. But = the arguments need to be way more convincing than just saying that it = may be difficult to implement or validate. 

     

    Cheers.

    Fabien

     

     

     

     

     

    Le ven. 23 oct. 2020 = =C3=A0 22:35, Justin Richer <jricher@mit.edu> = a =C3=A9crit :

     

     

    On Oct 23, 2020, at 3:52 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

     

    Justin

     

    I did = note that I was the one that argued for instance_id being in the object. = Since it is in the object in the current draft, not including a pass by = reference option would be preferable. 

     

    As for concrete examples:

    - = version of client

    - version of OS

    - = security attestation of OS / device

    - = location of client device

    - = network client is operating on

     

    These are all attributes of the client that an AS = may require on the initial grant request, and in future grant = requests (which is when an instance_id) would be used.

     

     

    This is = where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman:

     

    {

     

      = posture: {

        software_version: 1.2.3,

        os_version: 14.3.2

      =   device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 }

        location: { lat: =E2=80=A6= , lon: =E2=80=A6, alt: =E2=80=A6 }

      = },

     

      = client: =E2=80=9Cclient-541-ab"

     

    }

     

    This is = a more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.

     

     =E2=80= =94 Justin

     

     

    /Dick

     

    Error! Filename not = specified.=E1=90=A7

     

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = <jricher@mit.edu> wrote:

    Dick,

     

    As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.

     

    The crux = of my argument is that is exactly a case of pass-by-reference vs = pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol.

     

     =E2=80=94 Justin

     

    On Oct 23, 2020, at 3:07 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

     

    Hey Justin,

     

    As the draft has evolved, I question the continued = use of polymorphism. Note that I appreciate the elegance of using a = string for pass-by-reference, and an object for pass-by-value.

     

    In the = current draft, the 

     

    Every time = you create or process a field it will mean only one thing, and there=E2=80= =99s only one field to look at to answer a question. 

     

    is = violated in 2.3.1.  = Identifying the RC Instance

     

     

      =  instance_id  An identifier string that the AS can use to = identify the

          particular = instance of this RC.  The content and structure of this

          identifier is opaque to the = RC.

     

      =  "client": {

          =  "instance_id": "client-541-ab"

      =  }

     

      =  If there are no additional fields to send, the RC MAY send the

       instance identifier as a direct = reference value in lieu of the

      =  object.

     

      =  "client": "client-541-ab"

     

    The = instance identifier can be sent two ways. Polymorphism is a convenience = for the client, but requires the server to have two code paths = for "instance_id".  We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.

     

    In your = example of the "key" object below, setting "proof" to bearer would avoid = the issue you describe:

     

    {  "key": { 
        =  "proof": "bearer"
        }
    }

     

    In your = example, when processing the "key" object, code is having to check both = the JSON type of the property, as well as check the value of the "proof" = property. In the example I provided, only the value of "proof" needs to = be checked. The "proof" property is acting as a type for the "key" = object.

     

    Not = being a Java programmer, I don't know how this would work in a Java = implementation, but node.js, the processing would need to be done as = above.

     

    On a = related note, there was significant negative feedback on handles and = polymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D24855750 

     

    /Dick

     

     

    On Fri, Oct 23, 2020 at 10:20 AM = Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

     

    Thanks = for bringing this topic here =E2=80=94 I was able to see the forum = discussion that brought you here, and hopefully I can help clear up what = I mean with how polymorphism is used in the proposal. The short version = is that the goal is to avoid the kinds of = ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can = help that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems.

     

    Some background: I built out the XYZ protocol (one = of the predecessors to the initial GNAP Draft) in Java using strongly = typed parsers and Java objects specifically to prove to myself that it = could be done in a way that made any sense in the code. (My own open = source implementation is at https://github.com/bspk/oauth.xyz-java, = but note that it=E2=80=99s not yet up to date with the GNAP spec). It = was important to me that I be able to use the system-wide configured = parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get = the hooks into the right places (especially with the Jackson parser that = I used), but it is definitely possible to create a deterministic and = strongly-typed parser and serializer for this kind of data structure. = Some of the rationale for using polymorphism is covered in the trailing = appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

     

    The = driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object:

     

    { 

        key: {

      =     proof: httpsig,

      =     jwk: { =E2=80=A6 key value =E2=80=A6 }

      =   },

        bearer_token: true,

      =   bind_to_rc_key: true

    }

     

    This = would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself.

     

    { 

      =   key: {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80= =A6 }

        }

    }

     

    // = bearer token

     

    {

        key: false

    }

     

    // bound = to the RC=E2=80=99s presented key

     

    {

        key: true

    }

     

    If = someone sends a different type for this field, like an array or number = or a null, this doesn=E2=80=99t have a defined interpretation in the = protocol and would be a protocol level error.

     

    While it might sound like polymorphism means that = any field could have any type or value, the opposite is true: each = possible value is explicitly typed, it=E2=80=99s just that there are = potentially different types that express meaning for the field. This = applies to all members of all objects (dictionaries) as well as all = members of an array (list). Every time you process a field value or = other element, you look at the type and then the value to determine what = to do with that typed value.

     

    In your example below, each field within the = dictionary would also need to be typed, and each type would need to have = a clear indication of its meaning. To take your strawman key format = below, the =E2=80=9Cmodulus=E2=80=9D field could be defined = polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or = an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition = would further say what exactly the encoding of the string would be. That = means that when you read the =E2=80=9Cmodulus=E2=80=9D field there = wouldn=E2=80=99t be any confusion on what the value was or how it was = represented, regardless of the input format. Seeing a number there means = exactly one interpretation and seeing a string means exactly one = (different) interpretation =E2=80=94 but importantly, both of them are a = =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that = determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

     

    So = let=E2=80=99s dig into the specific bug you bring up in the strawman, = because it=E2=80=99s interesting: A JSON encoder that encodes numbers as = strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of = =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in = JSON, and they shouldn=E2=80=99t be treated the same by a parser = implementation when mapping to a concrete object. It=E2=80=99s in this = kind of automated guessing that this class of bugs occur, and that=E2=80=99= s going to be the case whether or not you take  advantage of = JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a = parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item). 

     

    The = design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design = document due to both lack of time to keep it updated with the rapid = changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually.

     

     =E2=80= =94 Justin

     

    On Oct 23, 2020, at 10:18 AM, Mika = Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:

     

    Hello, everyone.

     

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a = discussion forum and when I made note about certain concerns, I was = requested to send my comments to this working group.

     

    In short, I believe that the use of polymorphic JSON = in the protocol invites subtle and confusing implementation problems. I = also searched through the WG archives, and noticed that similar concerns = were noted, briefly, in a thread in July.

     

    The problem with polymorphic values, as I see it, is = that implementations will need to branch on the (inferred) type of a = given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into vulnerabilities.

     

    Let's = say we have these imaginary payloads, both possible and valid in the = same protocol step:

     

    # = payload 1

    {

      ...,

      = "public_key": {

        "alg": "rsa",

        "modulus": <BIGINT>

      }

    }

     

    # = payload 2

    {

      ...,

      = "public_key": {

        "alg": "rsa",

        "modulus": "<encoded = string>"

      }

    }

     

    In both = cases, the type of "public_key" field is a dictionary. In both cases, = they even have the same keys. However, the values in the dictionaries = are entirely different, and an implementation will have to branch to at = least two possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

     

    While the above is clearly a manufactured scenario, = it nonetheless demonstrates the potential for logic bugs with = polymorphic JSON. With richer types and more complex dictionaries, there = will surely be more room for errors.

     

    Ambiguity in protocols is always a source of = implementation complexity and interoperability snags, but in an = AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum?

     

    Best = regards,

    Mika

     

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

     

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    Error! Filename not = specified.=E1=90=A7

     

     

    --
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    =
    = --Apple-Mail=_33D51033-EB88-44AB-A408-B3B3C2F9969E-- From nobody Sun Oct 25 11:42:46 2020 Return-Path: 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 91F073A11A1 for ; Sun, 25 Oct 2020 11:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 bfrHQqVsObGb for ; Sun, 25 Oct 2020 11:42:40 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 529D83A119A for ; Sun, 25 Oct 2020 11:42:39 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id d3so10424150wma.4 for ; Sun, 25 Oct 2020 11:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=fil1+VrIn8z6KLdrQR8aBvThgs/tQTDxyppZJlArMLg=; b=o97H2oeGEStM6srwYYcHzgmYinnbI46D8eaCyqWtLf5i9aNLONxiw2IsZp2KVWJ8ia pT/IQsgzfYxVnE3OHCpDA0zLxl/22Auf7IbsGWlU4MiuDmv/+0KdiNLIL4OsrzGqRRc7 +qZ0hoDi5026roWO9eTXxfZNNdK8X1pkDJfOA8ICBWD3ffE9iJyrxgAfZaoqi4etl+F8 uExnqRBpdJMes7O9wQspKpAijpbqBFD1jjUCiQ8W65dN5WMHSDc5yVwnwFtfG0vMxA+s bFJMuCAdXmsu5qJznE0G9QOmDM8hx42hm4njzeRW58KiMnIwokQSuXdHxo04L+YRWOrv FKQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=fil1+VrIn8z6KLdrQR8aBvThgs/tQTDxyppZJlArMLg=; b=imbQmn2/7Ku5CKOVXSr/ffTsV/oZDtSpCECUkK2TN6v0B2IQdcVBohu90acD5JHqnp bcD6oGWT/JVXFgTUCbrSvhSKvmw12P1bpARZBnZt/0NrEbtd5N2Agi1X20wyqVW72lWl M9NCz9Yy3F4xj03eLR2Xz5tVDH83OXZ0Rev16KcjgQuzxarZI5BlFZbUgl4N3AsUmQaE j2tcYvlNhi9awhcZq0gU0f3KkgnNSw3JeGEK/9a+5S5becdlSRdbFO6IE8JogWIQJJrX YuOD0BImuzqg4xx5w/L4q62R+Rn1HQFytZxYoQiVlLU7iMda467lf5McONPmTQmv8bGs cRBw== X-Gm-Message-State: AOAM531zKVWOkaIqkjlWph2qOkh+/73z7LIsR9BiKYGJudVgNsp3VoFr VSpwr2rQv0/DVhxEBMwlO5o= X-Google-Smtp-Source: ABdhPJzC2nPB3UpTsjhjFNYhoc6ohJVobiXuXk4Zv2/u57AhbzdMo3cT0ENYl5CXbIfMGM8RdjO0tQ== X-Received: by 2002:a7b:c20e:: with SMTP id x14mr12122697wmi.76.1603651357471; Sun, 25 Oct 2020 11:42:37 -0700 (PDT) Received: from [192.168.68.107] (bzq-79-176-32-148.red.bezeqint.net. [79.176.32.148]) by smtp.gmail.com with ESMTPSA id t7sm18012357wrx.42.2020.10.25.11.42.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2020 11:42:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sun, 25 Oct 2020 20:42:34 +0200 From: Yaron Sheffer To: Justin Richer , Fabien Imbault CC: Dick Hardt , Mika =?UTF-8?B?Qm9zdHLDtm0=?= , GNAP Mailing List Message-ID: Thread-Topic: [GNAP] Feedback on polymorphism References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> In-Reply-To: <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3686503355_1947995185" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 18:42:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3686503355_1947995185 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Justin, =20 I agree that there are going to be more clients than AS=E2=80=99s, and that clien= ts should be simpler to write. =20 But I=E2=80=99m not following your next argument. It sounds like =E2=80=9CThe AS is com= plex anyway, and it=E2=80=99s security-critical anyway, so why not have it absorb = some additional complexity?=E2=80=9D. With polymorphism in the protocol, AS develo= pers are likely to move to weak typing (generic types, e.g. interface{} in G= o). The entire implementations will pay the price (in more brittle code) for= the benefit of the few polymorphic fields that indeed may be easier to vali= date. I don=E2=80=99t think this is the right call. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Justin Richer Date: Sunday, October 25, 2020 at 18:33 To: Fabien Imbault Cc: Yaron Sheffer , Dick Hardt , Mika Bostr=C3=B6m , GNAP Mailing = List Subject: Re: [GNAP] Feedback on polymorphism =20 I agree fully with Fabien=E2=80=99s statements on who we=E2=80=99re making things easy = for. If this security protocol isn=E2=80=99t easy and straightforward for client d= evelopers =E2=80=94 with or without a library =E2=80=94 then it simply will not be adopt= ed. It might be hard to see when looking at the whole protocol, but this goa= l is actually one of the drivers for the way polymorphism is used in the cur= rent draft. The driving philosophy of OpenID Connect=E2=80=99s development was =E2=80=9C= keep the simple things simple, make the complex things possible=E2=80=9D, and that= =E2=80=99s a philosophy I strongly believe we need to continue here in GNAP. =20 Importantly, a client developer shouldn=E2=80=99t need to have to support all pos= sible permutations in order to get something right. OAuth has shown us that = even when a protocol has a lot of options, client software is going to be co= ded to use only one set of options. If the protocol can support that reality= , I think we are doing well. In the current draft, generally speaking it=E2=80=99s= the AS that needs to handle different options, not the client. Take for exa= mple requesting resources: a very simple client might just send an array of = strings, like OAuth scopes. The AS needs to be able to handle the string inp= uts as well as the rich object descriptors, but the client software doesn=E2=80=99= t even need to know that the object format exists in order to create complia= nt JSON. The client developer can do this without any special libraries, it= can just bang out the JSON directly. Such a client won=E2=80=99t be able to do th= e more fancy stuff that the request objects allow, but for this client, that= =E2=80=99s fine since all it needs to do is produce an array with strings that the= AS will accept. The same is true across the various other options, like req= uesting multiple access tokens vs a single one, or providing an instance ide= ntifier vs. a set of information for the client instance itself. Client deve= lopers should be fully able to ignore parts of the protocol that they aren=E2=80= =99t using, especially the more advanced stuff. An AS shouldn=E2=80=99t get to have = such a choice, but as the AS is the lynchpin of the security model, I am OK = with things being slightly more complex to support, especially if it shifts = that complexity away from clients. =20 I am in favor of including JSON Schema in the draft in a non-normative way,= and you can see an earlier version of that experiment that Fabien and I und= ertook as part of the Design Team. The schema will be available for develope= rs who want to / can use it, but even for people who aren=E2=80=99t using the sche= ma directly it can provide additional context and information. I am willing = to put some cycles into creating schemas for the main request and response m= essages and put those into a pull request to create an appendix in the draft= . I=E2=80=99d also be fine with a non-normative JSON-LD reference for LD processor= s =E2=80=94 but (1) I=E2=80=99m not going to write that :) and (2) it can=E2=80=99t be require= d for the protocol to be understood. =20 =E2=80=94 Justin On Oct 25, 2020, at 8:47 AM, Fabien Imbault wrot= e: =20 Hi Yaron, =20 As Justin explained that's the kind of idea we tested. For instance https:/= /github.com/fimbault/test_gnap_schema (in rust). =20 Cheers Fabien=20 =20 Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer a =C3=A9cr= it : Personally, I would support polymorphism in the protocol if it (the RFC) ca= me with a well-defined JSON Schema [1] document, so a recipient can automati= cally validate incoming messages at run-time. I would expect senders to also= validate messages as part of their testing. It=E2=80=99s not an ideal solution, b= ecause: =20 Some people at the IETF don=E2=80=99t like JSON Schema, for various reasons. JSON Schema is not a standard, so it=E2=80=99s painful to require it normatively. Even if it=E2=80=99s normative, some recipients will not validate messages anyway= . =20 This would be shifting some of the complexity from the library developer to= the spec developer, which is the right thing to do IMO. =20 Thanks, Yaron =20 [1] https://json-schema.org/ =20 =20 From: Fabien Imbault Date: Sunday, October 25, 2020 at 12:39 To: Yaron Sheffer Cc: Dick Hardt , Mika Bostr=C3=B6m , GNAP Mailing List , Justin Richer <= jricher@mit.edu> Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Yaron, =20 Thanks for the feedback.=20 =20 Regarding client libraries, I think we can indeed learn a great deal from c= ryptographic libraries. Cryptographic design provides a great amount of flex= ibility for the specialists (including many parameters that you really need = to get right). We might think this is great to provide options but it actual= ly increases the cognitive load of library users. =20 Look instead at what Google has provided with tink as an alternative and yo= u'll see it is a much easier way for cryptographic engineers (who aren't cry= ptographers) to avoid mistakes or misuses.=20 =20 That's the *security* issue I'm referring to (not the fact that being open = they're tasty targets, although that may be related in some cases). And tink= is the kind of design we should be trying to achieve.=20 =20 I agree that it should be applicable to a wide range of well known programm= ing tools, including the likes of java and go.=20 But I don't really see a limitation here. Might not be the most idiomatic f= eel, but it can be made to work.=20 =20 Just so I understand, what alternatives would you prefer to polymorphism? I= can suggest json-ld but even Justin will Teel you it's even more complex :-= )=20 =20 Cheers Fabien=20 =20 Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer a =C3=A9cr= it : Hi Fabien, =20 I think your product management model has a lot of merit, but it does not c= apture the security issue well. =20 I agree that as we look at different customer personas, the =E2=80=9Cend user=E2=80=9D = (the developer that=E2=80=99s using the libraries) should be our highest priority.= But I disagree about end-user mistakes being the top *security* issue. Libr= aries are often open source in our space and used very widely. So they make = for tasty targets, and people are attacking them and are still finding secur= ity issues in libraries that we=E2=80=99ve been talking about forever [1]. =20 (Yes, my example is actually an app flaw, but I think it could have been pr= evented by a better designed library.) =20 In other words, we do need to care about how easy it is to implement the pr= otocol correctly by *library* developers. From Justin describing his own exp= erience and other people on the thread that Dick referred to, I would say th= at JSON polymorphism is painful for Java and Go developers. With all due res= pect, I care about them much more than I care about Haskell, as many more im= plementations are likely to use these languages. =20 Thanks, Yaron =20 [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing= -app/ =20 From: TXAuth on behalf of Fabien Imbault Date: Sunday, October 25, 2020 at 01:25 To: Dick Hardt Cc: Mika Bostr=C3=B6m , GNAP Mailin= g List , Justin Richer Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Dick, =20 Independantly from the debate on polyphormism, I beg to differ on your orde= r preference.=20 =20 Your assumption is that AS devs matter the most, because they're doing the = important security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spec= are unable to deal with the complexity that is passed onto them.=20 =20 99% of the people that will actually use the output of the work are applica= tion developers (client or RS) and their own users.=20 =20 Our intent as well as the protocol drive the usage. Client libraries may he= lp, but they're not a silver bullet, especially because GNAP ultimately has = no control about what people do there (for better or worse). And everything = we do here will help get to the better part.=20 =20 I'm not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't forget that a= nyway.=20 =20 Fabien=20 =20 =20 Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3=A9crit : I'm confused by your logic Fabien. =20 If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=20 =20 I differ on who our stakeholders are.=20 =20 I think our stakeholders are in least to most important: =20 AS developer RS developer client developer user =20 A client library developer can expose whatever interface they want to simpl= ify implementation. =20 I list the user so that we don't lose site of a critical role. =20 /Dick =20 =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault w= rote: Hi there,=20 =20 Let me try to approach the issue under a different light. More like a produ= ct manager would deal with feature selection to make it intuitive for its us= ers.=20 =20 For most people, riding a bike is far easier than using a unicycle. Feels m= ore stable. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chain rin= g, etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized.=20 =20 Back to the GNAP topic.=20 Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=20 (short answer: the priority should be simplicity for spec users, not spec i= mplementers and even less spec designers).=20 =20 The initial question that is asked is very interesting: isn't the design fl= awed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are look= ing for a global unique identifier? The argument stems of the fact that is s= till arguably harder and more error prone to implement. Fair enough.=20 =20 >From a spec implementer's perspective, it may well be more complex. It most= ly impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite not e= xactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I= mean, I wished it could be simpler, but it's manageable and there are other= ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still ea= sier from an implementation perspective than say, json-ld, which is massivel= y used in the SSI community.=20 =20 But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot? =20 The job to be done (JTBD), from the end-developer's perspective, is to effi= ciently ship an application. And provide authN/authZ capabilities for end-us= ers by relying on some well known implementation.=20 In turn, this spec implementer will rely on cryptographic utility libraries= that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts with= the title "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=20 Note that any decent flamewar will be efficiently fueled by people hating m= edium. Is it outrageous for blog posts to be behind a paywall? Maybe but it'= s even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the contrary = by to not paying a subscription if you believe that surveillance capitalism,= to reuse Zuboff's terms, should be eradicated.=20 What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, yo= u might not want to deal with hosting your own blog. But maybe as a reader y= ou'll find that annoying. Different audiences, different JTBD, different tra= deoffs.=20 =20 Polyphormism is a tool that enables the end-developer to have minimal knowl= edge of what it means to deal with a GNAP client library. You prepare the re= quest, send to the endpoint and you're good to go. Massively simpler than OA= uth2 or any similar protocol by the way (as anyone with teaching experience = on the subject might acknowledge). And there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-use= r.=20 =20 If we find a better way to deal with that simplicity balance, I'm all in. B= ut the arguments need to be way more convincing than just saying that it may= be difficult to implement or validate.=20 =20 Cheers. Fabien =20 =20 =20 =20 =20 Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9crit : =20 =20 On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: =20 Justin =20 I did note that I was the one that argued for instance_id being in the obje= ct. Since it is in the object in the current draft, not including a pass by = reference option would be preferable.=20 =20 As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on =20 These are all attributes of the client that an AS may require on the initia= l grant request, and in future grant requests (which is when an instance_id)= would be used. =20 =20 This is where our interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattribu= tes of the client=E2=80=9D in the same way that the key, display information, clas= s identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t modify = the instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a sepa= rate object, so you=E2=80=99d have something like this strawman: =20 { =20 posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, =20 client: =E2=80=9Cclient-541-ab" =20 } =20 This is a more fundamental question about GNAP than whether the syntax uses= polymorphism: this is about GNAP being very explicit about the data model o= f its elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the ter= m =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. = We=E2=80=99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in GNAP w= ith explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be mo= re precise about what exactly a client instance includes, and what it does n= ot. =20 =E2=80=94 Justin =20 =20 /Dick =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: Dick, =20 As you=E2=80=99ll recall, I argued against including the client instance identifi= er inside of the object as a mutually-exclusive field precisely because of t= he principle violation that you are pointing out here, and so it=E2=80=99s importa= nt to point out that the current text is a compromise that needs to be exami= ned in the wider experience of the working group. I am on the side of removi= ng the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored. =20 The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Cclient in= stance=E2=80=9D value itself but rather belong outside of that object in a another= part of the request. As stated in the editorial notes in this section, we n= eed to look carefully at how these concepts fit within the model and where w= e would want to put them. Without concrete examples of what these extensions= look like and how they=E2=80=99re generated, that is nearly impossible to do at t= his stage. I look forward to seeing examples of this kind of data and how it= can fit into the protocol. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: =20 Hey Justin, =20 As the draft has evolved, I question the continued use of polymorphism. Not= e that I appreciate the elegance of using a string for pass-by-reference, an= d an object for pass-by-value. =20 In the current draft, the=20 =20 Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question.=20 =20 is violated in 2.3.1. Identifying the RC Instance =20 =20 instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. =20 "client": { "instance_id": "client-541-ab" } =20 If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. =20 "client": "client-541-ab" =20 The instance identifier can be sent two ways. Polymorphism is a convenience= for the client, but requires the server to have two code paths for "instanc= e_id". We discussed this in the design team, and I argued for having "insta= nce_id" in the "client" object so that any updates, such as new devices asse= rtions, could be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference. =20 In your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe: =20 {=20 "key": {=20 "proof": "bearer"=20 }=20 } =20 In your example, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "proof= " property. In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "key" object. =20 Not being a Java programmer, I don't know how this would work in a Java imp= lementation, but node.js, the processing would need to be done as above. =20 On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D= 24855750=20 =20 /Dick =20 =20 On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: Hi Mika, =20 Thanks for bringing this topic here =E2=80=94 I was able to see the forum discuss= ion that brought you here, and hopefully I can help clear up what I mean wit= h how polymorphism is used in the proposal. The short version is that the go= al is to avoid the kinds of ambiguity that make insecure protocols, and so i= n that goal we=E2=80=99re fully aligned. I think that using polymorphism in very s= pecific ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems. =20 Some background: I built out the XYZ protocol (one of the predecessors to t= he initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made an= y sense in the code. (My own open source implementation is at https://github= .com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the G= NAP spec). It was important to me that I be able to use the system-wide conf= igured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the hooks = into the right places (especially with the Jackson parser that I used), but = it is definitely possible to create a deterministic and strongly-typed parse= r and serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft document= (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name= -json-structures-and-polymor), but it=E2=80=99s still good to discuss this here as= the working group decides which approaches to take.=20 =20 The driving reason for using polymorphism at the protocol level was to simp= lify the protocol and make it :more: deterministic to create and process, no= t less. Every time you create or process a field it will mean only one thing= , and there=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fiel= ds, which is prone to failure and requires additional error checking. Take f= or example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way. = Without that, you=E2=80=99d need to have different fields for the options and incl= ude additional checks in your parser to make sure they weren=E2=80=99t sent simult= aneously, otherwise you could get hit with this potential security vulnerabi= lity in an object: =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } =20 This would be an illegal object as per this alternate proposal, but then yo= u=E2=80=99d have to check each field and make sure it wasn=E2=80=99t put next to others = in the same object. I=E2=80=99ve done this exercise with many other protocols and = it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples= would pass code that doesn=E2=80=99t check this. With the polymorphic approach to= this same field, each of these three mutually-exclusive states is written i= n a way that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s i= mpossible and enforced by the syntax of JSON itself. =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } =20 // bearer token =20 { key: false } =20 // bound to the RC=E2=80=99s presented key =20 { key: true } =20 If someone sends a different type for this field, like an array or number o= r a null, this doesn=E2=80=99t have a defined interpretation in the protocol and w= ould be a protocol level error. =20 While it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly typed= , it=E2=80=99s just that there are potentially different types that express meanin= g for the field. This applies to all members of all objects (dictionaries) a= s well as all members of an array (list). Every time you process a field val= ue or other element, you look at the type and then the value to determine wh= at to do with that typed value. =20 In your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its meaning= . To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be d= efined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what exactl= y the encoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number ther= e means exactly one interpretation and seeing a string means exactly one (di= fferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80= =9D, since that=E2=80=99s the field that determines the type. An implementation woul= d likely use an internal BigInteger type of object to represent the field va= lue after parsing, so the question is how to go from the JSON value (which i= s typed) into the BigInteger value.You don=E2=80=99t just apply the type rules on = the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object.=20 =20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take advantage of JSON=E2=80=99s polymorph= ic nature. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing er= rors in more strict components downstream. This is something that protocol d= esigners need to be aware of and guard against in the design of the protocol= to reduce possible ambiguities. Within GNAP today, we generally have things= that branch whether they=E2=80=99re an object (for a rich description of somethin= g) or some non-structured special value (for a reference or other item).=20 =20 The design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design document d= ue to both lack of time to keep it updated with the rapid changes to the pro= tocol during the design team discussion, and not knowing if there would be i= nterest in such material. I personally think it would be helpful to include = as an informative reference in the final document, but that=E2=80=99s something fo= r the working group to take up eventually. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m wrote: =20 Hello, everyone. =20 For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments t= o this working group. =20 In short, I believe that the use of polymorphic JSON in the protocol invite= s subtle and confusing implementation problems. I also searched through the = WG archives, and noticed that similar concerns were noted, briefly, in a thr= ead in July.=20 =20 The problem with polymorphic values, as I see it, is that implementations w= ill need to branch on the (inferred) type of a given field. This isn't quite= as bad if the types are strictly different, but allows for subtle bugs when= the value in question is a dictionary. What makes this unappealing is that = "subtle bugs" in security protocols have a habit of turning into vulnerabili= ties. =20 Let's say we have these imaginary payloads, both possible and valid in the = same protocol step: =20 # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } =20 # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } =20 In both cases, the type of "public_key" field is a dictionary. In both case= s, they even have the same keys. However, the values in the dictionaries are= entirely different, and an implementation will have to branch to at least t= wo possible decoding mechanisms. To make things worse, some JSON implementat= ions may choose to encode non-dictionary values as strings, so it is possibl= e for an originator to transmit what they expect and believe to be payload 1= format, but which the receiver will interpret to be in payload 2 format. An= d if the encoded string contains only digits, it will even parse correctly a= s a bignum. =20 While the above is clearly a manufactured scenario, it nonetheless demonstr= ates the potential for logic bugs with polymorphic JSON. With richer types a= nd more complex dictionaries, there will surely be more room for errors. =20 Ambiguity in protocols is always a source of implementation complexity and = interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's ter= rifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in= everyone's interest to keep implementation complexity and mistake potential= to a minimum? =20 Best regards, Mika =20 --=20 Mika Bostr=C3=B6m Smarkets --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth Error! Filename not specified.=E1=90=A7 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 =20 --B_3686503355_1947995185 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Hi Justin,=

     

    I agree that = there are going to be more clients than AS=E2=80=99s, and that clients should be s= impler to write.

     

    But I=E2=80=99m not following your next argument. It sounds like =E2=80=9C= The AS is complex anyway, and it=E2=80=99s security-critical anyway, so why not ha= ve it absorb some additional complexity?=E2=80=9D. With polymorphism in the protoc= ol, AS developers are likely to move to weak typing (generic types, e.g. int= erface{} in Go). The entire implementations will pay the price (in more brit= tle code) for the benefit of the few polymorphic fields that indeed may be e= asier to validate. I don=E2=80=99t think this is the right call.

     

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

     

    From: Justin Richer <jricher@mit.edu>
    Date: Sunday,= October 25, 2020 at 18:33
    To: Fabien Imbault <fabien.imbault@g= mail.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Dick= Hardt <dick.hardt@gmail.com>, Mika Bostr=C3=B6m <mika.bostrom=3D40smarke= ts.com@dmarc.ietf.org>, GNAP Mailing List <txauth@ietf.org>
    S= ubject: Re: [GNAP] Feedback on polymorphism

    <= div>

     

    I agree= fully with Fabien=E2=80=99s statements on who we=E2=80=99re making things easy for. If = this security protocol isn=E2=80=99t easy and straightforward for client developer= s =E2=80=94 with or without a library =E2=80=94 then it simply will not be adopted. It m= ight be hard to see when looking at the whole protocol, but this goal is act= ually one of the drivers for the way polymorphism is used in the current dra= ft. The driving philosophy of OpenID Connect=E2=80=99s development was =E2=80=9Ckeep the= simple things simple, make the complex things possible=E2=80=9D, and that=E2=80=99s a p= hilosophy I strongly believe we need to continue here in GNAP.

     

    = Importantly, a client developer shouldn=E2=80=99t need to have to support all poss= ible permutations in order to get something right. OAuth has shown us that e= ven when a protocol has a lot of options, client software is going to be cod= ed to use only one set of options. If the protocol can support that reality,= I think we are doing well. In the current draft, generally speaking it=E2=80=99s = the AS that needs to handle different options, not the client. Take for exam= ple requesting resources: a very simple client might just send an array of s= trings, like OAuth scopes. The AS needs to be able to handle the string inpu= ts as well as the rich object descriptors, but the client software doesn=E2=80=99t= even need to know that the object format exists in order to create complian= t JSON.  The client developer can do this without any special libr= aries, it can just bang out the JSON directly. Such a client won=E2=80=99t be= able to do the more fancy stuff that the request objects allow, but for thi= s client, that=E2=80=99s fine since all it needs to do is produce an array with st= rings that the AS will accept. The same is true across the various other opt= ions, like requesting multiple access tokens vs a single one, or providing a= n instance identifier vs. a set of information for the client instance itsel= f. Client developers should be fully able to ignore parts of the protocol th= at they aren=E2=80=99t using, especially the more advanced stuff. An AS shouldn=E2=80=99= t get to have such a choice, but as the AS is the lynchpin of the security m= odel, I am OK with things being slightly more complex to support, especially= if it shifts that complexity away from clients.

     

    I am in = favor of including JSON Schema in the draft in a non-normative way, and you = can see an earlier version of that experiment that Fabien and I undertook as= part of the Design Team. The schema will be available for developers who wa= nt to / can use it, but even for people who aren=E2=80=99t using the schema direct= ly it can provide additional context and information. I am willing to put so= me cycles into creating schemas for the main request and response messages a= nd put those into a pull request to create an appendix in the draft. I=E2=80=99d a= lso be fine with a non-normative JSON-LD reference for LD processors =E2=80=94 but= (1) I=E2=80=99m not going to write that :) and (2) it can=E2=80=99t be required for the= protocol to be understood.

     

     =E2=80=94 Justin



    On Oct 25, 2020, = at 8:47 AM, Fabien Imbault <fab= ien.imbault@gmail.com> wrote:

    =  

    Hi Yaron,

     

    As = Justin explained that's the kind of idea we tested. For instance https://github.com/fimbault= /test_gnap_schema (in rust).

     

    Cheers

    Fabien 

     

    Le dim. 25 oct. 2= 020 =C3=A0 13:36, Yaron Sheffer <yaron= f.ietf@gmail.com> a =C3=A9crit :

    Personally, I would support po= lymorphism in the protocol if it (the RFC) came with a well-defined JSON Sch= ema [1] document, so a recipient can automatically validate incoming message= s at run-time. I would expect senders to also validate messages as part of t= heir testing. It=E2=80=99s not an ideal solution, because:

     <= o:p>

    • Some people at the IETF don=E2=80=99t like JSON Sch= ema, for various reasons.
    • JSON Schema is not a standard, s= o it=E2=80=99s painful to require it normatively.
    • Even if it=E2=80=99s= normative, some recipients will not validate messages anyway.

     

    This would be shifting some of the complexit= y from the library developer to the spec developer, which is the right thing= to do IMO.

     

    Thanks,

    &= nbsp;            = ;   Yaron

     

    [1] https://json-schema.org/

     

     

    From: Fabien Imba= ult <fabien.imb= ault@gmail.com>
    Date: Sunday, October 25, 2020 at 12:39
    = To: Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: Dick Hardt <dick.hardt@gmail.com>, M= ika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List &l= t;txauth@ietf.org>, = Justin Richer <jricher@m= it.edu>
    Subject: Re: [GNAP] Feedback on polymorphism    =

     

    Hi Yaron,=

     

    Thanks for the feedback.&= nbsp;

     

    Regarding clien= t libraries, I think we can indeed learn a great deal from cryptographic lib= raries. Cryptographic design provides a great amount of flexibility for the = specialists (including many parameters that you really need to get right). W= e might think this is great to provide options but it actually increases the= cognitive load of library users.

     

    Look instead at what Google has provided with tink as an = alternative and you'll see it is a much easier way for cryptographic enginee= rs (who aren't cryptographers) to avoid mistakes or misuses. 

     

    That's the *security* is= sue I'm referring to (not the fact that being open they're tasty targets, al= though that may be related in some cases). And tink is the kind of design we= should be trying to achieve. 

     

    I agree that it should be applicable to a wide range of= well known programming tools, including the likes of java and go. 

    But I don't really see a limitation here. Might not = be the most idiomatic feel, but it can be made to work. 

    =

     

    Just so I understand, what al= ternatives would you prefer to polymorphism? I can suggest json-ld but even = Justin will Teel you it's even more complex :-) 

     

    Cheers

    Fab= ien 

     

    Le dim. 25 oct. 2= 020 =C3=A0 11:17, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit :

    Hi Fabien,

     

    I t= hink your product management model has a lot of merit, but it does not captu= re the security issue well.

     

    I agree t= hat as we look at different customer personas, the =E2=80=9Cend user=E2=80=9D (the devel= oper that=E2=80=99s using the libraries) should be our highest priority. But I dis= agree about end-user mistakes being the top *security* issue. Librari= es are often open source in our space and used very widely. So they make for= tasty targets, and people are attacking them and are still finding security= issues in libraries that we=E2=80=99ve been talking about forever [1].=

     

    (Yes, my example is actually an app flaw, but I= think it could have been prevented by a better designed library.)

     

    In other words, we do need to care about how e= asy it is to implement the protocol correctly by *library* developers= . From Justin describing his own experience and other people on the thread t= hat Dick referred to, I would say that JSON polymorphism is painful for Java= and Go developers. With all due respect, I care about them much more than I= care about Haskell, as many more implementations are likely to use these la= nguages.

     

    Thanks,

    &nbs= p;            &n= bsp;  Yaron

     

    [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-t= racing-app/

     

    From: TXAuth &l= t;txauth-bounces@ie= tf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Sunday, October 25, 2020 at 01:25
    To: Dick Hardt <dick.hardt@gmail.com>
    <= b>Cc:     Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mail= ing List <txauth@ietf.or= g>, Justin Richer <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on polymorp= hism

     

    Hi = Dick,

     

    Independantly f= rom the debate on polyphormism, I beg to differ on your order preference.&nb= sp;

     

    Your assump= tion is that AS devs matter the most, because they're doing the important security implementation. But= eating our own dogfood might help a lot to change that view. Most security = issues occur because users of the spec are unable to deal with the complexit= y that is passed onto them. 

     

    99% of the people that will actually use the outpu= t of the work are application developers (client or RS) and their own users.=  

     

    Our intent as well as the protocol driv= e the usage. Client libraries may help, but they're not a silver bullet, esp= ecially because GNAP ultimately has no control about what people do there (f= or better or worse). And everything we do here will help get to the better p= art. 

     

    I'm not saying we don't intend to also care about AS developers (beginnin= g with ourselves) but it's a second order optimisation. And since it's a ten= dancy we're leaning towards by default, I'm pretty sure we won't forget that= anyway. 

     

    Fabien 

     

    &n= bsp;

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <= ;dick.hardt@gmail.com<= /a>> a =C3=A9crit :

    /Dick

     <= /o:p>

    Hi there, <= o:p>

     

    Let me try to approa= ch the issue under a different light. More like a product manager would deal= with feature selection to make it intuitive for its users. =

     

    For most people, riding a = bike is far easier than using a unicycle. Feels more stable. And yet it's wa= y easier to design for a single wheel than to build with 2. Because then you= 'll need a lot more accessories (chain, chain ring, etc.). Even so producing= a bike doesn't have to be a brittle process, it can be industrialized. = ;

     

    Back to the G= NAP topic. 

    Ultimately we should strive to make the spec as simple as can be. But= we need to ask: simple for whom? For the bike owner or for the bike vendor?=  

    (short answer: the priority should be simplicity for spec users, n= ot spec implementers and even less spec designers). <= /p>

     

    The initial question that = is asked is very interesting: isn't the design flawed if GNAP is using json = polyphormism? Or if the AS needs to handle the state of the request? Or if w= e must handle token revocation? Or if we are looking for a global unique ide= ntifier? The argument stems of the fact that is still arguably harder and mo= re error prone to implement. Fair enough. 

    &= nbsp;

    From a spec implementer's perspective, it m= ay well be more complex. It mostly impacts the json library you'll end up us= ing, plus a bit of input/output decoration around it. Even golang provides u= tilities for this, despite not exactly being made for this kind of purpose.<= o:p>

    My practical experience implementing it is that i= t's not that big a deal. I mean, I wished it could be simpler, but it's mana= geable and there are other ways to reach levels of insurance that it does wo= rk as intended (json schema, test cases to validate the implementation, etc.= ). Arguably it is still easier from an implementation perspective than say, = json-ld, which is massively used in the SSI community. 

    <= /div>

     

    But ultimately who are we desi= gning for? Are we striving to go easy on the spec implementer? Or are we try= ing to make sure end-developers using the client libraries won't shoot thems= elves in the foot?

     

    The job to be done (JTBD), from the end-developer's perspective, is to e= fficiently ship an application. And provide authN/authZ capabilities for end= -users by relying on some well known implementation. 

    In turn, this spec implementer will rely on cryptographic utility = libraries that deals internally with the complexity of their own domain, so = that we don't have to. And here we could launch another HN flame war that st= arts with the title "JWT sucks because". Which does have its set o= f very real issues but that's beyond the point. 

    Note that any decent flamewar will be efficiently fueled by people hati= ng medium. Is it outrageous for blog posts to be behind a paywall? Maybe but= it's even more outrageous to lack consistency, either by not knowing how to= get around a paywall if you're into a hacker punk movement, or on the contr= ary by to not paying a subscription if you believe that surveillance capital= ism, to reuse Zuboff's terms, should be eradicated. 

    What likely seems an unnecessary sidenote tries to illustrate the p= oint: for Justin it was easier to publish on medium, because as a blog publi= sher, you might not want to deal with hosting your own blog. But maybe as a = reader you'll find that annoying. Different audiences, different JTBD, diffe= rent tradeoffs. 

     

    =

    Polyphormism is a tool that enables the end-developer to have minimal= knowledge of what it means to deal with a GNAP client library. You prepare = the request, send to the endpoint and you're good to go. Massively simpler t= han OAuth2 or any similar protocol by the way (as anyone with teaching exper= ience on the subject might acknowledge). And  there's a lot more to be = done to make sure we indeed reduce the complexity for the end-developer and = the end-user. 

     

    If we find a better way to deal with that simplicity balance, I'm all i= n. But the arguments need to be way more convincing than just saying that it= may be difficult to implement or validate. 

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= > 

    Cheers.

    Fabien=

     

     

     

     

    <= /div>

     

    Le ven. 23 oct. 20= 20 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit :

     

     

    On Oct 23, 2020, at 3:52 PM, Dick Hardt = <dick.hardt@gmail.c= om> wrote:

     

    Jus= tin

     

    I did note that I= was the one that argued for instance_id being in the object. Since it is in= the object in the current draft, not including a pass by reference option w= ould be preferable. 

     

    As for concrete examples:

    - version of= client

    - version of OS

    =

    - security attestation of OS / device

    - locatio= n of client device

    - network client is operating = on

     

    These are al= l attributes of the client that an AS may require on the initial grant = request, and in future grant requests (which is when an instance_id) would b= e used.

     

     

    This is where our interp= retations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in t= he same way that the key, display information, class identifiers, and other = items currently represented by an instance_id are attributes of the client i= nstance. The attestation components don=E2=80=99t modify the instance so much as p= resent additional information on top of the client instance itself. This is = why I argue that they ought to be handled in a separate object, so you=E2=80=99d h= ave something like this strawman:

     

    {

     

    <= div>

      posture: {

        software_ve= rsion: 1.2.3,

        os_version: 14.3.2

        device_attestation: { =E2=80=A6 some struct= ure or signed blob? =E2=80=A6 }

        location:= { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

      },<= /o:p>

     

      client: =E2=80=9Ccl= ient-541-ab"

     

    }

     

    This is a = more fundamental question about GNAP than whether the syntax uses polymorphi= sm: this is about GNAP being very explicit about the data model of its eleme= nts. OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80=9Cclient= =E2=80=9D is referring to, exactly, is deeply problematic in practice. We=E2=80=99re eve= n seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the different aspects = that are out there. I think we=E2=80=99re getting closer here in GNAP with explici= t definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be more precise = about what exactly a client instance includes, and what it does not.

     

     =E2=80=94 Justin<= /o:p>

     

     

    /Dick

     

    Error! Filename not specified.=E1=90=A7

     

    On = Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:

    Dick,

     

    As= you=E2=80=99ll recall, I argued against including the client instance identifier = inside of the object as a mutually-exclusive field precisely because of the = principle violation that you are pointing out here, and so it=E2=80=99s important = to point out that the current text is a compromise that needs to be examined= in the wider experience of the working group. I am on the side of removing = the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but this n= eeds to be explored.

     

    <= div>

    The crux of my argument is that is exactly a case of pass-by-reference= vs pass-by-value, and that runtime attestations are not part of the =E2=80=9Cclie= nt instance=E2=80=9D value itself but rather belong outside of that object in a an= other part of the request. As stated in the editorial notes in this section,= we need to look carefully at how these concepts fit within the model and wh= ere we would want to put them. Without concrete examples of what these exten= sions look like and how they=E2=80=99re generated, that is nearly impossible to do= at this stage. I look forward to seeing examples of this kind of data and h= ow it can fit into the protocol.

     

     =E2=80=94 Justin

     

    On Oct= 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    &n= bsp;

    Hey Justin,

     <= o:p>

    As the draft has evolved, I question the continue= d use of polymorphism. Note that I appreciate the elegance of using a s= tring for pass-by-reference, and an object for pass-by-value.

    =

     

    In the current draft, the&nbs= p;

     

    Every time you create or process a field it will mean only one thing, a= nd there=E2=80=99s only one field to look at to answer a question. 

     

     

     =

       instance_id  An identifi= er string that the AS can use to identify the

    &nb= sp;     particular instance of this RC.  The content and stru= cture of this

          identifier is = opaque to the RC.

     

       "client": {

      &nbs= p;    "instance_id": "client-541-ab"

       }

     

       If there are no additional fields to send, th= e RC MAY send the

       instance identifie= r as a direct reference value in lieu of the

    &nbs= p;  object.

     

    =

       "client": "client-541-ab"

    <= /div>

     

    The instance iden= tifier can be sent two ways. Polymorphism is a convenience for the client, b= ut requires the server to have two code paths for "instance_i= d".  We discussed this in the design team, and I argued for having= "instance_id" in the "client" object so that any u= pdates, such as new devices assertions, could be in the "client" o= bject. As noted above, while I appreciate the elegance of using a string (ha= ndle) to reference a previously provided object, it complicates how to updat= e an existing object while providing the reference.

     

    In your example of the "key" = object below, setting "proof" to bearer would avoid the issue you = describe:

     

    {&nbs= p;
     "key": { 
         "proof"= ;: "bearer"
        }
    }

    &= nbsp;

    In your example, when processing the "= key" object, code is having to check both the JSON type of the property= , as well as check the value of the "proof" property. In the examp= le I provided, only the value of "proof" needs to be checked. The = "proof" property is acting as a type for the "key" objec= t.

     

    Not being a = Java programmer, I don't know how this would work in a Java implementation, = but node.js, the processing would need to be done as above.

     

    On a related note, there was si= gnificant negative feedback on handles and polymorphism in the Hacker News a= rticle https://news.ycombinator.com/item?id=3D24855750 

     

    /Dick

    <= div>

     

     

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

     

    =

    Thanks for bringing this topic here =E2=80=94 I was able to see the f= orum discussion that brought you here, and hopefully I can help clear up wha= t I mean with how polymorphism is used in the proposal. The short version is= that the goal is to avoid the kinds of ambiguity that make= insecure protocols, and so in that goal we=E2=80=99re fully aligned. I think that= using polymorphism in very specific ways can help that goal =E2=80=94 just as I a= gree that misusing it or applying it sloppily can lead to ambiguous and inse= cure systems.

     

    S= ome background: I built out the XYZ protocol (one of the predecessors to the= initial GNAP Draft) in Java using strongly typed parsers and Java objects s= pecifically to prove to myself that it could be done in a way that made any = sense in the code. (My own open source implementation is at https://github.com/bsp= k/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the GNAP = spec). It was important to me that I be able to use the system-wide configur= ed parsers to implement this and not have to resort to stepping through elem= ents completely by hand. Java doesn=E2=80=99t make it simple to get the hooks into= the right places (especially with the Jackson parser that I used), but it i= s definitely possible to create a deterministic and strongly-typed parser an= d serializer for this kind of data structure. Some of the rationale for usin= g polymorphism is covered in the trailing appendix of the draft document (https://www.ietf.org/arch= ive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polymo= r), but it=E2=80=99s still good to discuss this here as the working group deci= des which approaches to take. 

     

    The driving reason for using polymorphism at the protoc= ol level was to simplify the protocol and make it :more: deterministic to cr= eate and process, not less. Every time you create or process a field it will= mean only one thing, and there=E2=80=99s only one field to look at to answer a qu= estion. Without polymorphic field values, you usually need to rely on mutual= exclusivity of fields, which is prone to failure and requires additional er= ror checking. Take for example the key binding of access tokens. An access t= oken could be bound to the RC=E2=80=99s key used during the request, to a differen= t key chosen by the AS, or it could be a bearer token with no key at all. By= making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in terms of boolea= n values and objects and express this set of mutually-exclusive options in a= non-ambiguous way. Without that, you=E2=80=99d need to have different fields for = the options and include additional checks in your parser to make sure they w= eren=E2=80=99t sent simultaneously, otherwise you could get hit with this potentia= l security vulnerability in an object:

     

    { 

        key= : {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

        },

        = bearer_token: true,

        bind_to_rc_key:= true

    }

     

    This would be an illegal object as per this alternate pr= oposal, but then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise with many o= ther protocols and it=E2=80=99s both error prone and easy to ignore since all the = =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t check this. With the poly= morphic approach to this same field, each of these three mutually-exclusive = states is written in a way that they cannot be sent together. It=E2=80=99s not jus= t illegal, it=E2=80=99s impossible and enforced by the syntax of JSON itself.=

     

    { 

        key: {

      =     proof: httpsig,

         = ; jwk: { =E2=80=A6 key value =E2=80=A6 }

        }=

    }

     

    // bearer token

     

    {

        key: false<= /p>

    }

     

    // bound to the RC=E2=80=99s presented key

    &nb= sp;

    {

        ke= y: true

    }

     <= /o:p>

    If someone sends a different type for this field, like= an array or number or a null, this doesn=E2=80=99t have a defined interpretation = in the protocol and would be a protocol level error.

     

    While it might sound like polymorphism= means that any field could have any type or value, the opposite is true: ea= ch possible value is explicitly typed, it=E2=80=99s just that there are potentiall= y different types that express meaning for the field. This applies to all me= mbers of all objects (dictionaries) as well as all members of an array (list= ). Every time you process a field value or other element, you look at the ty= pe and then the value to determine what to do with that typed value.

     

    In your example below,= each field within the dictionary would also need to be typed, and each type= would need to have a clear indication of its meaning. To take your strawman= key format below, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically = as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of the s= tring would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D field there = wouldn=E2=80=99t be any confusion on what the value was or how it was represented,= regardless of the input format. Seeing a number there means exactly one int= erpretation and seeing a string means exactly one (different) interpretation= =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the f= ield that determines the type. An implementation would likely use an interna= l BigInteger type of object to represent the field value after parsing, so t= he question is how to go from the JSON value (which is typed) into the BigIn= teger value.You don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D fi= eld, you apply it to all sub-fields of that object. 

     

    So let=E2=80=99s dig into the specific = bug you bring up in the strawman, because it=E2=80=99s interesting: A JSON encoder= that encodes numbers as strings, and not numbers, is not compliant with the= JSON definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JS= ON, and they shouldn=E2=80=99t be treated the same by a parser implementation when= mapping to a concrete object. It=E2=80=99s in this kind of automated guessing tha= t this class of bugs occur, and that=E2=80=99s going to be the case whether or not= you take  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into ca= ses where a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing th= is kind of mapping, but ended up introducing errors in more strict component= s downstream. This is something that protocol designers need to be aware of = and guard against in the design of the protocol to reduce possible ambiguiti= es. Within GNAP today, we generally have things that branch whether they=E2=80=99r= e an object (for a rich description of something) or some non-structured spe= cial value (for a reference or other item). 

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= > 

    The design team created some simple JSON = Schemas for parts of the protocol during our discussion, but we didn=E2=80=99t inc= lude them in the design document due to both lack of time to keep it updated= with the rapid changes to the protocol during the design team discussion, a= nd not knowing if there would be interest in such material. I personally thi= nk it would be helpful to include as an informative reference in the final d= ocument, but that=E2=80=99s something for the working group to take up eventually.=

     

     =E2=80=94 Just= in

     

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m= <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:

     

    Hello, everyone.

     

    For background: GNAP/TxAuth= /XYZ/Oauth3 came up on a discussion forum and when I made note about certain= concerns, I was requested to send my comments to this working group.

     

    In short, I believe t= hat the use of polymorphic JSON in the protocol invites subtle and confusing= implementation problems. I also searched through the WG archives, and notic= ed that similar concerns were noted, briefly, in a thread in July.

     

    The problem with polymo= rphic values, as I see it, is that implementations will need to branch on th= e (inferred) type of a given field. This isn't quite as bad if the types are= strictly different, but allows for subtle bugs when the value in question i= s a dictionary. What makes this unappealing is that "subtle bugs" = in security protocols have a habit of turning into vulnerabilities.

     

    Let's say we have these= imaginary payloads, both possible and valid in the same protocol step:=

     

    # payload 1

    {

      ...,

    <= /div>

      "public_key": {

    &nbs= p;   "alg": "rsa",

    =     "modulus": <BIGINT>

    <= div>

      }

    }

     = ;

    # payload 2

    {

      ...,

      "pub= lic_key": {

        "alg&quo= t;: "rsa",

        "mod= ulus": "<encoded string>"

    &n= bsp; }

    }

     

    In both cases, the type of "public_key" field= is a dictionary. In both cases, they even have the same keys. However, the = values in the dictionaries are entirely different, and an implementation wil= l have to branch to at least two possible decoding mechanisms. To make thing= s worse, some JSON implementations may choose to encode non-dictionary value= s as strings, so it is possible for an originator to transmit what they expe= ct and believe to be payload 1 format, but which the receiver will interpret= to be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

     <= o:p>

    While the above is clearly a manufactured scenari= o, it nonetheless demonstrates the potential for logic bugs with polymorphic= JSON. With richer types and more complex dictionaries, there will surely be= more room for errors.

     

    Ambiguity in protocols is always a source of implementation complexi= ty and interoperability snags, but in an AuthN/AuthZ protocol it is worse: i= t's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't i= t be in everyone's interest to keep implementation complexity and mistake po= tential to a minimum?

     

    =

    Best regards,

    Mika

     

    --

    =

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf= .org/mailman/listinfo/txauth

    &n= bsp;

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman= /listinfo/txauth

    Error! Filename not specif= ied.=E1=90=A7

     = ;

    &n= bsp;

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman= /listinfo/txauth

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txa= uth

     =

    --B_3686503355_1947995185-- From nobody Sun Oct 25 13:42:13 2020 Return-Path: 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 B5F593A1608 for ; Sun, 25 Oct 2020 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 rtgV2ZvW97E3 for ; Sun, 25 Oct 2020 13:42:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DDF3A1606 for ; Sun, 25 Oct 2020 13:42:06 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09PKg1Vx007792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 Oct 2020 16:42:02 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_89E2EBE4-B8C4-4A84-9E7C-12FE385302D5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 25 Oct 2020 16:42:01 -0400 In-Reply-To: Cc: Fabien Imbault , Dick Hardt , =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List To: Yaron Sheffer References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 20:42:12 -0000 --Apple-Mail=_89E2EBE4-B8C4-4A84-9E7C-12FE385302D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s not exactly what I=E2=80=99m saying =E2=80=94 I=E2=80=99m = more making the argument that things that complexity in the AS isn=E2=80=99= t an automatic (or even high priority) negative, if it offers a = measurable benefit like simplicity to the rest of the system. Obviously = things that make an AS very difficult to implement are going to be a = problem. Also, I=E2=80=99m not sure I was clear about characterizing my = implementation in Java. I explicitly set out to build it the hard way: I = wanted something that would run through a completely automated parser, = without any pre-processing or special code paths, into static types and = concrete object classes. There are no generic =E2=80=9CObject=E2=80=9Ds = or =E2=80=9CList of Maps of Maps=E2=80=9D or things like that in my = implementation, and my code doesn=E2=80=99t even call the JSON parser = directly, since it=E2=80=99s all wired directly through Spring. The = difficult part wasn=E2=80=99t writing the code that says =E2=80=9Cfor = this specific field, if it=E2=80=99s a string do A, if it=E2=80=99s an = object do B=E2=80=9D, the actual difficult part was wiring it up such = that it=E2=80=99s transparent to the rest of my code base. If I had been = doing my own parsing by hand and then handing it to =E2=80=9Creal=E2=80=9D= classes, or had resorted to generic types upon parsing and pulling out = raw values when I need them, it would have been a lot simpler. But both = of these are fragile, as you point out, and the way I did it I was = actually guaranteeing strict parsing and strict types, even with all the = polymorphism in place. This is the approach I would expect a fully = compliant AS to do, and something that conformance testing, schemas, and = careful protocol design can ferret out from bad implementations. =E2=80=94 Justin > On Oct 25, 2020, at 2:42 PM, Yaron Sheffer = wrote: >=20 > Hi Justin, > =20 > I agree that there are going to be more clients than AS=E2=80=99s, and = that clients should be simpler to write. > =20 > But I=E2=80=99m not following your next argument. It sounds like = =E2=80=9CThe AS is complex anyway, and it=E2=80=99s security-critical = anyway, so why not have it absorb some additional complexity?=E2=80=9D. = With polymorphism in the protocol, AS developers are likely to move to = weak typing (generic types, e.g. interface{} in Go). The entire = implementations will pay the price (in more brittle code) for the = benefit of the few polymorphic fields that indeed may be easier to = validate. I don=E2=80=99t think this is the right call. > =20 > Thanks, > Yaron > =20 > From: Justin Richer > Date: Sunday, October 25, 2020 at 18:33 > To: Fabien Imbault > Cc: Yaron Sheffer , Dick Hardt = , Mika Bostr=C3=B6m = , GNAP Mailing List = > Subject: Re: [GNAP] Feedback on polymorphism > =20 > I agree fully with Fabien=E2=80=99s statements on who we=E2=80=99re = making things easy for. If this security protocol isn=E2=80=99t easy and = straightforward for client developers =E2=80=94 with or without a = library =E2=80=94 then it simply will not be adopted. It might be hard = to see when looking at the whole protocol, but this goal is actually one = of the drivers for the way polymorphism is used in the current draft. = The driving philosophy of OpenID Connect=E2=80=99s development was = =E2=80=9Ckeep the simple things simple, make the complex things = possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly believe we = need to continue here in GNAP. > =20 > Importantly, a client developer shouldn=E2=80=99t need to have to = support all possible permutations in order to get something right. OAuth = has shown us that even when a protocol has a lot of options, client = software is going to be coded to use only one set of options. If the = protocol can support that reality, I think we are doing well. In the = current draft, generally speaking it=E2=80=99s the AS that needs to = handle different options, not the client. Take for example requesting = resources: a very simple client might just send an array of strings, = like OAuth scopes. The AS needs to be able to handle the string inputs = as well as the rich object descriptors, but the client software = doesn=E2=80=99t even need to know that the object format exists in order = to create compliant JSON. The client developer can do this without any = special libraries, it can just bang out the JSON directly. Such a client = won=E2=80=99t be able to do the more fancy stuff that the request = objects allow, but for this client, that=E2=80=99s fine since all it = needs to do is produce an array with strings that the AS will accept. = The same is true across the various other options, like requesting = multiple access tokens vs a single one, or providing an instance = identifier vs. a set of information for the client instance itself. = Client developers should be fully able to ignore parts of the protocol = that they aren=E2=80=99t using, especially the more advanced stuff. An = AS shouldn=E2=80=99t get to have such a choice, but as the AS is the = lynchpin of the security model, I am OK with things being slightly more = complex to support, especially if it shifts that complexity away from = clients. > =20 > I am in favor of including JSON Schema in the draft in a non-normative = way, and you can see an earlier version of that experiment that Fabien = and I undertook as part of the Design Team. The schema will be available = for developers who want to / can use it, but even for people who = aren=E2=80=99t using the schema directly it can provide additional = context and information. I am willing to put some cycles into creating = schemas for the main request and response messages and put those into a = pull request to create an appendix in the draft. I=E2=80=99d also be = fine with a non-normative JSON-LD reference for LD processors =E2=80=94 = but (1) I=E2=80=99m not going to write that :) and (2) it can=E2=80=99t = be required for the protocol to be understood. > =20 > =E2=80=94 Justin >=20 >=20 >> On Oct 25, 2020, at 8:47 AM, Fabien Imbault > wrote: >> =20 >> Hi Yaron, >> =20 >> As Justin explained that's the kind of idea we tested. For instance = https://github.com/fimbault/test_gnap_schema = (in rust). >> =20 >> Cheers >> Fabien=20 >> =20 >> Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer = > a =C3=A9crit : >>> Personally, I would support polymorphism in the protocol if it (the = RFC) came with a well-defined JSON Schema [1] document, so a recipient = can automatically validate incoming messages at run-time. I would expect = senders to also validate messages as part of their testing. It=E2=80=99s = not an ideal solution, because: >>> =20 >>> Some people at the IETF don=E2=80=99t like JSON Schema, for various = reasons. >>> JSON Schema is not a standard, so it=E2=80=99s painful to require it = normatively. >>> Even if it=E2=80=99s normative, some recipients will not validate = messages anyway. >>> =20 >>> This would be shifting some of the complexity from the library = developer to the spec developer, which is the right thing to do IMO. >>> =20 >>> Thanks, >>> Yaron >>> =20 >>> [1] https://json-schema.org/ >>> =20 >>> =20 >>> From: Fabien Imbault > >>> Date: Sunday, October 25, 2020 at 12:39 >>> To: Yaron Sheffer > >>> Cc: Dick Hardt >, = Mika Bostr=C3=B6m >, GNAP Mailing List = >, Justin Richer = > >>> Subject: Re: [GNAP] Feedback on polymorphism >>> =20 >>> Hi Yaron, >>> =20 >>> Thanks for the feedback.=20 >>> =20 >>> Regarding client libraries, I think we can indeed learn a great deal = from cryptographic libraries. Cryptographic design provides a great = amount of flexibility for the specialists (including many parameters = that you really need to get right). We might think this is great to = provide options but it actually increases the cognitive load of library = users. >>> =20 >>> Look instead at what Google has provided with tink as an alternative = and you'll see it is a much easier way for cryptographic engineers (who = aren't cryptographers) to avoid mistakes or misuses.=20 >>> =20 >>> That's the *security* issue I'm referring to (not the fact that = being open they're tasty targets, although that may be related in some = cases). And tink is the kind of design we should be trying to achieve.=20= >>> =20 >>> I agree that it should be applicable to a wide range of well known = programming tools, including the likes of java and go.=20 >>> But I don't really see a limitation here. Might not be the most = idiomatic feel, but it can be made to work.=20 >>> =20 >>> Just so I understand, what alternatives would you prefer to = polymorphism? I can suggest json-ld but even Justin will Teel you it's = even more complex :-)=20 >>> =20 >>> Cheers >>> Fabien=20 >>> =20 >>>=20 >>> Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer = > a =C3=A9crit : >>>> Hi Fabien, >>>> =20 >>>> I think your product management model has a lot of merit, but it = does not capture the security issue well. >>>> =20 >>>> I agree that as we look at different customer personas, the =E2=80=9C= end user=E2=80=9D (the developer that=E2=80=99s using the libraries) = should be our highest priority. But I disagree about end-user mistakes = being the top *security* issue. Libraries are often open source in our = space and used very widely. So they make for tasty targets, and people = are attacking them and are still finding security issues in libraries = that we=E2=80=99ve been talking about forever [1]. >>>> =20 >>>> (Yes, my example is actually an app flaw, but I think it could have = been prevented by a better designed library.) >>>> =20 >>>> In other words, we do need to care about how easy it is to = implement the protocol correctly by *library* developers. =46rom Justin = describing his own experience and other people on the thread that Dick = referred to, I would say that JSON polymorphism is painful for Java and = Go developers. With all due respect, I care about them much more than I = care about Haskell, as many more implementations are likely to use these = languages. >>>> =20 >>>> Thanks, >>>> Yaron >>>> =20 >>>> [1] = https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-ap= p/ = >>>> =20 >>>> From: TXAuth > on behalf of Fabien Imbault = > >>>> Date: Sunday, October 25, 2020 at 01:25 >>>> To: Dick Hardt > >>>> Cc: Mika Bostr=C3=B6m >, GNAP Mailing List = >, Justin Richer = > >>>> Subject: Re: [GNAP] Feedback on polymorphism >>>> =20 >>>> Hi Dick, >>>> =20 >>>> Independantly from the debate on polyphormism, I beg to differ on = your order preference.=20 >>>> =20 >>>> Your assumption is that AS devs matter the most, because they're = doing the important security implementation. But eating our own dogfood = might help a lot to change that view. Most security issues occur because = users of the spec are unable to deal with the complexity that is passed = onto them.=20 >>>> =20 >>>> 99% of the people that will actually use the output of the work are = application developers (client or RS) and their own users.=20 >>>> =20 >>>> Our intent as well as the protocol drive the usage. Client = libraries may help, but they're not a silver bullet, especially because = GNAP ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >>>> =20 >>>> I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >>>> =20 >>>> Fabien=20 >>>> =20 >>>> =20 >>>>=20 >>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt > a =C3=A9crit : >>>>> I'm confused by your logic Fabien. >>>>> =20 >>>>> If a client library developer wants to expose polymorphism, they = can do that independent of what is in the protocol.=20 >>>>> =20 >>>>> I differ on who our stakeholders are.=20 >>>>> =20 >>>>> I think our stakeholders are in least to most important: >>>>> =20 >>>>> AS developer >>>>> RS developer >>>>> client developer >>>>> user >>>>> =20 >>>>> A client library developer can expose whatever interface they want = to simplify implementation. >>>>> =20 >>>>> I list the user so that we don't lose site of a critical role. >>>>> =20 >>>>> /Dick >>>>> =20 >>>>> =20 >>>>> Error! Filename not specified.=E1=90=A7 >>>>> =20 >>>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: >>>>>> Hi there,=20 >>>>>> =20 >>>>>> Let me try to approach the issue under a different light. More = like a product manager would deal with feature selection to make it = intuitive for its users.=20 >>>>>> =20 >>>>>> For most people, riding a bike is far easier than using a = unicycle. Feels more stable. And yet it's way easier to design for a = single wheel than to build with 2. Because then you'll need a lot more = accessories (chain, chain ring, etc.). Even so producing a bike doesn't = have to be a brittle process, it can be industrialized.=20 >>>>>> =20 >>>>>> Back to the GNAP topic.=20 >>>>>> Ultimately we should strive to make the spec as simple as can be. = But we need to ask: simple for whom? For the bike owner or for the bike = vendor?=20 >>>>>> (short answer: the priority should be simplicity for spec users, = not spec implementers and even less spec designers).=20 >>>>>> =20 >>>>>> The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to = handle the state of the request? Or if we must handle token revocation? = Or if we are looking for a global unique identifier? The argument stems = of the fact that is still arguably harder and more error prone to = implement. Fair enough.=20 >>>>>> =20 >>>>>> =46rom a spec implementer's perspective, it may well be more = complex. It mostly impacts the json library you'll end up using, plus a = bit of input/output decoration around it. Even golang provides utilities = for this, despite not exactly being made for this kind of purpose. >>>>>> My practical experience implementing it is that it's not that big = a deal. I mean, I wished it could be simpler, but it's manageable and = there are other ways to reach levels of insurance that it does work as = intended (json schema, test cases to validate the implementation, etc.). = Arguably it is still easier from an implementation perspective than say, = json-ld, which is massively used in the SSI community.=20 >>>>>> =20 >>>>>> But ultimately who are we designing for? Are we striving to go = easy on the spec implementer? Or are we trying to make sure = end-developers using the client libraries won't shoot themselves in the = foot? >>>>>> =20 >>>>>> The job to be done (JTBD), from the end-developer's perspective, = is to efficiently ship an application. And provide authN/authZ = capabilities for end-users by relying on some well known implementation.=20= >>>>>> In turn, this spec implementer will rely on cryptographic utility = libraries that deals internally with the complexity of their own domain, = so that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have its set = of very real issues but that's beyond the point.=20 >>>>>> Note that any decent flamewar will be efficiently fueled by = people hating medium. Is it outrageous for blog posts to be behind a = paywall? Maybe but it's even more outrageous to lack consistency, either = by not knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 >>>>>> What likely seems an unnecessary sidenote tries to illustrate the = point: for Justin it was easier to publish on medium, because as a blog = publisher, you might not want to deal with hosting your own blog. But = maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >>>>>> =20 >>>>>> Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >>>>>> =20 >>>>>> If we find a better way to deal with that simplicity balance, I'm = all in. But the arguments need to be way more convincing than just = saying that it may be difficult to implement or validate.=20 >>>>>> =20 >>>>>> Cheers. >>>>>> Fabien >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer > a =C3=A9crit : >>>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt > wrote: >>>>>>>> =20 >>>>>>>> Justin >>>>>>>> =20 >>>>>>>> I did note that I was the one that argued for instance_id being = in the object. Since it is in the object in the current draft, not = including a pass by reference option would be preferable.=20 >>>>>>>> =20 >>>>>>>> As for concrete examples: >>>>>>>> - version of client >>>>>>>> - version of OS >>>>>>>> - security attestation of OS / device >>>>>>>> - location of client device >>>>>>>> - network client is operating on >>>>>>>> =20 >>>>>>>> These are all attributes of the client that an AS may require = on the initial grant request, and in future grant requests (which is = when an instance_id) would be used. >>>>>>>> =20 >>>>>>> =20 >>>>>>> This is where our interpretations differ: I don=E2=80=99t see = these as =E2=80=9Cattributes of the client=E2=80=9D in the same way that = the key, display information, class identifiers, and other items = currently represented by an instance_id are attributes of the client = instance. The attestation components don=E2=80=99t modify the instance = so much as present additional information on top of the client instance = itself. This is why I argue that they ought to be handled in a separate = object, so you=E2=80=99d have something like this strawman: >>>>>>> =20 >>>>>>> { >>>>>>> =20 >>>>>>> posture: { >>>>>>> software_version: 1.2.3, >>>>>>> os_version: 14.3.2 >>>>>>> device_attestation: { =E2=80=A6 some structure or signed = blob? =E2=80=A6 } >>>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>>>>> }, >>>>>>> =20 >>>>>>> client: =E2=80=9Cclient-541-ab" >>>>>>> =20 >>>>>>> } >>>>>>> =20 >>>>>>> This is a more fundamental question about GNAP than whether the = syntax uses polymorphism: this is about GNAP being very explicit about = the data model of its elements. OAuth 2=E2=80=99s incredibly loose and = broad model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >>>>>>> =20 >>>>>>> =E2=80=94 Justin >>>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>>> /Dick >>>>>>>> =20 >>>>>>>> Error! Filename not specified.=E1=90=A7 >>>>>>>> =20 >>>>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer > wrote: >>>>>>>>> Dick, >>>>>>>>> =20 >>>>>>>>> As you=E2=80=99ll recall, I argued against including the = client instance identifier inside of the object as a mutually-exclusive = field precisely because of the principle violation that you are pointing = out here, and so it=E2=80=99s important to point out that the current = text is a compromise that needs to be examined in the wider experience = of the working group. I am on the side of removing the = mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an = object, but this needs to be explored. >>>>>>>>> =20 >>>>>>>>> The crux of my argument is that is exactly a case of = pass-by-reference vs pass-by-value, and that runtime attestations are = not part of the =E2=80=9Cclient instance=E2=80=9D value itself but = rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look = carefully at how these concepts fit within the model and where we would = want to put them. Without concrete examples of what these extensions = look like and how they=E2=80=99re generated, that is nearly impossible = to do at this stage. I look forward to seeing examples of this kind of = data and how it can fit into the protocol. >>>>>>>>> =20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt > wrote: >>>>>>>>>> =20 >>>>>>>>>> Hey Justin, >>>>>>>>>> =20 >>>>>>>>>> As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >>>>>>>>>> =20 >>>>>>>>>> In the current draft, the=20 >>>>>>>>>> =20 >>>>>>>>>>> Every time you create or process a field it will mean only = one thing, and there=E2=80=99s only one field to look at to answer a = question.=20 >>>>>>>>>> =20 >>>>>>>>>> is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>>> instance_id An identifier string that the AS can use to = identify the >>>>>>>>>>> particular instance of this RC. The content and = structure of this >>>>>>>>>>> identifier is opaque to the RC. >>>>>>>>>>> =20 >>>>>>>>>>> "client": { >>>>>>>>>>> "instance_id": "client-541-ab" >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> If there are no additional fields to send, the RC MAY = send the >>>>>>>>>>> instance identifier as a direct reference value in lieu = of the >>>>>>>>>>> object. >>>>>>>>>>> =20 >>>>>>>>>>> "client": "client-541-ab" >>>>>>>>>> =20 >>>>>>>>>> The instance identifier can be sent two ways. Polymorphism is = a convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >>>>>>>>>> =20 >>>>>>>>>> In your example of the "key" object below, setting "proof" to = bearer would avoid the issue you describe: >>>>>>>>>> =20 >>>>>>>>>> {=20 >>>>>>>>>> "key": {=20 >>>>>>>>>> "proof": "bearer"=20 >>>>>>>>>> }=20 >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> In your example, when processing the "key" object, code is = having to check both the JSON type of the property, as well as check the = value of the "proof" property. In the example I provided, only the value = of "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >>>>>>>>>> =20 >>>>>>>>>> Not being a Java programmer, I don't know how this would work = in a Java implementation, but node.js, the processing would need to be = done as above. >>>>>>>>>> =20 >>>>>>>>>> On a related note, there was significant negative feedback on = handles and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >>>>>>>>>> =20 >>>>>>>>>> /Dick >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = > wrote: >>>>>>>>>>> Hi Mika, >>>>>>>>>>> =20 >>>>>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able to = see the forum discussion that brought you here, and hopefully I can help = clear up what I mean with how polymorphism is used in the proposal. The = short version is that the goal is to avoid the kinds of ambiguity that = make insecure protocols, and so in that goal we=E2=80=99re fully = aligned. I think that using polymorphism in very specific ways can help = that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems. >>>>>>>>>>> =20 >>>>>>>>>>> Some background: I built out the XYZ protocol (one of the = predecessors to the initial GNAP Draft) in Java using strongly typed = parsers and Java objects specifically to prove to myself that it could = be done in a way that made any sense in the code. (My own open source = implementation is at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >>>>>>>>>>> =20 >>>>>>>>>>> The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >>>>>>>>>>> =20 >>>>>>>>>>> {=20 >>>>>>>>>>> key: { >>>>>>>>>>> proof: httpsig, >>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>> }, >>>>>>>>>>> bearer_token: true, >>>>>>>>>>> bind_to_rc_key: true >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> This would be an illegal object as per this alternate = proposal, but then you=E2=80=99d have to check each field and make sure = it wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve = done this exercise with many other protocols and it=E2=80=99s both error = prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples = would pass code that doesn=E2=80=99t check this. With the polymorphic = approach to this same field, each of these three mutually-exclusive = states is written in a way that they cannot be sent together. It=E2=80=99s= not just illegal, it=E2=80=99s impossible and enforced by the syntax of = JSON itself. >>>>>>>>>>> =20 >>>>>>>>>>> {=20 >>>>>>>>>>> key: { >>>>>>>>>>> proof: httpsig, >>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> // bearer token >>>>>>>>>>> =20 >>>>>>>>>>> { >>>>>>>>>>> key: false >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>>>>> =20 >>>>>>>>>>> { >>>>>>>>>>> key: true >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> If someone sends a different type for this field, like an = array or number or a null, this doesn=E2=80=99t have a defined = interpretation in the protocol and would be a protocol level error. >>>>>>>>>>> =20 >>>>>>>>>>> While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value = is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value. >>>>>>>>>>> =20 >>>>>>>>>>> In your example below, each field within the dictionary = would also need to be typed, and each type would need to have a clear = indication of its meaning. To take your strawman key format below, the = =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as = either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded = string=E2=80=9D (a JSON string). The definition would further say what = exactly the encoding of the string would be. That means that when you = read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any = confusion on what the value was or how it was represented, regardless of = the input format. Seeing a number there means exactly one interpretation = and seeing a string means exactly one (different) interpretation =E2=80=94= but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since = that=E2=80=99s the field that determines the type. An implementation = would likely use an internal BigInteger type of object to represent the = field value after parsing, so the question is how to go from the JSON = value (which is typed) into the BigInteger value.You don=E2=80=99t just = apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you = apply it to all sub-fields of that object.=20 >>>>>>>>>>> =20 >>>>>>>>>>> So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take = advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into = cases where a parser library was trying to be overly =E2=80=9Chelpful=E2=80= =9D in doing this kind of mapping, but ended up introducing errors in = more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item).=20 >>>>>>>>>>> =20 >>>>>>>>>>> The design team created some simple JSON Schemas for parts = of the protocol during our discussion, but we didn=E2=80=99t include = them in the design document due to both lack of time to keep it updated = with the rapid changes to the protocol during the design team = discussion, and not knowing if there would be interest in such material. = I personally think it would be helpful to include as an informative = reference in the final document, but that=E2=80=99s something for the = working group to take up eventually. >>>>>>>>>>> =20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>>>>>>>>>>> =20 >>>>>>>>>>>> Hello, everyone. >>>>>>>>>>>> =20 >>>>>>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a = discussion forum and when I made note about certain concerns, I was = requested to send my comments to this working group. >>>>>>>>>>>> =20 >>>>>>>>>>>> In short, I believe that the use of polymorphic JSON in the = protocol invites subtle and confusing implementation problems. I also = searched through the WG archives, and noticed that similar concerns were = noted, briefly, in a thread in July.=20 >>>>>>>>>>>> =20 >>>>>>>>>>>> The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >>>>>>>>>>>> =20 >>>>>>>>>>>> Let's say we have these imaginary payloads, both possible = and valid in the same protocol step: >>>>>>>>>>>> =20 >>>>>>>>>>>> # payload 1 >>>>>>>>>>>> { >>>>>>>>>>>> ..., >>>>>>>>>>>> "public_key": { >>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>> "modulus": >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> # payload 2 >>>>>>>>>>>> { >>>>>>>>>>>> ..., >>>>>>>>>>>> "public_key": { >>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>> "modulus": "" >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> In both cases, the type of "public_key" field is a = dictionary. In both cases, they even have the same keys. However, the = values in the dictionaries are entirely different, and an implementation = will have to branch to at least two possible decoding mechanisms. To = make things worse, some JSON implementations may choose to encode = non-dictionary values as strings, so it is possible for an originator to = transmit what they expect and believe to be payload 1 format, but which = the receiver will interpret to be in payload 2 format. And if the = encoded string contains only digits, it will even parse correctly as a = bignum. >>>>>>>>>>>> =20 >>>>>>>>>>>> While the above is clearly a manufactured scenario, it = nonetheless demonstrates the potential for logic bugs with polymorphic = JSON. With richer types and more complex dictionaries, there will surely = be more room for errors. >>>>>>>>>>>> =20 >>>>>>>>>>>> Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum? >>>>>>>>>>>> =20 >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Mika >>>>>>>>>>>> =20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> Mika Bostr=C3=B6m >>>>>>>>>>>> Smarkets >>>>>>>>>>>> --=20 >>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> TXAuth mailing list >>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>> Error! Filename not specified.=E1=90=A7 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>=20 >>>>>>> =20 >>>>>>> --=20 >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> -- TXAuth mailing list TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_89E2EBE4-B8C4-4A84-9E7C-12FE385302D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s not exactly what I=E2=80=99m saying =E2=80=94 = I=E2=80=99m more making the argument that things that complexity in the = AS isn=E2=80=99t an automatic (or even high priority) negative, if it = offers a measurable benefit like simplicity to the rest of the system. = Obviously things that make an AS very difficult to implement are going = to be a problem.

    Also,= I=E2=80=99m not sure I was clear about characterizing my implementation = in Java. I explicitly set out to build it the hard way: I wanted = something that would run through a completely automated parser, without = any pre-processing or special code paths, into static types and concrete = object classes. There are no generic =E2=80=9CObject=E2=80=9Ds or = =E2=80=9CList of Maps of Maps=E2=80=9D or things like that in my = implementation, and my code doesn=E2=80=99t even call the JSON parser = directly, since it=E2=80=99s all wired directly through Spring. The = difficult part wasn=E2=80=99t writing the code that says =E2=80=9Cfor = this specific field, if it=E2=80=99s a string do A, if it=E2=80=99s an = object do B=E2=80=9D, the actual difficult part was wiring it up such = that it=E2=80=99s transparent to the rest of my code base. If I had been = doing my own parsing by hand and then handing it to =E2=80=9Creal=E2=80=9D= classes, or had resorted to generic types upon parsing and pulling out = raw values when I need them, it would have been a lot simpler. But both = of these are fragile, as you point out, and the way I did it I was = actually guaranteeing strict parsing and strict types, even with all the = polymorphism in place. This is the approach I would expect a fully = compliant AS to do, and something that conformance testing, schemas, and = careful protocol design can ferret out from bad = implementations.

     =E2=80=94 Justin


    On Oct 25, 2020, at 2:42 PM, = Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Justin,
     
    I agree that there are = going to be more clients than AS=E2=80=99s, and that clients should be = simpler to write.
     
    But I=E2=80=99m not = following your next argument. It sounds like =E2=80=9CThe AS is complex = anyway, and it=E2=80=99s security-critical anyway, so why not have it = absorb some additional complexity?=E2=80=9D. With polymorphism in the = protocol, AS developers are likely to move to weak typing (generic = types, e.g. interface{} in Go). The entire implementations will pay the = price (in more brittle code) for the benefit of the few polymorphic = fields that indeed may be easier to validate. I don=E2=80=99t think this = is the right call.
     
    Thanks,
              &nb= sp;     Yaron
     
    From: Justin Richer <jricher@mit.edu>
    Date: Sunday, October 25, = 2020 at 18:33
    To: Fabien Imbault <fabien.imbault@gmail.com>
    Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP = Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP] Feedback on = polymorphism
     
    I agree fully with Fabien=E2=80=99s statements = on who we=E2=80=99re making things easy for. If this security protocol = isn=E2=80=99t easy and straightforward for client developers =E2=80=94 = with or without a library =E2=80=94 then it simply will not be adopted. = It might be hard to see when looking at the whole protocol, but this = goal is actually one of the drivers for the way polymorphism is used in = the current draft. The driving philosophy of OpenID Connect=E2=80=99s = development was =E2=80=9Ckeep the simple things simple, make the complex = things possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly = believe we need to continue here in GNAP.
     
    Importantly, a client developer shouldn=E2=80=99t need to = have to support all possible permutations in order to get something = right. OAuth has shown us that even when a protocol has a lot of = options, client software is going to be coded to use only one set of = options. If the protocol can support that reality, I think we are doing = well. In the current draft, generally speaking it=E2=80=99s the AS that = needs to handle different options, not the client. Take for example = requesting resources: a very simple client might just send an array of = strings, like OAuth scopes. The AS needs to be able to handle the string = inputs as well as the rich object descriptors, but the client software = doesn=E2=80=99t even need to know that the object format exists in order = to create compliant JSON.  The client developer can do this = without any special libraries, it can just bang out the JSON = directly. Such a client won=E2=80=99t be able to do the more fancy = stuff that the request objects allow, but for this client, that=E2=80=99s = fine since all it needs to do is produce an array with strings that the = AS will accept. The same is true across the various other options, like = requesting multiple access tokens vs a single one, or providing an = instance identifier vs. a set of information for the client instance = itself. Client developers should be fully able to ignore parts of the = protocol that they aren=E2=80=99t using, especially the more advanced = stuff. An AS shouldn=E2=80=99t get to have such a choice, but as the AS = is the lynchpin of the security model, I am OK with things being = slightly more complex to support, especially if it shifts that = complexity away from clients.
     
    I am = in favor of including JSON Schema in the draft in a non-normative way, = and you can see an earlier version of that experiment that Fabien and I = undertook as part of the Design Team. The schema will be available for = developers who want to / can use it, but even for people who aren=E2=80=99= t using the schema directly it can provide additional context and = information. I am willing to put some cycles into creating schemas for = the main request and response messages and put those into a pull request = to create an appendix in the draft. I=E2=80=99d also be fine with a = non-normative JSON-LD reference for LD processors =E2=80=94 but (1) = I=E2=80=99m not going to write that :) and (2) it can=E2=80=99t be = required for the protocol to be understood.
     
     =E2=80=94 Justin


    On Oct 25, 2020, at 8:47 AM, Fabien Imbault = <fabien.imbault@gmail.com> = wrote:
     
    Hi Yaron,
     
    As = Justin explained that's the kind of idea we tested. For instance https://github.com/fimbault/test_gnap_schema (in rust).
     
    Cheers
    Fabien 
     
    Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer = <yaronf.ietf@gmail.com> a = =C3=A9crit :
    Personally, I would = support polymorphism in the protocol if it (the RFC) came with a = well-defined JSON Schema [1] document, so a recipient can automatically = validate incoming messages at run-time. I would expect senders to also = validate messages as part of their testing. It=E2=80=99s not an ideal = solution, because:
     
    • Some people at the IETF don=E2=80=99t = like JSON Schema, for various reasons.
    • JSON Schema is not a standard, so it=E2=80=99s painful to = require it normatively.
    • Even if it=E2=80=99s normative, some recipients will not = validate messages anyway.
     
    This would be shifting some of the complexity = from the library developer to the spec developer, which is the right = thing to do IMO.
     
    Thanks,
              &nb= sp;     Yaron
     
    [1] https://json-schema.org/
     
     
    From: Fabien Imbault <fabien.imbault@gmail.com>
    Date: Sunday, October 25, = 2020 at 12:39
    To: Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: Dick = Hardt <dick.hardt@gmail.com>, Mika Bostr=C3=B6m = <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List = <txauth@ietf.org>, = Justin Richer <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on = polymorphism
     
    Hi Yaron,
     
    Thanks = for the feedback. 
     
    Regarding client libraries, I think we = can indeed learn a great deal from cryptographic libraries. = Cryptographic design provides a great amount of flexibility for the = specialists (including many parameters that you really need to get = right). We might think this is great to provide options but it actually = increases the cognitive load of library users.
     
    Look = instead at what Google has provided with tink as an alternative and = you'll see it is a much easier way for cryptographic engineers (who = aren't cryptographers) to avoid mistakes or misuses. 
     
    That's = the *security* issue I'm referring to (not the fact that being open = they're tasty targets, although that may be related in some cases). And = tink is the kind of design we should be trying to achieve. 
     
    I agree = that it should be applicable to a wide range of well known programming = tools, including the likes of java and go. 
    But I = don't really see a limitation here. Might not be the most idiomatic = feel, but it can be made to work. 
     
    Just so I = understand, what alternatives would you prefer to polymorphism? I can = suggest json-ld but even Justin will Teel you it's even more complex = :-) 
     
    Cheers
    Fabien 

     

    Le dim. 25 oct. 2020 =C3=A0 = 11:17, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit :
    Hi Fabien,
     
    I think your product management model has a lot = of merit, but it does not capture the security issue well.
     
    I agree that as we look at = different customer personas, the =E2=80=9Cend user=E2=80=9D (the = developer that=E2=80=99s using the libraries) should be our highest = priority. But I disagree about end-user mistakes being the top *security* issue. Libraries are often open source in our = space and used very widely. So they make for tasty targets, and people = are attacking them and are still finding security issues in libraries = that we=E2=80=99ve been talking about forever [1].
     
    (Yes, my example is = actually an app flaw, but I think it could have been prevented by a = better designed library.)
     
    In other = words, we do need to care about how easy it is to implement the protocol = correctly by *library* developers. =46rom Justin = describing his own experience and other people on the thread that Dick = referred to, I would say that JSON polymorphism is painful for Java and = Go developers. With all due respect, I care about them much more than I = care about Haskell, as many more implementations are likely to use these = languages.
     
    Thanks,
              &nb= sp;     Yaron
     
    [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact= -tracing-app/
     
    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault = <fabien.imbault@gmail.com>
    Date: Sunday, October 25, = 2020 at 01:25
    To: Dick Hardt <dick.hardt@gmail.com>
    Cc: Mika = Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List = <txauth@ietf.org>, = Justin Richer <jricher@mit.edu>
    Subject: Re: [GNAP] Feedback on = polymorphism
     
    Hi Dick,
     
    Independantly from the debate on polyphormism, I beg to = differ on your order preference. 
     
    Your = assumption is that AS devs matter the most, because they're doing the important = security implementation. But eating our own dogfood might help a lot to = change that view. Most security issues occur because users of the spec = are unable to deal with the complexity that is passed onto = them. 
     
    99% of the people that will actually = use the output of the work are application developers (client or RS) and = their own users. 
     
    Our intent as well = as the protocol drive the usage. Client libraries may help, but they're = not a silver bullet, especially because GNAP ultimately has no control = about what people do there (for better or worse). And everything we do = here will help get to the better part. 
     
    I'm not = saying we don't intend to also care about AS developers (beginning with = ourselves) but it's a second order optimisation. And since it's a = tendancy we're leaning towards by default, I'm pretty sure we won't = forget that anyway. 
     
    Fabien 
     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick = Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    I'm = confused by your logic Fabien.
     
    If a = client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol. 
     
    I differ = on who our stakeholders are. 
     
    I think = our stakeholders are in least to most important:
     
    • AS developer
    • RS developer
    • client developer
    • user
     
    A client = library developer can expose whatever interface they want to simplify = implementation.
     
    I list the user so that we don't lose = site of a critical role.
     
    /Dick
     
     
    Error! Filename not specified.=E1=90=A7
     
    On Fri, Oct 23, 2020 at = 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi there, 
     
    Let me try to approach the = issue under a different light. More like a product manager would deal = with feature selection to make it intuitive for its users. 
     
    For most people, riding a bike is far easier = than using a unicycle. Feels more stable. And yet it's way easier to = design for a single wheel than to build with 2. Because then you'll need = a lot more accessories (chain, chain ring, etc.). Even so producing a = bike doesn't have to be a brittle process, it can be = industrialized. 
     
    Back to = the GNAP topic. 
    Ultimately we should strive to make the spec as simple as can = be. But we need to ask: simple for whom? For the bike owner or for the = bike vendor? 
    (short answer: the priority should be simplicity = for spec users, not spec implementers and even less spec = designers). 
     
    The = initial question that is asked is very interesting: isn't the design = flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the = fact that is still arguably harder and more error prone to implement. = Fair enough. 
     
    =46rom a spec implementer's = perspective, it may well be more complex. It mostly impacts the json = library you'll end up using, plus a bit of input/output decoration = around it. Even golang provides utilities for this, despite not exactly = being made for this kind of purpose.
    My practical experience implementing it = is that it's not that big a deal. I mean, I wished it could be simpler, = but it's manageable and there are other ways to reach levels of = insurance that it does work as intended (json schema, test cases to = validate the implementation, etc.). Arguably it is still easier from an = implementation perspective than say, json-ld, which is massively used in = the SSI community. 
     
    But = ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the = client libraries won't shoot themselves in the foot?
     
    The job = to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation. 
    In turn, = this spec implementer will rely on cryptographic utility libraries that = deals internally with the complexity of their own domain, so that we = don't have to. And here we could launch another HN flame war that starts = with the title "JWT sucks because". Which does have its set of very real = issues but that's beyond the point. 
    Note that = any decent flamewar will be efficiently fueled by people hating medium. = Is it outrageous for blog posts to be behind a paywall? Maybe but it's = even more outrageous to lack consistency, either by not knowing how to = get around a paywall if you're into a hacker punk movement, or on the = contrary by to not paying a subscription if you believe that = surveillance capitalism, to reuse Zuboff's terms, should be = eradicated. 
    What likely seems an unnecessary sidenote tries = to illustrate the point: for Justin it was easier to publish on medium, = because as a blog publisher, you might not want to deal with hosting = your own blog. But maybe as a reader you'll find that annoying. = Different audiences, different JTBD, different tradeoffs. 
     
    Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). = And  there's a lot more to be done to make sure we indeed reduce = the complexity for the end-developer and the end-user. 
     
    If we = find a better way to deal with that simplicity balance, I'm all in. But = the arguments need to be way more convincing than just saying that it = may be difficult to implement or validate. 
     
    Cheers.
    Fabien
     
     
     
     
     
    Le ven. 23 oct. 2020 =C3=A0 22:35, = Justin Richer <jricher@mit.edu> a =C3=A9crit :
     

     

    On Oct 23, 2020, at = 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
     
    Justin
     
    I did = note that I was the one that argued for instance_id being in the object. = Since it is in the object in the current draft, not including a pass by = reference option would be preferable. 
     
    As for = concrete examples:
    - version of client
    - version = of OS
    - security attestation of OS / device
    - = location of client device
    - network client is operating on
     
    These are = all attributes of the client that an AS may require on the initial = grant request, and in future grant requests (which is when an = instance_id) would be used.
     
     
    This is where our interpretations = differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the = client=E2=80=9D in the same way that the key, display information, class = identifiers, and other items currently represented by an instance_id are = attributes of the client instance. The attestation components don=E2=80=99= t modify the instance so much as present additional information on top = of the client instance itself. This is why I argue that they ought to be = handled in a separate object, so you=E2=80=99d have something like this = strawman:
     
    {
     
      = posture: {
        software_version: 1.2.3,
      =   os_version: 14.3.2
        device_attestation: { =E2=80= =A6 some structure or signed blob? =E2=80=A6 }
      =   location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
      = },
     
      client: =E2=80=9Cclient-541-ab"
     
    }
     
    This is a = more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.
     
     =E2=80= =94 Justin
     

     

    /Dick
     
    Error! Filename not specified.=E1=90=A7
     
    On Fri, Oct 23, 2020 at = 12:42 PM Justin Richer <jricher@mit.edu> wrote:
    Dick,
     
    As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.
     
    The crux of my argument is that is = exactly a case of pass-by-reference vs pass-by-value, and that runtime = attestations are not part of the =E2=80=9Cclient instance=E2=80=9D value = itself but rather belong outside of that object in a another part of the = request. As stated in the editorial notes in this section, we need to = look carefully at how these concepts fit within the model and where we = would want to put them. Without concrete examples of what these = extensions look like and how they=E2=80=99re generated, that is nearly = impossible to do at this stage. I look forward to seeing examples of = this kind of data and how it can fit into the protocol.
     
     =E2=80= =94 Justin

     

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
     
    Hey Justin,
     
    As the = draft has evolved, I question the continued use of polymorphism. Note = that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value.
     
    In the = current draft, the 
     
    Every = time you create or process a field it will mean only one thing, and = there=E2=80=99s only one field to look at to answer a = question. 
     
    is = violated in 2.3.1.  Identifying the RC Instance
     
     
     =  instance_id  An identifier string that the AS can use to = identify the
          particular instance of this = RC.  The content and structure of this
      =     identifier is opaque to the RC.
     
      =  "client": {
           "instance_id": = "client-541-ab"
       }
     
      =  If there are no additional fields to send, the RC MAY send the
      =  instance identifier as a direct reference value in lieu of the
      =  object.
     
       "client": = "client-541-ab"
     
    The = instance identifier can be sent two ways. Polymorphism is a convenience = for the client, but requires the server to have two code paths = for "instance_id".  We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.
     
    In your example of the "key" object = below, setting "proof" to bearer would avoid the issue you describe:
     
    { 
     "key": { 
        =  "proof": "bearer" 
      =   } 
    }
     
    In your example, when processing the = "key" object, code is having to check both the JSON type of the = property, as well as check the value of the "proof" property. In the = example I provided, only the value of "proof" needs to be checked. The = "proof" property is acting as a type for the "key" object.
     
    Not being = a Java programmer, I don't know how this would work in a Java = implementation, but node.js, the processing would need to be done as = above.
     
    On a related note, there was = significant negative feedback on handles and polymorphism in the Hacker = News article https://news.ycombinator.com/item?id=3D24855750 
     
    /Dick
     
     
    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = <jricher@mit.edu> = wrote:
    Hi = Mika,
     
    Thanks for bringing this topic here =E2=80=94 I = was able to see the forum discussion that brought you here, and = hopefully I can help clear up what I mean with how polymorphism is used = in the proposal. The short version is that the goal is to avoid the kinds of ambiguity that make insecure = protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using polymorphism in very specific ways can help that goal =E2=80=94 = just as I agree that misusing it or applying it sloppily can lead to = ambiguous and insecure systems.
     
    Some = background: I built out the XYZ protocol (one of the predecessors to the = initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 
     
    The driving reason for using = polymorphism at the protocol level was to simplify the protocol and make = it :more: deterministic to create and process, not less. Every time you = create or process a field it will mean only one thing, and there=E2=80=99s= only one field to look at to answer a question. Without polymorphic = field values, you usually need to rely on mutual exclusivity of fields, = which is prone to failure and requires additional error checking. Take = for example the key binding of access tokens. An access token could be = bound to the RC=E2=80=99s key used during the request, to a different = key chosen by the AS, or it could be a bearer token with no key at all. = By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it = in terms of boolean values and objects and express this set of = mutually-exclusive options in a non-ambiguous way. Without that, you=E2=80= =99d need to have different fields for the options and include = additional checks in your parser to make sure they weren=E2=80=99t sent = simultaneously, otherwise you could get hit with this potential security = vulnerability in an object:
     
    { 
      =   key: {
          proof: httpsig,
      =     jwk: { =E2=80=A6 key value =E2=80=A6 }
      =   },
        bearer_token: true,
      =   bind_to_rc_key: true
    }
     
    This = would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself.
     
    { 
        key: {
      =     proof: httpsig,
          jwk: { =E2=80=A6 = key value =E2=80=A6 }
        }
    }
     
    // bearer = token
     
    {
        key: false
    }
     
    // bound to the RC=E2=80=99s presented key
     
    {
      =   key: true
    }
     
    If = someone sends a different type for this field, like an array or number = or a null, this doesn=E2=80=99t have a defined interpretation in the = protocol and would be a protocol level error.
     
    While it = might sound like polymorphism means that any field could have any type = or value, the opposite is true: each possible value is explicitly typed, = it=E2=80=99s just that there are potentially different types that = express meaning for the field. This applies to all members of all = objects (dictionaries) as well as all members of an array (list). Every = time you process a field value or other element, you look at the type = and then the value to determine what to do with that typed value.
     
    In your = example below, each field within the dictionary would also need to be = typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 
     
    So let=E2=80=99s dig into the specific = bug you bring up in the strawman, because it=E2=80=99s interesting: A = JSON encoder that encodes numbers as strings, and not numbers, is not = compliant with the JSON definitions of the field in question. For = another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is = not equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated the same by a parser implementation when mapping to a = concrete object. It=E2=80=99s in this kind of automated guessing that = this class of bugs occur, and that=E2=80=99s going to be the case = whether or not you take  advantage of JSON=E2=80=99s polymorphic = nature. I=E2=80=99ve run into cases where a parser library was trying to = be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but = ended up introducing errors in more strict components downstream. This = is something that protocol designers need to be aware of and guard = against in the design of the protocol to reduce possible ambiguities. = Within GNAP today, we generally have things that branch whether = they=E2=80=99re an object (for a rich description of something) or some = non-structured special value (for a reference or other item). 
     
    The = design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design = document due to both lack of time to keep it updated with the rapid = changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually.
     
     =E2=80=94 Justin

     

    On Oct 23, 2020, at = 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:
     
    Hello, everyone.
     
    For = background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and = when I made note about certain concerns, I was requested to send my = comments to this working group.
     
    In short, = I believe that the use of polymorphic JSON in the protocol invites = subtle and confusing implementation problems. I also searched through = the WG archives, and noticed that similar concerns were noted, briefly, = in a thread in July. 
     
    The = problem with polymorphic values, as I see it, is that implementations = will need to branch on the (inferred) type of a given field. This isn't = quite as bad if the types are strictly different, but allows for subtle = bugs when the value in question is a dictionary. What makes this = unappealing is that "subtle bugs" in security protocols have a habit of = turning into vulnerabilities.
     
    Let's say = we have these imaginary payloads, both possible and valid in the same = protocol step:
     
    # payload 1
    {
      = ...,
      "public_key": {
        "alg": "rsa",
        "modulus": <BIGINT>
      = }
    }
     
    # payload = 2
    {
      = ...,
      "public_key": {
        "alg": "rsa",
        "modulus": "<encoded string>"
      = }
    }
     
    In both = cases, the type of "public_key" field is a dictionary. In both cases, = they even have the same keys. However, the values in the dictionaries = are entirely different, and an implementation will have to branch to at = least two possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.
     
    While the = above is clearly a manufactured scenario, it nonetheless demonstrates = the potential for logic bugs with polymorphic JSON. With richer types = and more complex dictionaries, there will surely be more room for = errors.
     
    Ambiguity in protocols is always a = source of implementation complexity and interoperability snags, but in = an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum?
     
    Best = regards,
    Mika
     
    -- 
    Mika Bostr=C3=B6m
    Smarkets
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
     
    Error! Filename not = specified.=E1=90=A7
     
    <= /div>
     
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =
    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    = --Apple-Mail=_89E2EBE4-B8C4-4A84-9E7C-12FE385302D5-- From nobody Sun Oct 25 16:58:18 2020 Return-Path: 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 41AB13A16F3 for ; Sun, 25 Oct 2020 16:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 UZEUxcZ2INCL for ; Sun, 25 Oct 2020 16:58:13 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 9C5503A16F2 for ; Sun, 25 Oct 2020 16:58:12 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id h20so7870251lji.9 for ; Sun, 25 Oct 2020 16:58:12 -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=6Id8IP55v8U9KIb0oD+AT8oEVEOa9J+So+bQ3werQww=; b=skxGXUgs+/IrCO/nP9zTITWjup6WNq6ZxVy/OyQD9NIDxOkXwILVB4F0nVFKnhJJi9 /IM1soogsLTt8/FBDOEdksP3Kcb78btTh79JfcEIIKfeZwpabMDbAmZJO0oLxYLJbR4x s7kqVo+7jOJBQPapnd6DbDGcYtiIFdk5nPVJ9s0Md1UGwZ3FUTVsqpHmG2pN6K9zUYpd tPiVOmMPNFGG0bnxGsqseXN1EZGKKqlNXk51x3YhEg2zjIUEV4DVs+IsiMPE5zp0e7dX wvwKLvXKDwxqxDi5gFLKhvTyo1DrWWLwFoBta+a67Ax5LdKNRgYyy/9oLdvZnZYlS5l6 oMiw== 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=6Id8IP55v8U9KIb0oD+AT8oEVEOa9J+So+bQ3werQww=; b=qY5jkKsqAmVI/omGLsL6KlTc229AEXJUo5tUQ8uOta48p0Mb5mLAPtUybiNyvQo8Wn Zf8yqz/jXtYatkRqv1jbzrfoi2qLnx3RHnDrRw26xTQqljRAFn4YbCK99nK8p/eQ/ufR /x0TmngBSx7jX50zStVdvvZCqsbPw+pZcHmvZbUuoHU/8WzO1qF4eLWhDD+5MWHHrS8I n5FGG2HQtgjx3hfFerVmv/kp1kBs36YTxdgFN3j1qaRjGjKXuAquqoJMpTOMmUdKDTue 45/n9Cnyg7AZ5JoqMPma27I+tAdEmKE4L+hy+pECG1NOtbYwKZI+HPB3UTCxCAn8qnzO 4etg== X-Gm-Message-State: AOAM531F/8exhUx0kR9+bTIhlMFjhe2T6NoQuYoFFwzq9F8KZ+53eurp sosTXThRpxebII78kMxQI0XaP6SGVrk/etY6Mx0= X-Google-Smtp-Source: ABdhPJzHeKgb/5E+TgLUYs121qqofVRkr/Z7KoiQYT5plM5/i4DssLvox3QQCAQl38aWaezhlvZvvlHIHliYjaUz0ic= X-Received: by 2002:a2e:7304:: with SMTP id o4mr4323071ljc.437.1603670290485; Sun, 25 Oct 2020 16:58:10 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Dick Hardt Date: Sun, 25 Oct 2020 16:57:33 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000000584b05b28796dc" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 23:58:17 -0000 --00000000000000584b05b28796dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien A library developer can provide whatever abstraction layer makes sense for the library's target audience and language. If the client library developer wants to use polymorphism in the interface presented to the user's of the library, the library developer can do that independent of polymorphism in the protocol, and vice versa =3D> polymorphism in the protocol has no impact on client library developer= s =E1=90=A7 On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault wrote: > I'm just realizing your "least to most important" might actually say the > same as what I was trying to say. So I'm not even sure what we're arguing > against :-) > > In brief my point if it wasn't clear is that we should be crystal clear o= n > where we put the cursor of simplicity, because this can mean different > things for different people and different roles. > And as we see on HN we need to better explain our design choices. > > > Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a > =C3=A9crit : > >> Hi Dick, >> >> Independantly from the debate on polyphormism, I beg to differ on your >> order preference. >> >> Your assumption is that AS devs matter the most, because they're doing >> the important security implementation. But eating our own dogfood might >> help a lot to change that view. Most security issues occur because users= of >> the spec are unable to deal with the complexity that is passed onto them= . >> >> 99% of the people that will actually use the output of the work are >> application developers (client or RS) and their own users. >> >> Our intent as well as the protocol drive the usage. Client libraries may >> help, but they're not a silver bullet, especially because GNAP ultimatel= y >> has no control about what people do there (for better or worse). And >> everything we do here will help get to the better part. >> >> I'm not saying we don't intend to also care about AS developers >> (beginning with ourselves) but it's a second order optimisation. And sin= ce >> it's a tendancy we're leaning towards by default, I'm pretty sure we won= 't >> forget that anyway. >> >> Fabien >> >> >> >> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : >> >>> I'm confused by your logic Fabien. >>> >>> If a client library developer wants to expose polymorphism, they can do >>> that independent of what is in the protocol. >>> >>> I differ on who our stakeholders are. >>> >>> I think our stakeholders are in least to most important: >>> >>> >>> - AS developer >>> - RS developer >>> - client developer >>> - user >>> >>> >>> A client library developer can expose whatever interface they want to >>> simplify implementation. >>> >>> I list the user so that we don't lose site of a critical role. >>> >>> /Dick >>> >>> >>> =E1=90=A7 >>> >>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >>> wrote: >>> >>>> Hi there, >>>> >>>> Let me try to approach the issue under a different light. More like a >>>> product manager would deal with feature selection to make it intuitive= for >>>> its users. >>>> >>>> For most people, riding a bike is far easier than using a unicycle. >>>> Feels more stable. And yet it's way easier to design for a single whee= l >>>> than to build with 2. Because then you'll need a lot more accessories >>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be= a >>>> brittle process, it can be industrialized. >>>> >>>> Back to the GNAP topic. >>>> Ultimately we should strive to make the spec as simple as can be. But >>>> we need to ask: simple for whom? For the bike owner or for the bike ve= ndor? >>>> (short answer: the priority should be simplicity for spec users, not >>>> spec implementers and even less spec designers). >>>> >>>> The initial question that is asked is very interesting: isn't the >>>> design flawed if GNAP is using json polyphormism? Or if the AS needs t= o >>>> handle the state of the request? Or if we must handle token revocation= ? Or >>>> if we are looking for a global unique identifier? The argument stems o= f the >>>> fact that is still arguably harder and more error prone to implement. = Fair >>>> enough. >>>> >>>> From a spec implementer's perspective, it may well be more complex. It >>>> mostly impacts the json library you'll end up using, plus a bit of >>>> input/output decoration around it. Even golang provides utilities for = this, >>>> despite not exactly being made for this kind of purpose. >>>> My practical experience implementing it is that it's not that big a >>>> deal. I mean, I wished it could be simpler, but it's manageable and th= ere >>>> are other ways to reach levels of insurance that it does work as inten= ded >>>> (json schema, test cases to validate the implementation, etc.). Arguab= ly it >>>> is still easier from an implementation perspective than say, json-ld, = which >>>> is massively used in the SSI community. >>>> >>>> But ultimately who are we designing for? Are we striving to go easy on >>>> the spec implementer? Or are we trying to make sure end-developers usi= ng >>>> the client libraries won't shoot themselves in the foot? >>>> >>>> The job to be done (JTBD), from the end-developer's perspective, is to >>>> efficiently ship an application. And provide authN/authZ capabilities = for >>>> end-users by relying on some well known implementation. >>>> In turn, this spec implementer will rely on cryptographic utility >>>> libraries that deals internally with the complexity of their own domai= n, so >>>> that we don't have to. And here we could launch another HN flame war t= hat >>>> starts with the title "JWT sucks because". Which does have its set of = very >>>> real issues but that's beyond the point. >>>> Note that any decent flamewar will be efficiently fueled by people >>>> hating medium. Is it outrageous for blog posts to be behind a paywall? >>>> Maybe but it's even more outrageous to lack consistency, either by not >>>> knowing how to get around a paywall if you're into a hacker punk movem= ent, >>>> or on the contrary by to not paying a subscription if you believe that >>>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated= . >>>> What likely seems an unnecessary sidenote tries to illustrate the >>>> point: for Justin it was easier to publish on medium, because as a blo= g >>>> publisher, you might not want to deal with hosting your own blog. But = maybe >>>> as a reader you'll find that annoying. Different audiences, different = JTBD, >>>> different tradeoffs. >>>> >>>> Polyphormism is a tool that enables the end-developer to have minimal >>>> knowledge of what it means to deal with a GNAP client library. You pre= pare >>>> the request, send to the endpoint and you're good to go. Massively sim= pler >>>> than OAuth2 or any similar protocol by the way (as anyone with teachin= g >>>> experience on the subject might acknowledge). And there's a lot more = to be >>>> done to make sure we indeed reduce the complexity for the end-develope= r and >>>> the end-user. >>>> >>>> If we find a better way to deal with that simplicity balance, I'm all >>>> in. But the arguments need to be way more convincing than just saying = that >>>> it may be difficult to implement or validate. >>>> >>>> Cheers. >>>> Fabien >>>> >>>> >>>> >>>> >>>> >>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a = =C3=A9crit : >>>> >>>>> >>>>> >>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>>>> >>>>> Justin >>>>> >>>>> I did note that I was the one that argued for instance_id being in th= e >>>>> object. Since it is in the object in the current draft, not including= a >>>>> pass by reference option would be preferable. >>>>> >>>>> As for concrete examples: >>>>> - version of client >>>>> - version of OS >>>>> - security attestation of OS / device >>>>> - location of client device >>>>> - network client is operating on >>>>> >>>>> These are all attributes of the client that an AS may require on the >>>>> initial grant request, and in future grant requests (which is when an >>>>> instance_id) would be used. >>>>> >>>>> >>>>> This is where our interpretations differ: I don=E2=80=99t see these a= s >>>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the k= ey, display >>>>> information, class identifiers, and other items currently represented= by an >>>>> instance_id are attributes of the client instance. The attestation >>>>> components don=E2=80=99t modify the instance so much as present addit= ional >>>>> information on top of the client instance itself. This is why I argue= that >>>>> they ought to be handled in a separate object, so you=E2=80=99d have = something like >>>>> this strawman: >>>>> >>>>> { >>>>> >>>>> posture: { >>>>> software_version: 1.2.3, >>>>> os_version: 14.3.2 >>>>> device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 } >>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>>> }, >>>>> >>>>> client: =E2=80=9Cclient-541-ab" >>>>> >>>>> } >>>>> >>>>> This is a more fundamental question about GNAP than whether the synta= x >>>>> uses polymorphism: this is about GNAP being very explicit about the d= ata >>>>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad m= odel of what >>>>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply= problematic in >>>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with h= aving to >>>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that do= esn=E2=80=99t fully capture >>>>> the different aspects that are out there. I think we=E2=80=99re getti= ng closer here >>>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D= , but we still need to >>>>> be more precise about what exactly a client instance includes, and wh= at it >>>>> does not. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> /Dick >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer >>>>> wrote: >>>>> >>>>>> Dick, >>>>>> >>>>>> As you=E2=80=99ll recall, I argued against including the client inst= ance >>>>>> identifier inside of the object as a mutually-exclusive field precis= ely >>>>>> because of the principle violation that you are pointing out here, a= nd so >>>>>> it=E2=80=99s important to point out that the current text is a compr= omise that >>>>>> needs to be examined in the wider experience of the working group. I= am on >>>>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2= =80=9D option within an >>>>>> object, but this needs to be explored. >>>>>> >>>>>> The crux of my argument is that is exactly a case of >>>>>> pass-by-reference vs pass-by-value, and that runtime attestations ar= e not >>>>>> part of the =E2=80=9Cclient instance=E2=80=9D value itself but rathe= r belong outside of >>>>>> that object in a another part of the request. As stated in the edito= rial >>>>>> notes in this section, we need to look carefully at how these concep= ts fit >>>>>> within the model and where we would want to put them. Without concre= te >>>>>> examples of what these extensions look like and how they=E2=80=99re = generated, that >>>>>> is nearly impossible to do at this stage. I look forward to seeing e= xamples >>>>>> of this kind of data and how it can fit into the protocol. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote= : >>>>>> >>>>>> Hey Justin, >>>>>> >>>>>> As the draft has evolved, I question the continued use of >>>>>> polymorphism. Note that I appreciate the elegance of using a string = for >>>>>> pass-by-reference, and an object for pass-by-value. >>>>>> >>>>>> In the current draft, the >>>>>> >>>>>> Every time you create or process a field it will mean only one thing= , >>>>>> and there=E2=80=99s only one field to look at to answer a question. >>>>>> >>>>>> >>>>>> is violated in 2.3.1. Identifying the RC Instance >>>>>> >>>>>> >>>>>> >>>>>> instance_id An identifier string that the AS can use to identify >>>>>> the >>>>>> particular instance of this RC. The content and structure of >>>>>> this >>>>>> identifier is opaque to the RC. >>>>>> >>>>>> "client": { >>>>>> "instance_id": "client-541-ab" >>>>>> } >>>>>> >>>>>> If there are no additional fields to send, the RC MAY send the >>>>>> instance identifier as a direct reference value in lieu of the >>>>>> object. >>>>>> >>>>>> "client": "client-541-ab" >>>>>> >>>>>> >>>>>> The instance identifier can be sent two ways. Polymorphism is a >>>>>> convenience for the client, but requires the server to have two code= paths >>>>>> for "instance_id". We discussed this in the design team, and I argu= ed for >>>>>> having "instance_id" in the "client" object so that any updates, suc= h as >>>>>> new devices assertions, could be in the "client" object. As noted ab= ove, >>>>>> while I appreciate the elegance of using a string (handle) to refere= nce a >>>>>> previously provided object, it complicates how to update an existing= object >>>>>> while providing the reference. >>>>>> >>>>>> In your example of the "key" object below, setting "proof" to bearer >>>>>> would avoid the issue you describe: >>>>>> >>>>>> { >>>>>> "key": { >>>>>> "proof": "bearer" >>>>>> } >>>>>> } >>>>>> >>>>>> In your example, when processing the "key" object, code is having to >>>>>> check both the JSON type of the property, as well as check the value= of the >>>>>> "proof" property. In the example I provided, only the value of "proo= f" >>>>>> needs to be checked. The "proof" property is acting as a type for th= e "key" >>>>>> object. >>>>>> >>>>>> Not being a Java programmer, I don't know how this would work in a >>>>>> Java implementation, but node.js, the processing would need to be do= ne as >>>>>> above. >>>>>> >>>>>> On a related note, there was significant negative feedback on handle= s >>>>>> and polymorphism in the Hacker News article >>>>>> https://news.ycombinator.com/item?id=3D24855750 >>>>>> >>>>>> /Dick >>>>>> >>>>>> >>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Hi Mika, >>>>>>> >>>>>>> Thanks for bringing this topic here =E2=80=94 I was able to see the= forum >>>>>>> discussion that brought you here, and hopefully I can help clear up= what I >>>>>>> mean with how polymorphism is used in the proposal. The short versi= on is >>>>>>> that the goal is to *avoid* the kinds of ambiguity that make >>>>>>> insecure protocols, and so in that goal we=E2=80=99re fully aligned= . I think that >>>>>>> using polymorphism in very specific ways can help that goal =E2=80= =94 just as I >>>>>>> agree that misusing it or applying it sloppily can lead to ambiguou= s and >>>>>>> insecure systems. >>>>>>> >>>>>>> Some background: I built out the XYZ protocol (one of the >>>>>>> predecessors to the initial GNAP Draft) in Java using strongly type= d >>>>>>> parsers and Java objects specifically to prove to myself that it co= uld be >>>>>>> done in a way that made any sense in the code. (My own open source >>>>>>> implementation is at https://github.com/bspk/oauth.xyz-java, but >>>>>>> note that it=E2=80=99s not yet up to date with the GNAP spec). It w= as important to >>>>>>> me that I be able to use the system-wide configured parsers to impl= ement >>>>>>> this and not have to resort to stepping through elements completely= by >>>>>>> hand. Java doesn=E2=80=99t make it simple to get the hooks into the= right places >>>>>>> (especially with the Jackson parser that I used), but it is definit= ely >>>>>>> possible to create a deterministic and strongly-typed parser and se= rializer >>>>>>> for this kind of data structure. Some of the rationale for using >>>>>>> polymorphism is covered in the trailing appendix of the draft docum= ent ( >>>>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.ht= ml#name-json-structures-and-polymor), >>>>>>> but it=E2=80=99s still good to discuss this here as the working gro= up decides which >>>>>>> approaches to take. >>>>>>> >>>>>>> The driving reason for using polymorphism at the protocol level was >>>>>>> to simplify the protocol and make it :more: deterministic to create= and >>>>>>> process, not less. Every time you create or process a field it will= mean >>>>>>> only one thing, and there=E2=80=99s only one field to look at to an= swer a question. >>>>>>> Without polymorphic field values, you usually need to rely on mutua= l >>>>>>> exclusivity of fields, which is prone to failure and requires addit= ional >>>>>>> error checking. Take for example the key binding of access tokens. = An >>>>>>> access token could be bound to the RC=E2=80=99s key used during the= request, to a >>>>>>> different key chosen by the AS, or it could be a bearer token with = no key >>>>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we c= an define it in terms of >>>>>>> boolean values and objects and express this set of mutually-exclusi= ve >>>>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need to= have different >>>>>>> fields for the options and include additional checks in your parser= to make >>>>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with >>>>>>> this potential security vulnerability in an object: >>>>>>> >>>>>>> { >>>>>>> key: { >>>>>>> proof: httpsig, >>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>> }, >>>>>>> bearer_token: true, >>>>>>> bind_to_rc_key: true >>>>>>> } >>>>>>> >>>>>>> This would be an illegal object as per this alternate proposal, but >>>>>>> then you=E2=80=99d have to check each field and make sure it wasn= =E2=80=99t put next to >>>>>>> others in the same object. I=E2=80=99ve done this exercise with man= y other >>>>>>> protocols and it=E2=80=99s both error prone and easy to ignore sinc= e all the =E2=80=9Cgood=E2=80=9D >>>>>>> examples would pass code that doesn=E2=80=99t check this. With the = polymorphic >>>>>>> approach to this same field, each of these three mutually-exclusive= states >>>>>>> is written in a way that they cannot be sent together. It=E2=80=99s= not just >>>>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSON= itself. >>>>>>> >>>>>>> { >>>>>>> key: { >>>>>>> proof: httpsig, >>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> // bearer token >>>>>>> >>>>>>> { >>>>>>> key: false >>>>>>> } >>>>>>> >>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>> >>>>>>> { >>>>>>> key: true >>>>>>> } >>>>>>> >>>>>>> If someone sends a different type for this field, like an array or >>>>>>> number or a null, this doesn=E2=80=99t have a defined interpretatio= n in the >>>>>>> protocol and would be a protocol level error. >>>>>>> >>>>>>> While it might sound like polymorphism means that any field could >>>>>>> have any type or value, the opposite is true: each possible value i= s >>>>>>> explicitly typed, it=E2=80=99s just that there are potentially diff= erent types that >>>>>>> express meaning for the field. This applies to all members of all o= bjects >>>>>>> (dictionaries) as well as all members of an array (list). Every tim= e you >>>>>>> process a field value or other element, you look at the type and th= en the >>>>>>> value to determine what to do with that typed value. >>>>>>> >>>>>>> In your example below, each field within the dictionary would also >>>>>>> need to be typed, and each type would need to have a clear indicati= on of >>>>>>> its meaning. To take your strawman key format below, the =E2=80=9Cm= odulus=E2=80=9D field >>>>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an >>>>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition wo= uld further say what >>>>>>> exactly the encoding of the string would be. That means that when y= ou read >>>>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any c= onfusion on what the value was >>>>>>> or how it was represented, regardless of the input format. Seeing a= number >>>>>>> there means exactly one interpretation and seeing a string means ex= actly >>>>>>> one (different) interpretation =E2=80=94 but importantly, both of t= hem are a >>>>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that dete= rmines the type. An >>>>>>> implementation would likely use an internal BigInteger type of obje= ct to >>>>>>> represent the field value after parsing, so the question is how to = go from >>>>>>> the JSON value (which is typed) into the BigInteger value.You don= =E2=80=99t just >>>>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you= apply it to all >>>>>>> sub-fields of that object. >>>>>>> >>>>>>> So let=E2=80=99s dig into the specific bug you bring up in the stra= wman, >>>>>>> because it=E2=80=99s interesting: A JSON encoder that encodes numbe= rs as strings, >>>>>>> and not numbers, is not compliant with the JSON definitions of the = field in >>>>>>> question. For another example, the quoted string value of =E2=80=9C= true=E2=80=9D is not >>>>>>> equivalent to the boolean value true in JSON, and they shouldn=E2= =80=99t be treated >>>>>>> the same by a parser implementation when mapping to a concrete obje= ct. It=E2=80=99s >>>>>>> in this kind of automated guessing that this class of bugs occur, a= nd >>>>>>> that=E2=80=99s going to be the case whether or not you take advant= age of JSON=E2=80=99s >>>>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser libr= ary was trying >>>>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mappin= g, but ended up >>>>>>> introducing errors in more strict components downstream. This is so= mething >>>>>>> that protocol designers need to be aware of and guard against in th= e design >>>>>>> of the protocol to reduce possible ambiguities. Within GNAP today, = we >>>>>>> generally have things that branch whether they=E2=80=99re an object= (for a rich >>>>>>> description of something) or some non-structured special value (for= a >>>>>>> reference or other item). >>>>>>> >>>>>>> The design team created some simple JSON Schemas for parts of the >>>>>>> protocol during our discussion, but we didn=E2=80=99t include them = in the design >>>>>>> document due to both lack of time to keep it updated with the rapid= changes >>>>>>> to the protocol during the design team discussion, and not knowing = if there >>>>>>> would be interest in such material. I personally think it would be = helpful >>>>>>> to include as an informative reference in the final document, but t= hat=E2=80=99s >>>>>>> something for the working group to take up eventually. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> Hello, everyone. >>>>>>> >>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion foru= m >>>>>>> and when I made note about certain concerns, I was requested to sen= d my >>>>>>> comments to this working group. >>>>>>> >>>>>>> In short, I believe that the use of polymorphic JSON in the protoco= l >>>>>>> invites subtle and confusing implementation problems. I also search= ed >>>>>>> through the WG archives, and noticed that similar concerns were not= ed, >>>>>>> briefly, in a thread in July. >>>>>>> >>>>>>> The problem with polymorphic values, as I see it, is that >>>>>>> implementations will need to branch on the (inferred) type of a giv= en >>>>>>> field. This isn't quite as bad if the types are strictly different,= but >>>>>>> allows for subtle bugs when the value in question is a dictionary. = What >>>>>>> makes this unappealing is that "subtle bugs" in security protocols = have a >>>>>>> habit of turning into vulnerabilities. >>>>>>> >>>>>>> Let's say we have these imaginary payloads, both possible and valid >>>>>>> in the same protocol step: >>>>>>> >>>>>>> # payload 1 >>>>>>> { >>>>>>> ..., >>>>>>> "public_key": { >>>>>>> "alg": "rsa", >>>>>>> "modulus": >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> # payload 2 >>>>>>> { >>>>>>> ..., >>>>>>> "public_key": { >>>>>>> "alg": "rsa", >>>>>>> "modulus": "" >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> In both cases, the type of "public_key" field is a dictionary. In >>>>>>> both cases, they even have the same keys. However, the values in th= e >>>>>>> dictionaries are entirely different, and an implementation will hav= e to >>>>>>> branch to at least two possible decoding mechanisms. To make things= worse, >>>>>>> some JSON implementations may choose to encode non-dictionary value= s as >>>>>>> strings, so it is possible for an originator to transmit what they = expect >>>>>>> and believe to be payload 1 format, but which the receiver will int= erpret >>>>>>> to be in payload 2 format. And if the encoded string contains only = digits, >>>>>>> it will even parse correctly as a bignum. >>>>>>> >>>>>>> While the above is clearly a manufactured scenario, it nonetheless >>>>>>> demonstrates the potential for logic bugs with polymorphic JSON. Wi= th >>>>>>> richer types and more complex dictionaries, there will surely be mo= re room >>>>>>> for errors. >>>>>>> >>>>>>> Ambiguity in protocols is always a source of implementation >>>>>>> complexity and interoperability snags, but in an AuthN/AuthZ protoc= ol it is >>>>>>> worse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oau= th1/2, >>>>>>> wouldn't it be in everyone's interest to keep implementation comple= xity and >>>>>>> mistake potential to a minimum? >>>>>>> >>>>>>> Best regards, >>>>>>> Mika >>>>>>> >>>>>>> -- >>>>>>> Mika Bostr=C3=B6m >>>>>>> Smarkets >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --00000000000000584b05b28796dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Fabien

    A library developer can provi= de whatever abstraction layer makes sense for the library's target=C2= =A0audience and language.

    If the client library=C2= =A0developer wants to use polymorphism=C2=A0in the interface presented to t= he user's of the library, the library developer can do that independent= of polymorphism in the protocol, and vice versa=C2=A0

    =
    =3D> polymorphism in the protocol has no impact on client library d= evelopers


    3D""=E1=90=A7

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I'm just= realizing your "least to most important" might actually say the = same as what I was trying to say. So I'm not even sure what we're a= rguing against :-)=C2=A0

    In br= ief my point if it wasn't clear is that we should be crystal clear on w= here we put the cursor of simplicity, because this can mean different thing= s for different people and different roles.=C2=A0
    An= d as we see on HN we need to better explain our design choices.=C2=A0
    =


    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imb= ault <fabi= en.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Dick,

    Independantly from the debate on polyphormism= , I beg to differ on your order preference.=C2=A0
    Your assumption is that AS devs matter the most,<= span style=3D"font-family:sans-serif">=C2=A0because they're doing the i= mportant security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spe= c are unable to deal with the complexity that is passed onto them.=C2=A0

    99% of the people t= hat will actually use the output of the work are application developers (cl= ient or RS) and their own users.=C2=A0

    Our intent as well as= the protocol drive the usage. Client libraries may help, but they're n= ot a silver bullet, especially because GNAP ultimately has no control about= what people do there (for better or worse). And everything we do here will= help get to the better part.=C2=A0

    I'm not saying we don't intend to also care abou= t AS developers (beginning with ourselves) but it's a second order opti= misation. And since it's a tendancy we're leaning towards by defaul= t, I'm pretty sure we won't forget that anyway.=C2=A0

    Fabien=C2=A0
    <= div dir=3D"auto">


    <= div class=3D"gmail_quote" dir=3D"auto">
    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com<= /a>> a =C3=A9crit=C2=A0:
    I'm confused by your logic Fabien.
    If a client library developer wants to expose polymorphism, the= y can do that independent of what is in the protocol.=C2=A0

    <= /div>
    I differ on who our stakeholders are.=C2=A0

    <= div>I think our stakeholders are in least to most important:

    =
    • AS developer
    • RS developer
    • client develop= er
    • user

    A client library develop= er can expose whatever interface they want to simplify implementation.

    I list the user so that we don't lose site of a cr= itical role.

    /Dick


    =3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 6:27 PM F= abien Imbault <fabien.imbault@gmail.com> wrote:<= br>
    Hi there,=C2=A0

    Let me= try to approach the issue under a different light. More like a product man= ager would deal with feature selection to make it intuitive for its users.= =C2=A0

    For m= ost people, riding a bike is far easier than using a unicycle. Feels more s= table. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chai= n ring, etc.). Even so producing a bike doesn't have to be a brittle pr= ocess, it can be industrialized.=C2=A0

    Back to the GNAP topic.=C2=A0
    Ultimately we should strive to make the spec = as simple as can be. But we need to ask: simple for whom? For the bike owne= r or for the bike vendor?=C2=A0
    (short answer: the priority should be simplic= ity for spec users, not spec implementers and even less spec designers).=C2= =A0
    The initial question that is asked is very= interesting: isn't the design flawed if GNAP is using json polyphormis= m? Or if the AS needs to handle the state of the request? Or if we must han= dle token revocation? Or if we are looking for a global unique identifier? = The argument stems of the fact that is still arguably harder and more error= prone to implement. Fair enough.=C2=A0

    From a spec implementer's perspective, it may well be m= ore complex. It mostly impacts the json library you'll end up using, pl= us a bit of input/output decoration around it. Even golang provides utiliti= es for this, despite not exactly being made for this kind of purpose.
    =
    My practical experience implementing it is that it's = not that big a deal. I mean, I wished it could be simpler, but it's man= ageable and there are other ways to reach levels of insurance that it does = work as intended (json schema, test cases to validate the implementation, e= tc.). Arguably it is still easier from an implementation perspective than s= ay, json-ld, which is massively used in the SSI community.=C2=A0

    But ultimately who are we designin= g for? Are we striving to go easy on the spec implementer? Or are we trying= to make sure end-developers using the client libraries won't shoot the= mselves in the foot?

    The= job to be done (JTBD), from the end-developer's perspective, is to eff= iciently ship an application. And provide authN/authZ capabilities for end-= users by relying on some well known implementation.=C2=A0
    In turn, this spec implementer will rely on cryptographic utility lib= raries that deals internally with the complexity of their own domain, so th= at we don't have to. And here we could launch another HN flame war that= starts with the title "JWT sucks because". Which does have its s= et of very real issues but that's beyond the point.=C2=A0
    Note that any decent flamewar will be efficiently fueled by peopl= e hating medium. Is it outrageous for blog posts to be behind a paywall? Ma= ybe but it's even more outrageous to lack consistency, either by not kn= owing how to get around a paywall if you're into a hacker punk movement= , or on the contrary by to not paying a subscription if you believe that su= rveillance capitalism, to reuse Zuboff's terms, should be eradicated.= =C2=A0
    What likely seems an unnecessary sidenote tri= es to illustrate the point: for Justin it was easier to publish on medium, = because as a blog publisher, you might not want to deal with hosting your o= wn blog. But maybe as a reader you'll find that annoying. Different aud= iences, different JTBD, different tradeoffs.=C2=A0
    <= br>
    Polyphormism is a tool that enables the end-deve= loper to have minimal knowledge of what it means to deal with a GNAP client= library. You prepare the request, send to the endpoint and you're good= to go. Massively simpler than OAuth2 or any similar protocol by the way (a= s anyone with teaching experience on the subject might acknowledge). And=C2= =A0 there's a lot more to be done to make sure we indeed reduce the com= plexity for the end-developer and the end-user.=C2=A0

    If we find a better way to deal with that sim= plicity balance, I'm all in. But the arguments need to be way more conv= incing than just saying that it may be difficult to implement or validate.= =C2=A0

    Cheers.
    Fabien



    =

    = Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <= ;dick.h= ardt@gmail.com> wrote:

    Justin
    I did note that I was the one that argued for instance_id being= in the object. Since it is in the object in the current draft, not includi= ng a pass by reference option would be preferable.=C2=A0

    As for concrete examples:
    - version of client
    - = version of OS
    - security attestation of OS / device
    - l= ocation of client device
    - network client is operating on

    These are all attributes of the client that an AS may req= uire=C2=A0on the initial grant request, and in future grant requests (which= is when an instance_id) would be used.


    This is where our interpretations differ: I d= on=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in the= same way that the key, display information, class identifiers, and other i= tems currently represented by an instance_id are attributes of the client i= nstance. The attestation components don=E2=80=99t modify the instance so mu= ch as present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, so = you=E2=80=99d have something like this strawman:

    {=

    =C2=A0 posture: {
    =C2=A0 =C2=A0 softwar= e_version: 1.2.3,
    =C2=A0 =C2=A0 os_version: 14.3.2
    =C2= =A0 =C2=A0 device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 }
    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80= =A6, alt: =E2=80=A6 }
    =C2=A0 },

    =C2=A0 c= lient: =E2=80=9Cclient-541-ab"

    }
    This is a more fundamental question about GNAP than whether th= e syntax uses polymorphism: this is about GNAP being very explicit about th= e data model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, i= s deeply problematic in practice. We=E2=80=99re even seeing that in the OAu= th 2.1 work with having to define a =E2=80=9Ccredentialed client=E2=80=9D, = and even then that doesn=E2=80=99t fully capture the different aspects that= are out there. I think we=E2=80=99re getting closer here in GNAP with expl= icit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to = be more precise about what exactly a client instance includes, and what it = does not.

    =C2=A0=E2=80=94 Justin


    /Dick

    =E1=90=A7

    On Fri, Oct 23, 2020 at 12:= 42 PM Justin Richer <jricher@mit.edu> wrote:
    Dick,

    As you=E2=80=99ll = recall, I argued against including the client instance identifier inside of= the object as a mutually-exclusive field precisely because of the principl= e violation that you are pointing out here, and so it=E2=80=99s important t= o point out that the current text is a compromise that needs to be examined= in the wider experience of the working group. I am on the side of removing= the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an obje= ct, but this needs to be explored.

    The crux of my = argument is that is exactly a case of pass-by-reference vs pass-by-value, a= nd that runtime attestations are not part of the =E2=80=9Cclient instance= =E2=80=9D value itself but rather belong outside of that object in a anothe= r part of the request. As stated in the editorial notes in this section, we= need to look carefully at how these concepts fit within the model and wher= e we would want to put them. Without concrete examples of what these extens= ions look like and how they=E2=80=99re generated, that is nearly impossible= to do at this stage. I look forward to seeing examples of this kind of dat= a and how it can fit into the protocol.

    =C2=A0=E2= =80=94 Justin

    On Oct 23, = 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin,

    As th= e draft has evolved, I question the continued use of polymorphism. Note tha= t I appreciate the elegance=C2=A0of using a string for pass-by-reference, a= nd an object for pass-by-value.

    In the current dra= ft, the=C2=A0

    Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look at = to answer a question.=C2=A0



    =C2=A0 =C2=A0instance_id= =C2=A0An identifier string that the AS can use to identify the
    = =C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2=A0 The content and = structure of this
    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to th= e RC.

    =C2=A0 =C2=A0"client": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541-ab&qu= ot;
    =C2=A0 =C2=A0}

    =C2=A0 =C2=A0If there= are no additional fields to send, the RC MAY send the
    =C2=A0 =C2= =A0instance identifier as a direct reference value in lieu of the
    =C2=A0 =C2=A0object.

    =C2=A0 =C2=A0"client&qu= ot;: "client-541-ab"

    The in= stance identifier can be sent two ways. Polymorphism is a convenience for t= he client, but requires the server=C2=A0to have two code=C2=A0paths for &qu= ot;instance_id".=C2=A0 We discussed this in the design team, and I arg= ued for having "instance_id" in the "client" object=C2= =A0so that any updates, such as new devices assertions, could be in the &qu= ot;client" object. As noted above, while I appreciate the elegance of = using a string (handle) to reference a previously provided object, it compl= icates how to update an existing object while providing the reference.

    In your example of the "key" object below, s= etting "proof" to bearer would avoid the issue you describe:

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 = =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2=A0 }
    = }

    In your example, when processing the "k= ey" object, code is having to check both the JSON type of the property= , as well as check the value of the "proof" property. In the exam= ple I provided, only the value of "proof" needs to be checked. Th= e "proof" property is acting as a type for the "key" ob= ject.

    Not being a Java programmer, I don't kno= w how this would work in a Java implementation, but node.js, the processing= would need to be done as above.

    On a related note= , there was significant negative feedback on handles and polymorphism in th= e Hacker News article=C2=A0https://news.ycombinator.com/item?= id=3D24855750=C2=A0

    /Dick

    =

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> w= rote:
    Hi Mi= ka,

    Thanks for bringing this topic here =E2=80=94 I was = able to see the forum discussion that brought you here, and hopefully I can= help clear up what I mean with how polymorphism is used in the proposal. T= he short version is that the goal is to=C2=A0avoid=C2=A0the kinds of= ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can he= lp that goal =E2=80=94 just as I agree that misusing it or applying it slop= pily can lead to ambiguous and insecure systems.

    S= ome background: I built out the XYZ protocol (one of the predecessors to th= e initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made a= ny sense in the code. (My own open source implementation is at=C2=A0htt= ps://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet= up to date with the GNAP spec). It was important to me that I be able to u= se the system-wide configured parsers to implement this and not have to res= ort to stepping through elements completely by hand. Java doesn=E2=80=99t m= ake it simple to get the hooks into the right places (especially with the J= ackson parser that I used), but it is definitely possible to create a deter= ministic and strongly-typed parser and serializer for this kind of data str= ucture. Some of the rationale for using polymorphism is covered in the trai= ling appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gn= ap-core-protocol-00.html#name-json-structures-and-polymor), but it=E2= =80=99s still good to discuss this here as the working group decides which = approaches to take.=C2=A0

    The driving reason for u= sing polymorphism at the protocol level was to simplify the protocol and ma= ke it :more: deterministic to create and process, not less. Every time you = create or process a field it will mean only one thing, and there=E2=80=99s = only one field to look at to answer a question. Without polymorphic field v= alues, you usually need to rely on mutual exclusivity of fields, which is p= rone to failure and requires additional error checking. Take for example th= e key binding of access tokens. An access token could be bound to the RC=E2= =80=99s key used during the request, to a different key chosen by the AS, o= r it could be a bearer token with no key at all. By making the =E2=80=9Ckey= =E2=80=9D field polymorphic, we can define it in terms of boolean values an= d objects and express this set of mutually-exclusive options in a non-ambig= uous way. Without that, you=E2=80=99d need to have different fields for the= options and include additional checks in your parser to make sure they wer= en=E2=80=99t sent simultaneously, otherwise you could get hit with this pot= ential security vulnerability in an object:

    {=C2= =A0
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: ht= tpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 = }
    =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 bearer_token: true,
    =C2=A0 =C2=A0 bind_to_rc_key: true
    }

    =
    This would be an illegal object as per this alternate proposal, but th= en you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t p= ut next to others in the same object. I=E2=80=99ve done this exercise with = many other protocols and it=E2=80=99s both error prone and easy to ignore s= ince all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2= =80=99t check this. With the polymorphic approach to this same field, each = of these three mutually-exclusive states is written in a way that they cann= ot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible= and enforced by the syntax of JSON itself.

    {= =C2=A0
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof:= httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80= =A6 }
    =C2=A0 =C2=A0 }
    }

    // bea= rer token

    {
    =C2=A0 =C2=A0 key: false
    }

    // bound to the RC=E2=80=99s presen= ted key

    {
    =C2=A0 =C2=A0 key: true
    <= div>}

    If someone sends a different type for this f= ield, like an array or number or a null, this doesn=E2=80=99t have a define= d interpretation in the protocol and would be a protocol level error.
    =

    While it might sound like polymorphism means that any f= ield could have any type or value, the opposite is true: each possible valu= e is explicitly typed, it=E2=80=99s just that there are potentially differe= nt types that express meaning for the field. This applies to all members of= all objects (dictionaries) as well as all members of an array (list). Ever= y time you process a field value or other element, you look at the type and= then the value to determine what to do with that typed value.
    In your example below, each field within the dictionary would = also need to be typed, and each type would need to have a clear indication = of its meaning. To take your strawman key format below, the =E2=80=9Cmodulu= s=E2=80=9D field could be defined polymorphically as either a =E2=80=9Cbigi= nt=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of the = string would be. That means that when you read the =E2=80=9Cmodulus=E2=80= =9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number the= re means exactly one interpretation and seeing a string means exactly one (= different) interpretation =E2=80=94 but importantly, both of them are a =E2= =80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines the = type. An implementation would likely use an internal BigInteger type of obj= ect to represent the field value after parsing, so the question is how to g= o from the JSON value (which is typed) into the BigInteger value.You don=E2= =80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field= , you apply it to all sub-fields of that object.=C2=A0

    =
    So let=E2=80=99s dig into the specific bug you bring up in the strawma= n, because it=E2=80=99s interesting: A JSON encoder that encodes numbers as= strings, and not numbers, is not compliant with the JSON definitions of th= e field in question. For another example, the quoted string value of =E2=80= =9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON, and t= hey shouldn=E2=80=99t be treated the same by a parser implementation when m= apping to a concrete object. It=E2=80=99s in this kind of automated guessin= g that this class of bugs occur, and that=E2=80=99s going to be the case wh= ether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic nature.= I=E2=80=99ve run into cases where a parser library was trying to be overly= =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up intr= oducing errors in more strict components downstream. This is something that= protocol designers need to be aware of and guard against in the design of = the protocol to reduce possible ambiguities. Within GNAP today, we generall= y have things that branch whether they=E2=80=99re an object (for a rich des= cription of something) or some non-structured special value (for a referenc= e or other item).=C2=A0

    The design team created so= me simple JSON Schemas for parts of the protocol during our discussion, but= we didn=E2=80=99t include them in the design document due to both lack of = time to keep it updated with the rapid changes to the protocol during the d= esign team discussion, and not knowing if there would be interest in such m= aterial. I personally think it would be helpful to include as an informativ= e reference in the final document, but that=E2=80=99s something for the wor= king group to take up eventually.

    =C2=A0=E2=80=94 = Justin

    On Oct 23, 2020, at 10:= 18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com= @dmarc.ietf.org> wrote:

    Hello, e= veryone.

    For background: GNAP/TxAuth/XYZ/Oauth3 ca= me up on a discussion forum and when I made note about certain concerns, I = was requested to send my comments to this working group.

    =
    In short, I believe that the use of polymorphic JSON in the prot= ocol invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, brie= fly, in a thread in July.

    The problem with po= lymorphic values, as I see it, is that implementations will need to branch = on the (inferred) type of a given field. This isn't quite as bad if the= types are strictly different, but allows for subtle bugs when the value in= question is a dictionary. What makes this unappealing is that "subtle= bugs" in security protocols have a habit of turning into vulnerabilit= ies.

    Let's say we have these imaginary payload= s, both possible and valid in the same protocol step:

    <= div># payload 1
    {
    =C2=A0 ...,
    =C2=A0 "pu= blic_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "rsa&q= uot;,
    =C2=A0=C2=A0=C2=A0 "modulus": <BIGINT><= /div>
    =C2=A0 }
    }

    # payload 2
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    =C2=A0= =C2=A0=C2=A0 "modulus": "<encoded string>"
    <= div>=C2=A0 }
    }

    In both cases, the type o= f "public_key" field is a dictionary. In both cases, they even ha= ve the same keys. However, the values in the dictionaries are entirely diff= erent, and an implementation will have to branch to at least two possible d= ecoding mechanisms. To make things worse, some JSON implementations may cho= ose to encode non-dictionary values as strings, so it is possible for an or= iginator to transmit what they expect and believe to be payload 1 format, b= ut which the receiver will interpret to be in payload 2 format. And if the = encoded string contains only digits, it will even parse correctly as a bign= um.

    While the above is clearly a manufactured = scenario, it nonetheless demonstrates the potential for logic bugs with pol= ymorphic JSON. With richer types and more complex dictionaries, there will = surely be more room for errors.

    Ambiguity in proto= cols is always a source of implementation complexity and interoperability s= nags, but in an AuthN/AuthZ protocol it is worse: it's terrifying. If G= NAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in everyon= e's interest to keep implementation complexity and mistake potential to= a minimum?

    Best regards,
    Mika

    --
    =
    Mika Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mai= lman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth
    3D""=E1=90=A7


    --
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/txauth
    --00000000000000584b05b28796dc-- From nobody Sun Oct 25 17:05:02 2020 Return-Path: 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 0F76A3A16F2 for ; Sun, 25 Oct 2020 17:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 3G69B_h5zx6u for ; Sun, 25 Oct 2020 17:04:55 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 AC2073A115E for ; Sun, 25 Oct 2020 17:04:54 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id 184so9591236lfd.6 for ; Sun, 25 Oct 2020 17:04:54 -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=oJgvtbLmNMvTN130Q87n63y/9y8ZTT2kwoizRYNvlUg=; b=P0nTzPV4JpCYu+j1rjPvQ2gwl4fhSyUtH1ig6vvjo0Bv+QkLm1WbldQLRdaiTF+6Fz nWztJ6eea6GJveoh5QvGegkkSyrX1cvdNiTm4XEDIF1MMW2t3sK+39jGixr+3wq0L600 PaCGqG0tlPZFQ7MfLrsvZSBeq7cYDbmr9HzTTlPJXNOeFjjXp12CcRDhzp+L/yLheMN3 Qx3NwmrKBauT4koMVeiJjBC+77cqvzKL6WZmKjcFfWGpQPhm7XQce5ilam/ekNxZ44sP iJI6cnwHwMrUaZTd58mkIlvtn29ompP8s7PnCaic3hqTLqbs/JynAGTDwYUQqEirw8TY SE0g== 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=oJgvtbLmNMvTN130Q87n63y/9y8ZTT2kwoizRYNvlUg=; b=XsS/RDyeakpn9w9aEL1ouA9LK3JirkKf84pP6DyHTfeW3nD6YG+1wxTHbxe8NTbPdC Z3xBbonYrM6s9/NK+IvuK3kgYooGU264EpQBy22fVyRi1bD+F6Gv1h+hpmrCbFTV5OiV ZQPylLGKIgBR/At1D0xqgVKGomNmDHlGhNMT0bPoWxrdHB6iZlv7QN8TE/Cd9i2LL5UP mZ3mqF2KusxMe6vqB7mhkKcK4XyH3hd6k2TCVMMNm7WDakhUK9CLh6L5Ofkb82E4JZYX QhIk6HA7pPoBMpJK5MuKkHHXWqf1dqP9LzqQ4lH6QKkNrWzKeWwOPULhGUv3MeK2vrto LGMg== X-Gm-Message-State: AOAM5305HiWLdnJWTsyA7421G3LWNje2zu/5hA4JC1QH3XVbAaPISPG7 GOXQ5VfNVWtJtvKD4sfPk9K7x07t8ALrOMdNwZs= X-Google-Smtp-Source: ABdhPJwVMcc6EOepzXOMZA09BhUNhhC9PTJU3psw7q2UJTfGHLnw9hR9FIE5q27MuFpo0RWGnMjdmJYGPhgZdyLzsjA= X-Received: by 2002:a19:c70f:: with SMTP id x15mr3878726lff.296.1603670692376; Sun, 25 Oct 2020 17:04:52 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <068A8288-6894-4320-B1C0-56DB9A38D714@gmail.com> <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> In-Reply-To: <19D50064-2EB8-40EF-9921-E59C7260E164@mit.edu> From: Dick Hardt Date: Sun, 25 Oct 2020 17:04:16 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Yaron Sheffer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f4b4bb05b287ad27" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 00:05:01 -0000 --000000000000f4b4bb05b287ad27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I want to point out that JSON schema can enforce mutually exclusive properties. For example the "client" object containing once of "instance_id", "class_id", or "display" =E1=90=A7 On Sun, Oct 25, 2020 at 9:33 AM Justin Richer wrote: > I agree fully with Fabien=E2=80=99s statements on who we=E2=80=99re makin= g things easy > for. If this security protocol isn=E2=80=99t easy and straightforward for= client > developers =E2=80=94 with or without a library =E2=80=94 then it simply w= ill not be > adopted. It might be hard to see when looking at the whole protocol, but > this goal is actually one of the drivers for the way polymorphism is used > in the current draft. The driving philosophy of OpenID Connect=E2=80=99s > development was =E2=80=9Ckeep the simple things simple, make the complex = things > possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly believe we = need to continue > here in GNAP. > > Importantly, a client developer shouldn=E2=80=99t need to have to support= all > possible permutations in order to get something right. OAuth has shown us > that even when a protocol has a lot of options, client software is going = to > be coded to use only one set of options. If the protocol can support that > reality, I think we are doing well. In the current draft, generally > speaking it=E2=80=99s the AS that needs to handle different options, not = the > client. Take for example requesting resources: a very simple client might > just send an array of strings, like OAuth scopes. The AS needs to be able > to handle the string inputs as well as the rich object descriptors, but t= he > client software doesn=E2=80=99t even need to know that the object format = exists in > order to create compliant JSON. The client developer can do this without > any special libraries, it can just bang out the JSON directly. Such a > client won=E2=80=99t be able to do the more fancy stuff that the request = objects > allow, but for this client, that=E2=80=99s fine since all it needs to do = is produce > an array with strings that the AS will accept. The same is true across th= e > various other options, like requesting multiple access tokens vs a single > one, or providing an instance identifier vs. a set of information for the > client instance itself. Client developers should be fully able to ignore > parts of the protocol that they aren=E2=80=99t using, especially the more= advanced > stuff. An AS shouldn=E2=80=99t get to have such a choice, but as the AS i= s the > lynchpin of the security model, I am OK with things being slightly more > complex to support, especially if it shifts that complexity away from > clients. > > I am in favor of including JSON Schema in the draft in a non-normative > way, and you can see an earlier version of that experiment that Fabien an= d > I undertook as part of the Design Team. The schema will be available for > developers who want to / can use it, but even for people who aren=E2=80= =99t using > the schema directly it can provide additional context and information. I = am > willing to put some cycles into creating schemas for the main request and > response messages and put those into a pull request to create an appendix > in the draft. I=E2=80=99d also be fine with a non-normative JSON-LD refer= ence for > LD processors =E2=80=94 but (1) I=E2=80=99m not going to write that :) an= d (2) it can=E2=80=99t be > required for the protocol to be understood. > > =E2=80=94 Justin > > On Oct 25, 2020, at 8:47 AM, Fabien Imbault > wrote: > > Hi Yaron, > > As Justin explained that's the kind of idea we tested. For instance > https://github.com/fimbault/test_gnap_schema (in rust). > > Cheers > Fabien > > Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer = a > =C3=A9crit : > >> Personally, I would support polymorphism in the protocol if it (the RFC) >> came with a well-defined JSON Schema [1] document, so a recipient can >> automatically validate incoming messages at run-time. I would expect >> senders to also validate messages as part of their testing. It=E2=80=99s= not an >> ideal solution, because: >> >> >> >> - Some people at the IETF don=E2=80=99t like JSON Schema, for various= reasons. >> - JSON Schema is not a standard, so it=E2=80=99s painful to require i= t >> normatively. >> - Even if it=E2=80=99s normative, some recipients will not validate m= essages >> anyway. >> >> >> >> This would be shifting some of the complexity from the library developer >> to the spec developer, which is the right thing to do IMO. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> [1] https://json-schema.org/ >> >> >> >> >> >> *From: *Fabien Imbault >> *Date: *Sunday, October 25, 2020 at 12:39 >> *To: *Yaron Sheffer >> *Cc: *Dick Hardt , Mika Bostr=C3=B6m > 40smarkets.com@dmarc.ietf.org>, GNAP Mailing List , >> Justin Richer >> *Subject: *Re: [GNAP] Feedback on polymorphism >> >> >> >> Hi Yaron, >> >> >> >> Thanks for the feedback. >> >> >> >> Regarding client libraries, I think we can indeed learn a great deal fro= m >> cryptographic libraries. Cryptographic design provides a great amount of >> flexibility for the specialists (including many parameters that you real= ly >> need to get right). We might think this is great to provide options but = it >> actually increases the cognitive load of library users. >> >> >> >> Look instead at what Google has provided with tink as an alternative and >> you'll see it is a much easier way for cryptographic engineers (who aren= 't >> cryptographers) to avoid mistakes or misuses. >> >> >> >> That's the *security* issue I'm referring to (not the fact that being >> open they're tasty targets, although that may be related in some cases). >> And tink is the kind of design we should be trying to achieve. >> >> >> >> I agree that it should be applicable to a wide range of well known >> programming tools, including the likes of java and go. >> >> But I don't really see a limitation here. Might not be the most idiomati= c >> feel, but it can be made to work. >> >> >> >> Just so I understand, what alternatives would you prefer to polymorphism= ? >> I can suggest json-ld but even Justin will Teel you it's even more compl= ex >> :-) >> >> >> >> Cheers >> >> Fabien >> >> >> >> Le dim. 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer = a >> =C3=A9crit : >> >> Hi Fabien, >> >> >> >> I think your product management model has a lot of merit, but it does no= t >> capture the security issue well. >> >> >> >> I agree that as we look at different customer personas, the =E2=80=9Cend= user=E2=80=9D >> (the developer that=E2=80=99s using the libraries) should be our highest= priority. >> But I disagree about end-user mistakes being the top **security** issue. >> Libraries are often open source in our space and used very widely. So th= ey >> make for tasty targets, and people are attacking them and are still find= ing >> security issues in libraries that we=E2=80=99ve been talking about forev= er [1]. >> >> >> >> (Yes, my example is actually an app flaw, but I think it could have been >> prevented by a better designed library.) >> >> >> >> In other words, we do need to care about how easy it is to implement the >> protocol correctly by **library** developers. From Justin describing his >> own experience and other people on the thread that Dick referred to, I >> would say that JSON polymorphism is painful for Java and Go developers. >> With all due respect, I care about them much more than I care about >> Haskell, as many more implementations are likely to use these languages. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> [1] >> https://www.zofrex.com/blog/2020/10/20/alg-none-jwt-nhs-contact-tracing-= app/ >> >> >> >> *From: *TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Date: *Sunday, October 25, 2020 at 01:25 >> *To: *Dick Hardt >> *Cc: *Mika Bostr=C3=B6m , = GNAP >> Mailing List , Justin Richer >> *Subject: *Re: [GNAP] Feedback on polymorphism >> >> >> >> Hi Dick, >> >> >> >> Independantly from the debate on polyphormism, I beg to differ on your >> order preference. >> >> >> >> Your assumption is that AS devs matter the most, because they're doing >> the important security implementation. But eating our own dogfood might >> help a lot to change that view. Most security issues occur because users= of >> the spec are unable to deal with the complexity that is passed onto them= . >> >> >> >> 99% of the people that will actually use the output of the work are >> application developers (client or RS) and their own users. >> >> >> >> Our intent as well as the protocol drive the usage. Client libraries may >> help, but they're not a silver bullet, especially because GNAP ultimatel= y >> has no control about what people do there (for better or worse). And >> everything we do here will help get to the better part. >> >> >> >> I'm not saying we don't intend to also care about AS developers >> (beginning with ourselves) but it's a second order optimisation. And sin= ce >> it's a tendancy we're leaning towards by default, I'm pretty sure we won= 't >> forget that anyway. >> >> >> >> Fabien >> >> >> >> >> >> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : >> >> I'm confused by your logic Fabien. >> >> >> >> If a client library developer wants to expose polymorphism, they can do >> that independent of what is in the protocol. >> >> >> >> I differ on who our stakeholders are. >> >> >> >> I think our stakeholders are in least to most important: >> >> >> >> - AS developer >> - RS developer >> - client developer >> - user >> >> >> >> A client library developer can expose whatever interface they want to >> simplify implementation. >> >> >> >> I list the user so that we don't lose site of a critical role. >> >> >> >> /Dick >> >> >> >> >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >> wrote: >> >> Hi there, >> >> >> >> Let me try to approach the issue under a different light. More like a >> product manager would deal with feature selection to make it intuitive f= or >> its users. >> >> >> >> For most people, riding a bike is far easier than using a unicycle. Feel= s >> more stable. And yet it's way easier to design for a single wheel than t= o >> build with 2. Because then you'll need a lot more accessories (chain, ch= ain >> ring, etc.). Even so producing a bike doesn't have to be a brittle proce= ss, >> it can be industrialized. >> >> >> >> Back to the GNAP topic. >> >> Ultimately we should strive to make the spec as simple as can be. But we >> need to ask: simple for whom? For the bike owner or for the bike vendor? >> >> (short answer: the priority should be simplicity for spec users, not spe= c >> implementers and even less spec designers). >> >> >> >> The initial question that is asked is very interesting: isn't the design >> flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the >> state of the request? Or if we must handle token revocation? Or if we ar= e >> looking for a global unique identifier? The argument stems of the fact t= hat >> is still arguably harder and more error prone to implement. Fair enough. >> >> >> >> From a spec implementer's perspective, it may well be more complex. It >> mostly impacts the json library you'll end up using, plus a bit of >> input/output decoration around it. Even golang provides utilities for th= is, >> despite not exactly being made for this kind of purpose. >> >> My practical experience implementing it is that it's not that big a deal= . >> I mean, I wished it could be simpler, but it's manageable and there are >> other ways to reach levels of insurance that it does work as intended (j= son >> schema, test cases to validate the implementation, etc.). Arguably it is >> still easier from an implementation perspective than say, json-ld, which= is >> massively used in the SSI community. >> >> >> >> But ultimately who are we designing for? Are we striving to go easy on >> the spec implementer? Or are we trying to make sure end-developers using >> the client libraries won't shoot themselves in the foot? >> >> >> >> The job to be done (JTBD), from the end-developer's perspective, is to >> efficiently ship an application. And provide authN/authZ capabilities fo= r >> end-users by relying on some well known implementation. >> >> In turn, this spec implementer will rely on cryptographic utility >> libraries that deals internally with the complexity of their own domain,= so >> that we don't have to. And here we could launch another HN flame war tha= t >> starts with the title "JWT sucks because". Which does have its set of ve= ry >> real issues but that's beyond the point. >> >> Note that any decent flamewar will be efficiently fueled by people hatin= g >> medium. Is it outrageous for blog posts to be behind a paywall? Maybe bu= t >> it's even more outrageous to lack consistency, either by not knowing how= to >> get around a paywall if you're into a hacker punk movement, or on the >> contrary by to not paying a subscription if you believe that surveillanc= e >> capitalism, to reuse Zuboff's terms, should be eradicated. >> >> What likely seems an unnecessary sidenote tries to illustrate the point: >> for Justin it was easier to publish on medium, because as a blog publish= er, >> you might not want to deal with hosting your own blog. But maybe as a >> reader you'll find that annoying. Different audiences, different JTBD, >> different tradeoffs. >> >> >> >> Polyphormism is a tool that enables the end-developer to have minimal >> knowledge of what it means to deal with a GNAP client library. You prepa= re >> the request, send to the endpoint and you're good to go. Massively simpl= er >> than OAuth2 or any similar protocol by the way (as anyone with teaching >> experience on the subject might acknowledge). And there's a lot more to= be >> done to make sure we indeed reduce the complexity for the end-developer = and >> the end-user. >> >> >> >> If we find a better way to deal with that simplicity balance, I'm all in= . >> But the arguments need to be way more convincing than just saying that i= t >> may be difficult to implement or validate. >> >> >> >> Cheers. >> >> Fabien >> >> >> >> >> >> >> >> >> >> >> >> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : >> >> >> >> >> >> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >> >> >> >> Justin >> >> >> >> I did note that I was the one that argued for instance_id being in the >> object. Since it is in the object in the current draft, not including a >> pass by reference option would be preferable. >> >> >> >> As for concrete examples: >> >> - version of client >> >> - version of OS >> >> - security attestation of OS / device >> >> - location of client device >> >> - network client is operating on >> >> >> >> These are all attributes of the client that an AS may require on the >> initial grant request, and in future grant requests (which is when an >> instance_id) would be used. >> >> >> >> >> >> This is where our interpretations differ: I don=E2=80=99t see these as >> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key,= display >> information, class identifiers, and other items currently represented by= an >> instance_id are attributes of the client instance. The attestation >> components don=E2=80=99t modify the instance so much as present addition= al >> information on top of the client instance itself. This is why I argue th= at >> they ought to be handled in a separate object, so you=E2=80=99d have som= ething like >> this strawman: >> >> >> >> { >> >> >> >> posture: { >> >> software_version: 1.2.3, >> >> os_version: 14.3.2 >> >> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >> >> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >> >> }, >> >> >> >> client: =E2=80=9Cclient-541-ab" >> >> >> >> } >> >> >> >> This is a more fundamental question about GNAP than whether the syntax >> uses polymorphism: this is about GNAP being very explicit about the data >> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mode= l of what >> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pr= oblematic in >> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havi= ng to >> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture >> the different aspects that are out there. I think we=E2=80=99re getting = closer here >> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, b= ut we still need to >> be more precise about what exactly a client instance includes, and what = it >> does not. >> >> >> >> =E2=80=94 Justin >> >> >> >> >> >> /Dick >> >> >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >> >> Dick, >> >> >> >> As you=E2=80=99ll recall, I argued against including the client instance >> identifier inside of the object as a mutually-exclusive field precisely >> because of the principle violation that you are pointing out here, and s= o >> it=E2=80=99s important to point out that the current text is a compromis= e that >> needs to be examined in the wider experience of the working group. I am = on >> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >> object, but this needs to be explored. >> >> >> >> The crux of my argument is that is exactly a case of pass-by-reference v= s >> pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient >> instance=E2=80=9D value itself but rather belong outside of that object = in a >> another part of the request. As stated in the editorial notes in this >> section, we need to look carefully at how these concepts fit within the >> model and where we would want to put them. Without concrete examples of >> what these extensions look like and how they=E2=80=99re generated, that = is nearly >> impossible to do at this stage. I look forward to seeing examples of thi= s >> kind of data and how it can fit into the protocol. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >> >> >> >> Hey Justin, >> >> >> >> As the draft has evolved, I question the continued use of polymorphism. >> Note that I appreciate the elegance of using a string for >> pass-by-reference, and an object for pass-by-value. >> >> >> >> In the current draft, the >> >> >> >> Every time you create or process a field it will mean only one thing, an= d >> there=E2=80=99s only one field to look at to answer a question. >> >> >> >> is violated in 2.3.1. Identifying the RC Instance >> >> >> >> >> >> >> instance_id An identifier string that the AS can use to identify the >> >> particular instance of this RC. The content and structure of this >> >> identifier is opaque to the RC. >> >> >> >> "client": { >> >> "instance_id": "client-541-ab" >> >> } >> >> >> >> If there are no additional fields to send, the RC MAY send the >> >> instance identifier as a direct reference value in lieu of the >> >> object. >> >> >> >> "client": "client-541-ab" >> >> >> >> The instance identifier can be sent two ways. Polymorphism is a >> convenience for the client, but requires the server to have two code pat= hs >> for "instance_id". We discussed this in the design team, and I argued f= or >> having "instance_id" in the "client" object so that any updates, such as >> new devices assertions, could be in the "client" object. As noted above, >> while I appreciate the elegance of using a string (handle) to reference = a >> previously provided object, it complicates how to update an existing obj= ect >> while providing the reference. >> >> >> >> In your example of the "key" object below, setting "proof" to bearer >> would avoid the issue you describe: >> >> >> >> { >> "key": { >> "proof": "bearer" >> } >> } >> >> >> >> In your example, when processing the "key" object, code is having to >> check both the JSON type of the property, as well as check the value of = the >> "proof" property. In the example I provided, only the value of "proof" >> needs to be checked. The "proof" property is acting as a type for the "k= ey" >> object. >> >> >> >> Not being a Java programmer, I don't know how this would work in a Java >> implementation, but node.js, the processing would need to be done as abo= ve. >> >> >> >> On a related note, there was significant negative feedback on handles an= d >> polymorphism in the Hacker News article >> https://news.ycombinator.com/item?id=3D24855750 >> >> >> >> /Dick >> >> >> >> >> >> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >> >> Hi Mika, >> >> >> >> Thanks for bringing this topic here =E2=80=94 I was able to see the foru= m >> discussion that brought you here, and hopefully I can help clear up what= I >> mean with how polymorphism is used in the proposal. The short version is >> that the goal is to *avoid* the kinds of ambiguity that make insecure >> protocols, and so in that goal we=E2=80=99re fully aligned. I think that= using >> polymorphism in very specific ways can help that goal =E2=80=94 just as = I agree >> that misusing it or applying it sloppily can lead to ambiguous and insec= ure >> systems. >> >> >> >> Some background: I built out the XYZ protocol (one of the predecessors t= o >> the initial GNAP Draft) in Java using strongly typed parsers and Java >> objects specifically to prove to myself that it could be done in a way t= hat >> made any sense in the code. (My own open source implementation is at >> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not y= et up to >> date with the GNAP spec). It was important to me that I be able to use t= he >> system-wide configured parsers to implement this and not have to resort = to >> stepping through elements completely by hand. Java doesn=E2=80=99t make = it simple >> to get the hooks into the right places (especially with the Jackson pars= er >> that I used), but it is definitely possible to create a deterministic an= d >> strongly-typed parser and serializer for this kind of data structure. So= me >> of the rationale for using polymorphism is covered in the trailing appen= dix >> of the draft document ( >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#na= me-json-structures-and-polymor), >> but it=E2=80=99s still good to discuss this here as the working group de= cides which >> approaches to take. >> >> >> >> The driving reason for using polymorphism at the protocol level was to >> simplify the protocol and make it :more: deterministic to create and >> process, not less. Every time you create or process a field it will mean >> only one thing, and there=E2=80=99s only one field to look at to answer = a question. >> Without polymorphic field values, you usually need to rely on mutual >> exclusivity of fields, which is prone to failure and requires additional >> error checking. Take for example the key binding of access tokens. An >> access token could be bound to the RC=E2=80=99s key used during the requ= est, to a >> different key chosen by the AS, or it could be a bearer token with no ke= y >> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can de= fine it in terms of >> boolean values and objects and express this set of mutually-exclusive >> options in a non-ambiguous way. Without that, you=E2=80=99d need to have= different >> fields for the options and include additional checks in your parser to m= ake >> sure they weren=E2=80=99t sent simultaneously, otherwise you could get h= it with >> this potential security vulnerability in an object: >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> }, >> >> bearer_token: true, >> >> bind_to_rc_key: true >> >> } >> >> >> >> This would be an illegal object as per this alternate proposal, but then >> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t p= ut next to others >> in the same object. I=E2=80=99ve done this exercise with many other prot= ocols and >> it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9C= good=E2=80=9D examples >> would pass code that doesn=E2=80=99t check this. With the polymorphic ap= proach to >> this same field, each of these three mutually-exclusive states is writte= n >> in a way that they cannot be sent together. It=E2=80=99s not just illega= l, it=E2=80=99s >> impossible and enforced by the syntax of JSON itself. >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> } >> >> } >> >> >> >> // bearer token >> >> >> >> { >> >> key: false >> >> } >> >> >> >> // bound to the RC=E2=80=99s presented key >> >> >> >> { >> >> key: true >> >> } >> >> >> >> If someone sends a different type for this field, like an array or numbe= r >> or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and >> would be a protocol level error. >> >> >> >> While it might sound like polymorphism means that any field could have >> any type or value, the opposite is true: each possible value is explicit= ly >> typed, it=E2=80=99s just that there are potentially different types that= express >> meaning for the field. This applies to all members of all objects >> (dictionaries) as well as all members of an array (list). Every time you >> process a field value or other element, you look at the type and then th= e >> value to determine what to do with that typed value. >> >> >> >> In your example below, each field within the dictionary would also need >> to be typed, and each type would need to have a clear indication of its >> meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could >> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON = number) or an >> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would f= urther say what >> exactly the encoding of the string would be. That means that when you re= ad >> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confus= ion on what the value was >> or how it was represented, regardless of the input format. Seeing a numb= er >> there means exactly one interpretation and seeing a string means exactly >> one (different) interpretation =E2=80=94 but importantly, both of them a= re a >> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An >> implementation would likely use an internal BigInteger type of object to >> represent the field value after parsing, so the question is how to go fr= om >> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you appl= y it to all >> sub-fields of that object. >> >> >> >> So let=E2=80=99s dig into the specific bug you bring up in the strawman,= because >> it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings= , and not >> numbers, is not compliant with the JSON definitions of the field in >> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t= be treated >> the same by a parser implementation when mapping to a concrete object. I= t=E2=80=99s >> in this kind of automated guessing that this class of bugs occur, and >> that=E2=80=99s going to be the case whether or not you take advantage o= f JSON=E2=80=99s >> polymorphic nature. I=E2=80=99ve run into cases where a parser library w= as trying >> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up >> introducing errors in more strict components downstream. This is somethi= ng >> that protocol designers need to be aware of and guard against in the des= ign >> of the protocol to reduce possible ambiguities. Within GNAP today, we >> generally have things that branch whether they=E2=80=99re an object (for= a rich >> description of something) or some non-structured special value (for a >> reference or other item). >> >> >> >> The design team created some simple JSON Schemas for parts of the >> protocol during our discussion, but we didn=E2=80=99t include them in th= e design >> document due to both lack of time to keep it updated with the rapid chan= ges >> to the protocol during the design team discussion, and not knowing if th= ere >> would be interest in such material. I personally think it would be helpf= ul >> to include as an informative reference in the final document, but that= =E2=80=99s >> something for the working group to take up eventually. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >> >> >> >> Hello, everyone. >> >> >> >> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and >> when I made note about certain concerns, I was requested to send my >> comments to this working group. >> >> >> >> In short, I believe that the use of polymorphic JSON in the protocol >> invites subtle and confusing implementation problems. I also searched >> through the WG archives, and noticed that similar concerns were noted, >> briefly, in a thread in July. >> >> >> >> The problem with polymorphic values, as I see it, is that implementation= s >> will need to branch on the (inferred) type of a given field. This isn't >> quite as bad if the types are strictly different, but allows for subtle >> bugs when the value in question is a dictionary. What makes this >> unappealing is that "subtle bugs" in security protocols have a habit of >> turning into vulnerabilities. >> >> >> >> Let's say we have these imaginary payloads, both possible and valid in >> the same protocol step: >> >> >> >> # payload 1 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": >> >> } >> >> } >> >> >> >> # payload 2 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": "" >> >> } >> >> } >> >> >> >> In both cases, the type of "public_key" field is a dictionary. In both >> cases, they even have the same keys. However, the values in the >> dictionaries are entirely different, and an implementation will have to >> branch to at least two possible decoding mechanisms. To make things wors= e, >> some JSON implementations may choose to encode non-dictionary values as >> strings, so it is possible for an originator to transmit what they expec= t >> and believe to be payload 1 format, but which the receiver will interpre= t >> to be in payload 2 format. And if the encoded string contains only digit= s, >> it will even parse correctly as a bignum. >> >> >> >> While the above is clearly a manufactured scenario, it nonetheless >> demonstrates the potential for logic bugs with polymorphic JSON. With >> richer types and more complex dictionaries, there will surely be more ro= om >> for errors. >> >> >> >> Ambiguity in protocols is always a source of implementation complexity >> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, would= n't >> it be in everyone's interest to keep implementation complexity and mista= ke >> potential to a minimum? >> >> >> >> Best regards, >> >> Mika >> >> >> >> -- >> >> Mika Bostr=C3=B6m >> >> Smarkets >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> > --000000000000f4b4bb05b287ad27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I want to point out that JSON schema can enforce mutually = exclusive properties.

    For example the "client"= object containing once of "instance_id", "class_id", o= r "display"





    3D""=E1=90=A7
    =
    On Sun= , Oct 25, 2020 at 9:33 AM Justin Richer <jricher@mit.edu> wrote:
    I agree fully = with Fabien=E2=80=99s statements on who we=E2=80=99re making things easy fo= r. If this security protocol isn=E2=80=99t easy and straightforward for cli= ent developers =E2=80=94 with or without a library =E2=80=94 then it simply= will not be adopted. It might be hard to see when looking at the whole pro= tocol, but this goal is actually one of the drivers for the way polymorphis= m is used in the current draft. The driving philosophy of OpenID Connect=E2= =80=99s development was =E2=80=9Ckeep the simple things simple, make the co= mplex things possible=E2=80=9D, and that=E2=80=99s a philosophy I strongly = believe we need to continue here in GNAP.

    Importantly, a= client developer shouldn=E2=80=99t need to have to support all possible pe= rmutations in order to get something right. OAuth has shown us that even wh= en a protocol has a lot of options, client software is going to be coded to= use only one set of options. If the protocol can support that reality, I t= hink we are doing well. In the current draft, generally speaking it=E2=80= =99s the AS that needs to handle different options, not the client. Take fo= r example requesting resources: a very simple client might just send an arr= ay of strings, like OAuth scopes. The AS needs to be able to handle the str= ing inputs as well as the rich object descriptors, but the client software = doesn=E2=80=99t even need to know that the object format exists in order to= create compliant JSON.=C2=A0=C2=A0The client developer can do this without= any special libraries, it can just bang out the JSON directly.=C2=A0Such a= client won=E2=80=99t be able to do the more fancy stuff that the request o= bjects allow, but for this client, that=E2=80=99s fine since all it needs t= o do is produce an array with strings that the AS will accept. The same is = true across the various other options, like requesting multiple access toke= ns vs a single one, or providing an instance identifier vs. a set of inform= ation for the client instance itself. Client developers should be fully abl= e to ignore parts of the protocol that they aren=E2=80=99t using, especiall= y the more advanced stuff. An AS shouldn=E2=80=99t get to have such a choic= e, but as the AS is the lynchpin of the security model, I am OK with things= being slightly more complex to support, especially if it shifts that compl= exity away from clients.

    I am in favor of includin= g JSON Schema in the draft in a non-normative way, and you can see an earli= er version of that experiment that Fabien and I undertook as part of the De= sign Team. The schema will be available for developers who want to / can us= e it, but even for people who aren=E2=80=99t using the schema directly it c= an provide additional context and information. I am willing to put some cyc= les into creating schemas for the main request and response messages and pu= t those into a pull request to create an appendix in the draft. I=E2=80=99d= also be fine with a non-normative JSON-LD reference for LD processors =E2= =80=94 but (1) I=E2=80=99m not going to write that :) and (2) it can=E2=80= =99t be required for the protocol to be understood.

    =C2=A0=E2=80=94 Justin

    On= Oct 25, 2020, at 8:47 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron,

    As Justin explained that's the kind of idea we tested. For in= stance=C2=A0https://github.com/fimbault/test_gnap_schema (in rust).

    Cheers
    Fabien=C2=A0

    Le dim. 25 oct. 2020 =C3=A0 13:36, Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> a =C3=A9crit=C2=A0:
    <= div>

    Personally, I would support polymorphism in the = protocol if it (the RFC) came with a well-defined JSON Schema [1] document,= so a recipient can automatically validate incoming messages at run-time. I= would expect senders to also validate messages as part of their testing. I= t=E2=80=99s not an ideal solution, because:

    =C2=A0

    • Some people at the IETF don=E2=80=99t like J= SON Schema, for various reasons.
    • JSON Schema is not a standard, so it=E2=80=99s painful to require it = normatively.
    • Even if it=E2= =80=99s normative, some recipients will not validate messages anyway.

    =C2=A0

    This would be shifting some of the complexity from the libra= ry developer to the spec developer, which is the right thing to do IMO.<= /u>

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ya= ron

    =C2=A0

    [1] https://json-schema.org/

    =C2=A0

    =C2=A0=

    From: Fabien Imbault <fabien.imbault@gmail.com&g= t;
    Date: Sunday, October 25, 2020 at 12:39
    To: Yaron Sh= effer <yaronf.ietf@gmail.com>
    Cc: Dick Hardt <d= ick.hardt@gmail.com>, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List <txauth@ietf.o= rg>, Justin Richer <jricher@mit.edu>
    Subject: Re: [= GNAP] Feedback on polymorphism

    =C2=A0

    Hi= Yaron,

    =C2=A0

    Thanks for the feedback.=C2=A0

    =C2=A0

    Regarding client libraries, I think we can indeed learn= a great deal from cryptographic libraries. Cryptographic design provides a= great amount of flexibility for the specialists (including many parameters= that you really need to get right). We might think this is great to provid= e options but it actually increases the cognitive load of library users.=

    =C2=A0

    Look instead at what Google has provided wi= th tink as an alternative and you'll see it is a much easier way for cr= yptographic engineers (who aren't cryptographers) to avoid mistakes or = misuses.=C2=A0

    = =C2=A0

    That's the *security= * issue I'm referring to (not the fact that being open they're tast= y targets, although that may be related in some cases). And tink is the kin= d of design we should be trying to achieve.=C2=A0

    =C2=A0

    I agree that it should be applicable to a wide range of well known= programming tools, including the likes of java and go.=C2=A0=

    But I don't really see a limitati= on here. Might not be the most idiomatic feel, but it can be made to work.= =C2=A0

    =C2=A0<= /u>

    Just so I understand, what alterna= tives would you prefer to polymorphism? I can suggest json-ld but even Just= in will Teel you it's even more complex :-)=C2=A0

    =C2=A0

    Cheers

    Fa= bien=C2=A0

    =C2=A0

    Le dim.= 25 oct. 2020 =C3=A0 11:17, Yaron Sheffer <yaronf.ietf@gmail.com&= gt; a =C3=A9crit=C2=A0:

    =

    Hi Fabien,

    =C2=A0

    I think your product man= agement model has a lot of merit, but it does not capture the security issu= e well.

    =C2=A0

    I agree that as we look at different customer personas,= the =E2=80=9Cend user=E2=80=9D (the developer that=E2=80=99s using the lib= raries) should be our highest priority. But I disagree about end-user mista= kes being the top *security* issue. Libraries are often open source = in our space and used very widely. So they make for tasty targets, and peop= le are attacking them and are still finding security issues in libraries th= at we=E2=80=99ve been talking about forever [1].

    =C2=A0

    (Yes, my exam= ple is actually an app flaw, but I think it could have been prevented by a = better designed library.)

    =C2=A0=

    In other words, we do need to care ab= out how easy it is to implement the protocol correctly by *library* = developers. From Justin describing his own experience and other people on t= he thread that Dick referred to, I would say that JSON polymorphism is pain= ful for Java and Go developers. With all due respect, I care about them muc= h more than I care about Haskell, as many more implementations are likely t= o use these languages.

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    =C2= =A0

    [1] https://www.zofrex.com/blog/2020/10/20/alg-none-jwt= -nhs-contact-tracing-app/

    =C2= =A0

    From: TXAuth <txauth-bounces@ietf.org>= on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Sunday, October 25, 2020 at 01:25
    To: Dick Hardt <= ;dick.hardt@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bo= strom=3D40smarkets.com@dmarc.ietf.org>, GNAP Mailing List= <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
    Sub= ject: Re: [GNAP] Feedback on polymorphism

    =C2=A0

    Hi Dick,

    =C2=A0=

    Independantly from the deb= ate on polyphormism, I beg to differ on your order preference.=C2=A0=

    =C2=A0

    =

    Your assumption is that AS devs matter the most= ,=C2=A0because they're doi= ng the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users of= the spec are unable to deal with the complexity that is passed onto them.= =C2=A0

    =C2=A0<= /u>

    99% of the people that will= actually use the output of the work are application developers (client or = RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the protocol drive= the usage. Client libraries may help, but they're not a silver bullet,= especially because GNAP ultimately has no control about what people do the= re (for better or worse). And everything we do here will help get to the be= tter part.=C2=A0

    = =C2=A0

    I'm not sayin= g we don't intend to also care about AS developers (beginning with ours= elves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't = forget that anyway.=C2=A0

    =C2=A0

    Fabien=C2= =A0

    =C2=A0=

    =C2=A0<= u>

    Le sam. 24 oct. 2020 =C3= =A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0= :

    I'm c= onfused by your logic Fabien.

    = =C2=A0

    If a client libra= ry developer wants to expose polymorphism, they can do that independent of = what is in the protocol.=C2=A0

    =C2=A0

    I differ o= n who our stakeholders are.=C2=A0

    =C2=A0

    I think= our stakeholders are in least to most important:

    =C2=A0

    • AS developer
    • RS developer
    • client devel= oper
    • user
    =

    =C2=A0

    A client library developer can expose whatever interface t= hey want to simplify implementation.

    =C2=A0

    I = list the user so that we don't lose site of a critical role.<= /u>

    =C2=A0

    /Dick

    =C2=A0

    =C2=A0

    Error! Filename not specified.=E1=90=A7

    =C2=A0<= /u>

    On Fri, Oct 23, 2020 at 6:27= PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    Hi there,=C2= =A0

    =C2=A0=

    Let me try to approach the issue under a d= ifferent light. More like a product manager would deal with feature selecti= on to make it intuitive for its users.=C2=A0

    =C2=A0

    For most people, riding a bike is far easier than using a unicycle. Feel= s more stable. And yet it's way easier to design for a single wheel tha= n to build with 2. Because then you'll need a lot more accessories (cha= in, chain ring, etc.). Even so producing a bike doesn't have to be a br= ittle process, it can be industrialized.=C2=A0

    =

    =C2=A0

    Back to the GNAP topic.=C2=A0

    Ultimately we should str= ive to make the spec as simple as can be. But we need to ask: simple for wh= om? For the bike owner or for the bike vendor?=C2=A0

    (short answer: the priority should be simplicity for spec users, not = spec implementers and even less spec designers).=C2=A0=

    =C2=A0

    The initial question that is asked is very interesting= : isn't the design flawed if GNAP is using json polyphormism? Or if the= AS needs to handle the state of the request? Or if we must handle token re= vocation? Or if we are looking for a global unique identifier? The argument= stems of the fact that is still arguably harder and more error prone to im= plement. Fair enough.=C2=A0

    =C2=A0

    From a spec i= mplementer's perspective, it may well be more complex. It mostly impact= s the json library you'll end up using, plus a bit of input/output deco= ration around it. Even golang provides utilities for this, despite not exac= tly being made for this kind of purpose.

    My practical experience implementing it is that it's n= ot that big a deal. I mean, I wished it could be simpler, but it's mana= geable and there are other ways to reach levels of insurance that it does w= ork as intended (json schema, test cases to validate the implementation, et= c.). Arguably it is still easier from an implementation perspective than sa= y, json-ld, which is massively used in the SSI community.=C2=A0

    =C2=A0

    =

    But ultimately who are we designing for? Are we stri= ving to go easy on the spec implementer? Or are we trying to make sure end-= developers using the client libraries won't shoot themselves in the foo= t?

    =C2=A0<= /p>

    The job to be done (JTBD), from the en= d-developer's perspective, is to efficiently ship an application. And p= rovide authN/authZ capabilities for end-users by relying on some well known= implementation.=C2=A0

    I= n turn, this spec implementer will rely on cryptographic utility libraries = that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts= with the title "JWT sucks because". Which does have its set of v= ery real issues but that's beyond the point.=C2=A0

    Note that any decent flamewar will be effici= ently fueled by people hating medium. Is it outrageous for blog posts to be= behind a paywall? Maybe but it's even more outrageous to lack consiste= ncy, either by not knowing how to get around a paywall if you're into a= hacker punk movement, or on the contrary by to not paying a subscription i= f you believe that surveillance capitalism, to reuse Zuboff's terms, sh= ould be eradicated.=C2=A0

    What likely seems an unnecessary sidenote tries to illustrate the point: = for Justin it was easier to publish on medium, because as a blog publisher,= you might not want to deal with hosting your own blog. But maybe as a read= er you'll find that annoying. Different audiences, different JTBD, diff= erent tradeoffs.=C2=A0

    = =C2=A0

    Polyphormism is a= tool that enables the end-developer to have minimal knowledge of what it m= eans to deal with a GNAP client library. You prepare the request, send to t= he endpoint and you're good to go. Massively simpler than OAuth2 or any= similar protocol by the way (as anyone with teaching experience on the sub= ject might acknowledge). And=C2=A0 there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-us= er.=C2=A0

    =C2=A0<= u>

    If we find a better way to deal= with that simplicity balance, I'm all in. But the arguments need to be= way more convincing than just saying that it may be difficult to implement= or validate.=C2=A0

    =C2= =A0

    Cheers.

    Fabien

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer &l= t;j= richer@mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0

    =C2=A0

    On Oc= t 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote= :

    =C2=A0

    Justin

    =C2=A0

    I did note= that I was the one that argued for instance_id being in the object. Since = it is in the object in the current draft, not including a pass by reference= option would be preferable.=C2=A0

    =C2=A0

    As for= concrete examples:

    - ve= rsion of client

    - versio= n of OS

    - security attes= tation of OS / device

    - = location of client device

    - network client is operating on

    =C2=A0

    These = are all attributes of the client that an AS may require=C2=A0on the initial= grant request, and in future grant requests (which is when an instance_id)= would be used.

    =C2=A0

    = =C2=A0

    This is where our= interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes o= f the client=E2=80=9D in the same way that the key, display information, cl= ass identifiers, and other items currently represented by an instance_id ar= e attributes of the client instance. The attestation components don=E2=80= =99t modify the instance so much as present additional information on top o= f the client instance itself. This is why I argue that they ought to be han= dled in a separate object, so you=E2=80=99d have something like this strawm= an:

    =C2=A0=

    {

    =C2=A0

    = =C2=A0 posture: {

    =C2=A0= =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2

    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some struct= ure or signed blob? =E2=80=A6 }

    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2= =80=A6 }

    =C2=A0 },

    =C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"=

    =C2=A0

    }

    =C2=A0

    This is= a more fundamental question about GNAP than whether the syntax uses polymo= rphism: this is about GNAP being very explicit about the data model of its = elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the te= rm =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic= in practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with hav= ing to define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that d= oesn=E2=80=99t fully capture the different aspects that are out there. I th= ink we=E2=80=99re getting closer here in GNAP with explicit definition of = =E2=80=9Cclient instance=E2=80=9D, but we still need to be more precise abo= ut what exactly a client instance includes, and what it does not.=

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    =C2=A0

    /D= ick

    =C2=A0=

    Error! Filename not specified.=E1=90= =A7

    =C2=A0

    On Fri, Oct 23, 2020 at 12:42 PM Jus= tin Richer <jricher@mit.edu> wrote:

    Dick,

    =C2=A0

    As you=E2= =80=99ll recall, I argued against including the client instance identifier = inside of the object as a mutually-exclusive field precisely because of the= principle violation that you are pointing out here, and so it=E2=80=99s im= portant to point out that the current text is a compromise that needs to be= examined in the wider experience of the working group. I am on the side of= removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option withi= n an object, but this needs to be explored.

    =C2=A0

    The crux of my argument is that is exactly a case of pass-by-reference v= s pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient instance=E2=80=9D value itself but rather belong outside of that = object in a another part of the request. As stated in the editorial notes i= n this section, we need to look carefully at how these concepts fit within = the model and where we would want to put them. Without concrete examples of= what these extensions look like and how they=E2=80=99re generated, that is= nearly impossible to do at this stage. I look forward to seeing examples o= f this kind of data and how it can fit into the protocol.

    =

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    <= blockquote style=3D"margin-top:5pt;margin-bottom:5pt">

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    =

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0instance_id =C2=A0An identifi= er string that the AS can use to identify the

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0 =C2=A0 particular instance of this RC.= =C2=A0 The content and structure of this

    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.

    =C2=A0

    =C2=A0 =C2=A0"client": {

    =C2=A0 =C2=A0 =C2=A0 =C2=A0"in= stance_id": "client-541-ab"

    =C2=A0 =C2=A0}

    =C2=A0

    =C2=A0 = =C2=A0If there are no additional fields to send, the RC MAY send the=

    =C2=A0 =C2=A0instance identifi= er as a direct reference value in lieu of the

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0object.

    =C2=A0

    =C2=A0 =C2=A0"client": "client-541-ab"<= /p>

    =C2=A0

    <= /div>

    The instance identifier can be sent two wa= ys. Polymorphism is a convenience for the client, but requires the server= =C2=A0to have two code=C2=A0paths for "instance_id".=C2=A0 We dis= cussed this in the design team, and I argued for having "instance_id&q= uot; in the "client" object=C2=A0so that any updates, such as new= devices assertions, could be in the "client" object. As noted ab= ove, while I appreciate the elegance of using a string (handle) to referenc= e a previously provided object, it complicates how to update an existing ob= ject while providing the reference.

    =C2=A0

    In yo= ur example of the "key" object below, setting "proof" t= o bearer would avoid the issue you describe:

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"= proof": "bearer"
    =C2=A0 =C2=A0 }
    }

    =

    =C2=A0

    In your example, when processing the "key" objec= t, code is having to check both the JSON type of the property, as well as c= heck the value of the "proof" property. In the example I provided= , only the value of "proof" needs to be checked. The "proof&= quot; property is acting as a type for the "key" object.

    =C2=A0

    Not being a Java programmer, I don't know how= this would work in a Java implementation, but node.js, the processing woul= d need to be done as above.

    =C2=A0

    On a related = note, there was significant negative feedback on handles and polymorphism i= n the Hacker News article=C2=A0https://news.ycombinat= or.com/item?id=3D24855750=C2=A0

    =C2=A0

    /Dick=

    =C2=A0

    =C2=A0

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer= <jricher@mit.edu> wrote:

    Hi Mika,

    =C2=A0

    Thanks for bri= nging this topic here =E2=80=94 I was able to see the forum discussion that= brought you here, and hopefully I can help clear up what I mean with how p= olymorphism is used in the proposal. The short version is that the goal is = to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecure protoco= ls, and so in that goal we=E2=80=99re fully aligned. I think that using pol= ymorphism in very specific ways can help that goal =E2=80=94 just as I agre= e that misusing it or applying it sloppily can lead to ambiguous and insecu= re systems.

    =C2=A0

    Some background: I built out = the XYZ protocol (one of the predecessors to the initial GNAP Draft) in Jav= a using strongly typed parsers and Java objects specifically to prove to my= self that it could be done in a way that made any sense in the code. (My ow= n open source implementation is at=C2=A0https://github.com/bsp= k/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with th= e GNAP spec). It was important to me that I be able to use the system-wide = configured parsers to implement this and not have to resort to stepping thr= ough elements completely by hand. Java doesn=E2=80=99t make it simple to ge= t the hooks into the right places (especially with the Jackson parser that = I used), but it is definitely possible to create a deterministic and strong= ly-typed parser and serializer for this kind of data structure. Some of the= rationale for using polymorphism is covered in the trailing appendix of th= e draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-pr= otocol-00.html#name-json-structures-and-polymor), but it=E2=80=99s stil= l good to discuss this here as the working group decides which approaches t= o take.=C2=A0

    =C2=A0<= /u>

    The driving reason for usin= g polymorphism at the protocol level was to simplify the protocol and make = it :more: deterministic to create and process, not less. Every time you cre= ate or process a field it will mean only one thing, and there=E2=80=99s onl= y one field to look at to answer a question. Without polymorphic field valu= es, you usually need to rely on mutual exclusivity of fields, which is pron= e to failure and requires additional error checking. Take for example the k= ey binding of access tokens. An access token could be bound to the RC=E2=80= =99s key used during the request, to a different key chosen by the AS, or i= t could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2= =80=9D field polymorphic, we can define it in terms of boolean values and o= bjects and express this set of mutually-exclusive options in a non-ambiguou= s way. Without that, you=E2=80=99d need to have different fields for the op= tions and include additional checks in your parser to make sure they weren= =E2=80=99t sent simultaneously, otherwise you could get hit with this poten= tial security vulnerability in an object:

    =C2=A0

    {=C2=A0

    =C2=A0 =C2=A0 k= ey: {

    =C2=A0 =C2=A0 =C2= =A0 proof: httpsig,

    =C2= =A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    <= /div>

    =C2=A0 =C2=A0 },

    =C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0

    This would be an illegal object as per this alternate proposal, but= then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise wi= th many other protocols and it=E2=80=99s both error prone and easy to ignor= e since all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn= =E2=80=99t check this. With the polymorphic approach to this same field, ea= ch of these three mutually-exclusive states is written in a way that they c= annot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossi= ble and enforced by the syntax of JSON itself.

    =

    =C2=A0

    {=C2=A0

    =C2= =A0 =C2=A0 key: {

    =C2=A0= =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    //= bearer token

    =C2=A0<= /u>

    {

    =C2=A0 =C2=A0 key: false

    <= div>

    }

    =C2=A0

    // bou= nd to the RC=E2=80=99s presented key

    =C2=A0

    {<= u>

    =C2=A0 =C2=A0 key: true<= u>

    }

    =C2=A0

    If someone sends a different type for this field, like an array= or number or a null, this doesn=E2=80=99t have a defined interpretation in= the protocol and would be a protocol level error.

    <= div>

    =C2=A0

    While it might sound like polymorphism means that any field could= have any type or value, the opposite is true: each possible value is expli= citly typed, it=E2=80=99s just that there are potentially different types t= hat express meaning for the field. This applies to all members of all objec= ts (dictionaries) as well as all members of an array (list). Every time you= process a field value or other element, you look at the type and then the = value to determine what to do with that typed value.

    =C2=A0

    In your example below, each field within the dictionary would a= lso need to be typed, and each type would need to have a clear indication o= f its meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could be defined polymorphically as either a =E2=80=9Cbigin= t=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON s= tring). The definition would further say what exactly the encoding of the s= tring would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D= field there wouldn=E2=80=99t be any confusion on what the value was or how= it was represented, regardless of the input format. Seeing a number there = means exactly one interpretation and seeing a string means exactly one (dif= ferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80= =9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines the typ= e. An implementation would likely use an internal BigInteger type of object= to represent the field value after parsing, so the question is how to go f= rom the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, y= ou apply it to all sub-fields of that object.=C2=A0

    =

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up in the s= trawman, because it=E2=80=99s interesting: A JSON encoder that encodes numb= ers as strings, and not numbers, is not compliant with the JSON definitions= of the field in question. For another example, the quoted string value of = =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON,= and they shouldn=E2=80=99t be treated the same by a parser implementation = when mapping to a concrete object. It=E2=80=99s in this kind of automated g= uessing that this class of bugs occur, and that=E2=80=99s going to be the c= ase whether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic n= ature. I=E2=80=99ve run into cases where a parser library was trying to be = overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended u= p introducing errors in more strict components downstream. This is somethin= g that protocol designers need to be aware of and guard against in the desi= gn of the protocol to reduce possible ambiguities. Within GNAP today, we ge= nerally have things that branch whether they=E2=80=99re an object (for a ri= ch description of something) or some non-structured special value (for a re= ference or other item).=C2=A0

    =C2=A0

    The design = team created some simple JSON Schemas for parts of the protocol during our = discussion, but we didn=E2=80=99t include them in the design document due t= o both lack of time to keep it updated with the rapid changes to the protoc= ol during the design team discussion, and not knowing if there would be int= erest in such material. I personally think it would be helpful to include a= s an informative reference in the final document, but that=E2=80=99s someth= ing for the working group to take up eventually.

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct = 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika= .bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:

    =C2=A0

    Hello, everyone.

    =C2=A0

    For backg= round: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made= note about certain concerns, I was requested to send my comments to this w= orking group.

    =C2=A0<= /u>

    In short, I believe that th= e use of polymorphic JSON in the protocol invites subtle and confusing impl= ementation problems. I also searched through the WG archives, and noticed t= hat similar concerns were noted, briefly, in a thread in July.

    =C2=A0

    =

    The problem with polymorphic values, as I see it, is= that implementations will need to branch on the (inferred) type of a given= field. This isn't quite as bad if the types are strictly different, bu= t allows for subtle bugs when the value in question is a dictionary. What m= akes this unappealing is that "subtle bugs" in security protocols= have a habit of turning into vulnerabilities.

    =

    =C2=A0

    Let's say we have these imaginary payloads, both possible and val= id in the same protocol step:

    =C2=A0

    # payload 1=

    {

    =C2=A0 ...,

    =C2=A0 "public_key": {

    <= div>

    =C2=A0=C2=A0=C2=A0 "alg": "rsa&qu= ot;,

    =C2=A0=C2=A0=C2=A0 = "modulus": <BIGINT>

    =C2=A0 }

    }

    =C2=A0

    <= /div>

    # payload 2

    {

    = =C2=A0 ...,

    =C2=A0 "= ;public_key": {

    =C2= =A0=C2=A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<= ;encoded string>"

    =C2=A0 }

    }

    =C2=A0

    =

    In both cases, the type of "public_key" fi= eld is a dictionary. In both cases, they even have the same keys. However, = the values in the dictionaries are entirely different, and an implementatio= n will have to branch to at least two possible decoding mechanisms. To make= things worse, some JSON implementations may choose to encode non-dictionar= y values as strings, so it is possible for an originator to transmit what t= hey expect and believe to be payload 1 format, but which the receiver will = interpret to be in payload 2 format. And if the encoded string contains onl= y digits, it will even parse correctly as a bignum.

    =

    =C2=A0

    While the above is clearly a manufactured scenario, it nonethele= ss demonstrates the potential for logic bugs with polymorphic JSON. With ri= cher types and more complex dictionaries, there will surely be more room fo= r errors.

    =C2=A0<= u>

    Ambiguity in protocols is alway= s a source of implementation complexity and interoperability snags, but in = an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is= intended to supersede Oauth1/2, wouldn't it be in everyone's inter= est to keep implementation complexity and mistake potential to a minimum?

    =C2=A0

    <= /div>

    Best regards,

    =

    Mika

    =C2=A0

    -- <= /p>

    Mika Bostr=C3= =B6m

    Smarkets

    --
    T= XAuth mailing list
    TXAuth@ietf.org
    https://www.ie= tf.org/mailman/listinfo/txauth

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/txauth

    Error! Filename not specified.=E1=90=A7<= /span>

    =C2=A0

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    -- TXAuth mailing list TXAuth@ietf.org https://www= .ietf.org/mailman/listinfo/txauth


    --000000000000f4b4bb05b287ad27-- From nobody Sun Oct 25 19:04:35 2020 Return-Path: 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 072413A17BA for ; Sun, 25 Oct 2020 19:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 xC2xqPDzHC_o for ; Sun, 25 Oct 2020 19:04:28 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 7E8253A17B9 for ; Sun, 25 Oct 2020 19:04:28 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id z2so6817928ilh.11 for ; Sun, 25 Oct 2020 19:04:28 -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=S/F8up78BOceNvKBrRml9UAWyfJClHi2CRfXblBwYNc=; b=PRBT6V2oOiCNN0tgEnKPrAplXtnv5CRxRvQ3et5NKbgn4V0K2culS1LXY9hsaL+v8D PzmzxQz5+swI3a4tSqU68HUjN37HFfX0e+pfYZpzUlKLtwlJ+ytEx3LK6ZlIhtNj/mDE SrNWwWl0aO2CmztfkuUCRHYfgaRm5wlLeQeMZavetG7H3wEeK8YGCjiL9ck7Vqps08uL UNOo4PB8uJm7Mwgvyg4UFQWvufxnBO7+2o246Iu3eb8F7dfN9k4ixX9TDjVAR5Sy7+co +YqmTkWtyLCaPtErB2J6hW4DNUPBwa5xoN35NUtnXWRxBRXgwHT9Afm9CI3JOfhB4Me+ OyJw== 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=S/F8up78BOceNvKBrRml9UAWyfJClHi2CRfXblBwYNc=; b=R2T4/zR/A0pEVk63yLXA7t03EjWn548+kIkZwTSZsINNkqAkqltAL0GW7oKhEK+Y6n tykkuefszvR0LWC7mDL5Mt9hQhtukDbm1ZqqgEk14/zi//yKG/YVva2FR3Phz/HTCGOq ninTdOQz/pCszU2eaZx2xvtawklDJ6Yf3L2dYrB3D+ztf//I+4MtOiagvR8qCm48JMIw w5Juq5VHzaIVUVB/0Pmn73wJyABzib/7judwzcGiXfXg+K7W6Y6cSMJFVs0u4yx3j32E HL5Ci+AO90oRptlXH+XHyjT8NVLpsUidbYJoEMFPO3aSl0eal0/s5naR9FY5ldIba4vM AkZA== X-Gm-Message-State: AOAM533089Ke7KHBEpkcQeK+65Is9+2qM4yZ4MRaydVru2+Nc6RPdWSB N8SmYC4J/t7strq0UKCpxpwekY8Hqq7D+FQT1Hg= X-Google-Smtp-Source: ABdhPJywRklOIepX6JQF1374hoYReamPRfShTlN7OwClz2u5SWY7dXX3/UDy56A8HCGdbrotjTh5VGhGFAhUCMDsZEc= X-Received: by 2002:a92:1548:: with SMTP id v69mr4274050ilk.68.1603677867391; Sun, 25 Oct 2020 19:04:27 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 26 Oct 2020 03:04:14 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000009ec10e05b2895917" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 02:04:33 -0000 --0000000000009ec10e05b2895917 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Well technically yes. Obviously the client can present any interface it seems fit. Still there's the question of the common model we want to present to the outside world and supported by the protocol itself (which client libraries all build upon). But beneath the polyphormism question, the HN debate seems on the surface a lot like the original xyz (polyphormism goes along with the reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where the client design has more latitude). Just explained differently, by outside people with different agendas. Which is a bit weird because many of the critics on HN (who criticize polyphormism) also seem to really dislike OAuth in the first place (the inconsistencies are partially due to a bunch of different people commenting). Really to me there's no fundamental truth behind that question. It's a matter of preference and priorities in the design. Whatever choices we make, we'll have to be prepared to explain and justify them in the open, even to some people that will dislike pretty much whatever we do (because it's fun to look smart and critize without proposing alternatives). And we owe these answers to people like Mika, who genuinely try to make the best of it. Fabien Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a =C3= =A9crit : > Hi Fabien > > A library developer can provide whatever abstraction layer makes sense fo= r > the library's target audience and language. > > If the client library developer wants to use polymorphism in the interfac= e > presented to the user's of the library, the library developer can do that > independent of polymorphism in the protocol, and vice versa > > =3D> polymorphism in the protocol has no impact on client library develop= ers > > > =E1=90=A7 > > On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault > wrote: > >> I'm just realizing your "least to most important" might actually say the >> same as what I was trying to say. So I'm not even sure what we're arguin= g >> against :-) >> >> In brief my point if it wasn't clear is that we should be crystal clear >> on where we put the cursor of simplicity, because this can mean differen= t >> things for different people and different roles. >> And as we see on HN we need to better explain our design choices. >> >> >> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >> a =C3=A9crit : >> >>> Hi Dick, >>> >>> Independantly from the debate on polyphormism, I beg to differ on your >>> order preference. >>> >>> Your assumption is that AS devs matter the most, because they're doing >>> the important security implementation. But eating our own dogfood might >>> help a lot to change that view. Most security issues occur because user= s of >>> the spec are unable to deal with the complexity that is passed onto the= m. >>> >>> 99% of the people that will actually use the output of the work are >>> application developers (client or RS) and their own users. >>> >>> Our intent as well as the protocol drive the usage. Client libraries ma= y >>> help, but they're not a silver bullet, especially because GNAP ultimate= ly >>> has no control about what people do there (for better or worse). And >>> everything we do here will help get to the better part. >>> >>> I'm not saying we don't intend to also care about AS developers >>> (beginning with ourselves) but it's a second order optimisation. And si= nce >>> it's a tendancy we're leaning towards by default, I'm pretty sure we wo= n't >>> forget that anyway. >>> >>> Fabien >>> >>> >>> >>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a >>> =C3=A9crit : >>> >>>> I'm confused by your logic Fabien. >>>> >>>> If a client library developer wants to expose polymorphism, they can d= o >>>> that independent of what is in the protocol. >>>> >>>> I differ on who our stakeholders are. >>>> >>>> I think our stakeholders are in least to most important: >>>> >>>> >>>> - AS developer >>>> - RS developer >>>> - client developer >>>> - user >>>> >>>> >>>> A client library developer can expose whatever interface they want to >>>> simplify implementation. >>>> >>>> I list the user so that we don't lose site of a critical role. >>>> >>>> /Dick >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi there, >>>>> >>>>> Let me try to approach the issue under a different light. More like a >>>>> product manager would deal with feature selection to make it intuitiv= e for >>>>> its users. >>>>> >>>>> For most people, riding a bike is far easier than using a unicycle. >>>>> Feels more stable. And yet it's way easier to design for a single whe= el >>>>> than to build with 2. Because then you'll need a lot more accessories >>>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to b= e a >>>>> brittle process, it can be industrialized. >>>>> >>>>> Back to the GNAP topic. >>>>> Ultimately we should strive to make the spec as simple as can be. But >>>>> we need to ask: simple for whom? For the bike owner or for the bike v= endor? >>>>> (short answer: the priority should be simplicity for spec users, not >>>>> spec implementers and even less spec designers). >>>>> >>>>> The initial question that is asked is very interesting: isn't the >>>>> design flawed if GNAP is using json polyphormism? Or if the AS needs = to >>>>> handle the state of the request? Or if we must handle token revocatio= n? Or >>>>> if we are looking for a global unique identifier? The argument stems = of the >>>>> fact that is still arguably harder and more error prone to implement.= Fair >>>>> enough. >>>>> >>>>> From a spec implementer's perspective, it may well be more complex. I= t >>>>> mostly impacts the json library you'll end up using, plus a bit of >>>>> input/output decoration around it. Even golang provides utilities for= this, >>>>> despite not exactly being made for this kind of purpose. >>>>> My practical experience implementing it is that it's not that big a >>>>> deal. I mean, I wished it could be simpler, but it's manageable and t= here >>>>> are other ways to reach levels of insurance that it does work as inte= nded >>>>> (json schema, test cases to validate the implementation, etc.). Argua= bly it >>>>> is still easier from an implementation perspective than say, json-ld,= which >>>>> is massively used in the SSI community. >>>>> >>>>> But ultimately who are we designing for? Are we striving to go easy o= n >>>>> the spec implementer? Or are we trying to make sure end-developers us= ing >>>>> the client libraries won't shoot themselves in the foot? >>>>> >>>>> The job to be done (JTBD), from the end-developer's perspective, is t= o >>>>> efficiently ship an application. And provide authN/authZ capabilities= for >>>>> end-users by relying on some well known implementation. >>>>> In turn, this spec implementer will rely on cryptographic utility >>>>> libraries that deals internally with the complexity of their own doma= in, so >>>>> that we don't have to. And here we could launch another HN flame war = that >>>>> starts with the title "JWT sucks because". Which does have its set of= very >>>>> real issues but that's beyond the point. >>>>> Note that any decent flamewar will be efficiently fueled by people >>>>> hating medium. Is it outrageous for blog posts to be behind a paywall= ? >>>>> Maybe but it's even more outrageous to lack consistency, either by no= t >>>>> knowing how to get around a paywall if you're into a hacker punk move= ment, >>>>> or on the contrary by to not paying a subscription if you believe tha= t >>>>> surveillance capitalism, to reuse Zuboff's terms, should be eradicate= d. >>>>> What likely seems an unnecessary sidenote tries to illustrate the >>>>> point: for Justin it was easier to publish on medium, because as a bl= og >>>>> publisher, you might not want to deal with hosting your own blog. But= maybe >>>>> as a reader you'll find that annoying. Different audiences, different= JTBD, >>>>> different tradeoffs. >>>>> >>>>> Polyphormism is a tool that enables the end-developer to have minimal >>>>> knowledge of what it means to deal with a GNAP client library. You pr= epare >>>>> the request, send to the endpoint and you're good to go. Massively si= mpler >>>>> than OAuth2 or any similar protocol by the way (as anyone with teachi= ng >>>>> experience on the subject might acknowledge). And there's a lot more= to be >>>>> done to make sure we indeed reduce the complexity for the end-develop= er and >>>>> the end-user. >>>>> >>>>> If we find a better way to deal with that simplicity balance, I'm all >>>>> in. But the arguments need to be way more convincing than just saying= that >>>>> it may be difficult to implement or validate. >>>>> >>>>> Cheers. >>>>> Fabien >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a >>>>> =C3=A9crit : >>>>> >>>>>> >>>>>> >>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote= : >>>>>> >>>>>> Justin >>>>>> >>>>>> I did note that I was the one that argued for instance_id being in >>>>>> the object. Since it is in the object in the current draft, not incl= uding a >>>>>> pass by reference option would be preferable. >>>>>> >>>>>> As for concrete examples: >>>>>> - version of client >>>>>> - version of OS >>>>>> - security attestation of OS / device >>>>>> - location of client device >>>>>> - network client is operating on >>>>>> >>>>>> These are all attributes of the client that an AS may require on the >>>>>> initial grant request, and in future grant requests (which is when a= n >>>>>> instance_id) would be used. >>>>>> >>>>>> >>>>>> This is where our interpretations differ: I don=E2=80=99t see these = as >>>>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the = key, display >>>>>> information, class identifiers, and other items currently represente= d by an >>>>>> instance_id are attributes of the client instance. The attestation >>>>>> components don=E2=80=99t modify the instance so much as present addi= tional >>>>>> information on top of the client instance itself. This is why I argu= e that >>>>>> they ought to be handled in a separate object, so you=E2=80=99d have= something like >>>>>> this strawman: >>>>>> >>>>>> { >>>>>> >>>>>> posture: { >>>>>> software_version: 1.2.3, >>>>>> os_version: 14.3.2 >>>>>> device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 } >>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>>>> }, >>>>>> >>>>>> client: =E2=80=9Cclient-541-ab" >>>>>> >>>>>> } >>>>>> >>>>>> This is a more fundamental question about GNAP than whether the >>>>>> syntax uses polymorphism: this is about GNAP being very explicit abo= ut the >>>>>> data model of its elements. OAuth 2=E2=80=99s incredibly loose and b= road model of >>>>>> what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is = deeply problematic in >>>>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with = having to >>>>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that d= oesn=E2=80=99t fully capture >>>>>> the different aspects that are out there. I think we=E2=80=99re gett= ing closer here >>>>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80= =9D, but we still need to >>>>>> be more precise about what exactly a client instance includes, and w= hat it >>>>>> does not. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> /Dick >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Dick, >>>>>>> >>>>>>> As you=E2=80=99ll recall, I argued against including the client ins= tance >>>>>>> identifier inside of the object as a mutually-exclusive field preci= sely >>>>>>> because of the principle violation that you are pointing out here, = and so >>>>>>> it=E2=80=99s important to point out that the current text is a comp= romise that >>>>>>> needs to be examined in the wider experience of the working group. = I am on >>>>>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2= =80=9D option within an >>>>>>> object, but this needs to be explored. >>>>>>> >>>>>>> The crux of my argument is that is exactly a case of >>>>>>> pass-by-reference vs pass-by-value, and that runtime attestations a= re not >>>>>>> part of the =E2=80=9Cclient instance=E2=80=9D value itself but rath= er belong outside of >>>>>>> that object in a another part of the request. As stated in the edit= orial >>>>>>> notes in this section, we need to look carefully at how these conce= pts fit >>>>>>> within the model and where we would want to put them. Without concr= ete >>>>>>> examples of what these extensions look like and how they=E2=80=99re= generated, that >>>>>>> is nearly impossible to do at this stage. I look forward to seeing = examples >>>>>>> of this kind of data and how it can fit into the protocol. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>> Hey Justin, >>>>>>> >>>>>>> As the draft has evolved, I question the continued use of >>>>>>> polymorphism. Note that I appreciate the elegance of using a string= for >>>>>>> pass-by-reference, and an object for pass-by-value. >>>>>>> >>>>>>> In the current draft, the >>>>>>> >>>>>>> Every time you create or process a field it will mean only one >>>>>>> thing, and there=E2=80=99s only one field to look at to answer a qu= estion. >>>>>>> >>>>>>> >>>>>>> is violated in 2.3.1. Identifying the RC Instance >>>>>>> >>>>>>> >>>>>>> >>>>>>> instance_id An identifier string that the AS can use to identif= y >>>>>>> the >>>>>>> particular instance of this RC. The content and structure of >>>>>>> this >>>>>>> identifier is opaque to the RC. >>>>>>> >>>>>>> "client": { >>>>>>> "instance_id": "client-541-ab" >>>>>>> } >>>>>>> >>>>>>> If there are no additional fields to send, the RC MAY send the >>>>>>> instance identifier as a direct reference value in lieu of the >>>>>>> object. >>>>>>> >>>>>>> "client": "client-541-ab" >>>>>>> >>>>>>> >>>>>>> The instance identifier can be sent two ways. Polymorphism is a >>>>>>> convenience for the client, but requires the server to have two cod= e paths >>>>>>> for "instance_id". We discussed this in the design team, and I arg= ued for >>>>>>> having "instance_id" in the "client" object so that any updates, su= ch as >>>>>>> new devices assertions, could be in the "client" object. As noted a= bove, >>>>>>> while I appreciate the elegance of using a string (handle) to refer= ence a >>>>>>> previously provided object, it complicates how to update an existin= g object >>>>>>> while providing the reference. >>>>>>> >>>>>>> In your example of the "key" object below, setting "proof" to beare= r >>>>>>> would avoid the issue you describe: >>>>>>> >>>>>>> { >>>>>>> "key": { >>>>>>> "proof": "bearer" >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> In your example, when processing the "key" object, code is having t= o >>>>>>> check both the JSON type of the property, as well as check the valu= e of the >>>>>>> "proof" property. In the example I provided, only the value of "pro= of" >>>>>>> needs to be checked. The "proof" property is acting as a type for t= he "key" >>>>>>> object. >>>>>>> >>>>>>> Not being a Java programmer, I don't know how this would work in a >>>>>>> Java implementation, but node.js, the processing would need to be d= one as >>>>>>> above. >>>>>>> >>>>>>> On a related note, there was significant negative feedback on >>>>>>> handles and polymorphism in the Hacker News article >>>>>>> https://news.ycombinator.com/item?id=3D24855750 >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Mika, >>>>>>>> >>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able to see th= e forum >>>>>>>> discussion that brought you here, and hopefully I can help clear u= p what I >>>>>>>> mean with how polymorphism is used in the proposal. The short vers= ion is >>>>>>>> that the goal is to *avoid* the kinds of ambiguity that make >>>>>>>> insecure protocols, and so in that goal we=E2=80=99re fully aligne= d. I think that >>>>>>>> using polymorphism in very specific ways can help that goal =E2=80= =94 just as I >>>>>>>> agree that misusing it or applying it sloppily can lead to ambiguo= us and >>>>>>>> insecure systems. >>>>>>>> >>>>>>>> Some background: I built out the XYZ protocol (one of the >>>>>>>> predecessors to the initial GNAP Draft) in Java using strongly typ= ed >>>>>>>> parsers and Java objects specifically to prove to myself that it c= ould be >>>>>>>> done in a way that made any sense in the code. (My own open source >>>>>>>> implementation is at https://github.com/bspk/oauth.xyz-java, but >>>>>>>> note that it=E2=80=99s not yet up to date with the GNAP spec). It = was important to >>>>>>>> me that I be able to use the system-wide configured parsers to imp= lement >>>>>>>> this and not have to resort to stepping through elements completel= y by >>>>>>>> hand. Java doesn=E2=80=99t make it simple to get the hooks into th= e right places >>>>>>>> (especially with the Jackson parser that I used), but it is defini= tely >>>>>>>> possible to create a deterministic and strongly-typed parser and s= erializer >>>>>>>> for this kind of data structure. Some of the rationale for using >>>>>>>> polymorphism is covered in the trailing appendix of the draft docu= ment ( >>>>>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.h= tml#name-json-structures-and-polymor), >>>>>>>> but it=E2=80=99s still good to discuss this here as the working gr= oup decides which >>>>>>>> approaches to take. >>>>>>>> >>>>>>>> The driving reason for using polymorphism at the protocol level wa= s >>>>>>>> to simplify the protocol and make it :more: deterministic to creat= e and >>>>>>>> process, not less. Every time you create or process a field it wil= l mean >>>>>>>> only one thing, and there=E2=80=99s only one field to look at to a= nswer a question. >>>>>>>> Without polymorphic field values, you usually need to rely on mutu= al >>>>>>>> exclusivity of fields, which is prone to failure and requires addi= tional >>>>>>>> error checking. Take for example the key binding of access tokens.= An >>>>>>>> access token could be bound to the RC=E2=80=99s key used during th= e request, to a >>>>>>>> different key chosen by the AS, or it could be a bearer token with= no key >>>>>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we = can define it in terms of >>>>>>>> boolean values and objects and express this set of mutually-exclus= ive >>>>>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need t= o have different >>>>>>>> fields for the options and include additional checks in your parse= r to make >>>>>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could= get hit with >>>>>>>> this potential security vulnerability in an object: >>>>>>>> >>>>>>>> { >>>>>>>> key: { >>>>>>>> proof: httpsig, >>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>> }, >>>>>>>> bearer_token: true, >>>>>>>> bind_to_rc_key: true >>>>>>>> } >>>>>>>> >>>>>>>> This would be an illegal object as per this alternate proposal, bu= t >>>>>>>> then you=E2=80=99d have to check each field and make sure it wasn= =E2=80=99t put next to >>>>>>>> others in the same object. I=E2=80=99ve done this exercise with ma= ny other >>>>>>>> protocols and it=E2=80=99s both error prone and easy to ignore sin= ce all the =E2=80=9Cgood=E2=80=9D >>>>>>>> examples would pass code that doesn=E2=80=99t check this. With the= polymorphic >>>>>>>> approach to this same field, each of these three mutually-exclusiv= e states >>>>>>>> is written in a way that they cannot be sent together. It=E2=80=99= s not just >>>>>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSO= N itself. >>>>>>>> >>>>>>>> { >>>>>>>> key: { >>>>>>>> proof: httpsig, >>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> // bearer token >>>>>>>> >>>>>>>> { >>>>>>>> key: false >>>>>>>> } >>>>>>>> >>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>> >>>>>>>> { >>>>>>>> key: true >>>>>>>> } >>>>>>>> >>>>>>>> If someone sends a different type for this field, like an array or >>>>>>>> number or a null, this doesn=E2=80=99t have a defined interpretati= on in the >>>>>>>> protocol and would be a protocol level error. >>>>>>>> >>>>>>>> While it might sound like polymorphism means that any field could >>>>>>>> have any type or value, the opposite is true: each possible value = is >>>>>>>> explicitly typed, it=E2=80=99s just that there are potentially dif= ferent types that >>>>>>>> express meaning for the field. This applies to all members of all = objects >>>>>>>> (dictionaries) as well as all members of an array (list). Every ti= me you >>>>>>>> process a field value or other element, you look at the type and t= hen the >>>>>>>> value to determine what to do with that typed value. >>>>>>>> >>>>>>>> In your example below, each field within the dictionary would also >>>>>>>> need to be typed, and each type would need to have a clear indicat= ion of >>>>>>>> its meaning. To take your strawman key format below, the =E2=80=9C= modulus=E2=80=9D field >>>>>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an >>>>>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition w= ould further say what >>>>>>>> exactly the encoding of the string would be. That means that when = you read >>>>>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any = confusion on what the value was >>>>>>>> or how it was represented, regardless of the input format. Seeing = a number >>>>>>>> there means exactly one interpretation and seeing a string means e= xactly >>>>>>>> one (different) interpretation =E2=80=94 but importantly, both of = them are a >>>>>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that det= ermines the type. An >>>>>>>> implementation would likely use an internal BigInteger type of obj= ect to >>>>>>>> represent the field value after parsing, so the question is how to= go from >>>>>>>> the JSON value (which is typed) into the BigInteger value.You don= =E2=80=99t just >>>>>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, yo= u apply it to all >>>>>>>> sub-fields of that object. >>>>>>>> >>>>>>>> So let=E2=80=99s dig into the specific bug you bring up in the str= awman, >>>>>>>> because it=E2=80=99s interesting: A JSON encoder that encodes numb= ers as strings, >>>>>>>> and not numbers, is not compliant with the JSON definitions of the= field in >>>>>>>> question. For another example, the quoted string value of =E2=80= =9Ctrue=E2=80=9D is not >>>>>>>> equivalent to the boolean value true in JSON, and they shouldn=E2= =80=99t be treated >>>>>>>> the same by a parser implementation when mapping to a concrete obj= ect. It=E2=80=99s >>>>>>>> in this kind of automated guessing that this class of bugs occur, = and >>>>>>>> that=E2=80=99s going to be the case whether or not you take advan= tage of JSON=E2=80=99s >>>>>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser lib= rary was trying >>>>>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mappi= ng, but ended up >>>>>>>> introducing errors in more strict components downstream. This is s= omething >>>>>>>> that protocol designers need to be aware of and guard against in t= he design >>>>>>>> of the protocol to reduce possible ambiguities. Within GNAP today,= we >>>>>>>> generally have things that branch whether they=E2=80=99re an objec= t (for a rich >>>>>>>> description of something) or some non-structured special value (fo= r a >>>>>>>> reference or other item). >>>>>>>> >>>>>>>> The design team created some simple JSON Schemas for parts of the >>>>>>>> protocol during our discussion, but we didn=E2=80=99t include them= in the design >>>>>>>> document due to both lack of time to keep it updated with the rapi= d changes >>>>>>>> to the protocol during the design team discussion, and not knowing= if there >>>>>>>> would be interest in such material. I personally think it would be= helpful >>>>>>>> to include as an informative reference in the final document, but = that=E2=80=99s >>>>>>>> something for the working group to take up eventually. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>> Hello, everyone. >>>>>>>> >>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion >>>>>>>> forum and when I made note about certain concerns, I was requested= to send >>>>>>>> my comments to this working group. >>>>>>>> >>>>>>>> In short, I believe that the use of polymorphic JSON in the >>>>>>>> protocol invites subtle and confusing implementation problems. I a= lso >>>>>>>> searched through the WG archives, and noticed that similar concern= s were >>>>>>>> noted, briefly, in a thread in July. >>>>>>>> >>>>>>>> The problem with polymorphic values, as I see it, is that >>>>>>>> implementations will need to branch on the (inferred) type of a gi= ven >>>>>>>> field. This isn't quite as bad if the types are strictly different= , but >>>>>>>> allows for subtle bugs when the value in question is a dictionary.= What >>>>>>>> makes this unappealing is that "subtle bugs" in security protocols= have a >>>>>>>> habit of turning into vulnerabilities. >>>>>>>> >>>>>>>> Let's say we have these imaginary payloads, both possible and vali= d >>>>>>>> in the same protocol step: >>>>>>>> >>>>>>>> # payload 1 >>>>>>>> { >>>>>>>> ..., >>>>>>>> "public_key": { >>>>>>>> "alg": "rsa", >>>>>>>> "modulus": >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> # payload 2 >>>>>>>> { >>>>>>>> ..., >>>>>>>> "public_key": { >>>>>>>> "alg": "rsa", >>>>>>>> "modulus": "" >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> In both cases, the type of "public_key" field is a dictionary. In >>>>>>>> both cases, they even have the same keys. However, the values in t= he >>>>>>>> dictionaries are entirely different, and an implementation will ha= ve to >>>>>>>> branch to at least two possible decoding mechanisms. To make thing= s worse, >>>>>>>> some JSON implementations may choose to encode non-dictionary valu= es as >>>>>>>> strings, so it is possible for an originator to transmit what they= expect >>>>>>>> and believe to be payload 1 format, but which the receiver will in= terpret >>>>>>>> to be in payload 2 format. And if the encoded string contains only= digits, >>>>>>>> it will even parse correctly as a bignum. >>>>>>>> >>>>>>>> While the above is clearly a manufactured scenario, it nonetheless >>>>>>>> demonstrates the potential for logic bugs with polymorphic JSON. W= ith >>>>>>>> richer types and more complex dictionaries, there will surely be m= ore room >>>>>>>> for errors. >>>>>>>> >>>>>>>> Ambiguity in protocols is always a source of implementation >>>>>>>> complexity and interoperability snags, but in an AuthN/AuthZ proto= col it is >>>>>>>> worse: it's terrifying. If GNAP/Oauth3 is intended to supersede Oa= uth1/2, >>>>>>>> wouldn't it be in everyone's interest to keep implementation compl= exity and >>>>>>>> mistake potential to a minimum? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mika >>>>>>>> >>>>>>>> -- >>>>>>>> Mika Bostr=C3=B6m >>>>>>>> Smarkets >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> --0000000000009ec10e05b2895917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Dick,

    Wel= l technically yes. Obviously the client can present any interface it seems = fit.=C2=A0

    Still there&#= 39;s the question of the common model we want to present to the outside wor= ld and supported by the protocol itself (which client libraries all build u= pon).=C2=A0

    But beneath = the polyphormism question, the HN debate seems on the surface a lot like th= e original xyz (polyphormism goes along with the reduced endpoint model) vs= xauth (a bit closer to OAuth2 in spirit, and where the client design has m= ore latitude). Just explained differently, by outside people with different= agendas.=C2=A0

    Which is= a bit weird because many of the critics on HN (who criticize polyphormism)= also seem to really dislike OAuth in the first place (the inconsistencies = are partially due to a bunch of different people commenting).=C2=A0

    Really to me there's no fun= damental truth behind that question. It's a matter of preference and pr= iorities in the design. Whatever choices we make, we'll have to be prep= ared to explain and justify them in the open, even to some people that will= dislike pretty much whatever we do (because it's fun to look smart and= critize without proposing alternatives). And we owe these answers to peopl= e like Mika, who genuinely try to make the best of it.=C2=A0

    Fabien=C2=A0

    Le lun. 26 oct. 202= 0 =C3=A0 00:58, Dick Hardt <dick= .hardt@gmail.com> a =C3=A9crit=C2=A0:
    Hi Fabien

    A library developer= can provide whatever abstraction layer makes sense for the library's t= arget=C2=A0audience and language.

    If the client li= brary=C2=A0developer wants to use polymorphism=C2=A0in the interface presen= ted to the user's of the library, the library developer can do that ind= ependent of polymorphism in the protocol, and vice versa=C2=A0
    =3D> polymorphism in the protocol has no impact on client l= ibrary developers


    3D""=E1=90= =A7

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
    I'm just realizing your "least t= o most important" might actually say the same as what I was trying to = say. So I'm not even sure what we're arguing against :-)=C2=A0

    In brief my point if it wasn't= clear is that we should be crystal clear on where we put the cursor of sim= plicity, because this can mean different things for different people and di= fferent roles.=C2=A0
    And as we see on HN we need to = better explain our design choices.=C2=A0

    <= /div>
    L= e dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@g= mail.com> a =C3=A9crit=C2=A0:
    Hi Dick,

    =
    Independantly from the debate on polyphormism, I beg to d= iffer on your order preference.=C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're doing the important s= ecurity implementation. But eating our own dogfood might help a lot to chan= ge that view. Most security issues occur because users of the spec are unab= le to deal with the complexity that is passed onto them.=C2=A0
    =

    99% of the people that will a= ctually use the output of the work are application developers (client or RS= ) and their own users.=C2=A0

    Our intent as well as the proto= col drive the usage. Client libraries may help, but they're not a silve= r bullet, especially because GNAP ultimately has no control about what peop= le do there (for better or worse). And everything we do here will help get = to the better part.=C2=A0

    I'm not saying we don't intend to also care about AS deve= lopers (beginning with ourselves) but it's a second order optimisation.= And since it's a tendancy we're leaning towards by default, I'= m pretty sure we won't forget that anyway.=C2=A0

    Fabien=C2=A0



    Le sa= m. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.= com> a =C3=A9crit=C2=A0:
    I'm confused by your logic Fabien.
    If a client library developer wants to expose polymorphism,= they can do that independent of what is in the protocol.=C2=A0
    <= br>
    I differ on who our stakeholders are.=C2=A0

    I think our stakeholders are in least to most important:
    =
    • AS developer
    • RS developer
    • client dev= eloper
    • user

    A client library dev= eloper can expose whatever interface they want to simplify implementation.<= /div>

    I list the user so that we don't lose site of = a critical role.

    /Dick

    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 6:27 PM Fab= ien Imbault <fabien.imbault@gmail.com>= ; wrote:
    Hi there,=C2=A0

    Let me try to approach the issue under a different light. More like a pr= oduct manager would deal with feature selection to make it intuitive for it= s users.=C2=A0

    For most people, riding a bike is far easier than using a unicycle. Feel= s more stable. And yet it's way easier to design for a single wheel tha= n to build with 2. Because then you'll need a lot more accessories (cha= in, chain ring, etc.). Even so producing a bike doesn't have to be a br= ittle process, it can be industrialized.=C2=A0

    <= /div>
    Back to the GNAP topic.=C2=A0
    <= span style=3D"font-family:sans-serif">Ultimately we should strive to make t= he spec as simple as can be. But we need to ask: simple for whom? For the b= ike owner or for the bike vendor?=C2=A0
    <= span style=3D"font-family:sans-serif">(short answer: the priority should be= simplicity for spec users, not spec implementers and even less spec design= ers).=C2=A0

    The initial question that is asked= is very interesting: isn't the design flawed if GNAP is using json pol= yphormism? Or if the AS needs to handle the state of the request? Or if we = must handle token revocation? Or if we are looking for a global unique iden= tifier? The argument stems of the fact that is still arguably harder and mo= re error prone to implement. Fair enough.=C2=A0

    =
    From a spec implementer's perspective, it may w= ell be more complex. It mostly impacts the json library you'll end up u= sing, plus a bit of input/output decoration around it. Even golang provides= utilities for this, despite not exactly being made for this kind of purpos= e.
    My practical experience implementing it is that i= t's not that big a deal. I mean, I wished it could be simpler, but it&#= 39;s manageable and there are other ways to reach levels of insurance that = it does work as intended (json schema, test cases to validate the implement= ation, etc.). Arguably it is still easier from an implementation perspectiv= e than say, json-ld, which is massively used in the SSI community.=C2=A0

    But ultimately who are we = designing for? Are we striving to go easy on the spec implementer? Or are w= e trying to make sure end-developers using the client libraries won't s= hoot themselves in the foot?

    The job to be done (JTBD), from the end-developer's perspective, i= s to efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation.=C2=A0
    In turn, this spec implementer will rely on cryptographic uti= lity libraries that deals internally with the complexity of their own domai= n, so that we don't have to. And here we could launch another HN flame = war that starts with the title "JWT sucks because". Which does ha= ve its set of very real issues but that's beyond the point.=C2=A0
    =
    Note that any decent flamewar will be efficiently fueled = by people hating medium. Is it outrageous for blog posts to be behind a pay= wall? Maybe but it's even more outrageous to lack consistency, either b= y not knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you believe= that surveillance capitalism, to reuse Zuboff's terms, should be eradi= cated.=C2=A0
    What likely seems an unnecessary sideno= te tries to illustrate the point: for Justin it was easier to publish on me= dium, because as a blog publisher, you might not want to deal with hosting = your own blog. But maybe as a reader you'll find that annoying. Differe= nt audiences, different JTBD, different tradeoffs.=C2=A0

    Polyphormism is a tool that enables the en= d-developer to have minimal knowledge of what it means to deal with a GNAP = client library. You prepare the request, send to the endpoint and you'r= e good to go. Massively simpler than OAuth2 or any similar protocol by the = way (as anyone with teaching experience on the subject might acknowledge). = And=C2=A0 there's a lot more to be done to make sure we indeed reduce t= he complexity for the end-developer and the end-user.=C2=A0

    If we find a better way to deal with = that simplicity balance, I'm all in. But the arguments need to be way m= ore convincing than just saying that it may be difficult to implement or va= lidate.=C2=A0

    Cheers.
    Fabien





    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a = =C3=A9crit=C2=A0:
    On Oct 23, 2020, at 3:52= PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    <= div dir=3D"ltr">Justin

    I did note that I was the one tha= t argued for instance_id being in the object. Since it is in the object in = the current draft, not including a pass by reference option would be prefer= able.=C2=A0

    As for concrete examples:
    - = version of client
    - version of OS
    - security attestatio= n of OS / device
    - location of client device
    - network = client is operating on

    These are all attributes of= the client that an AS may require=C2=A0on the initial grant request, and i= n future grant requests (which is when an instance_id) would be used.
    =


    This is where o= ur interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes= of the client=E2=80=9D in the same way that the key, display information, = class identifiers, and other items currently represented by an instance_id = are attributes of the client instance. The attestation components don=E2=80= =99t modify the instance so much as present additional information on top o= f the client instance itself. This is why I argue that they ought to be han= dled in a separate object, so you=E2=80=99d have something like this strawm= an:

    {

    =C2=A0 posture: {
    =C2=A0 =C2=A0 software_version: 1.2.3,
    =C2=A0 =C2=A0 os_= version: 14.3.2
    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 som= e structure or signed blob? =E2=80=A6 }
    =C2=A0 =C2=A0 location: {= lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
    =C2=A0 },
    =

    =C2=A0 client: =E2=80=9Cclient-541-ab"
    <= br>
    }

    This is a more fundamental questio= n about GNAP than whether the syntax uses polymorphism: this is about GNAP = being very explicit about the data model of its elements. OAuth 2=E2=80=99s= incredibly loose and broad model of what the term =E2=80=9Cclient=E2=80=9D= is referring to, exactly, is deeply problematic in practice. We=E2=80=99re= even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully captur= e the different aspects that are out there. I think we=E2=80=99re getting c= loser here in GNAP with explicit definition of =E2=80=9Cclient instance=E2= =80=9D, but we still need to be more precise about what exactly a client in= stance includes, and what it does not.

    =C2=A0=E2= =80=94 Justin


    /Dick

    3D""=E1=90=A7
    On= Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wro= te:
    Dick,
    As you=E2=80=99ll recall, I argued against including the = client instance identifier inside of the object as a mutually-exclusive fie= ld precisely because of the principle violation that you are pointing out h= ere, and so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the working= group. I am on the side of removing the mutually-exclusive =E2=80=9Cinstan= ce_id=E2=80=9D option within an object, but this needs to be explored.

    The crux of my argument is that is exactly a case of p= ass-by-reference vs pass-by-value, and that runtime attestations are not pa= rt of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong = outside of that object in a another part of the request. As stated in the e= ditorial notes in this section, we need to look carefully at how these conc= epts fit within the model and where we would want to put them. Without conc= rete examples of what these extensions look like and how they=E2=80=99re ge= nerated, that is nearly impossible to do at this stage. I look forward to s= eeing examples of this kind of data and how it can fit into the protocol.

    =C2=A0=E2=80=94 Justin

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dic= k.hardt@gmail.com> wrote:

    Hey Justin,

    As the draft has evolved, I questi= on the continued use of polymorphism. Note that I appreciate the elegance= =C2=A0of using a string for pass-by-reference, and an object for pass-by-va= lue.

    In the current draft, the=C2=A0
    2.3.1.=C2=A0 Identifying the RC Instance<= /div>


    =C2=A0 =C2=A0instance_id =C2=A0An identi= fier string that the AS can use to identify the
    =C2=A0 =C2=A0 =C2= =A0 particular instance of this RC.=C2=A0 The content and structure of this=
    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.
    <= br>
    =C2=A0 =C2=A0"client": {
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0"instance_id": "client-541-ab"
    = =C2=A0 =C2=A0}

    =C2=A0 =C2=A0If there are no additi= onal fields to send, the RC MAY send the
    =C2=A0 =C2=A0instance id= entifier as a direct reference value in lieu of the
    =C2=A0 =C2=A0= object.

    =C2=A0 =C2=A0"client": "cli= ent-541-ab"

    The instance identif= ier can be sent two ways. Polymorphism is a convenience for the client, but= requires the server=C2=A0to have two code=C2=A0paths for "instance_id= ".=C2=A0 We discussed this in the design team, and I argued for having= "instance_id" in the "client" object=C2=A0so that any = updates, such as new devices assertions, could be in the "client"= object. As noted above, while I appreciate the elegance of using a string = (handle) to reference a previously provided object, it complicates how to u= pdate an existing object while providing the reference.

    In your example of the "key" object below, setting "pr= oof" to bearer would avoid the issue you describe:

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0&quo= t;proof": "bearer"
    =C2=A0 =C2=A0 }
    }
    <= br>
    In your example, when processing the "key" object, = code is having to check both the JSON type of the property, as well as chec= k the value of the "proof" property. In the example I provided, o= nly the value of "proof" needs to be checked. The "proof&quo= t; property is acting as a type for the "key" object.
    <= br>
    Not being a Java programmer, I don't know how this would = work in a Java implementation, but node.js, the processing would need to be= done as above.

    On a related note, there was signi= ficant negative feedback on handles and polymorphism in the Hacker News art= icle=C2=A0https://news.ycombinator.com/item?id=3D= 24855750=C2=A0

    /Dick

    =
    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu= > wrote:
    Hi Mika,

    Thanks for bringing this topic here =E2=80=94 = I was able to see the forum discussion that brought you here, and hopefully= I can help clear up what I mean with how polymorphism is used in the propo= sal. The short version is that the goal is to=C2=A0avoid=C2=A0the ki= nds of ambiguity that make insecure protocols, and so in that goal we=E2=80= =99re fully aligned. I think that using polymorphism in very specific ways = can help that goal =E2=80=94 just as I agree that misusing it or applying i= t sloppily can lead to ambiguous and insecure systems.

    =
    Some background: I built out the XYZ protocol (one of the predecessors= to the initial GNAP Draft) in Java using strongly typed parsers and Java o= bjects specifically to prove to myself that it could be done in a way that = made any sense in the code. (My own open source implementation is at=C2=A0<= a href=3D"https://github.com/bspk/oauth.xyz-java" rel=3D"noreferrer norefer= rer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" targ= et=3D"_blank">https://github.com/bspk/oauth.xyz-java, but note that it= =E2=80=99s not yet up to date with the GNAP spec). It was important to me t= hat I be able to use the system-wide configured parsers to implement this a= nd not have to resort to stepping through elements completely by hand. Java= doesn=E2=80=99t make it simple to get the hooks into the right places (esp= ecially with the Jackson parser that I used), but it is definitely possible= to create a deterministic and strongly-typed parser and serializer for thi= s kind of data structure. Some of the rationale for using polymorphism is c= overed in the trailing appendix of the draft document (https://www.ietf= .org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-= and-polymor), but it=E2=80=99s still good to discuss this here as the w= orking group decides which approaches to take.=C2=A0

    The driving reason for using polymorphism at the protocol level was to s= implify the protocol and make it :more: deterministic to create and process= , not less. Every time you create or process a field it will mean only one = thing, and there=E2=80=99s only one field to look at to answer a question. = Without polymorphic field values, you usually need to rely on mutual exclus= ivity of fields, which is prone to failure and requires additional error ch= ecking. Take for example the key binding of access tokens. An access token = could be bound to the RC=E2=80=99s key used during the request, to a differ= ent key chosen by the AS, or it could be a bearer token with no key at all.= By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in= terms of boolean values and objects and express this set of mutually-exclu= sive options in a non-ambiguous way. Without that, you=E2=80=99d need to ha= ve different fields for the options and include additional checks in your p= arser to make sure they weren=E2=80=99t sent simultaneously, otherwise you = could get hit with this potential security vulnerability in an object:

    {=C2=A0
    =C2=A0 =C2=A0 key: {
    =C2= =A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2= =80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 },
    =C2=A0 = =C2=A0 bearer_token: true,
    =C2=A0 =C2=A0 bind_to_rc_key: true
    }

    This would be an illegal object as per th= is alternate proposal, but then you=E2=80=99d have to check each field and = make sure it wasn=E2=80=99t put next to others in the same object. I=E2=80= =99ve done this exercise with many other protocols and it=E2=80=99s both er= ror prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples = would pass code that doesn=E2=80=99t check this. With the polymorphic appro= ach to this same field, each of these three mutually-exclusive states is wr= itten in a way that they cannot be sent together. It=E2=80=99s not just ill= egal, it=E2=80=99s impossible and enforced by the syntax of JSON itself.

    {=C2=A0
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: = { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 }
    }

    // bearer token

    {
    = =C2=A0 =C2=A0 key: false
    }

    // boun= d to the RC=E2=80=99s presented key

    {
    = =C2=A0 =C2=A0 key: true
    }

    If someone sen= ds a different type for this field, like an array or number or a null, this= doesn=E2=80=99t have a defined interpretation in the protocol and would be= a protocol level error.

    While it might sound like= polymorphism means that any field could have any type or value, the opposi= te is true: each possible value is explicitly typed, it=E2=80=99s just that= there are potentially different types that express meaning for the field. = This applies to all members of all objects (dictionaries) as well as all me= mbers of an array (list). Every time you process a field value or other ele= ment, you look at the type and then the value to determine what to do with = that typed value.

    In your example below, each fiel= d within the dictionary would also need to be typed, and each type would ne= ed to have a clear indication of its meaning. To take your strawman key for= mat below, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphic= ally as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cen= coded string=E2=80=9D (a JSON string). The definition would further say wha= t exactly the encoding of the string would be. That means that when you rea= d the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was or how it was represented, regardless of the input= format. Seeing a number there means exactly one interpretation and seeing = a string means exactly one (different) interpretation =E2=80=94 but importa= ntly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s th= e field that determines the type. An implementation would likely use an int= ernal BigInteger type of object to represent the field value after parsing,= so the question is how to go from the JSON value (which is typed) into the= BigInteger value.You don=E2=80=99t just apply the type rules on the =E2=80= =9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object= .=C2=A0

    So let=E2=80=99s dig into the specific bug= you bring up in the strawman, because it=E2=80=99s interesting: A JSON enc= oder that encodes numbers as strings, and not numbers, is not compliant wit= h the JSON definitions of the field in question. For another example, the q= uoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boole= an value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in th= is kind of automated guessing that this class of bugs occur, and that=E2=80= =99s going to be the case whether or not you take =C2=A0advantage of JSON= =E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a parser l= ibrary was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind= of mapping, but ended up introducing errors in more strict components down= stream. This is something that protocol designers need to be aware of and g= uard against in the design of the protocol to reduce possible ambiguities. = Within GNAP today, we generally have things that branch whether they=E2=80= =99re an object (for a rich description of something) or some non-structure= d special value (for a reference or other item).=C2=A0

    =
    The design team created some simple JSON Schemas for parts of the prot= ocol during our discussion, but we didn=E2=80=99t include them in the desig= n document due to both lack of time to keep it updated with the rapid chang= es to the protocol during the design team discussion, and not knowing if th= ere would be interest in such material. I personally think it would be help= ful to include as an informative reference in the final document, but that= =E2=80=99s something for the working group to take up eventually.

    =C2=A0=E2=80=94 Justin

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:
    Hello, everyone.

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and = when I made note about certain concerns, I was requested to send my comment= s to this working group.

    In short, I believe t= hat the use of polymorphic JSON in the protocol invites subtle and confusin= g implementation problems. I also searched through the WG archives, and not= iced that similar concerns were noted, briefly, in a thread in July.

    The problem with polymorphic values, as I see it, i= s that implementations will need to branch on the (inferred) type of a give= n field. This isn't quite as bad if the types are strictly different, b= ut allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocol= s have a habit of turning into vulnerabilities.

    Le= t's say we have these imaginary payloads, both possible and valid in th= e same protocol step:

    # payload 1
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =C2= =A0=C2=A0=C2=A0 "alg": "rsa",
    =C2=A0=C2= =A0=C2=A0 "modulus": <BIGINT>
    =C2=A0 }
    = }

    # payload 2
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0 "= ;alg": "rsa",
    =C2=A0=C2=A0=C2=A0 "modulus&quo= t;: "<encoded string>"
    =C2=A0 }
    }
    =

    In both cases, the type of "public_key" field= is a dictionary. In both cases, they even have the same keys. However, the= values in the dictionaries are entirely different, and an implementation w= ill have to branch to at least two possible decoding mechanisms. To make th= ings worse, some JSON implementations may choose to encode non-dictionary v= alues as strings, so it is possible for an originator to transmit what they= expect and believe to be payload 1 format, but which the receiver will int= erpret to be in payload 2 format. And if the encoded string contains only d= igits, it will even parse correctly as a bignum.

    While the above is clearly a manufactured scenario, it nonetheless demon= strates the potential for logic bugs with polymorphic JSON. With richer typ= es and more complex dictionaries, there will surely be more room for errors= .

    Ambiguity in protocols is always a source of imp= lementation complexity and interoperability snags, but in an AuthN/AuthZ pr= otocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supe= rsede Oauth1/2, wouldn't it be in everyone's interest to keep imple= mentation complexity and mistake potential to a minimum?

    =
    Best regards,
    Mika

    --
    Mika Bos= tr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    3D""= =E1=90=A7


    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    --0000000000009ec10e05b2895917-- From nobody Wed Oct 28 09:34:54 2020 Return-Path: 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 6A04F3A005F for ; Wed, 28 Oct 2020 09:28:57 -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_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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smarkets.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 gzTy_RHdmHlN for ; Wed, 28 Oct 2020 09:28:52 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 899BF3A0062 for ; Wed, 28 Oct 2020 09:28:52 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id w191so175866oif.2 for ; Wed, 28 Oct 2020 09:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smarkets.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G6VlBqucXva9KjrokR87UNiPr1+U/lbIoSmGYWZa1sE=; b=QyTYu2oAXfz2f/kb8gcSOrM5wikWJzoo9zuUmzebkn/yqu0Yyhx4kf4EIfUYvcNOB1 2AacgCzCdPY/kq1E/L2rDnOC9Cmuj/04A66+VyJf4RfOUW/JM4J1hnYjMhW9pacdnmbF 6ypc/WyMkKWX4jiXMcblbR1d9+DQUYx1CWbvmzQQ2h3/Iny0TBfd85+8xoCtadjO3RUI 9KBvb8eQy3GnpymWxR/BNGpFpLQ7XmVr8UBRL66cLQLTl3N0zRBrCAa46682HlyB3MIS ay+b9C0M/ekQ/figBbAkVRnceWx6fVWbdcmpBuRXP1A5M8OMpvaAWTlfVuhuxN807/rQ gJEg== 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=G6VlBqucXva9KjrokR87UNiPr1+U/lbIoSmGYWZa1sE=; b=o8I49VEeifM9X9UVCKXZbYzDKzRAX8b2IV72x0fw4ZyvR9PxwIfX07zqECwS091poA dX9XzO1j0HBO4AXROXMBVWVJ6Jk258bcUJjrDWEmUQMom3OgXgY9otJRI1mpyrz9NpcC 4O6pqt+jpAl1c/qAOEG+uiWbhlPMwx2mlvuJnVOHIrpoKkc/mbS6nwfU2xbwJLlqcIIR KvYnLWvjeqPGyb1vYXzXcD47C2/BnsathlWac9QkNGGw8IEMzNvsy/k5iMw0wMPAitkn 8rirc3bOG4Iz4PjWLBCjYIbVki2jCxW/6Uzn6rcWiG6pZFu0Stwy8ua8fDdn4D6+zHqu 8rmg== X-Gm-Message-State: AOAM530dO3zGqqw3tQFBRHJ+clH1a54SPWAv/y+aAjXcXyYNyQ21xYRz kdolpqmkKw1Uj5HG5gA6Mt6Zsn+7dEQ+wZ0nxKVxZnIdgLWthgej X-Google-Smtp-Source: ABdhPJxaHwjtyJ0HgRIqW9xAnjSke98WzuBGFsvigqqql6q4/wwORn9lfIRtr9Q7Hj3e8TWbUmmo7dwU9NipKavm2GI= X-Received: by 2002:aca:3687:: with SMTP id d129mr172424oia.100.1603902531400; Wed, 28 Oct 2020 09:28:51 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: =?UTF-8?Q?Mika_Bostr=C3=B6m?= Date: Wed, 28 Oct 2020 16:28:39 +0000 Message-ID: To: Fabien Imbault Cc: Dick Hardt , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a38b3305b2bda89f" Archived-At: X-Mailman-Approved-At: Wed, 28 Oct 2020 09:34:53 -0700 Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:28:58 -0000 --000000000000a38b3305b2bda89f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Looks like I stuck my finger in a hornets' nest. First off, apologies for not chipping in earlier, but there was a lot of material to digest. Also, warning: lots to read ahead. I'm one of those people who end up making use of AuthN/AuthZ functionality through a library. On top of that I can see myself being roped in as a server (AS) implementation help. So I'm approaching this from an outsider's perspective. Someone who expects to be exposed to the eventual RFC and all the nitty-gritty details. My relatively terse comment ended up at the top of the aforementioned HN thread, which didn't necessarily help. Sorry about that. Now, having read Justin's initial reply - and the rest of the thread - I believe I can see where the desire for polymorphism comes from. To be clear: I am all for strict types inside an implementation, as it will add helpful guard-rails to the state management code paths. However, I see this as a case of leaky abstraction. If we take the existing oauth.xyj-java code to be the reference implementation, the choice makes logical sense: JSON is not expressive enough to serialise arbitrary objects, so in order to avoid writing complex payload parser(s) the internal implementation details now leak to the protocol itself. From a purely technical perspective, it's a cool trick. From a distance it even looks a bit like the result of protobuf decoding, but without the generated code parts. But then the downside. I don't personally expect to be able to use the reference implementation, being mostly a Python user myself. A fair number of AS implementations will be written with languages such as Go, Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them will have to deal with the polymorphism. From what I've read over the past couple of days, I understand that at least Go supports custom unmarshalers from JSON to typed structs, at the cost of an indirection. Normally when a Go code processes JSON to a typed struct, the process is helped by field annotations in the type definition itself. For example, if the payload for a person in JSON was { "name": "", "age": , "country": "", "city": "" } .. then the type definition would look like: type Person struct { Name string `json:"name" Age int `json:"age"` Country string `json:"country"` City string `json:"city"` } When the (possibly complex) type of a given field is fixed, unmarshaling should still be straightforward. I haven't verified, but since the annotation only gives which field to look at for a given typed value, there should be nothing special about that. But when the field can instead be a union of more than one distinct types, things start to get messy. There is no union type in the language at all, so the following construct is not even possible: type Entity struct { Resources []string `json:"resources"` Client union(Client, string) `json:"client"` } As I understand, the implicit expectation is that in the above case, the unmarshaler detects that "client" is a string, and so expands it from an opaque handle to the expected, populated type. Even after thinking about the ramifications over the past few days I remain confused, because I don't see how the commonly used annotations could work. If the expectation is that protocol implementations should use strong types, then the use of polymorphic JSON is very likely to make things _more_ complicated for non-reference implementations. Hence my concern. I'm afraid that the leaky abstraction, while making the reference implementation more robust and straightforward, contributes to making other implementations less robust. And this being a security protocol, the potential for brittle and/or confused implementations is terrifying. I am a fan of reducing complexity, and from what I can see, for the reference implementation the polymorphic approach actually does that. But I'm afraid it does so at others' expense. Languages have their individual constraints, idioms and best practices. If parsing a protocol payload introduces low-level complexities and encourages to go against common practices, that is an invitation for problems. I am aware that my choice of words in the HN thread was likely to put people on defense, and for that I apologise. But I do believe that the choice of polymorphic JSON is going to make the life and use of other implementations notably less boring than people in general would prefer. Cheers, Mika On Mon, 26 Oct 2020 at 02:04, Fabien Imbault wrote: > Hi Dick, > > Well technically yes. Obviously the client can present any interface it > seems fit. > > Still there's the question of the common model we want to present to the > outside world and supported by the protocol itself (which client librarie= s > all build upon). > > But beneath the polyphormism question, the HN debate seems on the surface > a lot like the original xyz (polyphormism goes along with the reduced > endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where the > client design has more latitude). Just explained differently, by outside > people with different agendas. > > Which is a bit weird because many of the critics on HN (who criticize > polyphormism) also seem to really dislike OAuth in the first place (the > inconsistencies are partially due to a bunch of different people > commenting). > > Really to me there's no fundamental truth behind that question. It's a > matter of preference and priorities in the design. Whatever choices we > make, we'll have to be prepared to explain and justify them in the open, > even to some people that will dislike pretty much whatever we do (because > it's fun to look smart and critize without proposing alternatives). And w= e > owe these answers to people like Mika, who genuinely try to make the best > of it. > > Fabien > > Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : > >> Hi Fabien >> >> A library developer can provide whatever abstraction layer makes sense >> for the library's target audience and language. >> >> If the client library developer wants to use polymorphism in the >> interface presented to the user's of the library, the library developer = can >> do that independent of polymorphism in the protocol, and vice versa >> >> =3D> polymorphism in the protocol has no impact on client library develo= pers >> >> >> =E1=90=A7 >> >> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >> wrote: >> >>> I'm just realizing your "least to most important" might actually say th= e >>> same as what I was trying to say. So I'm not even sure what we're argui= ng >>> against :-) >>> >>> In brief my point if it wasn't clear is that we should be crystal clear >>> on where we put the cursor of simplicity, because this can mean differe= nt >>> things for different people and different roles. >>> And as we see on HN we need to better explain our design choices. >>> >>> >>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >>> a =C3=A9crit : >>> >>>> Hi Dick, >>>> >>>> Independantly from the debate on polyphormism, I beg to differ on your >>>> order preference. >>>> >>>> Your assumption is that AS devs matter the most, because they're doing >>>> the important security implementation. But eating our own dogfood migh= t >>>> help a lot to change that view. Most security issues occur because use= rs of >>>> the spec are unable to deal with the complexity that is passed onto th= em. >>>> >>>> 99% of the people that will actually use the output of the work are >>>> application developers (client or RS) and their own users. >>>> >>>> Our intent as well as the protocol drive the usage. Client libraries >>>> may help, but they're not a silver bullet, especially because GNAP >>>> ultimately has no control about what people do there (for better or wo= rse). >>>> And everything we do here will help get to the better part. >>>> >>>> I'm not saying we don't intend to also care about AS developers >>>> (beginning with ourselves) but it's a second order optimisation. And s= ince >>>> it's a tendancy we're leaning towards by default, I'm pretty sure we w= on't >>>> forget that anyway. >>>> >>>> Fabien >>>> >>>> >>>> >>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a >>>> =C3=A9crit : >>>> >>>>> I'm confused by your logic Fabien. >>>>> >>>>> If a client library developer wants to expose polymorphism, they can >>>>> do that independent of what is in the protocol. >>>>> >>>>> I differ on who our stakeholders are. >>>>> >>>>> I think our stakeholders are in least to most important: >>>>> >>>>> >>>>> - AS developer >>>>> - RS developer >>>>> - client developer >>>>> - user >>>>> >>>>> >>>>> A client library developer can expose whatever interface they want to >>>>> simplify implementation. >>>>> >>>>> I list the user so that we don't lose site of a critical role. >>>>> >>>>> /Dick >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi there, >>>>>> >>>>>> Let me try to approach the issue under a different light. More like = a >>>>>> product manager would deal with feature selection to make it intuiti= ve for >>>>>> its users. >>>>>> >>>>>> For most people, riding a bike is far easier than using a unicycle. >>>>>> Feels more stable. And yet it's way easier to design for a single wh= eel >>>>>> than to build with 2. Because then you'll need a lot more accessorie= s >>>>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to = be a >>>>>> brittle process, it can be industrialized. >>>>>> >>>>>> Back to the GNAP topic. >>>>>> Ultimately we should strive to make the spec as simple as can be. Bu= t >>>>>> we need to ask: simple for whom? For the bike owner or for the bike = vendor? >>>>>> (short answer: the priority should be simplicity for spec users, not >>>>>> spec implementers and even less spec designers). >>>>>> >>>>>> The initial question that is asked is very interesting: isn't the >>>>>> design flawed if GNAP is using json polyphormism? Or if the AS needs= to >>>>>> handle the state of the request? Or if we must handle token revocati= on? Or >>>>>> if we are looking for a global unique identifier? The argument stems= of the >>>>>> fact that is still arguably harder and more error prone to implement= . Fair >>>>>> enough. >>>>>> >>>>>> From a spec implementer's perspective, it may well be more complex. >>>>>> It mostly impacts the json library you'll end up using, plus a bit o= f >>>>>> input/output decoration around it. Even golang provides utilities fo= r this, >>>>>> despite not exactly being made for this kind of purpose. >>>>>> My practical experience implementing it is that it's not that big a >>>>>> deal. I mean, I wished it could be simpler, but it's manageable and = there >>>>>> are other ways to reach levels of insurance that it does work as int= ended >>>>>> (json schema, test cases to validate the implementation, etc.). Argu= ably it >>>>>> is still easier from an implementation perspective than say, json-ld= , which >>>>>> is massively used in the SSI community. >>>>>> >>>>>> But ultimately who are we designing for? Are we striving to go easy >>>>>> on the spec implementer? Or are we trying to make sure end-developer= s using >>>>>> the client libraries won't shoot themselves in the foot? >>>>>> >>>>>> The job to be done (JTBD), from the end-developer's perspective, is >>>>>> to efficiently ship an application. And provide authN/authZ capabili= ties >>>>>> for end-users by relying on some well known implementation. >>>>>> In turn, this spec implementer will rely on cryptographic utility >>>>>> libraries that deals internally with the complexity of their own dom= ain, so >>>>>> that we don't have to. And here we could launch another HN flame war= that >>>>>> starts with the title "JWT sucks because". Which does have its set o= f very >>>>>> real issues but that's beyond the point. >>>>>> Note that any decent flamewar will be efficiently fueled by people >>>>>> hating medium. Is it outrageous for blog posts to be behind a paywal= l? >>>>>> Maybe but it's even more outrageous to lack consistency, either by n= ot >>>>>> knowing how to get around a paywall if you're into a hacker punk mov= ement, >>>>>> or on the contrary by to not paying a subscription if you believe th= at >>>>>> surveillance capitalism, to reuse Zuboff's terms, should be eradicat= ed. >>>>>> What likely seems an unnecessary sidenote tries to illustrate the >>>>>> point: for Justin it was easier to publish on medium, because as a b= log >>>>>> publisher, you might not want to deal with hosting your own blog. Bu= t maybe >>>>>> as a reader you'll find that annoying. Different audiences, differen= t JTBD, >>>>>> different tradeoffs. >>>>>> >>>>>> Polyphormism is a tool that enables the end-developer to have minima= l >>>>>> knowledge of what it means to deal with a GNAP client library. You p= repare >>>>>> the request, send to the endpoint and you're good to go. Massively s= impler >>>>>> than OAuth2 or any similar protocol by the way (as anyone with teach= ing >>>>>> experience on the subject might acknowledge). And there's a lot mor= e to be >>>>>> done to make sure we indeed reduce the complexity for the end-develo= per and >>>>>> the end-user. >>>>>> >>>>>> If we find a better way to deal with that simplicity balance, I'm al= l >>>>>> in. But the arguments need to be way more convincing than just sayin= g that >>>>>> it may be difficult to implement or validate. >>>>>> >>>>>> Cheers. >>>>>> Fabien >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a >>>>>> =C3=A9crit : >>>>>> >>>>>>> >>>>>>> >>>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> I did note that I was the one that argued for instance_id being in >>>>>>> the object. Since it is in the object in the current draft, not inc= luding a >>>>>>> pass by reference option would be preferable. >>>>>>> >>>>>>> As for concrete examples: >>>>>>> - version of client >>>>>>> - version of OS >>>>>>> - security attestation of OS / device >>>>>>> - location of client device >>>>>>> - network client is operating on >>>>>>> >>>>>>> These are all attributes of the client that an AS may require on th= e >>>>>>> initial grant request, and in future grant requests (which is when = an >>>>>>> instance_id) would be used. >>>>>>> >>>>>>> >>>>>>> This is where our interpretations differ: I don=E2=80=99t see these= as >>>>>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the= key, display >>>>>>> information, class identifiers, and other items currently represent= ed by an >>>>>>> instance_id are attributes of the client instance. The attestation >>>>>>> components don=E2=80=99t modify the instance so much as present add= itional >>>>>>> information on top of the client instance itself. This is why I arg= ue that >>>>>>> they ought to be handled in a separate object, so you=E2=80=99d hav= e something like >>>>>>> this strawman: >>>>>>> >>>>>>> { >>>>>>> >>>>>>> posture: { >>>>>>> software_version: 1.2.3, >>>>>>> os_version: 14.3.2 >>>>>>> device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 } >>>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>>>>> }, >>>>>>> >>>>>>> client: =E2=80=9Cclient-541-ab" >>>>>>> >>>>>>> } >>>>>>> >>>>>>> This is a more fundamental question about GNAP than whether the >>>>>>> syntax uses polymorphism: this is about GNAP being very explicit ab= out the >>>>>>> data model of its elements. OAuth 2=E2=80=99s incredibly loose and = broad model of >>>>>>> what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is= deeply problematic in >>>>>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with= having to >>>>>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that = doesn=E2=80=99t fully capture >>>>>>> the different aspects that are out there. I think we=E2=80=99re get= ting closer here >>>>>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80= =9D, but we still need to >>>>>>> be more precise about what exactly a client instance includes, and = what it >>>>>>> does not. >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Dick, >>>>>>>> >>>>>>>> As you=E2=80=99ll recall, I argued against including the client in= stance >>>>>>>> identifier inside of the object as a mutually-exclusive field prec= isely >>>>>>>> because of the principle violation that you are pointing out here,= and so >>>>>>>> it=E2=80=99s important to point out that the current text is a com= promise that >>>>>>>> needs to be examined in the wider experience of the working group.= I am on >>>>>>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id= =E2=80=9D option within an >>>>>>>> object, but this needs to be explored. >>>>>>>> >>>>>>>> The crux of my argument is that is exactly a case of >>>>>>>> pass-by-reference vs pass-by-value, and that runtime attestations = are not >>>>>>>> part of the =E2=80=9Cclient instance=E2=80=9D value itself but rat= her belong outside of >>>>>>>> that object in a another part of the request. As stated in the edi= torial >>>>>>>> notes in this section, we need to look carefully at how these conc= epts fit >>>>>>>> within the model and where we would want to put them. Without conc= rete >>>>>>>> examples of what these extensions look like and how they=E2=80=99r= e generated, that >>>>>>>> is nearly impossible to do at this stage. I look forward to seeing= examples >>>>>>>> of this kind of data and how it can fit into the protocol. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hey Justin, >>>>>>>> >>>>>>>> As the draft has evolved, I question the continued use of >>>>>>>> polymorphism. Note that I appreciate the elegance of using a strin= g for >>>>>>>> pass-by-reference, and an object for pass-by-value. >>>>>>>> >>>>>>>> In the current draft, the >>>>>>>> >>>>>>>> Every time you create or process a field it will mean only one >>>>>>>> thing, and there=E2=80=99s only one field to look at to answer a q= uestion. >>>>>>>> >>>>>>>> >>>>>>>> is violated in 2.3.1. Identifying the RC Instance >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> instance_id An identifier string that the AS can use to >>>>>>>> identify the >>>>>>>> particular instance of this RC. The content and structure o= f >>>>>>>> this >>>>>>>> identifier is opaque to the RC. >>>>>>>> >>>>>>>> "client": { >>>>>>>> "instance_id": "client-541-ab" >>>>>>>> } >>>>>>>> >>>>>>>> If there are no additional fields to send, the RC MAY send the >>>>>>>> instance identifier as a direct reference value in lieu of the >>>>>>>> object. >>>>>>>> >>>>>>>> "client": "client-541-ab" >>>>>>>> >>>>>>>> >>>>>>>> The instance identifier can be sent two ways. Polymorphism is a >>>>>>>> convenience for the client, but requires the server to have two co= de paths >>>>>>>> for "instance_id". We discussed this in the design team, and I ar= gued for >>>>>>>> having "instance_id" in the "client" object so that any updates, s= uch as >>>>>>>> new devices assertions, could be in the "client" object. As noted = above, >>>>>>>> while I appreciate the elegance of using a string (handle) to refe= rence a >>>>>>>> previously provided object, it complicates how to update an existi= ng object >>>>>>>> while providing the reference. >>>>>>>> >>>>>>>> In your example of the "key" object below, setting "proof" to >>>>>>>> bearer would avoid the issue you describe: >>>>>>>> >>>>>>>> { >>>>>>>> "key": { >>>>>>>> "proof": "bearer" >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> In your example, when processing the "key" object, code is having >>>>>>>> to check both the JSON type of the property, as well as check the = value of >>>>>>>> the "proof" property. In the example I provided, only the value of= "proof" >>>>>>>> needs to be checked. The "proof" property is acting as a type for = the "key" >>>>>>>> object. >>>>>>>> >>>>>>>> Not being a Java programmer, I don't know how this would work in a >>>>>>>> Java implementation, but node.js, the processing would need to be = done as >>>>>>>> above. >>>>>>>> >>>>>>>> On a related note, there was significant negative feedback on >>>>>>>> handles and polymorphism in the Hacker News article >>>>>>>> https://news.ycombinator.com/item?id=3D24855750 >>>>>>>> >>>>>>>> /Dick >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Mika, >>>>>>>>> >>>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able to see t= he forum >>>>>>>>> discussion that brought you here, and hopefully I can help clear = up what I >>>>>>>>> mean with how polymorphism is used in the proposal. The short ver= sion is >>>>>>>>> that the goal is to *avoid* the kinds of ambiguity that make >>>>>>>>> insecure protocols, and so in that goal we=E2=80=99re fully align= ed. I think that >>>>>>>>> using polymorphism in very specific ways can help that goal =E2= =80=94 just as I >>>>>>>>> agree that misusing it or applying it sloppily can lead to ambigu= ous and >>>>>>>>> insecure systems. >>>>>>>>> >>>>>>>>> Some background: I built out the XYZ protocol (one of the >>>>>>>>> predecessors to the initial GNAP Draft) in Java using strongly ty= ped >>>>>>>>> parsers and Java objects specifically to prove to myself that it = could be >>>>>>>>> done in a way that made any sense in the code. (My own open sourc= e >>>>>>>>> implementation is at https://github.com/bspk/oauth.xyz-java, but >>>>>>>>> note that it=E2=80=99s not yet up to date with the GNAP spec). It= was important to >>>>>>>>> me that I be able to use the system-wide configured parsers to im= plement >>>>>>>>> this and not have to resort to stepping through elements complete= ly by >>>>>>>>> hand. Java doesn=E2=80=99t make it simple to get the hooks into t= he right places >>>>>>>>> (especially with the Jackson parser that I used), but it is defin= itely >>>>>>>>> possible to create a deterministic and strongly-typed parser and = serializer >>>>>>>>> for this kind of data structure. Some of the rationale for using >>>>>>>>> polymorphism is covered in the trailing appendix of the draft doc= ument ( >>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.= html#name-json-structures-and-polymor), >>>>>>>>> but it=E2=80=99s still good to discuss this here as the working g= roup decides which >>>>>>>>> approaches to take. >>>>>>>>> >>>>>>>>> The driving reason for using polymorphism at the protocol level >>>>>>>>> was to simplify the protocol and make it :more: deterministic to = create and >>>>>>>>> process, not less. Every time you create or process a field it wi= ll mean >>>>>>>>> only one thing, and there=E2=80=99s only one field to look at to = answer a question. >>>>>>>>> Without polymorphic field values, you usually need to rely on mut= ual >>>>>>>>> exclusivity of fields, which is prone to failure and requires add= itional >>>>>>>>> error checking. Take for example the key binding of access tokens= . An >>>>>>>>> access token could be bound to the RC=E2=80=99s key used during t= he request, to a >>>>>>>>> different key chosen by the AS, or it could be a bearer token wit= h no key >>>>>>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we= can define it in terms of >>>>>>>>> boolean values and objects and express this set of mutually-exclu= sive >>>>>>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need = to have different >>>>>>>>> fields for the options and include additional checks in your pars= er to make >>>>>>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you coul= d get hit with >>>>>>>>> this potential security vulnerability in an object: >>>>>>>>> >>>>>>>>> { >>>>>>>>> key: { >>>>>>>>> proof: httpsig, >>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>> }, >>>>>>>>> bearer_token: true, >>>>>>>>> bind_to_rc_key: true >>>>>>>>> } >>>>>>>>> >>>>>>>>> This would be an illegal object as per this alternate proposal, >>>>>>>>> but then you=E2=80=99d have to check each field and make sure it = wasn=E2=80=99t put next to >>>>>>>>> others in the same object. I=E2=80=99ve done this exercise with m= any other >>>>>>>>> protocols and it=E2=80=99s both error prone and easy to ignore si= nce all the =E2=80=9Cgood=E2=80=9D >>>>>>>>> examples would pass code that doesn=E2=80=99t check this. With th= e polymorphic >>>>>>>>> approach to this same field, each of these three mutually-exclusi= ve states >>>>>>>>> is written in a way that they cannot be sent together. It=E2=80= =99s not just >>>>>>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JS= ON itself. >>>>>>>>> >>>>>>>>> { >>>>>>>>> key: { >>>>>>>>> proof: httpsig, >>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> // bearer token >>>>>>>>> >>>>>>>>> { >>>>>>>>> key: false >>>>>>>>> } >>>>>>>>> >>>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>>> >>>>>>>>> { >>>>>>>>> key: true >>>>>>>>> } >>>>>>>>> >>>>>>>>> If someone sends a different type for this field, like an array o= r >>>>>>>>> number or a null, this doesn=E2=80=99t have a defined interpretat= ion in the >>>>>>>>> protocol and would be a protocol level error. >>>>>>>>> >>>>>>>>> While it might sound like polymorphism means that any field could >>>>>>>>> have any type or value, the opposite is true: each possible value= is >>>>>>>>> explicitly typed, it=E2=80=99s just that there are potentially di= fferent types that >>>>>>>>> express meaning for the field. This applies to all members of all= objects >>>>>>>>> (dictionaries) as well as all members of an array (list). Every t= ime you >>>>>>>>> process a field value or other element, you look at the type and = then the >>>>>>>>> value to determine what to do with that typed value. >>>>>>>>> >>>>>>>>> In your example below, each field within the dictionary would als= o >>>>>>>>> need to be typed, and each type would need to have a clear indica= tion of >>>>>>>>> its meaning. To take your strawman key format below, the =E2=80= =9Cmodulus=E2=80=9D field >>>>>>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an >>>>>>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition = would further say what >>>>>>>>> exactly the encoding of the string would be. That means that when= you read >>>>>>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any= confusion on what the value was >>>>>>>>> or how it was represented, regardless of the input format. Seeing= a number >>>>>>>>> there means exactly one interpretation and seeing a string means = exactly >>>>>>>>> one (different) interpretation =E2=80=94 but importantly, both of= them are a >>>>>>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that de= termines the type. An >>>>>>>>> implementation would likely use an internal BigInteger type of ob= ject to >>>>>>>>> represent the field value after parsing, so the question is how t= o go from >>>>>>>>> the JSON value (which is typed) into the BigInteger value.You don= =E2=80=99t just >>>>>>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, y= ou apply it to all >>>>>>>>> sub-fields of that object. >>>>>>>>> >>>>>>>>> So let=E2=80=99s dig into the specific bug you bring up in the st= rawman, >>>>>>>>> because it=E2=80=99s interesting: A JSON encoder that encodes num= bers as strings, >>>>>>>>> and not numbers, is not compliant with the JSON definitions of th= e field in >>>>>>>>> question. For another example, the quoted string value of =E2=80= =9Ctrue=E2=80=9D is not >>>>>>>>> equivalent to the boolean value true in JSON, and they shouldn=E2= =80=99t be treated >>>>>>>>> the same by a parser implementation when mapping to a concrete ob= ject. It=E2=80=99s >>>>>>>>> in this kind of automated guessing that this class of bugs occur,= and >>>>>>>>> that=E2=80=99s going to be the case whether or not you take adva= ntage of JSON=E2=80=99s >>>>>>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser li= brary was trying >>>>>>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapp= ing, but ended up >>>>>>>>> introducing errors in more strict components downstream. This is = something >>>>>>>>> that protocol designers need to be aware of and guard against in = the design >>>>>>>>> of the protocol to reduce possible ambiguities. Within GNAP today= , we >>>>>>>>> generally have things that branch whether they=E2=80=99re an obje= ct (for a rich >>>>>>>>> description of something) or some non-structured special value (f= or a >>>>>>>>> reference or other item). >>>>>>>>> >>>>>>>>> The design team created some simple JSON Schemas for parts of the >>>>>>>>> protocol during our discussion, but we didn=E2=80=99t include the= m in the design >>>>>>>>> document due to both lack of time to keep it updated with the rap= id changes >>>>>>>>> to the protocol during the design team discussion, and not knowin= g if there >>>>>>>>> would be interest in such material. I personally think it would b= e helpful >>>>>>>>> to include as an informative reference in the final document, but= that=E2=80=99s >>>>>>>>> something for the working group to take up eventually. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>>>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>> Hello, everyone. >>>>>>>>> >>>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion >>>>>>>>> forum and when I made note about certain concerns, I was requeste= d to send >>>>>>>>> my comments to this working group. >>>>>>>>> >>>>>>>>> In short, I believe that the use of polymorphic JSON in the >>>>>>>>> protocol invites subtle and confusing implementation problems. I = also >>>>>>>>> searched through the WG archives, and noticed that similar concer= ns were >>>>>>>>> noted, briefly, in a thread in July. >>>>>>>>> >>>>>>>>> The problem with polymorphic values, as I see it, is that >>>>>>>>> implementations will need to branch on the (inferred) type of a g= iven >>>>>>>>> field. This isn't quite as bad if the types are strictly differen= t, but >>>>>>>>> allows for subtle bugs when the value in question is a dictionary= . What >>>>>>>>> makes this unappealing is that "subtle bugs" in security protocol= s have a >>>>>>>>> habit of turning into vulnerabilities. >>>>>>>>> >>>>>>>>> Let's say we have these imaginary payloads, both possible and >>>>>>>>> valid in the same protocol step: >>>>>>>>> >>>>>>>>> # payload 1 >>>>>>>>> { >>>>>>>>> ..., >>>>>>>>> "public_key": { >>>>>>>>> "alg": "rsa", >>>>>>>>> "modulus": >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> # payload 2 >>>>>>>>> { >>>>>>>>> ..., >>>>>>>>> "public_key": { >>>>>>>>> "alg": "rsa", >>>>>>>>> "modulus": "" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> In both cases, the type of "public_key" field is a dictionary. In >>>>>>>>> both cases, they even have the same keys. However, the values in = the >>>>>>>>> dictionaries are entirely different, and an implementation will h= ave to >>>>>>>>> branch to at least two possible decoding mechanisms. To make thin= gs worse, >>>>>>>>> some JSON implementations may choose to encode non-dictionary val= ues as >>>>>>>>> strings, so it is possible for an originator to transmit what the= y expect >>>>>>>>> and believe to be payload 1 format, but which the receiver will i= nterpret >>>>>>>>> to be in payload 2 format. And if the encoded string contains onl= y digits, >>>>>>>>> it will even parse correctly as a bignum. >>>>>>>>> >>>>>>>>> While the above is clearly a manufactured scenario, it nonetheles= s >>>>>>>>> demonstrates the potential for logic bugs with polymorphic JSON. = With >>>>>>>>> richer types and more complex dictionaries, there will surely be = more room >>>>>>>>> for errors. >>>>>>>>> >>>>>>>>> Ambiguity in protocols is always a source of implementation >>>>>>>>> complexity and interoperability snags, but in an AuthN/AuthZ prot= ocol it is >>>>>>>>> worse: it's terrifying. If GNAP/Oauth3 is intended to supersede O= auth1/2, >>>>>>>>> wouldn't it be in everyone's interest to keep implementation comp= lexity and >>>>>>>>> mistake potential to a minimum? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Mika >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mika Bostr=C3=B6m >>>>>>>>> Smarkets >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> --=20 Mika Bostr=C3=B6m Smarkets --000000000000a38b3305b2bda89f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi everyone,

    Looks like I st= uck my finger in a hornets' nest. First off, apologies for not chipping= in earlier, but there was a lot of material to digest. Also, warning: lots= to read ahead.

    I'm one of those people wh= o end up making use of AuthN/AuthZ functionality through a library. On top = of that I can see myself being roped in as a server (AS) implementation hel= p. So I'm approaching this from an outsider's perspective. Someone = who expects to be exposed to the eventual RFC and all the nitty-gritty deta= ils. My relatively terse comment ended up at the top of the aforementioned = HN thread, which didn't necessarily help. Sorry about that.
    <= br>
    Now, having read Justin's initial reply - and the rest of= the thread - I believe I can see where the desire for polymorphism comes f= rom. To be clear: I am all for strict types inside an implementation, as it= will add helpful guard-rails to the state management code paths. However, = I see this as a case of leaky abstraction. If we take the existing oauth.xy= j-java code to be the reference implementation, the choice makes logical se= nse: JSON is not expressive enough to serialise arbitrary objects, so in or= der to avoid writing complex payload parser(s) the internal implementation = details now leak to the protocol itself. From a purely technical perspectiv= e, it's a cool trick. From a distance it even looks a bit like the resu= lt of protobuf decoding, but without the generated code parts.

    But then the downside. I don't personally expect to be= able to use the reference implementation, being mostly a Python user mysel= f. A fair number of AS implementations will be written with languages such = as Go, Python, C#, Ruby, and JavaScript (thanks to node.js), and all of the= m will have to deal with the polymorphism. From what I've read over the= past couple of days, I understand that at least Go supports custom unmarsh= alers from JSON to typed structs, at the cost of an indirection. Normally w= hen a Go code processes JSON to a typed struct, the process is helped by fi= eld annotations in the type definition itself. For example, if the payload = for a person in JSON was

    {
    =C2=A0 "= name": "<string>",
    =C2=A0 "age": &= lt;int>,
    =C2=A0 "country": "<string>&= quot;,
    =C2=A0 "city": "<string>"
    <= div>}

    .. then the type definition would look like:=

    type Person struct {
    =C2=A0 Name string= `json:"name"
    =C2=A0 Age int `json:"age"`
    =C2=A0 Country string `json:"country"`
    =C2=A0 Ci= ty string `json:"city"`
    }

    When= the (possibly complex) type of a given field is fixed, unmarshaling should= still be straightforward. I haven't verified, but since the annotation= only gives which field to look at for a given typed value, there should be= nothing special about that. But when the field can instead be a union of m= ore than one distinct types, things start to get messy. There is no union t= ype in the language at all, so the following construct is not even possible= :

    type Entity struct {
    =C2=A0 Resources = []string `json:"resources"`
    =C2=A0 Client union(Cli= ent, string) `json:"client"`
    }

    =
    As I understand, the implicit expectation is that in the above case, t= he unmarshaler detects that "client" is a string, and so expands = it from an opaque handle to the expected, populated type. Even after thinki= ng about the ramifications over the past few days I remain confused, becaus= e I don't see how the commonly used annotations could work. If the expe= ctation is that protocol implementations should use strong types, then the = use of polymorphic JSON is very likely to make things _more_ complicated fo= r non-reference implementations.

    Hence my concern.= I'm afraid that the leaky abstraction, while making the reference impl= ementation more robust and straightforward, contributes to making other imp= lementations less robust. And this being a security protocol, the potential= for brittle and/or confused implementations is terrifying.

    I am a fan of reducing complexity, and from what I can see, for th= e reference implementation the polymorphic approach actually does that. But= I'm afraid it does so at others' expense. Languages have their ind= ividual constraints, idioms and best practices. If parsing a protocol paylo= ad introduces low-level complexities and encourages to go against common pr= actices, that is an invitation for problems. I am aware that my choice of w= ords in the HN thread was likely to put people on defense, and for that I a= pologise. But I do believe that the choice of polymorphic JSON is going to = make the life and use of other implementations notably less boring than peo= ple in general would prefer.

    Cheers,
    Mik= a

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi D= ick,

    Well technically yes. Obv= iously the client can present any interface it seems fit.=C2=A0

    Still there's the question of t= he common model we want to present to the outside world and supported by th= e protocol itself (which client libraries all build upon).=C2=A0

    But beneath the polyphormism quest= ion, the HN debate seems on the surface a lot like the original xyz (polyph= ormism goes along with the reduced endpoint model) vs xauth (a bit closer t= o OAuth2 in spirit, and where the client design has more latitude). Just ex= plained differently, by outside people with different agendas.=C2=A0
    <= div dir=3D"auto">
    Which is a bit weird because m= any of the critics on HN (who criticize polyphormism) also seem to really d= islike OAuth in the first place (the inconsistencies are partially due to a= bunch of different people commenting).=C2=A0

    Really to me there's no fundamental truth behind = that question. It's a matter of preference and priorities in the design= . Whatever choices we make, we'll have to be prepared to explain and ju= stify them in the open, even to some people that will dislike pretty much w= hatever we do (because it's fun to look smart and critize without propo= sing alternatives). And we owe these answers to people like Mika, who genui= nely try to make the best of it.=C2=A0

    Fabien=C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Ha= rdt <dick.hard= t@gmail.com> a =C3=A9crit=C2=A0:
    Hi Fabien

    A lib= rary developer can provide whatever abstraction layer makes sense for the l= ibrary's target=C2=A0audience and language.

    If= the client library=C2=A0developer wants to use polymorphism=C2=A0in the in= terface presented to the user's of the library, the library developer c= an do that independent of polymorphism in the protocol, and vice versa=C2= =A0

    =3D> polymorphism in the protocol has no im= pact on client library developers


    =
    3D""=E1=90=A7

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbau= lt <fabien.imbault@gmail.com> wrote:
    I'm just realizi= ng your "least to most important" might actually say the same as = what I was trying to say. So I'm not even sure what we're arguing a= gainst :-)=C2=A0

    In brief my p= oint if it wasn't clear is that we should be crystal clear on where we = put the cursor of simplicity, because this can mean different things for di= fferent people and different roles.=C2=A0
    And as we = see on HN we need to better explain our design choices.=C2=A0


    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" rel=3D"noreferrer" target=3D"_bl= ank">fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Dick,

    Independantly from the debate on pol= yphormism, I beg to differ on your order preference.=C2=A0

    Your assumption is that AS devs matter t= he most,=C2=A0because they're do= ing the important security implementation. But eating our own dogfood might= help a lot to change that view. Most security issues occur because users o= f the spec are unable to deal with the complexity that is passed onto them.= =C2=A0

    99% of the= people that will actually use the output of the work are application devel= opers (client or RS) and their own users.=C2=A0

    =
    Our intent a= s well as the protocol drive the usage. Client libraries may help, but they= 're not a silver bullet, especially because GNAP ultimately has no cont= rol about what people do there (for better or worse). And everything we do = here will help get to the better part.=C2=A0
    =
    I'm not saying we don't intend to also = care about AS developers (beginning with ourselves) but it's a second o= rder optimisation. And since it's a tendancy we're leaning towards = by default, I'm pretty sure we won't forget that anyway.=C2=A0

    Fabien=C2= =A0



    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <= dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
    I'm confused by your = logic Fabien.

    If a client library developer wants to exp= ose polymorphism, they can do that independent of what is in the protocol.= =C2=A0

    I differ on who our stakeholders are.=C2=A0=

    I think our stakeholders are in least to most imp= ortant:

    • AS developer
    • RS developer<= /li>
    • client developer
    • user

    A = client library developer can expose whatever interface they want to simplif= y implementation.

    I list the user so that we don&#= 39;t lose site of a critical role.

    /Dick


    3D""=E1=90=A7

    On Fri, Oct = 23, 2020 at 6:27 PM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
    Hi there,=C2=A0

    Let me try to approach the issue under a differen= t light. More like a product manager would deal with feature selection to m= ake it intuitive for its users.=C2=A0

    For most people, riding a bike is far easier th= an using a unicycle. Feels more stable. And yet it's way easier to desi= gn for a single wheel than to build with 2. Because then you'll need a = lot more accessories (chain, chain ring, etc.). Even so producing a bike do= esn't have to be a brittle process, it can be industrialized.=C2=A0

    Back to the GNAP topic.=C2= =A0
    Ultimately = we should strive to make the spec as simple as can be. But we need to ask: = simple for whom? For the bike owner or for the bike vendor?=C2=A0
    (short answ= er: the priority should be simplicity for spec users, not spec implementers= and even less spec designers).=C2=A0

    The init= ial question that is asked is very interesting: isn't the design flawed= if GNAP is using json polyphormism? Or if the AS needs to handle the state= of the request? Or if we must handle token revocation? Or if we are lookin= g for a global unique identifier? The argument stems of the fact that is st= ill arguably harder and more error prone to implement. Fair enough.=C2=A0

    From a spec implementer&#= 39;s perspective, it may well be more complex. It mostly impacts the json l= ibrary you'll end up using, plus a bit of input/output decoration aroun= d it. Even golang provides utilities for this, despite not exactly being ma= de for this kind of purpose.
    My practical experience= implementing it is that it's not that big a deal. I mean, I wished it = could be simpler, but it's manageable and there are other ways to reach= levels of insurance that it does work as intended (json schema, test cases= to validate the implementation, etc.). Arguably it is still easier from an= implementation perspective than say, json-ld, which is massively used in t= he SSI community.=C2=A0

    = But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cl= ient libraries won't shoot themselves in the foot?

    The job to be done (JTBD), from the end-deve= loper's perspective, is to efficiently ship an application. And provide= authN/authZ capabilities for end-users by relying on some well known imple= mentation.=C2=A0
    In turn, this spec implementer will= rely on cryptographic utility libraries that deals internally with the com= plexity of their own domain, so that we don't have to. And here we coul= d launch another HN flame war that starts with the title "JWT sucks be= cause". Which does have its set of very real issues but that's bey= ond the point.=C2=A0
    Note that any decent flamewar w= ill be efficiently fueled by people hating medium. Is it outrageous for blo= g posts to be behind a paywall? Maybe but it's even more outrageous to = lack consistency, either by not knowing how to get around a paywall if you&= #39;re into a hacker punk movement, or on the contrary by to not paying a s= ubscription if you believe that surveillance capitalism, to reuse Zuboff= 9;s terms, should be eradicated.=C2=A0
    What likely s= eems an unnecessary sidenote tries to illustrate the point: for Justin it w= as easier to publish on medium, because as a blog publisher, you might not = want to deal with hosting your own blog. But maybe as a reader you'll f= ind that annoying. Different audiences, different JTBD, different tradeoffs= .=C2=A0

    Polyphormism is = a tool that enables the end-developer to have minimal knowledge of what it = means to deal with a GNAP client library. You prepare the request, send to = the endpoint and you're good to go. Massively simpler than OAuth2 or an= y similar protocol by the way (as anyone with teaching experience on the su= bject might acknowledge). And=C2=A0 there's a lot more to be done to ma= ke sure we indeed reduce the complexity for the end-developer and the end-u= ser.=C2=A0

    If we find a = better way to deal with that simplicity balance, I'm all in. But the ar= guments need to be way more convincing than just saying that it may be diff= icult to implement or validate.=C2=A0

    Cheers.
    Fabien
    =




    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin R= icher <jr= icher@mit.edu> a =C3=A9crit=C2=A0:


    = On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com>= ; wrote:

    Justin

    I did not= e that I was the one that argued for instance_id being in the object. Since= it is in the object in the current draft, not including a pass by referenc= e option would be preferable.=C2=A0

    As for concret= e examples:
    - version of client
    - version of OS
    - security attestation of OS / device
    - location of client dev= ice
    - network client is operating on

    The= se are all attributes of the client that an AS may require=C2=A0on the init= ial grant request, and in future grant requests (which is when an instance_= id) would be used.


    This is where our interpretations differ: I don=E2=80=99t see thes= e as =E2=80=9Cattributes of the client=E2=80=9D in the same way that the ke= y, display information, class identifiers, and other items currently repres= ented by an instance_id are attributes of the client instance. The attestat= ion components don=E2=80=99t modify the instance so much as present additio= nal information on top of the client instance itself. This is why I argue t= hat they ought to be handled in a separate object, so you=E2=80=99d have so= mething like this strawman:

    {

    =
    =C2=A0 posture: {
    =C2=A0 =C2=A0 software_version: 1.2.3,
    =C2=A0 =C2=A0 os_version: 14.3.2
    =C2=A0 =C2=A0 device_atte= station: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }
    = =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }<= /div>
    =C2=A0 },

    =C2=A0 client: =E2=80=9Cclient= -541-ab"

    }

    This is a= more fundamental question about GNAP than whether the syntax uses polymorp= hism: this is about GNAP being very explicit about the data model of its el= ements. OAuth 2=E2=80=99s incredibly loose and broad model of what the term= =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic i= n practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doe= sn=E2=80=99t fully capture the different aspects that are out there. I thin= k we=E2=80=99re getting closer here in GNAP with explicit definition of =E2= =80=9Cclient instance=E2=80=9D, but we still need to be more precise about = what exactly a client instance includes, and what it does not.
    =C2=A0=E2=80=94 Justin


    /Dick

    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer &l= t;jricher@mit.edu> wrote:
    Dick,

    As you=E2=80=99ll recall, I a= rgued against including the client instance identifier inside of the object= as a mutually-exclusive field precisely because of the principle violation= that you are pointing out here, and so it=E2=80=99s important to point out= that the current text is a compromise that needs to be examined in the wid= er experience of the working group. I am on the side of removing the mutual= ly-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored.

    The crux of my argument is= that is exactly a case of pass-by-reference vs pass-by-value, and that run= time attestations are not part of the =E2=80=9Cclient instance=E2=80=9D val= ue itself but rather belong outside of that object in a another part of the= request. As stated in the editorial notes in this section, we need to look= carefully at how these concepts fit within the model and where we would wa= nt to put them. Without concrete examples of what these extensions look lik= e and how they=E2=80=99re generated, that is nearly impossible to do at thi= s stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol.

    =C2=A0=E2=80=94 Justin<= /div>

    On Oct 23, 2020, at 3:07 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin,

    As the d= raft has evolved, I question the continued use of polymorphism. Note that I= appreciate the elegance=C2=A0of using a string for pass-by-reference, and = an object for pass-by-value.

    In the current draft,= the=C2=A0

    Every time you create or process a fi= eld it will mean only one thing, and there=E2=80=99s only one field to look= at to answer a question.=C2=A0



    = =C2=A0 =C2=A0instance_id =C2=A0An identifier string that the AS can use to = identify the
    =C2=A0 =C2=A0 =C2=A0 particular instance of this RC.= =C2=A0 The content and structure of this
    =C2=A0 =C2=A0 =C2=A0 ide= ntifier is opaque to the RC.

    =C2=A0 =C2=A0"cl= ient": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id":= "client-541-ab"
    =C2=A0 =C2=A0}

    =C2=A0 =C2=A0If there are no additional fields to send, the RC MAY send t= he
    =C2=A0 =C2=A0instance identifier as a direct reference value i= n lieu of the
    =C2=A0 =C2=A0object.

    =C2= =A0 =C2=A0"client": "client-541-ab"
    <= div>
    The instance identifier can be sent two ways. Polymorphi= sm is a convenience for the client, but requires the server=C2=A0to have tw= o code=C2=A0paths for "instance_id".=C2=A0 We discussed this in t= he design team, and I argued for having "instance_id" in the &quo= t;client" object=C2=A0so that any updates, such as new devices asserti= ons, could be in the "client" object. As noted above, while I app= reciate the elegance of using a string (handle) to reference a previously p= rovided object, it complicates how to update an existing object while provi= ding the reference.

    In your example of the "k= ey" object below, setting "proof" to bearer would avoid the = issue you describe:

    {=C2=A0
    =C2=A0"key&quo= t;: {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"proof": "bearer" =C2=A0 =C2=A0 }
    }

    In your example, when = processing the "key" object, code is having to check both the JSO= N type of the property, as well as check the value of the "proof"= property. In the example I provided, only the value of "proof" n= eeds to be checked. The "proof" property is acting as a type for = the "key" object.

    Not being a Java progr= ammer, I don't know how this would work in a Java implementation, but n= ode.js, the processing would need to be done as above.

    =
    On a related note, there was significant negative feedback on handles = and polymorphism in the Hacker News article=C2=A0ht= tps://news.ycombinator.com/item?id=3D24855750=C2=A0

    /Dick


    On Fri, Oct 23, 2020 at 10:20 AM= Justin Richer <jricher@mit.edu> wrote:
    Hi Mika,

    Thanks fo= r bringing this topic here =E2=80=94 I was able to see the forum discussion= that brought you here, and hopefully I can help clear up what I mean with = how polymorphism is used in the proposal. The short version is that the goa= l is to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecure pr= otocols, and so in that goal we=E2=80=99re fully aligned. I think that usin= g polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree that misusing it or applying it sloppily can lead to ambiguous and i= nsecure systems.

    Some background: I built out the = XYZ protocol (one of the predecessors to the initial GNAP Draft) in Java us= ing strongly typed parsers and Java objects specifically to prove to myself= that it could be done in a way that made any sense in the code. (My own op= en source implementation is at=C2=A0https://github.com/bspk/= oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the = GNAP spec). It was important to me that I be able to use the system-wide co= nfigured parsers to implement this and not have to resort to stepping throu= gh elements completely by hand. Java doesn=E2=80=99t make it simple to get = the hooks into the right places (especially with the Jackson parser that I = used), but it is definitely possible to create a deterministic and strongly= -typed parser and serializer for this kind of data structure. Some of the r= ationale for using polymorphism is covered in the trailing appendix of the = draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-pr= otocol-00.html#name-json-structures-and-polymor), but it=E2=80=99s stil= l good to discuss this here as the working group decides which approaches t= o take.=C2=A0

    The driving reason for using polymor= phism at the protocol level was to simplify the protocol and make it :more:= deterministic to create and process, not less. Every time you create or pr= ocess a field it will mean only one thing, and there=E2=80=99s only one fie= ld to look at to answer a question. Without polymorphic field values, you u= sually need to rely on mutual exclusivity of fields, which is prone to fail= ure and requires additional error checking. Take for example the key bindin= g of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it could b= e a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D fi= eld polymorphic, we can define it in terms of boolean values and objects an= d express this set of mutually-exclusive options in a non-ambiguous way. Wi= thout that, you=E2=80=99d need to have different fields for the options and= include additional checks in your parser to make sure they weren=E2=80=99t= sent simultaneously, otherwise you could get hit with this potential secur= ity vulnerability in an object:

    {=C2=A0
    = =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    = =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 bearer_token: true,
    =C2= =A0 =C2=A0 bind_to_rc_key: true
    }

    This w= ould be an illegal object as per this alternate proposal, but then you=E2= =80=99d have to check each field and make sure it wasn=E2=80=99t put next t= o others in the same object. I=E2=80=99ve done this exercise with many othe= r protocols and it=E2=80=99s both error prone and easy to ignore since all = the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t ch= eck this. With the polymorphic approach to this same field, each of these t= hree mutually-exclusive states is written in a way that they cannot be sent= together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and enfor= ced by the syntax of JSON itself.

    {=C2=A0
    =C2=A0 =C2=A0 key: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,<= /div>
    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =
    =C2=A0 =C2=A0 }
    }

    // bearer token

    {
    =C2=A0 =C2=A0 key: false
    }

    // bound to the RC=E2=80=99s presented key

    {
    =C2=A0 =C2=A0 key: true
    }
    =

    If someone sends a different type for this field, like = an array or number or a null, this doesn=E2=80=99t have a defined interpret= ation in the protocol and would be a protocol level error.

    While it might sound like polymorphism means that any field could = have any type or value, the opposite is true: each possible value is explic= itly typed, it=E2=80=99s just that there are potentially different types th= at express meaning for the field. This applies to all members of all object= s (dictionaries) as well as all members of an array (list). Every time you = process a field value or other element, you look at the type and then the v= alue to determine what to do with that typed value.

    In your example below, each field within the dictionary would also need t= o be typed, and each type would need to have a clear indication of its mean= ing. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D = field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D= (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). Th= e definition would further say what exactly the encoding of the string woul= d be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D field the= re wouldn=E2=80=99t be any confusion on what the value was or how it was re= presented, regardless of the input format. Seeing a number there means exac= tly one interpretation and seeing a string means exactly one (different) in= terpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus= =E2=80=9D, since that=E2=80=99s the field that determines the type. An impl= ementation would likely use an internal BigInteger type of object to repres= ent the field value after parsing, so the question is how to go from the JS= ON value (which is typed) into the BigInteger value.You don=E2=80=99t just = apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply i= t to all sub-fields of that object.=C2=A0

    So let= =E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, a= nd not numbers, is not compliant with the JSON definitions of the field in = question. For another example, the quoted string value of =E2=80=9Ctrue=E2= =80=9D is not equivalent to the boolean value true in JSON, and they should= n=E2=80=99t be treated the same by a parser implementation when mapping to = a concrete object. It=E2=80=99s in this kind of automated guessing that thi= s class of bugs occur, and that=E2=80=99s going to be the case whether or n= ot you take =C2=A0advantage of JSON=E2=80=99s polymorphic nature. I=E2=80= =99ve run into cases where a parser library was trying to be overly =E2=80= =9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing= errors in more strict components downstream. This is something that protoc= ol designers need to be aware of and guard against in the design of the pro= tocol to reduce possible ambiguities. Within GNAP today, we generally have = things that branch whether they=E2=80=99re an object (for a rich descriptio= n of something) or some non-structured special value (for a reference or ot= her item).=C2=A0

    The design team created some simp= le JSON Schemas for parts of the protocol during our discussion, but we did= n=E2=80=99t include them in the design document due to both lack of time to= keep it updated with the rapid changes to the protocol during the design t= eam discussion, and not knowing if there would be interest in such material= . I personally think it would be helpful to include as an informative refer= ence in the final document, but that=E2=80=99s something for the working gr= oup to take up eventually.

    =C2=A0=E2=80=94 Justin<= /div>

    On Oct 23, 2020, at 10:18 AM, = Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets= .com@dmarc.ietf.org> wrote:

    Hell= o, everyone.

    For background: GNAP/TxAuth/XYZ/Oauth= 3 came up on a discussion forum and when I made note about certain concerns= , I was requested to send my comments to this working group.
    =
    In short, I believe that the use of polymorphic JSON in the = protocol invites subtle and confusing implementation problems. I also searc= hed through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.

    The problem wit= h polymorphic values, as I see it, is that implementations will need to bra= nch on the (inferred) type of a given field. This isn't quite as bad if= the types are strictly different, but allows for subtle bugs when the valu= e in question is a dictionary. What makes this unappealing is that "su= btle bugs" in security protocols have a habit of turning into vulnerab= ilities.

    Let's say we have these imaginary pay= loads, both possible and valid in the same protocol step:

    # payload 1
    {
    =C2=A0 ...,
    =C2=A0 &quo= t;public_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "r= sa",
    =C2=A0=C2=A0=C2=A0 "modulus": <BIGINT&= gt;
    =C2=A0 }
    }

    # payload 2
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    =C2= =A0=C2=A0=C2=A0 "modulus": "<encoded string>"
    =C2=A0 }
    }

    In both cases, the typ= e of "public_key" field is a dictionary. In both cases, they even= have the same keys. However, the values in the dictionaries are entirely d= ifferent, and an implementation will have to branch to at least two possibl= e decoding mechanisms. To make things worse, some JSON implementations may = choose to encode non-dictionary values as strings, so it is possible for an= originator to transmit what they expect and believe to be payload 1 format= , but which the receiver will interpret to be in payload 2 format. And if t= he encoded string contains only digits, it will even parse correctly as a b= ignum.

    While the above is clearly a manufactur= ed scenario, it nonetheless demonstrates the potential for logic bugs with = polymorphic JSON. With richer types and more complex dictionaries, there wi= ll surely be more room for errors.

    Ambiguity in pr= otocols is always a source of implementation complexity and interoperabilit= y snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying. I= f GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in ever= yone's interest to keep implementation complexity and mistake potential= to a minimum?

    Best regards,
    Mika

    --
    Mika Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    3D""=E1=90=A7


    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h


    --
    Mika Bostr=C3= =B6m
    Smarkets
    --000000000000a38b3305b2bda89f-- From nobody Wed Oct 28 09:55:54 2020 Return-Path: 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 94E9A3A08EB for ; Wed, 28 Oct 2020 09:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 Ew5U9zbihQ0w for ; Wed, 28 Oct 2020 09:55:44 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 778C83A067A for ; Wed, 28 Oct 2020 09:55:44 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id r9so34916ioo.7 for ; Wed, 28 Oct 2020 09:55:44 -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=i1h+OVYy8YQqi63eQHI6937kADdOn8uDNPEwqRhCGn4=; b=bbebKu60G8KK7NAVJDOKvnjZ6g5MnTTpsJkfXRCTLS74Xu53XAxwZroKGEicP2kMeH JO91NGn4AbwrrWEeI9ubH5H2gFPpTnpwXAbAd6ERL1Ze7TzDxA4pl3XqihRs3dDaF9YP 6XwPirxg3WZlF/NkQAV0f6azWhaQefzOm4aLARXLeT/AM+FB6XfjggkMZ1T02SsXGUI4 V+TKkOilI+Cc4rwbIyyqDQw1oUDrM1SPVWiGgPXqEi+cV0wxL4qUhwFdco6WOsINfGup /WiHGFA1MBDWudqoLjJ2TM/Nbdu88ANPujrpycjlxlsILadlmDf3LTRlN/WBV9QkFegx OBnw== 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=i1h+OVYy8YQqi63eQHI6937kADdOn8uDNPEwqRhCGn4=; b=BHMpLQex8t0q15+Nxr7L+hDLNxhVgAB+70iWs+NjXf3f4NtinwL68p1hO/wSx59x+E BQDiuaXF30QHxVDachedpZCnS2FE9mW/lNdUuwADo1w35reqXTUm2RnciPiQK/pgolIC Zaurg5CqxN0PIsCoHCoQr+AiiGHyvrqkAlUmhdk5mjTs44l2J5YNn23eoVl4XkxsE2HH xwuFmoEkEKsnpNEwJyo3xKv0OCxEtyzktYtWR3GhWJxUbxAIqFqOXJnqZN405UbNkQQY CL9GKtVuLvlOx4tWd0au4PkQY9MGe+TMUf6LivfmymrpG2F/wYOlHzCqV1bNqEKhNMh5 TmMQ== X-Gm-Message-State: AOAM533sRKuFnzQI78EgF1AY/R0fYTjnAjAGA0Yustmcel5iqi0GXh3G LmeFJOiPabXS/jWv4xtmNBjrBICggIFXniBCJrQ= X-Google-Smtp-Source: ABdhPJxy8BLBKFLNn3IWgq7sMOkIa9z/mxLF/MsOw/h7h+oH4Bsk69pZma9UILSj2ZbaC0O+lHN5aSOgtIH1WPtig+8= X-Received: by 2002:a02:48:: with SMTP id 69mr75854jaa.108.1603904143422; Wed, 28 Oct 2020 09:55:43 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 28 Oct 2020 17:55:32 +0100 Message-ID: To: =?UTF-8?Q?Mika_Bostr=C3=B6m?= Cc: Dick Hardt , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b8fa5b05b2be081d" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:55:53 -0000 --000000000000b8fa5b05b2be081d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the great feedback. Your concern is very valid. My implementation is in rust, which makes life easier in that specific case. So I'm not a golang specialist but I guess the transcription of json strings/arrays into go structs would work around the lines described by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 When we have a more formalized json schema, I suggest we make a library of json examples and some related code samples in mainstream languages, to check it is feasible for everyone. Cheers, Fabien On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m wrote: > Hi everyone, > > Looks like I stuck my finger in a hornets' nest. First off, apologies for > not chipping in earlier, but there was a lot of material to digest. Also, > warning: lots to read ahead. > > I'm one of those people who end up making use of AuthN/AuthZ functionalit= y > through a library. On top of that I can see myself being roped in as a > server (AS) implementation help. So I'm approaching this from an outsider= 's > perspective. Someone who expects to be exposed to the eventual RFC and al= l > the nitty-gritty details. My relatively terse comment ended up at the top > of the aforementioned HN thread, which didn't necessarily help. Sorry abo= ut > that. > > Now, having read Justin's initial reply - and the rest of the thread - I > believe I can see where the desire for polymorphism comes from. To be > clear: I am all for strict types inside an implementation, as it will add > helpful guard-rails to the state management code paths. However, I see th= is > as a case of leaky abstraction. If we take the existing oauth.xyj-java co= de > to be the reference implementation, the choice makes logical sense: JSON = is > not expressive enough to serialise arbitrary objects, so in order to avoi= d > writing complex payload parser(s) the internal implementation details now > leak to the protocol itself. From a purely technical perspective, it's a > cool trick. From a distance it even looks a bit like the result of protob= uf > decoding, but without the generated code parts. > > But then the downside. I don't personally expect to be able to use the > reference implementation, being mostly a Python user myself. A fair numbe= r > of AS implementations will be written with languages such as Go, Python, > C#, Ruby, and JavaScript (thanks to node.js), and all of them will have t= o > deal with the polymorphism. From what I've read over the past couple of > days, I understand that at least Go supports custom unmarshalers from JSO= N > to typed structs, at the cost of an indirection. Normally when a Go code > processes JSON to a typed struct, the process is helped by field > annotations in the type definition itself. For example, if the payload fo= r > a person in JSON was > > { > "name": "", > "age": , > "country": "", > "city": "" > } > > .. then the type definition would look like: > > type Person struct { > Name string `json:"name" > Age int `json:"age"` > Country string `json:"country"` > City string `json:"city"` > } > > When the (possibly complex) type of a given field is fixed, unmarshaling > should still be straightforward. I haven't verified, but since the > annotation only gives which field to look at for a given typed value, the= re > should be nothing special about that. But when the field can instead be a > union of more than one distinct types, things start to get messy. There i= s > no union type in the language at all, so the following construct is not > even possible: > > type Entity struct { > Resources []string `json:"resources"` > Client union(Client, string) `json:"client"` > } > > As I understand, the implicit expectation is that in the above case, the > unmarshaler detects that "client" is a string, and so expands it from an > opaque handle to the expected, populated type. Even after thinking about > the ramifications over the past few days I remain confused, because I don= 't > see how the commonly used annotations could work. If the expectation is > that protocol implementations should use strong types, then the use of > polymorphic JSON is very likely to make things _more_ complicated for > non-reference implementations. > > Hence my concern. I'm afraid that the leaky abstraction, while making the > reference implementation more robust and straightforward, contributes to > making other implementations less robust. And this being a security > protocol, the potential for brittle and/or confused implementations is > terrifying. > > I am a fan of reducing complexity, and from what I can see, for the > reference implementation the polymorphic approach actually does that. But > I'm afraid it does so at others' expense. Languages have their individual > constraints, idioms and best practices. If parsing a protocol payload > introduces low-level complexities and encourages to go against common > practices, that is an invitation for problems. I am aware that my choice = of > words in the HN thread was likely to put people on defense, and for that = I > apologise. But I do believe that the choice of polymorphic JSON is going = to > make the life and use of other implementations notably less boring than > people in general would prefer. > > Cheers, > Mika > > On Mon, 26 Oct 2020 at 02:04, Fabien Imbault > wrote: > >> Hi Dick, >> >> Well technically yes. Obviously the client can present any interface it >> seems fit. >> >> Still there's the question of the common model we want to present to the >> outside world and supported by the protocol itself (which client librari= es >> all build upon). >> >> But beneath the polyphormism question, the HN debate seems on the surfac= e >> a lot like the original xyz (polyphormism goes along with the reduced >> endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where th= e >> client design has more latitude). Just explained differently, by outside >> people with different agendas. >> >> Which is a bit weird because many of the critics on HN (who criticize >> polyphormism) also seem to really dislike OAuth in the first place (the >> inconsistencies are partially due to a bunch of different people >> commenting). >> >> Really to me there's no fundamental truth behind that question. It's a >> matter of preference and priorities in the design. Whatever choices we >> make, we'll have to be prepared to explain and justify them in the open, >> even to some people that will dislike pretty much whatever we do (becaus= e >> it's fun to look smart and critize without proposing alternatives). And = we >> owe these answers to people like Mika, who genuinely try to make the bes= t >> of it. >> >> Fabien >> >> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : >> >>> Hi Fabien >>> >>> A library developer can provide whatever abstraction layer makes sense >>> for the library's target audience and language. >>> >>> If the client library developer wants to use polymorphism in the >>> interface presented to the user's of the library, the library developer= can >>> do that independent of polymorphism in the protocol, and vice versa >>> >>> =3D> polymorphism in the protocol has no impact on client library >>> developers >>> >>> >>> =E1=90=A7 >>> >>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >>> wrote: >>> >>>> I'm just realizing your "least to most important" might actually say >>>> the same as what I was trying to say. So I'm not even sure what we're >>>> arguing against :-) >>>> >>>> In brief my point if it wasn't clear is that we should be crystal clea= r >>>> on where we put the cursor of simplicity, because this can mean differ= ent >>>> things for different people and different roles. >>>> And as we see on HN we need to better explain our design choices. >>>> >>>> >>>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >>>> a =C3=A9crit : >>>> >>>>> Hi Dick, >>>>> >>>>> Independantly from the debate on polyphormism, I beg to differ on you= r >>>>> order preference. >>>>> >>>>> Your assumption is that AS devs matter the most, because they're >>>>> doing the important security implementation. But eating our own dogfo= od >>>>> might help a lot to change that view. Most security issues occur beca= use >>>>> users of the spec are unable to deal with the complexity that is pass= ed >>>>> onto them. >>>>> >>>>> 99% of the people that will actually use the output of the work are >>>>> application developers (client or RS) and their own users. >>>>> >>>>> Our intent as well as the protocol drive the usage. Client libraries >>>>> may help, but they're not a silver bullet, especially because GNAP >>>>> ultimately has no control about what people do there (for better or w= orse). >>>>> And everything we do here will help get to the better part. >>>>> >>>>> I'm not saying we don't intend to also care about AS developers >>>>> (beginning with ourselves) but it's a second order optimisation. And = since >>>>> it's a tendancy we're leaning towards by default, I'm pretty sure we = won't >>>>> forget that anyway. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> >>>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt = a >>>>> =C3=A9crit : >>>>> >>>>>> I'm confused by your logic Fabien. >>>>>> >>>>>> If a client library developer wants to expose polymorphism, they can >>>>>> do that independent of what is in the protocol. >>>>>> >>>>>> I differ on who our stakeholders are. >>>>>> >>>>>> I think our stakeholders are in least to most important: >>>>>> >>>>>> >>>>>> - AS developer >>>>>> - RS developer >>>>>> - client developer >>>>>> - user >>>>>> >>>>>> >>>>>> A client library developer can expose whatever interface they want t= o >>>>>> simplify implementation. >>>>>> >>>>>> I list the user so that we don't lose site of a critical role. >>>>>> >>>>>> /Dick >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> Let me try to approach the issue under a different light. More like >>>>>>> a product manager would deal with feature selection to make it intu= itive >>>>>>> for its users. >>>>>>> >>>>>>> For most people, riding a bike is far easier than using a unicycle. >>>>>>> Feels more stable. And yet it's way easier to design for a single w= heel >>>>>>> than to build with 2. Because then you'll need a lot more accessori= es >>>>>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to= be a >>>>>>> brittle process, it can be industrialized. >>>>>>> >>>>>>> Back to the GNAP topic. >>>>>>> Ultimately we should strive to make the spec as simple as can be. >>>>>>> But we need to ask: simple for whom? For the bike owner or for the = bike >>>>>>> vendor? >>>>>>> (short answer: the priority should be simplicity for spec users, no= t >>>>>>> spec implementers and even less spec designers). >>>>>>> >>>>>>> The initial question that is asked is very interesting: isn't the >>>>>>> design flawed if GNAP is using json polyphormism? Or if the AS need= s to >>>>>>> handle the state of the request? Or if we must handle token revocat= ion? Or >>>>>>> if we are looking for a global unique identifier? The argument stem= s of the >>>>>>> fact that is still arguably harder and more error prone to implemen= t. Fair >>>>>>> enough. >>>>>>> >>>>>>> From a spec implementer's perspective, it may well be more complex. >>>>>>> It mostly impacts the json library you'll end up using, plus a bit = of >>>>>>> input/output decoration around it. Even golang provides utilities f= or this, >>>>>>> despite not exactly being made for this kind of purpose. >>>>>>> My practical experience implementing it is that it's not that big a >>>>>>> deal. I mean, I wished it could be simpler, but it's manageable and= there >>>>>>> are other ways to reach levels of insurance that it does work as in= tended >>>>>>> (json schema, test cases to validate the implementation, etc.). Arg= uably it >>>>>>> is still easier from an implementation perspective than say, json-l= d, which >>>>>>> is massively used in the SSI community. >>>>>>> >>>>>>> But ultimately who are we designing for? Are we striving to go easy >>>>>>> on the spec implementer? Or are we trying to make sure end-develope= rs using >>>>>>> the client libraries won't shoot themselves in the foot? >>>>>>> >>>>>>> The job to be done (JTBD), from the end-developer's perspective, is >>>>>>> to efficiently ship an application. And provide authN/authZ capabil= ities >>>>>>> for end-users by relying on some well known implementation. >>>>>>> In turn, this spec implementer will rely on cryptographic utility >>>>>>> libraries that deals internally with the complexity of their own do= main, so >>>>>>> that we don't have to. And here we could launch another HN flame wa= r that >>>>>>> starts with the title "JWT sucks because". Which does have its set = of very >>>>>>> real issues but that's beyond the point. >>>>>>> Note that any decent flamewar will be efficiently fueled by people >>>>>>> hating medium. Is it outrageous for blog posts to be behind a paywa= ll? >>>>>>> Maybe but it's even more outrageous to lack consistency, either by = not >>>>>>> knowing how to get around a paywall if you're into a hacker punk mo= vement, >>>>>>> or on the contrary by to not paying a subscription if you believe t= hat >>>>>>> surveillance capitalism, to reuse Zuboff's terms, should be eradica= ted. >>>>>>> What likely seems an unnecessary sidenote tries to illustrate the >>>>>>> point: for Justin it was easier to publish on medium, because as a = blog >>>>>>> publisher, you might not want to deal with hosting your own blog. B= ut maybe >>>>>>> as a reader you'll find that annoying. Different audiences, differe= nt JTBD, >>>>>>> different tradeoffs. >>>>>>> >>>>>>> Polyphormism is a tool that enables the end-developer to have >>>>>>> minimal knowledge of what it means to deal with a GNAP client libra= ry. You >>>>>>> prepare the request, send to the endpoint and you're good to go. Ma= ssively >>>>>>> simpler than OAuth2 or any similar protocol by the way (as anyone w= ith >>>>>>> teaching experience on the subject might acknowledge). And there's= a lot >>>>>>> more to be done to make sure we indeed reduce the complexity for th= e >>>>>>> end-developer and the end-user. >>>>>>> >>>>>>> If we find a better way to deal with that simplicity balance, I'm >>>>>>> all in. But the arguments need to be way more convincing than just = saying >>>>>>> that it may be difficult to implement or validate. >>>>>>> >>>>>>> Cheers. >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt >>>>>>>> wrote: >>>>>>>> >>>>>>>> Justin >>>>>>>> >>>>>>>> I did note that I was the one that argued for instance_id being in >>>>>>>> the object. Since it is in the object in the current draft, not in= cluding a >>>>>>>> pass by reference option would be preferable. >>>>>>>> >>>>>>>> As for concrete examples: >>>>>>>> - version of client >>>>>>>> - version of OS >>>>>>>> - security attestation of OS / device >>>>>>>> - location of client device >>>>>>>> - network client is operating on >>>>>>>> >>>>>>>> These are all attributes of the client that an AS may require on >>>>>>>> the initial grant request, and in future grant requests (which is = when an >>>>>>>> instance_id) would be used. >>>>>>>> >>>>>>>> >>>>>>>> This is where our interpretations differ: I don=E2=80=99t see thes= e as >>>>>>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that th= e key, display >>>>>>>> information, class identifiers, and other items currently represen= ted by an >>>>>>>> instance_id are attributes of the client instance. The attestation >>>>>>>> components don=E2=80=99t modify the instance so much as present ad= ditional >>>>>>>> information on top of the client instance itself. This is why I ar= gue that >>>>>>>> they ought to be handled in a separate object, so you=E2=80=99d ha= ve something like >>>>>>>> this strawman: >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> posture: { >>>>>>>> software_version: 1.2.3, >>>>>>>> os_version: 14.3.2 >>>>>>>> device_attestation: { =E2=80=A6 some structure or signed blob?= =E2=80=A6 } >>>>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>>>>>> }, >>>>>>>> >>>>>>>> client: =E2=80=9Cclient-541-ab" >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> This is a more fundamental question about GNAP than whether the >>>>>>>> syntax uses polymorphism: this is about GNAP being very explicit a= bout the >>>>>>>> data model of its elements. OAuth 2=E2=80=99s incredibly loose and= broad model of >>>>>>>> what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, i= s deeply problematic in >>>>>>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work wit= h having to >>>>>>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that= doesn=E2=80=99t fully capture >>>>>>>> the different aspects that are out there. I think we=E2=80=99re ge= tting closer here >>>>>>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80= =9D, but we still need to >>>>>>>> be more precise about what exactly a client instance includes, and= what it >>>>>>>> does not. >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> >>>>>>>> /Dick >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> >>>>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dick, >>>>>>>>> >>>>>>>>> As you=E2=80=99ll recall, I argued against including the client i= nstance >>>>>>>>> identifier inside of the object as a mutually-exclusive field pre= cisely >>>>>>>>> because of the principle violation that you are pointing out here= , and so >>>>>>>>> it=E2=80=99s important to point out that the current text is a co= mpromise that >>>>>>>>> needs to be examined in the wider experience of the working group= . I am on >>>>>>>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id= =E2=80=9D option within an >>>>>>>>> object, but this needs to be explored. >>>>>>>>> >>>>>>>>> The crux of my argument is that is exactly a case of >>>>>>>>> pass-by-reference vs pass-by-value, and that runtime attestations= are not >>>>>>>>> part of the =E2=80=9Cclient instance=E2=80=9D value itself but ra= ther belong outside of >>>>>>>>> that object in a another part of the request. As stated in the ed= itorial >>>>>>>>> notes in this section, we need to look carefully at how these con= cepts fit >>>>>>>>> within the model and where we would want to put them. Without con= crete >>>>>>>>> examples of what these extensions look like and how they=E2=80=99= re generated, that >>>>>>>>> is nearly impossible to do at this stage. I look forward to seein= g examples >>>>>>>>> of this kind of data and how it can fit into the protocol. >>>>>>>>> >>>>>>>>> =E2=80=94 Justin >>>>>>>>> >>>>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hey Justin, >>>>>>>>> >>>>>>>>> As the draft has evolved, I question the continued use of >>>>>>>>> polymorphism. Note that I appreciate the elegance of using a stri= ng for >>>>>>>>> pass-by-reference, and an object for pass-by-value. >>>>>>>>> >>>>>>>>> In the current draft, the >>>>>>>>> >>>>>>>>> Every time you create or process a field it will mean only one >>>>>>>>> thing, and there=E2=80=99s only one field to look at to answer a = question. >>>>>>>>> >>>>>>>>> >>>>>>>>> is violated in 2.3.1. Identifying the RC Instance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> instance_id An identifier string that the AS can use to >>>>>>>>> identify the >>>>>>>>> particular instance of this RC. The content and structure >>>>>>>>> of this >>>>>>>>> identifier is opaque to the RC. >>>>>>>>> >>>>>>>>> "client": { >>>>>>>>> "instance_id": "client-541-ab" >>>>>>>>> } >>>>>>>>> >>>>>>>>> If there are no additional fields to send, the RC MAY send the >>>>>>>>> instance identifier as a direct reference value in lieu of the >>>>>>>>> object. >>>>>>>>> >>>>>>>>> "client": "client-541-ab" >>>>>>>>> >>>>>>>>> >>>>>>>>> The instance identifier can be sent two ways. Polymorphism is a >>>>>>>>> convenience for the client, but requires the server to have two c= ode paths >>>>>>>>> for "instance_id". We discussed this in the design team, and I a= rgued for >>>>>>>>> having "instance_id" in the "client" object so that any updates, = such as >>>>>>>>> new devices assertions, could be in the "client" object. As noted= above, >>>>>>>>> while I appreciate the elegance of using a string (handle) to ref= erence a >>>>>>>>> previously provided object, it complicates how to update an exist= ing object >>>>>>>>> while providing the reference. >>>>>>>>> >>>>>>>>> In your example of the "key" object below, setting "proof" to >>>>>>>>> bearer would avoid the issue you describe: >>>>>>>>> >>>>>>>>> { >>>>>>>>> "key": { >>>>>>>>> "proof": "bearer" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> In your example, when processing the "key" object, code is having >>>>>>>>> to check both the JSON type of the property, as well as check the= value of >>>>>>>>> the "proof" property. In the example I provided, only the value o= f "proof" >>>>>>>>> needs to be checked. The "proof" property is acting as a type for= the "key" >>>>>>>>> object. >>>>>>>>> >>>>>>>>> Not being a Java programmer, I don't know how this would work in = a >>>>>>>>> Java implementation, but node.js, the processing would need to be= done as >>>>>>>>> above. >>>>>>>>> >>>>>>>>> On a related note, there was significant negative feedback on >>>>>>>>> handles and polymorphism in the Hacker News article >>>>>>>>> https://news.ycombinator.com/item?id=3D24855750 >>>>>>>>> >>>>>>>>> /Dick >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Mika, >>>>>>>>>> >>>>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able to see = the forum >>>>>>>>>> discussion that brought you here, and hopefully I can help clear= up what I >>>>>>>>>> mean with how polymorphism is used in the proposal. The short ve= rsion is >>>>>>>>>> that the goal is to *avoid* the kinds of ambiguity that make >>>>>>>>>> insecure protocols, and so in that goal we=E2=80=99re fully alig= ned. I think that >>>>>>>>>> using polymorphism in very specific ways can help that goal =E2= =80=94 just as I >>>>>>>>>> agree that misusing it or applying it sloppily can lead to ambig= uous and >>>>>>>>>> insecure systems. >>>>>>>>>> >>>>>>>>>> Some background: I built out the XYZ protocol (one of the >>>>>>>>>> predecessors to the initial GNAP Draft) in Java using strongly t= yped >>>>>>>>>> parsers and Java objects specifically to prove to myself that it= could be >>>>>>>>>> done in a way that made any sense in the code. (My own open sour= ce >>>>>>>>>> implementation is at https://github.com/bspk/oauth.xyz-java, but >>>>>>>>>> note that it=E2=80=99s not yet up to date with the GNAP spec). I= t was important to >>>>>>>>>> me that I be able to use the system-wide configured parsers to i= mplement >>>>>>>>>> this and not have to resort to stepping through elements complet= ely by >>>>>>>>>> hand. Java doesn=E2=80=99t make it simple to get the hooks into = the right places >>>>>>>>>> (especially with the Jackson parser that I used), but it is defi= nitely >>>>>>>>>> possible to create a deterministic and strongly-typed parser and= serializer >>>>>>>>>> for this kind of data structure. Some of the rationale for using >>>>>>>>>> polymorphism is covered in the trailing appendix of the draft do= cument ( >>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00= .html#name-json-structures-and-polymor), >>>>>>>>>> but it=E2=80=99s still good to discuss this here as the working = group decides which >>>>>>>>>> approaches to take. >>>>>>>>>> >>>>>>>>>> The driving reason for using polymorphism at the protocol level >>>>>>>>>> was to simplify the protocol and make it :more: deterministic to= create and >>>>>>>>>> process, not less. Every time you create or process a field it w= ill mean >>>>>>>>>> only one thing, and there=E2=80=99s only one field to look at to= answer a question. >>>>>>>>>> Without polymorphic field values, you usually need to rely on mu= tual >>>>>>>>>> exclusivity of fields, which is prone to failure and requires ad= ditional >>>>>>>>>> error checking. Take for example the key binding of access token= s. An >>>>>>>>>> access token could be bound to the RC=E2=80=99s key used during = the request, to a >>>>>>>>>> different key chosen by the AS, or it could be a bearer token wi= th no key >>>>>>>>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, w= e can define it in terms of >>>>>>>>>> boolean values and objects and express this set of mutually-excl= usive >>>>>>>>>> options in a non-ambiguous way. Without that, you=E2=80=99d need= to have different >>>>>>>>>> fields for the options and include additional checks in your par= ser to make >>>>>>>>>> sure they weren=E2=80=99t sent simultaneously, otherwise you cou= ld get hit with >>>>>>>>>> this potential security vulnerability in an object: >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> key: { >>>>>>>>>> proof: httpsig, >>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>> }, >>>>>>>>>> bearer_token: true, >>>>>>>>>> bind_to_rc_key: true >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This would be an illegal object as per this alternate proposal, >>>>>>>>>> but then you=E2=80=99d have to check each field and make sure it= wasn=E2=80=99t put next to >>>>>>>>>> others in the same object. I=E2=80=99ve done this exercise with = many other >>>>>>>>>> protocols and it=E2=80=99s both error prone and easy to ignore s= ince all the =E2=80=9Cgood=E2=80=9D >>>>>>>>>> examples would pass code that doesn=E2=80=99t check this. With t= he polymorphic >>>>>>>>>> approach to this same field, each of these three mutually-exclus= ive states >>>>>>>>>> is written in a way that they cannot be sent together. It=E2=80= =99s not just >>>>>>>>>> illegal, it=E2=80=99s impossible and enforced by the syntax of J= SON itself. >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> key: { >>>>>>>>>> proof: httpsig, >>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> // bearer token >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> key: false >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>>>> >>>>>>>>>> { >>>>>>>>>> key: true >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> If someone sends a different type for this field, like an array >>>>>>>>>> or number or a null, this doesn=E2=80=99t have a defined interpr= etation in the >>>>>>>>>> protocol and would be a protocol level error. >>>>>>>>>> >>>>>>>>>> While it might sound like polymorphism means that any field coul= d >>>>>>>>>> have any type or value, the opposite is true: each possible valu= e is >>>>>>>>>> explicitly typed, it=E2=80=99s just that there are potentially d= ifferent types that >>>>>>>>>> express meaning for the field. This applies to all members of al= l objects >>>>>>>>>> (dictionaries) as well as all members of an array (list). Every = time you >>>>>>>>>> process a field value or other element, you look at the type and= then the >>>>>>>>>> value to determine what to do with that typed value. >>>>>>>>>> >>>>>>>>>> In your example below, each field within the dictionary would >>>>>>>>>> also need to be typed, and each type would need to have a clear = indication >>>>>>>>>> of its meaning. To take your strawman key format below, the =E2= =80=9Cmodulus=E2=80=9D field >>>>>>>>>> could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an >>>>>>>>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition= would further say what >>>>>>>>>> exactly the encoding of the string would be. That means that whe= n you read >>>>>>>>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be an= y confusion on what the value was >>>>>>>>>> or how it was represented, regardless of the input format. Seein= g a number >>>>>>>>>> there means exactly one interpretation and seeing a string means= exactly >>>>>>>>>> one (different) interpretation =E2=80=94 but importantly, both o= f them are a >>>>>>>>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that d= etermines the type. An >>>>>>>>>> implementation would likely use an internal BigInteger type of o= bject to >>>>>>>>>> represent the field value after parsing, so the question is how = to go from >>>>>>>>>> the JSON value (which is typed) into the BigInteger value.You do= n=E2=80=99t just >>>>>>>>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, = you apply it to all >>>>>>>>>> sub-fields of that object. >>>>>>>>>> >>>>>>>>>> So let=E2=80=99s dig into the specific bug you bring up in the s= trawman, >>>>>>>>>> because it=E2=80=99s interesting: A JSON encoder that encodes nu= mbers as strings, >>>>>>>>>> and not numbers, is not compliant with the JSON definitions of t= he field in >>>>>>>>>> question. For another example, the quoted string value of =E2=80= =9Ctrue=E2=80=9D is not >>>>>>>>>> equivalent to the boolean value true in JSON, and they shouldn= =E2=80=99t be treated >>>>>>>>>> the same by a parser implementation when mapping to a concrete o= bject. It=E2=80=99s >>>>>>>>>> in this kind of automated guessing that this class of bugs occur= , and >>>>>>>>>> that=E2=80=99s going to be the case whether or not you take adv= antage of JSON=E2=80=99s >>>>>>>>>> polymorphic nature. I=E2=80=99ve run into cases where a parser l= ibrary was trying >>>>>>>>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of map= ping, but ended up >>>>>>>>>> introducing errors in more strict components downstream. This is= something >>>>>>>>>> that protocol designers need to be aware of and guard against in= the design >>>>>>>>>> of the protocol to reduce possible ambiguities. Within GNAP toda= y, we >>>>>>>>>> generally have things that branch whether they=E2=80=99re an obj= ect (for a rich >>>>>>>>>> description of something) or some non-structured special value (= for a >>>>>>>>>> reference or other item). >>>>>>>>>> >>>>>>>>>> The design team created some simple JSON Schemas for parts of th= e >>>>>>>>>> protocol during our discussion, but we didn=E2=80=99t include th= em in the design >>>>>>>>>> document due to both lack of time to keep it updated with the ra= pid changes >>>>>>>>>> to the protocol during the design team discussion, and not knowi= ng if there >>>>>>>>>> would be interest in such material. I personally think it would = be helpful >>>>>>>>>> to include as an informative reference in the final document, bu= t that=E2=80=99s >>>>>>>>>> something for the working group to take up eventually. >>>>>>>>>> >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> >>>>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>>>>>>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>>>>>>>> >>>>>>>>>> Hello, everyone. >>>>>>>>>> >>>>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion >>>>>>>>>> forum and when I made note about certain concerns, I was request= ed to send >>>>>>>>>> my comments to this working group. >>>>>>>>>> >>>>>>>>>> In short, I believe that the use of polymorphic JSON in the >>>>>>>>>> protocol invites subtle and confusing implementation problems. I= also >>>>>>>>>> searched through the WG archives, and noticed that similar conce= rns were >>>>>>>>>> noted, briefly, in a thread in July. >>>>>>>>>> >>>>>>>>>> The problem with polymorphic values, as I see it, is that >>>>>>>>>> implementations will need to branch on the (inferred) type of a = given >>>>>>>>>> field. This isn't quite as bad if the types are strictly differe= nt, but >>>>>>>>>> allows for subtle bugs when the value in question is a dictionar= y. What >>>>>>>>>> makes this unappealing is that "subtle bugs" in security protoco= ls have a >>>>>>>>>> habit of turning into vulnerabilities. >>>>>>>>>> >>>>>>>>>> Let's say we have these imaginary payloads, both possible and >>>>>>>>>> valid in the same protocol step: >>>>>>>>>> >>>>>>>>>> # payload 1 >>>>>>>>>> { >>>>>>>>>> ..., >>>>>>>>>> "public_key": { >>>>>>>>>> "alg": "rsa", >>>>>>>>>> "modulus": >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> # payload 2 >>>>>>>>>> { >>>>>>>>>> ..., >>>>>>>>>> "public_key": { >>>>>>>>>> "alg": "rsa", >>>>>>>>>> "modulus": "" >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> In both cases, the type of "public_key" field is a dictionary. I= n >>>>>>>>>> both cases, they even have the same keys. However, the values in= the >>>>>>>>>> dictionaries are entirely different, and an implementation will = have to >>>>>>>>>> branch to at least two possible decoding mechanisms. To make thi= ngs worse, >>>>>>>>>> some JSON implementations may choose to encode non-dictionary va= lues as >>>>>>>>>> strings, so it is possible for an originator to transmit what th= ey expect >>>>>>>>>> and believe to be payload 1 format, but which the receiver will = interpret >>>>>>>>>> to be in payload 2 format. And if the encoded string contains on= ly digits, >>>>>>>>>> it will even parse correctly as a bignum. >>>>>>>>>> >>>>>>>>>> While the above is clearly a manufactured scenario, it >>>>>>>>>> nonetheless demonstrates the potential for logic bugs with polym= orphic >>>>>>>>>> JSON. With richer types and more complex dictionaries, there wil= l surely be >>>>>>>>>> more room for errors. >>>>>>>>>> >>>>>>>>>> Ambiguity in protocols is always a source of implementation >>>>>>>>>> complexity and interoperability snags, but in an AuthN/AuthZ pro= tocol it is >>>>>>>>>> worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, >>>>>>>>>> wouldn't it be in everyone's interest to keep implementation com= plexity and >>>>>>>>>> mistake potential to a minimum? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Mika >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mika Bostr=C3=B6m >>>>>>>>>> Smarkets >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >>>>>>>>> =E1=90=A7 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> > > -- > Mika Bostr=C3=B6m > Smarkets > --000000000000b8fa5b05b2be081d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the great feedback. Your concern is very valid.= =C2=A0

    My implementation is in rust, which makes li= fe easier in that specific case.=C2=A0

    So I&= #39;m not a golang specialist but I guess the transcription of json strings= /arrays into go structs would work around the lines described by=C2=A0h= ttps://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1
    =
    When we have a more formalized json schema, I suggest we make a librar= y of json examples and some related code samples in mainstream languages, t= o check it is feasible for everyone.=C2=A0

    <= div>Cheers,
    Fabien


    On Wed, Oct 28, 2020 at 5:= 28 PM Mika Bostr=C3=B6m <mi= ka.bostrom@smarkets.com> wrote:
    Hi everyone,

    Looks like I stuck my finger in a hornets' nest. First off, apo= logies for not chipping in earlier, but there was a lot of material to dige= st. Also, warning: lots to read ahead.

    I'm= one of those people who end up making use of AuthN/AuthZ functionality thr= ough a library. On top of that I can see myself being roped in as a server = (AS) implementation help. So I'm approaching this from an outsider'= s perspective. Someone who expects to be exposed to the eventual RFC and al= l the nitty-gritty details. My relatively terse comment ended up at the top= of the aforementioned HN thread, which didn't necessarily help. Sorry = about that.

    Now, having read Justin's initial = reply - and the rest of the thread - I believe I can see where the desire f= or polymorphism comes from. To be clear: I am all for strict types inside a= n implementation, as it will add helpful guard-rails to the state managemen= t code paths. However, I see this as a case of leaky abstraction. If we tak= e the existing oauth.xyj-java code to be the reference implementation, the = choice makes logical sense: JSON is not expressive enough to serialise arbi= trary objects, so in order to avoid writing complex payload parser(s) the i= nternal implementation details now leak to the protocol itself. From a pure= ly technical perspective, it's a cool trick. From a distance it even lo= oks a bit like the result of protobuf decoding, but without the generated c= ode parts.

    But then the downside. I don't = personally expect to be able to use the reference implementation, being mos= tly a Python user myself. A fair number of AS implementations will be writt= en with languages such as Go, Python, C#, Ruby, and JavaScript (thanks to n= ode.js), and all of them will have to deal with the polymorphism. From what= I've read over the past couple of days, I understand that at least Go = supports custom unmarshalers from JSON to typed structs, at the cost of an = indirection. Normally when a Go code processes JSON to a typed struct, the = process is helped by field annotations in the type definition itself. For e= xample, if the payload for a person in JSON was

    {<= /div>
    =C2=A0 "name": "<string>",
    = =C2=A0 "age": <int>,
    =C2=A0 "country&quo= t;: "<string>",
    =C2=A0 "city": "&l= t;string>"
    }

    .. then the type de= finition would look like:

    type Person struct {
    =C2=A0 Name string `json:"name"
    =C2=A0 Age int `= json:"age"`
    =C2=A0 Country string `json:"country&q= uot;`
    =C2=A0 City string `json:"city"`
    }

    When the (possibly complex) type of a given field is f= ixed, unmarshaling should still be straightforward. I haven't verified,= but since the annotation only gives which field to look at for a given typ= ed value, there should be nothing special about that. But when the field ca= n instead be a union of more than one distinct types, things start to get m= essy. There is no union type in the language at all, so the following const= ruct is not even possible:

    type Entity struct {
    =C2=A0 Resources []string `json:"resources"`
    =C2=A0 Client union(Client, string) `json:"client"`
    }=

    As I understand, the implicit expectation is = that in the above case, the unmarshaler detects that "client" is = a string, and so expands it from an opaque handle to the expected, populate= d type. Even after thinking about the ramifications over the past few days = I remain confused, because I don't see how the commonly used annotation= s could work. If the expectation is that protocol implementations should us= e strong types, then the use of polymorphic JSON is very likely to make thi= ngs _more_ complicated for non-reference implementations.
    Hence my concern. I'm afraid that the leaky abstraction, while = making the reference implementation more robust and straightforward, contri= butes to making other implementations less robust. And this being a securit= y protocol, the potential for brittle and/or confused implementations is te= rrifying.

    I am a fan of reducing complexity, and fr= om what I can see, for the reference implementation the polymorphic approac= h actually does that. But I'm afraid it does so at others' expense.= Languages have their individual constraints, idioms and best practices. If= parsing a protocol payload introduces low-level complexities and encourage= s to go against common practices, that is an invitation for problems. I am = aware that my choice of words in the HN thread was likely to put people on = defense, and for that I apologise. But I do believe that the choice of poly= morphic JSON is going to make the life and use of other implementations not= ably less boring than people in general would prefer.

    <= div>Cheers,
    Mika

    On Mon, 26 Oct 2020 at 02:04, Fabien Im= bault <fab= ien.imbault@gmail.com> wrote:
    Hi Dick,

    =
    Well technically yes. Obviously the client can present an= y interface it seems fit.=C2=A0

    Still there's the question of the common model we want to pre= sent to the outside world and supported by the protocol itself (which clien= t libraries all build upon).=C2=A0

    But beneath the polyphormism question, the HN debate seems on th= e surface a lot like the original xyz (polyphormism goes along with the red= uced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where = the client design has more latitude). Just explained differently, by outsid= e people with different agendas.=C2=A0

    Which is a bit weird because many of the critics on HN (who = criticize polyphormism) also seem to really dislike OAuth in the first plac= e (the inconsistencies are partially due to a bunch of different people com= menting).=C2=A0

    Really t= o me there's no fundamental truth behind that question. It's a matt= er of preference and priorities in the design. Whatever choices we make, we= 'll have to be prepared to explain and justify them in the open, even t= o some people that will dislike pretty much whatever we do (because it'= s fun to look smart and critize without proposing alternatives). And we owe= these answers to people like Mika, who genuinely try to make the best of i= t.=C2=A0

    Fabien=C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9cr= it=C2=A0:
    Hi Fabien

    A library developer can provide wha= tever abstraction layer makes sense for the library's target=C2=A0audie= nce and language.

    If the client library=C2=A0devel= oper wants to use polymorphism=C2=A0in the interface presented to the user&= #39;s of the library, the library developer can do that independent of poly= morphism in the protocol, and vice versa=C2=A0

    =3D= > polymorphism in the protocol has no impact on client library developer= s


    3D""=E1=90=A7<= /div>
    O= n Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
    I'm just realizing your "least to most impo= rtant" might actually say the same as what I was trying to say. So I&#= 39;m not even sure what we're arguing against :-)=C2=A0

    In brief my point if it wasn't clear is t= hat we should be crystal clear on where we put the cursor of simplicity, be= cause this can mean different things for different people and different rol= es.=C2=A0
    And as we see on HN we need to better expl= ain our design choices.=C2=A0


    Le dim. 25 o= ct. 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:
    Hi Dick,

    Independantly from the debate on polyphormism, I beg to differ on= your order preference.=C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're doing the important security im= plementation. But eating our own dogfood might help a lot to change that vi= ew. Most security issues occur because users of the spec are unable to deal= with the complexity that is passed onto them.=C2=A0

    99% of the people that will actually = use the output of the work are application developers (client or RS) and th= eir own users.=C2=A0

    Our intent as well as the protocol driv= e the usage. Client libraries may help, but they're not a silver bullet= , especially because GNAP ultimately has no control about what people do th= ere (for better or worse). And everything we do here will help get to the b= etter part.=C2=A0

    I'm not saying we don't intend to also care about AS developers (b= eginning with ourselves) but it's a second order optimisation. And sinc= e it's a tendancy we're leaning towards by default, I'm pretty = sure we won't forget that anyway.=C2=A0

    Fabien=C2=A0
    <= br style=3D"font-family:sans-serif">


    Le sam. 24 oct. = 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit=C2=A0:
    I'm confused by your logic Fabien.

    =
    If a client library developer wants to expose polymorphism, they can d= o that independent of what is in the protocol.=C2=A0

    I differ on who our stakeholders are.=C2=A0

    I t= hink our stakeholders are in least to most important:

    <= div>
    • AS developer
    • RS developer
    • client developer
      • =
    • user

    A client library developer can = expose whatever interface they want to simplify implementation.
    <= br>
    I list the user so that we don't lose site of a critical = role.

    /Dick


    3D""=E1=90=A7

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Im= bault <fabien.imbault@gmail.com> wrot= e:
    Hi there,=C2=A0

    Let= me try to approach the issue under a different light. More like a product = manager would deal with feature selection to make it intuitive for its user= s.=C2=A0

    For= most people, riding a bike is far easier than using a unicycle. Feels more= stable. And yet it's way easier to design for a single wheel than to b= uild with 2. Because then you'll need a lot more accessories (chain, ch= ain ring, etc.). Even so producing a bike doesn't have to be a brittle = process, it can be industrialized.=C2=A0

    <= div dir=3D"auto">Back to the GNAP topic.=C2=A0
    Ultimately we should strive to make the spe= c as simple as can be. But we need to ask: simple for whom? For the bike ow= ner or for the bike vendor?=C2=A0
    (short answer: the priority should be simpl= icity for spec users, not spec implementers and even less spec designers).= =C2=A0

    The initial question that is asked is v= ery interesting: isn't the design flawed if GNAP is using json polyphor= mism? Or if the AS needs to handle the state of the request? Or if we must = handle token revocation? Or if we are looking for a global unique identifie= r? The argument stems of the fact that is still arguably harder and more er= ror prone to implement. Fair enough.=C2=A0

    From a spec implementer's perspective, it may well b= e more complex. It mostly impacts the json library you'll end up using,= plus a bit of input/output decoration around it. Even golang provides util= ities for this, despite not exactly being made for this kind of purpose.
    My practical experience implementing it is that it'= ;s not that big a deal. I mean, I wished it could be simpler, but it's = manageable and there are other ways to reach levels of insurance that it do= es work as intended (json schema, test cases to validate the implementation= , etc.). Arguably it is still easier from an implementation perspective tha= n say, json-ld, which is massively used in the SSI community.=C2=A0

    But ultimately who are we desig= ning for? Are we striving to go easy on the spec implementer? Or are we try= ing to make sure end-developers using the client libraries won't shoot = themselves in the foot?

    = The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities for e= nd-users by relying on some well known implementation.=C2=A0
    In turn, this spec implementer will rely on cryptographic utility= libraries that deals internally with the complexity of their own domain, s= o that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have i= ts set of very real issues but that's beyond the point.=C2=A0
    Note that any decent flamewar will be efficiently fueled by p= eople hating medium. Is it outrageous for blog posts to be behind a paywall= ? Maybe but it's even more outrageous to lack consistency, either by no= t knowing how to get around a paywall if you're into a hacker punk move= ment, or on the contrary by to not paying a subscription if you believe tha= t surveillance capitalism, to reuse Zuboff's terms, should be eradicate= d.=C2=A0
    What likely seems an unnecessary sidenote t= ries to illustrate the point: for Justin it was easier to publish on medium= , because as a blog publisher, you might not want to deal with hosting your= own blog. But maybe as a reader you'll find that annoying. Different a= udiences, different JTBD, different tradeoffs.=C2=A0

    Polyphormism is a tool that enables the end-de= veloper to have minimal knowledge of what it means to deal with a GNAP clie= nt library. You prepare the request, send to the endpoint and you're go= od to go. Massively simpler than OAuth2 or any similar protocol by the way = (as anyone with teaching experience on the subject might acknowledge). And= =C2=A0 there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=C2=A0

    If we find a better way to deal with that = simplicity balance, I'm all in. But the arguments need to be way more c= onvincing than just saying that it may be difficult to implement or validat= e.=C2=A0

    Cheers.
    Fabien

    <= br>



    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9= crit=C2=A0:


    On Oct 23, 2020, at 3:52 PM, D= ick Hardt <dick.hardt@gmail.com> wrote:

    Justin

    I did note that I was the one that argu= ed for instance_id being in the object. Since it is in the object in the cu= rrent draft, not including a pass by reference option would be preferable.= =C2=A0

    As for concrete examples:
    - versi= on of client
    - version of OS
    - security attestation of = OS / device
    - location of client device
    - network clien= t is operating on

    These are all attributes of the = client that an AS may require=C2=A0on the initial grant request, and in fut= ure grant requests (which is when an instance_id) would be used.
    =

    This is where our in= terpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of t= he client=E2=80=9D in the same way that the key, display information, class= identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t = modify the instance so much as present additional information on top of the= client instance itself. This is why I argue that they ought to be handled = in a separate object, so you=E2=80=99d have something like this strawman:

    {

    =C2=A0 posture: {
    <= div>=C2=A0 =C2=A0 software_version: 1.2.3,
    =C2=A0 =C2=A0 os_versi= on: 14.3.2
    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some str= ucture or signed blob? =E2=80=A6 }
    =C2=A0 =C2=A0 location: { lat:= =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
    =C2=A0 },
    =
    =C2=A0 client: =E2=80=9Cclient-541-ab"

    }

    This is a more fundamental question abo= ut GNAP than whether the syntax uses polymorphism: this is about GNAP being= very explicit about the data model of its elements. OAuth 2=E2=80=99s incr= edibly loose and broad model of what the term =E2=80=9Cclient=E2=80=9D is r= eferring to, exactly, is deeply problematic in practice. We=E2=80=99re even= seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccredent= ialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the= different aspects that are out there. I think we=E2=80=99re getting closer= here in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D= , but we still need to be more precise about what exactly a client instance= includes, and what it does not.

    =C2=A0=E2=80=94 J= ustin


    /Dick

    3D""=E1=90=A7
    On F= ri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote= :
    Dick,
    As you=E2=80=99ll recall, I argued against including the cl= ient instance identifier inside of the object as a mutually-exclusive field= precisely because of the principle violation that you are pointing out her= e, and so it=E2=80=99s important to point out that the current text is a co= mpromise that needs to be examined in the wider experience of the working g= roup. I am on the side of removing the mutually-exclusive =E2=80=9Cinstance= _id=E2=80=9D option within an object, but this needs to be explored.
    <= div>
    The crux of my argument is that is exactly a case of pas= s-by-reference vs pass-by-value, and that runtime attestations are not part= of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong ou= tside of that object in a another part of the request. As stated in the edi= torial notes in this section, we need to look carefully at how these concep= ts fit within the model and where we would want to put them. Without concre= te examples of what these extensions look like and how they=E2=80=99re gene= rated, that is nearly impossible to do at this stage. I look forward to see= ing examples of this kind of data and how it can fit into the protocol.

    =C2=A0=E2=80=94 Justin

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.ha= rdt@gmail.com> wrote:

    Hey Justin,

    As the draft has evolved, I question t= he continued use of polymorphism. Note that I appreciate the elegance=C2=A0= of using a string for pass-by-reference, and an object for pass-by-value.

    In the current draft, the=C2=A0


    The in= stance identifier can be sent two ways. Polymorphism is a convenience for t= he client, but requires the server=C2=A0to have two code=C2=A0paths for &qu= ot;instance_id".=C2=A0 We discussed this in the design team, and I arg= ued for having "instance_id" in the "client" object=C2= =A0so that any updates, such as new devices assertions, could be in the &qu= ot;client" object. As noted above, while I appreciate the elegance of = using a string (handle) to reference a previously provided object, it compl= icates how to update an existing object while providing the reference.

    In your example of the "key" object below, s= etting "proof" to bearer would avoid the issue you describe:

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 = =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2=A0 }
    = }

    In your example, when processing the "k= ey" object, code is having to check both the JSON type of the property= , as well as check the value of the "proof" property. In the exam= ple I provided, only the value of "proof" needs to be checked. Th= e "proof" property is acting as a type for the "key" ob= ject.

    Not being a Java programmer, I don't kno= w how this would work in a Java implementation, but node.js, the processing= would need to be done as above.


    /Dick


    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jri= cher@mit.edu> wrote:
    Hi Mika,

    Thanks for bringing this topic= here =E2=80=94 I was able to see the forum discussion that brought you her= e, and hopefully I can help clear up what I mean with how polymorphism is u= sed in the proposal. The short version is that the goal is to=C2=A0avoid= =C2=A0the kinds of ambiguity that make insecure protocols, and so in th= at goal we=E2=80=99re fully aligned. I think that using polymorphism in ver= y specific ways can help that goal =E2=80=94 just as I agree that misusing = it or applying it sloppily can lead to ambiguous and insecure systems.

    Some background: I built out the XYZ protocol (one of = the predecessors to the initial GNAP Draft) in Java using strongly typed pa= rsers and Java objects specifically to prove to myself that it could be don= e in a way that made any sense in the code. (My own open source implementat= ion is at=C2=A0https://github.com/bspk/oauth.xyz-java, b= ut note that it=E2=80=99s not yet up to date with the GNAP spec). It was im= portant to me that I be able to use the system-wide configured parsers to i= mplement this and not have to resort to stepping through elements completel= y by hand. Java doesn=E2=80=99t make it simple to get the hooks into the ri= ght places (especially with the Jackson parser that I used), but it is defi= nitely possible to create a deterministic and strongly-typed parser and ser= ializer for this kind of data structure. Some of the rationale for using po= lymorphism is covered in the trailing appendix of the draft document (h= ttps://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-j= son-structures-and-polymor), but it=E2=80=99s still good to discuss thi= s here as the working group decides which approaches to take.=C2=A0

    The driving reason for using polymorphism at the protocol= level was to simplify the protocol and make it :more: deterministic to cre= ate and process, not less. Every time you create or process a field it will= mean only one thing, and there=E2=80=99s only one field to look at to answ= er a question. Without polymorphic field values, you usually need to rely o= n mutual exclusivity of fields, which is prone to failure and requires addi= tional error checking. Take for example the key binding of access tokens. A= n access token could be bound to the RC=E2=80=99s key used during the reque= st, to a different key chosen by the AS, or it could be a bearer token with= no key at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we c= an define it in terms of boolean values and objects and express this set of= mutually-exclusive options in a non-ambiguous way. Without that, you=E2=80= =99d need to have different fields for the options and include additional c= hecks in your parser to make sure they weren=E2=80=99t sent simultaneously,= otherwise you could get hit with this potential security vulnerability in = an object:

    {=C2=A0
    =C2=A0 =C2=A0 key: {<= /div>
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0 =C2= =A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 },
    =
    =C2=A0 =C2=A0 bearer_token: true,
    =C2=A0 =C2=A0 bind_to_rc_k= ey: true
    }

    This would be an illegal obje= ct as per this alternate proposal, but then you=E2=80=99d have to check eac= h field and make sure it wasn=E2=80=99t put next to others in the same obje= ct. I=E2=80=99ve done this exercise with many other protocols and it=E2=80= =99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80= =9D examples would pass code that doesn=E2=80=99t check this. With the poly= morphic approach to this same field, each of these three mutually-exclusive= states is written in a way that they cannot be sent together. It=E2=80=99s= not just illegal, it=E2=80=99s impossible and enforced by the syntax of JS= ON itself.

    {=C2=A0
    =C2=A0 =C2=A0 ke= y: {
    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,
    =C2=A0 =C2=A0= =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }
    =C2=A0 =C2=A0 }
    }

    // bearer token

    {
    =C2=A0 =C2=A0 key: false
    }

    // bound to the RC=E2=80=99s presented key

    {=
    =C2=A0 =C2=A0 key: true
    }

    If = someone sends a different type for this field, like an array or number or a= null, this doesn=E2=80=99t have a defined interpretation in the protocol a= nd would be a protocol level error.

    While it might= sound like polymorphism means that any field could have any type or value,= the opposite is true: each possible value is explicitly typed, it=E2=80=99= s just that there are potentially different types that express meaning for = the field. This applies to all members of all objects (dictionaries) as wel= l as all members of an array (list). Every time you process a field value o= r other element, you look at the type and then the value to determine what = to do with that typed value.

    In your example below= , each field within the dictionary would also need to be typed, and each ty= pe would need to have a clear indication of its meaning. To take your straw= man key format below, the =E2=80=9Cmodulus=E2=80=9D field could be defined = polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an = =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would furt= her say what exactly the encoding of the string would be. That means that w= hen you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be = any confusion on what the value was or how it was represented, regardless o= f the input format. Seeing a number there means exactly one interpretation = and seeing a string means exactly one (different) interpretation =E2=80=94 = but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that= =E2=80=99s the field that determines the type. An implementation would like= ly use an internal BigInteger type of object to represent the field value a= fter parsing, so the question is how to go from the JSON value (which is ty= ped) into the BigInteger value.You don=E2=80=99t just apply the type rules = on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields o= f that object.=C2=A0

    So let=E2=80=99s dig into the= specific bug you bring up in the strawman, because it=E2=80=99s interestin= g: A JSON encoder that encodes numbers as strings, and not numbers, is not = compliant with the JSON definitions of the field in question. For another e= xample, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent= to the boolean value true in JSON, and they shouldn=E2=80=99t be treated t= he same by a parser implementation when mapping to a concrete object. It=E2= =80=99s in this kind of automated guessing that this class of bugs occur, a= nd that=E2=80=99s going to be the case whether or not you take =C2=A0advant= age of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where= a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doin= g this kind of mapping, but ended up introducing errors in more strict comp= onents downstream. This is something that protocol designers need to be awa= re of and guard against in the design of the protocol to reduce possible am= biguities. Within GNAP today, we generally have things that branch whether = they=E2=80=99re an object (for a rich description of something) or some non= -structured special value (for a reference or other item).=C2=A0
    =
    The design team created some simple JSON Schemas for parts o= f the protocol during our discussion, but we didn=E2=80=99t include them in= the design document due to both lack of time to keep it updated with the r= apid changes to the protocol during the design team discussion, and not kno= wing if there would be interest in such material. I personally think it wou= ld be helpful to include as an informative reference in the final document,= but that=E2=80=99s something for the working group to take up eventually.<= /div>

    =C2=A0=E2=80=94 Justin

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org>= wrote:

    Hello, everyone.

    =
    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion f= orum and when I made note about certain concerns, I was requested to send m= y comments to this working group.

    In short, I = believe that the use of polymorphic JSON in the protocol invites subtle and= confusing implementation problems. I also searched through the WG archives= , and noticed that similar concerns were noted, briefly, in a thread in Jul= y.

    The problem with polymorphic values, as I = see it, is that implementations will need to branch on the (inferred) type = of a given field. This isn't quite as bad if the types are strictly dif= ferent, but allows for subtle bugs when the value in question is a dictiona= ry. What makes this unappealing is that "subtle bugs" in security= protocols have a habit of turning into vulnerabilities.

    Let's say we have these imaginary payloads, both possible and va= lid in the same protocol step:

    # payload 1
    {
    =C2=A0 ...,
    =C2=A0 "public_key": {
    =
    =C2=A0=C2=A0=C2=A0 "alg": "rsa",
    =C2= =A0=C2=A0=C2=A0 "modulus": <BIGINT>
    =C2=A0 }
    }

    # payload 2
    {
    =C2=A0 .= ..,
    =C2=A0 "public_key": {
    =C2=A0=C2=A0=C2=A0= "alg": "rsa",
    =C2=A0=C2=A0=C2=A0 "modul= us": "<encoded string>"
    =C2=A0 }
    }=

    In both cases, the type of "public_key"= field is a dictionary. In both cases, they even have the same keys. Howeve= r, the values in the dictionaries are entirely different, and an implementa= tion will have to branch to at least two possible decoding mechanisms. To m= ake things worse, some JSON implementations may choose to encode non-dictio= nary values as strings, so it is possible for an originator to transmit wha= t they expect and believe to be payload 1 format, but which the receiver wi= ll interpret to be in payload 2 format. And if the encoded string contains = only digits, it will even parse correctly as a bignum.

    While the above is clearly a manufactured scenario, it nonetheless= demonstrates the potential for logic bugs with polymorphic JSON. With rich= er types and more complex dictionaries, there will surely be more room for = errors.

    Ambiguity in protocols is always a source = of implementation complexity and interoperability snags, but in an AuthN/Au= thZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is intended t= o supersede Oauth1/2, wouldn't it be in everyone's interest to keep= implementation complexity and mistake potential to a minimum?

    Best regards,
    Mika

    --
    Mi= ka Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/txauth
    =
    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h
    3D""=E1=90=A7


    --
    TXAuth mailing list
    T= XAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txaut= h


    --
    Mika Bostr=C3=B6m
    Smarkets
    =
    --000000000000b8fa5b05b2be081d-- From nobody Wed Oct 28 10:11:57 2020 Return-Path: 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 AD9073A07B2 for ; Wed, 28 Oct 2020 10:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 m6BlbbG_O3dA for ; Wed, 28 Oct 2020 10:11:50 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DC03A0779 for ; Wed, 28 Oct 2020 10:11:49 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SHBj6x026707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 13:11:46 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1DD9F0AC-D89F-41C3-8040-555CBE5DAB31" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 13:11:45 -0400 In-Reply-To: Cc: Fabien Imbault , Dick Hardt , GNAP Mailing List To: =?utf-8?Q?Mika_Bostr=C3=B6m?= References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 17:11:56 -0000 --Apple-Mail=_1DD9F0AC-D89F-41C3-8040-555CBE5DAB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mika, First, thank you for joining the conversation, and thank you for the = great feedback! The spec is really just getting started, and this kind = of discussion and input is important. As you can see, the working group = hasn=E2=80=99t fully settled on a set of answers yet, and so more = perspectives are needed and desired. There are always tradeoffs with = every protocol decision, and it=E2=80=99s important that we understand = these decisions as we make them. I think we would both agree that the goal this kind of a standard is = definitely not to expect people to use a particular reference = implementation, and anything that relies on a specific library, = language, or implementation isn=E2=80=99t truly interoperable in any = meaningful way.=20 I=E2=80=99m not familiar enough with Go to comment on details of the = implementation below, but in the Java implementation that I did, each = field with different type-based representations is tagged with a = serializer/deserializer hook. This is very common for Java-based JSON = systems, and not just for polymorphic content. For example, if I have a = JWT, I want it stored as a structured object that contains easy access = to all the parsed data, but I need it serialized as a single string = within JSON. Therefore I tag the individual field that=E2=80=99s of Java = type JWT with serializer and deserializer classes, both of which do a = simple transformation to and from the canonical string form that the JWT = class provides for me. Fields with multiple possible types are handled = similarly to this: as you note below, there is a domain object class for = the field itself, and the deserializer checks the type of the JSON node = during parsing to determine how to populate that class object. Going in = the other direction, the serializer looks at the state of the object and = its contents to figure out if it needs to be a complex type (like a JSON = object) or a simple type (like a JSON string) and outputs the = appropriate JSON node to the serializer=E2=80=99s stream.=20 I=E2=80=99ve worked with a number of other languages and platforms, and = there are similar capabilities to what I had used for Java, described = here. I believe in Go you=E2=80=99d have something similar to do a = custom marshall/unmarshall of the field/type in question. You don=E2=80=99= t really want it to be a =E2=80=9Cunion type=E2=80=9D within the data = model, so much as you need to be able how to get into and out of JSON. = And in my experience, for dynamically typed languages like Python and = JavaScript, it=E2=80=99s often easier (or at least more common) to just = parse the JSON directly and pull out the values directly as needed, as = opposed to mapping them to a concrete class object. You can actually do = something similar with Java if you want to just map to generic types. = These implementations will need to do some additional sanity checks = during the reading of individual fields, but these end up being the same = kinds of checks and mappings that happen during the parsing phase of a = statically typed language. In other words, you check for =E2=80=9Cstring = or object=E2=80=9D at the point of reading the =E2=80=9Cclient=E2=80=9D = field and branch your code there, as opposed to having the parser do it = for you. This might seem like a lot of overhead for just trying to read = a value, but bear in mind that the alternative is to do something like = read an object, then check across the fields of that object, and branch = your code based on that =E2=80=94 including new error branches for = inconsistent states. This is why it=E2=80=99s important to me that polymorphism is applied in = a very specific way in the protocol. If there=E2=80=99s a field named = =E2=80=9Cclient=E2=80=9D then I should be able to look at whatever value = is in that field and get back a =E2=80=9Cclient=E2=80=9D of some kind = that I can put into a dat structure, whether I=E2=80=99m parsing the = object directly or looking up a reference. If I can get something = that=E2=80=99s not a =E2=80=9Cclient=E2=80=9D from that field, or if I = have to deal with several radically different kinds of objects from = there, then I think we=E2=80=99ve missed the mark. The one place = currently in the protocol where we have objects with some known = structure but potentially arbitrary contents are within the = =E2=80=9Cresources=E2=80=9D array, and for that there is a required = =E2=80=9Ctype=E2=80=9D field to keep different sides from guessing what = to do with it. Even so, it=E2=80=99s always a requested resource = description, so it semantically always maps to the same :kind: of = object. Ultimately, the question we need to ask is this: if we don=E2=80=99t use = polymorphism within the protocol to express the constructs that we=E2=80=99= re using it for, what are we going to use instead? In my experience, = it=E2=80=99s much more brittle to have a system built out of nameless = objects with collections of mutually-exclusive fields and constraints = about contents. Sure you can support those by parsing to a single class = object, but then you need wrappers around the class objects to ensure = they aren=E2=80=99t accidentally put into an internally inconsistent = state. Plus, to be secure you=E2=80=99ll need to ensure all inputs and = outputs aren=E2=80=99t in an inconsistent state. My proposed approach is = that we build such interlocks into the protocol directly by careful use = of type-based information in the stream. To me, this looks more like the = BAD kind of polymorphism that you=E2=80=99ve talked about, where I need = to look inside the data stream to figure out what flavor of object I=E2=80= =99m dealing with without having an explicit type-based definition.=20 Again, thank you for joining the conversation. There=E2=80=99s = definitely a lot of material to dig into =E2=80=94 this is a big effort = and it=E2=80=99s going to take some time before it=E2=80=99s finished! = Your continued feedback is not only welcomed, it is encouraged, and = I=E2=80=99d recommend you even join the mailing list if you want to keep = engaging with the group. =E2=80=94 Justin > On Oct 28, 2020, at 12:28 PM, Mika Bostr=C3=B6m = wrote: >=20 > Hi everyone, >=20 > Looks like I stuck my finger in a hornets' nest. First off, apologies = for not chipping in earlier, but there was a lot of material to digest. = Also, warning: lots to read ahead. >=20 > I'm one of those people who end up making use of AuthN/AuthZ = functionality through a library. On top of that I can see myself being = roped in as a server (AS) implementation help. So I'm approaching this = from an outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that. >=20 > Now, having read Justin's initial reply - and the rest of the thread - = I believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts. >=20 > But then the downside. I don't personally expect to be able to use the = reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was >=20 > { > "name": "", > "age": , > "country": "", > "city": "" > } >=20 > .. then the type definition would look like: >=20 > type Person struct { > Name string `json:"name" > Age int `json:"age"` > Country string `json:"country"` > City string `json:"city"` > } >=20 > When the (possibly complex) type of a given field is fixed, = unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed = value, there should be nothing special about that. But when the field = can instead be a union of more than one distinct types, things start to = get messy. There is no union type in the language at all, so the = following construct is not even possible: >=20 > type Entity struct { > Resources []string `json:"resources"` > Client union(Client, string) `json:"client"` > } >=20 > As I understand, the implicit expectation is that in the above case, = the unmarshaler detects that "client" is a string, and so expands it = from an opaque handle to the expected, populated type. Even after = thinking about the ramifications over the past few days I remain = confused, because I don't see how the commonly used annotations could = work. If the expectation is that protocol implementations should use = strong types, then the use of polymorphic JSON is very likely to make = things _more_ complicated for non-reference implementations.=20 >=20 > Hence my concern. I'm afraid that the leaky abstraction, while making = the reference implementation more robust and straightforward, = contributes to making other implementations less robust. And this being = a security protocol, the potential for brittle and/or confused = implementations is terrifying.=20 >=20 > I am a fan of reducing complexity, and from what I can see, for the = reference implementation the polymorphic approach actually does that. = But I'm afraid it does so at others' expense. Languages have their = individual constraints, idioms and best practices. If parsing a protocol = payload introduces low-level complexities and encourages to go against = common practices, that is an invitation for problems. I am aware that my = choice of words in the HN thread was likely to put people on defense, = and for that I apologise. But I do believe that the choice of = polymorphic JSON is going to make the life and use of other = implementations notably less boring than people in general would prefer. >=20 > Cheers, > Mika >=20 > On Mon, 26 Oct 2020 at 02:04, Fabien Imbault > wrote: > Hi Dick, >=20 > Well technically yes. Obviously the client can present any interface = it seems fit.=20 >=20 > Still there's the question of the common model we want to present to = the outside world and supported by the protocol itself (which client = libraries all build upon).=20 >=20 > But beneath the polyphormism question, the HN debate seems on the = surface a lot like the original xyz (polyphormism goes along with the = reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and = where the client design has more latitude). Just explained differently, = by outside people with different agendas.=20 >=20 > Which is a bit weird because many of the critics on HN (who criticize = polyphormism) also seem to really dislike OAuth in the first place (the = inconsistencies are partially due to a bunch of different people = commenting).=20 >=20 > Really to me there's no fundamental truth behind that question. It's a = matter of preference and priorities in the design. Whatever choices we = make, we'll have to be prepared to explain and justify them in the open, = even to some people that will dislike pretty much whatever we do = (because it's fun to look smart and critize without proposing = alternatives). And we owe these answers to people like Mika, who = genuinely try to make the best of it.=20 >=20 > Fabien=20 >=20 > Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt > a =C3=A9crit : > Hi Fabien >=20 > A library developer can provide whatever abstraction layer makes sense = for the library's target audience and language. >=20 > If the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice versa=20= >=20 > =3D> polymorphism in the protocol has no impact on client library = developers >=20 >=20 > =E1=90=A7 >=20 > On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = > wrote: > I'm just realizing your "least to most important" might actually say = the same as what I was trying to say. So I'm not even sure what we're = arguing against :-)=20 >=20 > In brief my point if it wasn't clear is that we should be crystal = clear on where we put the cursor of simplicity, because this can mean = different things for different people and different roles.=20 > And as we see on HN we need to better explain our design choices.=20 >=20 >=20 > Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault = > a =C3=A9crit = : > Hi Dick, >=20 > Independantly from the debate on polyphormism, I beg to differ on your = order preference.=20 >=20 > Your assumption is that AS devs matter the most, because they're doing = the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users = of the spec are unable to deal with the complexity that is passed onto = them.=20 >=20 > 99% of the people that will actually use the output of the work are = application developers (client or RS) and their own users.=20 >=20 > Our intent as well as the protocol drive the usage. Client libraries = may help, but they're not a silver bullet, especially because GNAP = ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >=20 > I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >=20 > Fabien=20 >=20 >=20 >=20 > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt > a =C3=A9crit : > I'm confused by your logic Fabien. >=20 > If a client library developer wants to expose polymorphism, they can = do that independent of what is in the protocol.=20 >=20 > I differ on who our stakeholders are.=20 >=20 > I think our stakeholders are in least to most important: >=20 > AS developer > RS developer > client developer > user >=20 > A client library developer can expose whatever interface they want to = simplify implementation. >=20 > I list the user so that we don't lose site of a critical role. >=20 > /Dick >=20 >=20 > =E1=90=A7 >=20 > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: > Hi there,=20 >=20 > Let me try to approach the issue under a different light. More like a = product manager would deal with feature selection to make it intuitive = for its users.=20 >=20 > For most people, riding a bike is far easier than using a unicycle. = Feels more stable. And yet it's way easier to design for a single wheel = than to build with 2. Because then you'll need a lot more accessories = (chain, chain ring, etc.). Even so producing a bike doesn't have to be a = brittle process, it can be industrialized.=20 >=20 > Back to the GNAP topic.=20 > Ultimately we should strive to make the spec as simple as can be. But = we need to ask: simple for whom? For the bike owner or for the bike = vendor?=20 > (short answer: the priority should be simplicity for spec users, not = spec implementers and even less spec designers).=20 >=20 > The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to = handle the state of the request? Or if we must handle token revocation? = Or if we are looking for a global unique identifier? The argument stems = of the fact that is still arguably harder and more error prone to = implement. Fair enough.=20 >=20 > =46rom a spec implementer's perspective, it may well be more complex. = It mostly impacts the json library you'll end up using, plus a bit of = input/output decoration around it. Even golang provides utilities for = this, despite not exactly being made for this kind of purpose. > My practical experience implementing it is that it's not that big a = deal. I mean, I wished it could be simpler, but it's manageable and = there are other ways to reach levels of insurance that it does work as = intended (json schema, test cases to validate the implementation, etc.). = Arguably it is still easier from an implementation perspective than say, = json-ld, which is massively used in the SSI community.=20 >=20 > But ultimately who are we designing for? Are we striving to go easy on = the spec implementer? Or are we trying to make sure end-developers using = the client libraries won't shoot themselves in the foot? >=20 > The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation.=20 > In turn, this spec implementer will rely on cryptographic utility = libraries that deals internally with the complexity of their own domain, = so that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have its set = of very real issues but that's beyond the point.=20 > Note that any decent flamewar will be efficiently fueled by people = hating medium. Is it outrageous for blog posts to be behind a paywall? = Maybe but it's even more outrageous to lack consistency, either by not = knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 > What likely seems an unnecessary sidenote tries to illustrate the = point: for Justin it was easier to publish on medium, because as a blog = publisher, you might not want to deal with hosting your own blog. But = maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >=20 > Polyphormism is a tool that enables the end-developer to have minimal = knowledge of what it means to deal with a GNAP client library. You = prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >=20 > If we find a better way to deal with that simplicity balance, I'm all = in. But the arguments need to be way more convincing than just saying = that it may be difficult to implement or validate.=20 >=20 > Cheers. > Fabien >=20 >=20 >=20 >=20 >=20 > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer > a =C3=A9crit : >=20 >=20 >> On Oct 23, 2020, at 3:52 PM, Dick Hardt > wrote: >>=20 >> Justin >>=20 >> I did note that I was the one that argued for instance_id being in = the object. Since it is in the object in the current draft, not = including a pass by reference option would be preferable.=20 >>=20 >> As for concrete examples: >> - version of client >> - version of OS >> - security attestation of OS / device >> - location of client device >> - network client is operating on >>=20 >> These are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used. >>=20 >=20 > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman: >=20 > { >=20 > posture: { > software_version: 1.2.3, > os_version: 14.3.2 > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > }, >=20 > client: =E2=80=9Cclient-541-ab" >=20 > } >=20 > This is a more fundamental question about GNAP than whether the syntax = uses polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >=20 > =E2=80=94 Justin >=20 >=20 >> /Dick >>=20 >> =E1=90=A7 >>=20 >> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer > wrote: >> Dick, >>=20 >> As you=E2=80=99ll recall, I argued against including the client = instance identifier inside of the object as a mutually-exclusive field = precisely because of the principle violation that you are pointing out = here, and so it=E2=80=99s important to point out that the current text = is a compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored. >>=20 >> The crux of my argument is that is exactly a case of = pass-by-reference vs pass-by-value, and that runtime attestations are = not part of the =E2=80=9Cclient instance=E2=80=9D value itself but = rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look = carefully at how these concepts fit within the model and where we would = want to put them. Without concrete examples of what these extensions = look like and how they=E2=80=99re generated, that is nearly impossible = to do at this stage. I look forward to seeing examples of this kind of = data and how it can fit into the protocol. >>=20 >> =E2=80=94 Justin >>=20 >>> On Oct 23, 2020, at 3:07 PM, Dick Hardt > wrote: >>>=20 >>> Hey Justin, >>>=20 >>> As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >>>=20 >>> In the current draft, the=20 >>>=20 >>> Every time you create or process a field it will mean only one = thing, and there=E2=80=99s only one field to look at to answer a = question.=20 >>>=20 >>> is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >>>=20 >>>=20 >>> instance_id An identifier string that the AS can use to identify = the >>> particular instance of this RC. The content and structure of = this >>> identifier is opaque to the RC. >>>=20 >>> "client": { >>> "instance_id": "client-541-ab" >>> } >>>=20 >>> If there are no additional fields to send, the RC MAY send the >>> instance identifier as a direct reference value in lieu of the >>> object. >>>=20 >>> "client": "client-541-ab" >>>=20 >>> The instance identifier can be sent two ways. Polymorphism is a = convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >>>=20 >>> In your example of the "key" object below, setting "proof" to bearer = would avoid the issue you describe: >>>=20 >>> {=20 >>> "key": {=20 >>> "proof": "bearer"=20 >>> }=20 >>> } >>>=20 >>> In your example, when processing the "key" object, code is having to = check both the JSON type of the property, as well as check the value of = the "proof" property. In the example I provided, only the value of = "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >>>=20 >>> Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done = as above. >>>=20 >>> On a related note, there was significant negative feedback on = handles and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >>>=20 >>> /Dick >>>=20 >>>=20 >>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer > wrote: >>> Hi Mika, >>>=20 >>> Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. >>>=20 >>> Some background: I built out the XYZ protocol (one of the = predecessors to the initial GNAP Draft) in Java using strongly typed = parsers and Java objects specifically to prove to myself that it could = be done in a way that made any sense in the code. (My own open source = implementation is at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >>>=20 >>> The driving reason for using polymorphism at the protocol level was = to simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >>>=20 >>> {=20 >>> key: { >>> proof: httpsig, >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> }, >>> bearer_token: true, >>> bind_to_rc_key: true >>> } >>>=20 >>> This would be an illegal object as per this alternate proposal, but = then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. >>>=20 >>> {=20 >>> key: { >>> proof: httpsig, >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> } >>> } >>>=20 >>> // bearer token >>>=20 >>> { >>> key: false >>> } >>>=20 >>> // bound to the RC=E2=80=99s presented key >>>=20 >>> { >>> key: true >>> } >>>=20 >>> If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. >>>=20 >>> While it might sound like polymorphism means that any field could = have any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. >>>=20 >>> In your example below, each field within the dictionary would also = need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 >>>=20 >>> So let=E2=80=99s dig into the specific bug you bring up in the = strawman, because it=E2=80=99s interesting: A JSON encoder that encodes = numbers as strings, and not numbers, is not compliant with the JSON = definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in = this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where = a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item).=20 >>>=20 >>> The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>>>=20 >>>> Hello, everyone. >>>>=20 >>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion = forum and when I made note about certain concerns, I was requested to = send my comments to this working group. >>>>=20 >>>> In short, I believe that the use of polymorphic JSON in the = protocol invites subtle and confusing implementation problems. I also = searched through the WG archives, and noticed that similar concerns were = noted, briefly, in a thread in July.=20 >>>>=20 >>>> The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >>>>=20 >>>> Let's say we have these imaginary payloads, both possible and valid = in the same protocol step: >>>>=20 >>>> # payload 1 >>>> { >>>> ..., >>>> "public_key": { >>>> "alg": "rsa", >>>> "modulus": >>>> } >>>> } >>>>=20 >>>> # payload 2 >>>> { >>>> ..., >>>> "public_key": { >>>> "alg": "rsa", >>>> "modulus": "" >>>> } >>>> } >>>>=20 >>>> In both cases, the type of "public_key" field is a dictionary. In = both cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >>>>=20 >>>> While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >>>>=20 >>>> Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum? >>>>=20 >>>> Best regards, >>>> Mika >>>>=20 >>>> --=20 >>>> Mika Bostr=C3=B6m >>>> Smarkets >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> =E1=90=A7 >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Mika Bostr=C3=B6m > Smarkets --Apple-Mail=_1DD9F0AC-D89F-41C3-8040-555CBE5DAB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mika,

    First, thank you for joining the conversation, and thank you = for the great feedback! The spec is really just getting started, and = this kind of discussion and input is important. As you can see, the = working group hasn=E2=80=99t fully settled on a set of answers yet, and = so more perspectives are needed and desired. There are always tradeoffs = with every protocol decision, and it=E2=80=99s important that we = understand these decisions as we make them.

    I think we would both agree that the = goal this kind of a standard is definitely not to expect people to use a = particular reference implementation, and anything that relies on a = specific library, language, or implementation isn=E2=80=99t truly = interoperable in any meaningful way. 

    I=E2=80=99m not familiar enough with Go = to comment on details of the implementation below, but in the Java = implementation that I did, each field with different type-based = representations is tagged with a serializer/deserializer hook. This is = very common for Java-based JSON systems, and not just for polymorphic = content. For example, if I have a JWT, I want it stored as a structured = object that contains easy access to all the parsed data, but I need it = serialized as a single string within JSON. Therefore I tag the = individual field that=E2=80=99s of Java type JWT with serializer and = deserializer classes, both of which do a simple transformation to and = from the canonical string form that the JWT class provides for me. = Fields with multiple possible types are handled similarly to this: as = you note below, there is a domain object class for the field itself, and = the deserializer checks the type of the JSON node during parsing to = determine how to populate that class object. Going in the other = direction, the serializer looks at the state of the object and its = contents to figure out if it needs to be a complex type (like a JSON = object) or a simple type (like a JSON string) and outputs the = appropriate JSON node to the serializer=E2=80=99s = stream. 

    I=E2=80=99ve worked with a number of other languages and = platforms, and there are similar capabilities to what I had used for = Java, described here. I believe in Go you=E2=80=99d have something = similar to do a custom marshall/unmarshall of the field/type in = question. You don=E2=80=99t really want it to be a =E2=80=9Cunion = type=E2=80=9D within the data model, so much as you need to be able how = to get into and out of JSON. And in my experience, for dynamically typed = languages like Python and JavaScript, it=E2=80=99s often easier (or at = least more common) to just parse the JSON directly and pull out the = values directly as needed, as opposed to mapping them to a concrete = class object. You can actually do something similar with Java if you = want to just map to generic types. These implementations will need to do = some additional sanity checks during the reading of individual fields, = but these end up being the same kinds of checks and mappings that happen = during the parsing phase of a statically typed language. In other words, = you check for =E2=80=9Cstring or object=E2=80=9D at the point of reading = the =E2=80=9Cclient=E2=80=9D field and branch your code there, as = opposed to having the parser do it for you. This might seem like a lot = of overhead for just trying to read a value, but bear in mind that the = alternative is to do something like read an object, then check across = the fields of that object, and branch your code based on that =E2=80=94 = including new error branches for inconsistent states.

    This is why it=E2=80=99s = important to me that polymorphism is applied in a very specific way in = the protocol. If there=E2=80=99s a field named =E2=80=9Cclient=E2=80=9D = then I should be able to look at whatever value is in that field and get = back a =E2=80=9Cclient=E2=80=9D of some kind that I can put into a dat = structure, whether I=E2=80=99m parsing the object directly or looking up = a reference. If I can get something that=E2=80=99s not a =E2=80=9Cclient=E2= =80=9D from that field, or if I have to deal with several radically = different kinds of objects from there, then I think we=E2=80=99ve missed = the mark. The one place currently in the protocol where we have objects = with some known structure but potentially arbitrary contents are within = the =E2=80=9Cresources=E2=80=9D array, and for that there is a required = =E2=80=9Ctype=E2=80=9D field to keep different sides from guessing what = to do with it. Even so, it=E2=80=99s always a requested resource = description, so it semantically always maps to the same :kind: of = object.

    Ultimately, the question we need to ask is this: if we = don=E2=80=99t use polymorphism within the protocol to express the = constructs that we=E2=80=99re using it for, what are we going to use = instead? In my experience, it=E2=80=99s much more brittle to have a = system built out of nameless objects with collections of = mutually-exclusive fields and constraints about contents. Sure you can = support those by parsing to a single class object, but then you need = wrappers around the class objects to ensure they aren=E2=80=99t = accidentally put into an internally inconsistent state. Plus, to be = secure you=E2=80=99ll need to ensure all inputs and outputs aren=E2=80=99t= in an inconsistent state. My proposed approach is that we build such = interlocks into the protocol directly by careful use of type-based = information in the stream. To me, this looks more like the BAD kind of = polymorphism that you=E2=80=99ve talked about, where I need to look = inside the data stream to figure out what flavor of object I=E2=80=99m = dealing with without having an explicit type-based = definition. 

    Again, thank you for joining the conversation. There=E2=80=99s = definitely a lot of material to dig into =E2=80=94 this is a big effort = and it=E2=80=99s going to take some time before it=E2=80=99s finished! = Your continued feedback is not only welcomed, it is encouraged, and = I=E2=80=99d recommend you even join the mailing list if you want to keep = engaging with the group.

     =E2=80=94 Justin

    On Oct = 28, 2020, at 12:28 PM, Mika Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote:

    Hi = everyone,

    Looks = like I stuck my finger in a hornets' nest. First off, apologies for not = chipping in earlier, but there was a lot of material to digest. Also, = warning: lots to read ahead.

    I'm one of those people who end up = making use of AuthN/AuthZ functionality through a library. On top of = that I can see myself being roped in as a server (AS) implementation = help. So I'm approaching this from an outsider's perspective. Someone = who expects to be exposed to the eventual RFC and all the nitty-gritty = details. My relatively terse comment ended up at the top of the = aforementioned HN thread, which didn't necessarily help. Sorry about = that.

    Now, = having read Justin's initial reply - and the rest of the thread - I = believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts.

    But then the downside. I don't = personally expect to be able to use the reference implementation, being = mostly a Python user myself. A fair number of AS implementations will be = written with languages such as Go, Python, C#, Ruby, and JavaScript = (thanks to node.js), and all of them will have to deal with the = polymorphism. =46rom what I've read over the past couple of days, I = understand that at least Go supports custom unmarshalers from JSON to = typed structs, at the cost of an indirection. Normally when a Go code = processes JSON to a typed struct, the process is helped by field = annotations in the type definition itself. For example, if the payload = for a person in JSON was

    {
      "name": = "<string>",
      "age": <int>,
      "country": = "<string>",
      "city": = "<string>"
    }

    .. then the type definition would look = like:

    type = Person struct {
      Name string = `json:"name"
      Age int `json:"age"`
      Country string `json:"country"`
      City string `json:"city"`
    }

    When the (possibly complex) type of a given field is fixed, = unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed = value, there should be nothing special about that. But when the field = can instead be a union of more than one distinct types, things start to = get messy. There is no union type in the language at all, so the = following construct is not even possible:

    type Entity struct {
      Resources []string `json:"resources"`
      Client union(Client, string) = `json:"client"`
    }

    As I understand, the = implicit expectation is that in the above case, the unmarshaler detects = that "client" is a string, and so expands it from an opaque handle to = the expected, populated type. Even after thinking about the = ramifications over the past few days I remain confused, because I don't = see how the commonly used annotations could work. If the expectation is = that protocol implementations should use strong types, then the use of = polymorphic JSON is very likely to make things _more_ complicated for = non-reference implementations.

    Hence my concern. I'm afraid that the leaky = abstraction, while making the reference implementation more robust and = straightforward, contributes to making other implementations less = robust. And this being a security protocol, the potential for brittle = and/or confused implementations is terrifying.

    I am a fan of reducing = complexity, and from what I can see, for the reference implementation = the polymorphic approach actually does that. But I'm afraid it does so = at others' expense. Languages have their individual constraints, idioms = and best practices. If parsing a protocol payload introduces low-level = complexities and encourages to go against common practices, that is an = invitation for problems. I am aware that my choice of words in the HN = thread was likely to put people on defense, and for that I apologise. = But I do believe that the choice of polymorphic JSON is going to make = the life and use of other implementations notably less boring than = people in general would prefer.

    Cheers,
    Mika

    On Mon, 26 Oct 2020 at 02:04, Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Dick,

    Well technically yes. Obviously the client can present any = interface it seems fit. 

    Still there's the question = of the common model we want to present to the outside world and = supported by the protocol itself (which client libraries all build = upon). 

    But beneath the polyphormism question, the HN = debate seems on the surface a lot like the original xyz (polyphormism = goes along with the reduced endpoint model) vs xauth (a bit closer to = OAuth2 in spirit, and where the client design has more latitude). Just = explained differently, by outside people with different = agendas. 

    Which is a bit weird because many of the = critics on HN (who criticize polyphormism) also seem to really dislike = OAuth in the first place (the inconsistencies are partially due to a = bunch of different people commenting). 

    Really to = me there's no fundamental truth behind that question. It's a matter of = preference and priorities in the design. Whatever choices we make, we'll = have to be prepared to explain and justify them in the open, even to = some people that will dislike pretty much whatever we do (because it's = fun to look smart and critize without proposing alternatives). And we = owe these answers to people like Mika, who genuinely try to make the = best of it. 

    Fabien 

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt = <dick.hardt@gmail.com> a =C3=A9crit :
    Hi = Fabien

    A library = developer can provide whatever abstraction layer makes sense for the = library's target audience and language.

    If the client library developer = wants to use polymorphism in the interface presented to the user's = of the library, the library developer can do that independent of = polymorphism in the protocol, and vice versa 

    =3D> polymorphism in = the protocol has no impact on client library developers


    3D""=E1=90=A7

    On Sat, Oct = 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I'm just = realizing your "least to most important" might actually say the same as = what I was trying to say. So I'm not even sure what we're arguing = against :-) 

    In brief my point if it wasn't clear is that we = should be crystal clear on where we put the cursor of simplicity, = because this can mean different things for different people and = different roles. 
    And as we see = on HN we need to better explain our design choices. 


    Le dim. 25 = oct. 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@gmail.com> a = =C3=A9crit :
    Hi = Dick,

    Independantly from the debate on polyphormism, I beg to = differ on your order preference. 

    Your = assumption is that AS devs matter the most, because they're doing = the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users = of the spec are unable to deal with the complexity that is passed onto = them. 

    99% of the people that = will actually use the output of the work are application developers = (client or RS) and their own users. 

    Our intent as well as the = protocol drive the usage. Client libraries may help, but they're not a = silver bullet, especially because GNAP ultimately has no control about = what people do there (for better or worse). And everything we do here = will help get to the better part. 

    I'm not = saying we don't intend to also care about AS developers (beginning with = ourselves) but it's a second order optimisation. And since it's a = tendancy we're leaning towards by default, I'm pretty sure we won't = forget that anyway. 

    Fabien 


    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt = <dick.hardt@gmail.com> a = =C3=A9crit :
    I'm = confused by your logic Fabien.

    If a client library developer wants to expose polymorphism, = they can do that independent of what is in the protocol. 

    I differ on who our = stakeholders are. 

    I think our stakeholders are in least to most = important:

    • AS developer
    • RS = developer
    • client developer
    • user

    A client library developer can expose whatever interface they = want to simplify implementation.

    I list the user so that we don't lose = site of a critical role.

    /Dick


    3D""=E1=90=A7

    On Fri, Oct = 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    Hi there, 

    Let me try to approach the issue under a = different light. More like a product manager would deal with feature = selection to make it intuitive for its users. 

    For most people, riding a bike is far easier = than using a unicycle. Feels more stable. And yet it's way easier to = design for a single wheel than to build with 2. Because then you'll need = a lot more accessories (chain, chain ring, etc.). Even so producing a = bike doesn't have to be a brittle process, it can be = industrialized. 

    Back to the GNAP = topic. 
    Ultimately we should strive = to make the spec as simple as can be. But we need to ask: simple for = whom? For the bike owner or for the bike vendor? 
    (short answer: the priority = should be simplicity for spec users, not spec implementers and even less = spec designers). 

    The initial = question that is asked is very interesting: isn't the design flawed if = GNAP is using json polyphormism? Or if the AS needs to handle the state = of the request? Or if we must handle token revocation? Or if we are = looking for a global unique identifier? The argument stems of the fact = that is still arguably harder and more error prone to implement. Fair = enough. 

    =46rom a spec implementer's perspective, it may = well be more complex. It mostly impacts the json library you'll end up = using, plus a bit of input/output decoration around it. Even golang = provides utilities for this, despite not exactly being made for this = kind of purpose.
    My practical = experience implementing it is that it's not that big a deal. I mean, I = wished it could be simpler, but it's manageable and there are other ways = to reach levels of insurance that it does work as intended (json schema, = test cases to validate the implementation, etc.). Arguably it is still = easier from an implementation perspective than say, json-ld, which is = massively used in the SSI community. 

    But = ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the = client libraries won't shoot themselves in the foot?

    The job to be done (JTBD), from the end-developer's = perspective, is to efficiently ship an application. And provide = authN/authZ capabilities for end-users by relying on some well known = implementation. 
    In turn, this = spec implementer will rely on cryptographic utility libraries that deals = internally with the complexity of their own domain, so that we don't = have to. And here we could launch another HN flame war that starts with = the title "JWT sucks because". Which does have its set of very real = issues but that's beyond the point. 
    Note that any decent flamewar will be efficiently fueled by = people hating medium. Is it outrageous for blog posts to be behind a = paywall? Maybe but it's even more outrageous to lack consistency, either = by not knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated. 
    What likely seems an = unnecessary sidenote tries to illustrate the point: for Justin it was = easier to publish on medium, because as a blog publisher, you might not = want to deal with hosting your own blog. But maybe as a reader you'll = find that annoying. Different audiences, different JTBD, different = tradeoffs. 

    Polyphormism is a tool = that enables the end-developer to have minimal knowledge of what it = means to deal with a GNAP client library. You prepare the request, send = to the endpoint and you're good to go. Massively simpler than OAuth2 or = any similar protocol by the way (as anyone with teaching experience on = the subject might acknowledge). And  there's a lot more to be done = to make sure we indeed reduce the complexity for the end-developer and = the end-user. 

    If we find a better way to = deal with that simplicity balance, I'm all in. But the arguments need to = be way more convincing than just saying that it may be difficult to = implement or validate. 

    Cheers.
    Fabien





    Le ven. 23 = oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit :


    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

    Justin

    I = did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable. 

    As for concrete = examples:
    - version of client
    - = version of OS
    - security attestation of OS / = device
    - location of client device
    - network client is operating on

    These are all attributes of the client = that an AS may require on the initial grant request, and in future = grant requests (which is when an instance_id) would be used.


    This is where our = interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes = of the client=E2=80=9D in the same way that the key, display = information, class identifiers, and other items currently represented by = an instance_id are attributes of the client instance. The attestation = components don=E2=80=99t modify the instance so much as present = additional information on top of the client instance itself. This is why = I argue that they ought to be handled in a separate object, so you=E2=80=99= d have something like this strawman:

    {

      posture: {
        software_version: 1.2.3,
        os_version: 14.3.2
      =   device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 }
        location: { lat: =E2=80=A6,= lon: =E2=80=A6, alt: =E2=80=A6 }
      = },

      = client: =E2=80=9Cclient-541-ab"

    }

    This is a more fundamental question = about GNAP than whether the syntax uses polymorphism: this is about GNAP = being very explicit about the data model of its elements. OAuth 2=E2=80=99= s incredibly loose and broad model of what the term =E2=80=9Cclient=E2=80=9D= is referring to, exactly, is deeply problematic in practice. We=E2=80=99r= e even seeing that in the OAuth 2.1 work with having to define a = =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t = fully capture the different aspects that are out there. I think we=E2=80=99= re getting closer here in GNAP with explicit definition of =E2=80=9Cclient= instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.

     =E2=80=94 = Justin


    /Dick

    3D""=E1=90=A7

    On Fri, Oct = 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
    Dick,

    As you=E2=80=99ll = recall, I argued against including the client instance identifier inside = of the object as a mutually-exclusive field precisely because of the = principle violation that you are pointing out here, and so it=E2=80=99s = important to point out that the current text is a compromise that needs = to be examined in the wider experience of the working group. I am on the = side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D = option within an object, but this needs to be explored.

    The crux of my argument = is that is exactly a case of pass-by-reference vs pass-by-value, and = that runtime attestations are not part of the =E2=80=9Cclient = instance=E2=80=9D value itself but rather belong outside of that object = in a another part of the request. As stated in the editorial notes in = this section, we need to look carefully at how these concepts fit within = the model and where we would want to put them. Without concrete examples = of what these extensions look like and how they=E2=80=99re generated, = that is nearly impossible to do at this stage. I look forward to seeing = examples of this kind of data and how it can fit into the = protocol.

     =E2=80=94 Justin
    On Oct = 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

    Hey Justin,

    As the draft has = evolved, I question the continued use of polymorphism. Note that I = appreciate the elegance of using a string for pass-by-reference, = and an object for pass-by-value.

    In the current draft, = the 

    Every time you create or process a field it = will mean only one thing, and there=E2=80=99s only one field to look at = to answer a question. 

    is violated in 2.3.1.  Identifying the RC Instance


      =  instance_id  An identifier string that the AS can use to = identify the
          particular = instance of this RC.  The content and structure of this
          identifier is opaque to the = RC.

      =  "client": {
          =  "instance_id": "client-541-ab"
      =  }

      =  If there are no additional fields to send, the RC MAY send = the
       instance identifier as a direct = reference value in lieu of the
      =  object.

       "client": "client-541-ab"

    The instance identifier = can be sent two ways. Polymorphism is a convenience for the client, but = requires the server to have two code paths for = "instance_id".  We discussed this in the design team, and I argued = for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.

    In = your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe:

    { 
     "key": = { 
         "proof": "bearer"
        }
    }

    In your example, when = processing the "key" object, code is having to check both the JSON type = of the property, as well as check the value of the "proof" property. In = the example I provided, only the value of "proof" needs to be checked. = The "proof" property is acting as a type for the "key" object.

    Not being a Java = programmer, I don't know how this would work in a Java implementation, = but node.js, the processing would need to be done as above.

    On a related note, there = was significant negative feedback on handles and polymorphism in the = Hacker News article https://news.ycombinator.com/item?id=3D24855750 
    =

    /Dick


    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = <jricher@mit.edu> wrote:
    Hi Mika,

    Thanks for bringing this = topic here =E2=80=94 I was able to see the forum discussion that brought = you here, and hopefully I can help clear up what I mean with how = polymorphism is used in the proposal. The short version is that the goal = is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems.

    Some background: I built out the XYZ = protocol (one of the predecessors to the initial GNAP Draft) in Java = using strongly typed parsers and Java objects specifically to prove to = myself that it could be done in a way that made any sense in the code. = (My own open source implementation is at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

    The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an = object:

    { 
        key: {
          proof: httpsig,
          jwk: { =E2=80=A6 key value =E2=80=A6 = }
        },
      =   bearer_token: true,
        = bind_to_rc_key: true
    }

    This would be an illegal object as per = this alternate proposal, but then you=E2=80=99d have to check each field = and make sure it wasn=E2=80=99t put next to others in the same object. = I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99s= both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the = polymorphic approach to this same field, each of these three = mutually-exclusive states is written in a way that they cannot be sent = together. It=E2=80=99s not just illegal, it=E2=80=99s impossible and = enforced by the syntax of JSON itself.

    { 
        key: {
        =   proof: httpsig,
          jwk: { = =E2=80=A6 key value =E2=80=A6 }
        = }
    }

    // bearer token

    {
        key: false
    }

    // bound to the RC=E2=80=99s presented key

    {
        key: true
    }

    If someone sends a = different type for this field, like an array or number or a null, this = doesn=E2=80=99t have a defined interpretation in the protocol and would = be a protocol level error.

    While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value = is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value.

    In your = example below, each field within the dictionary would also need to be = typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

    So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take =  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run = into cases where a parser library was trying to be overly =E2=80=9Chelpful= =E2=80=9D in doing this kind of mapping, but ended up introducing errors = in more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item). 

    The design team created some simple = JSON Schemas for parts of the protocol during our discussion, but we = didn=E2=80=99t include them in the design document due to both lack of = time to keep it updated with the rapid changes to the protocol during = the design team discussion, and not knowing if there would be interest = in such material. I personally think it would be helpful to include as = an informative reference in the final document, but that=E2=80=99s = something for the working group to take up eventually.

     =E2=80=94 = Justin

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m= <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:

    Hello, everyone.

    For background: GNAP/TxAuth/XYZ/Oauth3 = came up on a discussion forum and when I made note about certain = concerns, I was requested to send my comments to this working group.

    In = short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July.

    The problem with polymorphic values, as = I see it, is that implementations will need to branch on the (inferred) = type of a given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into = vulnerabilities.

    Let's say we have these imaginary payloads, both possible and = valid in the same protocol step:

    # payload 1
    {
      ...,
      = "public_key": {
        "alg": "rsa",
        "modulus": = <BIGINT>
      }
    }

    # = payload 2
    {
      = ...,
      "public_key": {
        "alg": "rsa",
        "modulus": "<encoded = string>"
      }
    }

    In both cases, the type = of "public_key" field is a dictionary. In both cases, they even have the = same keys. However, the values in the dictionaries are entirely = different, and an implementation will have to branch to at least two = possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

    While the above is = clearly a manufactured scenario, it nonetheless demonstrates the = potential for logic bugs with polymorphic JSON. With richer types and = more complex dictionaries, there will surely be more room for = errors.

    Ambiguity in protocols is always a source of implementation = complexity and interoperability snags, but in an AuthN/AuthZ protocol it = is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede = Oauth1/2, wouldn't it be in everyone's interest to keep implementation = complexity and mistake potential to a minimum?

    Best regards,
    Mika

    --
    Mika Bostr=C3=B6m
    Smarkets
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =
    3D""=E1=90=A7


    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =


    --
    Mika Bostr=C3=B6m
    Smarkets

    = --Apple-Mail=_1DD9F0AC-D89F-41C3-8040-555CBE5DAB31-- From nobody Wed Oct 28 11:47:33 2020 Return-Path: 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 304C33A0B50 for ; Wed, 28 Oct 2020 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 DbwbzXk9b_5h for ; Wed, 28 Oct 2020 11:47:19 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 0F94C3A0B22 for ; Wed, 28 Oct 2020 11:47:19 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t9so164932wrq.11 for ; Wed, 28 Oct 2020 11:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=WKtDX2gkeN6PmEiTxG+ix1f4FB92HFISesjpJoB4S0I=; b=of5iNvbya5cf9uonZz41/C1kbBUblQ9y0uxaUPD9+oXFJXNids04acFkJ+3bjaSebv FYT0jKe2ls7H95NtqR+pFPOrIYhUUfPfCVx4GaVQEy7PrwhENSnKwITr3IYW4fJKLtrK 4/rBH9fPKwbcDAFHad8xSLLYuwZblqIdJ/HKFvBL6auOXY808sqSXNpT4D9AThjmORhe fSwuh9LoDwQ3DuyXVerOG9W84OPq8yFBoxRvu+N8JrIJr8DM4e5I+KmZjycBhgkMdjpm WDUxuxZ8RtcJKOyjl8ioDi/JABVW2/JDO8D1sGwFfHcQ59fMha3v5q6SkMd1smEkVGYW CSKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=WKtDX2gkeN6PmEiTxG+ix1f4FB92HFISesjpJoB4S0I=; b=TN7Pk1R0wZmZicwCRdUJ5ZYrdaMU2dHxODXcmAK8IZ5/Wr4BpR2MtApG7d0/5ymAJm LekKAtIWuYhMJBfX5g9MwsJOtCKMcGfIVS6e93AGFeYCATj6xniRF9Cw3wYSNAWDnXrp Rot31bloXkUaXj215FaX5hCHoGGScW8z+pqfbteeytcF89L7cHn0F/HMGWVw0sW2kBhO 9lcnaCZH276vw888WZ1c2PcCnqS6Y8GWHQPM1UMpW2WSjF7EnCgYjviPlSlQy0gt4HV9 Fl47C0trEwmITDxNbE0HpkqAIA7VjL6ESu5UgdPercz/vVUOXOZHp5PrZMDuk3zCbgvz YFIw== X-Gm-Message-State: AOAM532ji8XASSRQwQEwESsFhoNmDrIERmXCGFj6ytxpGqPUGe7YYRyn 61zcGR6yagFpaGEml+6AyXc= X-Google-Smtp-Source: ABdhPJzQjUHKXyhaKUUqT/5hg6/k/55/yldEu0cee72zkJ3UEXuP9TirAhRAPTBP7qqfcfp+8uoGxw== X-Received: by 2002:adf:d0cf:: with SMTP id z15mr815618wrh.213.1603910837280; Wed, 28 Oct 2020 11:47:17 -0700 (PDT) Received: from [172.26.223.43] (pub-corp-lon-8.intuit.com. [91.102.40.8]) by smtp.gmail.com with ESMTPSA id i126sm424586wmi.0.2020.10.28.11.47.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2020 11:47:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Wed, 28 Oct 2020 20:47:13 +0200 From: Yaron Sheffer To: Fabien Imbault , Mika =?UTF-8?B?Qm9zdHLDtm0=?= CC: GNAP Mailing List , Justin Richer , Dick Hardt Message-ID: Thread-Topic: [GNAP] Feedback on polymorphism References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3686762835_2038932513" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 18:47:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3686762835_2038932513 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than th= e problem. The code in the article you cite is very specific to the use case= and IMHO quite ugly. So my preferred Go implementation would be a combinati= on of untyped structures (Go interface{}) and run-time enforcement of JSON S= chema. =20 Also, going back to our earlier discussion on this topic, I just read Sec. = 7 of gnap-00 and realized that the RC also needs to deal with polymorphism (= the =E2=80=9Ckey=E2=80=9D value), not only the AS. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Wednesday, October 28, 2020 at 18:56 To: Mika Bostr=C3=B6m Cc: GNAP Mailing List , Justin Richer , D= ick Hardt Subject: Re: [GNAP] Feedback on polymorphism =20 Thanks for the great feedback. Your concern is very valid.=20 =20 My implementation is in rust, which makes life easier in that specific case= .=20 =20 So I'm not a golang specialist but I guess the transcription of json string= s/arrays into go structs would work around the lines described by https://me= dium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 When we have a more formalized json schema, I suggest we make a library of = json examples and some related code samples in mainstream languages, to chec= k it is feasible for everyone.=20 =20 Cheers, Fabien =20 =20 On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m w= rote: Hi everyone, =20 Looks like I stuck my finger in a hornets' nest. First off, apologies for n= ot chipping in earlier, but there was a lot of material to digest. Also, war= ning: lots to read ahead. =20 I'm one of those people who end up making use of AuthN/AuthZ functionality = through a library. On top of that I can see myself being roped in as a serve= r (AS) implementation help. So I'm approaching this from an outsider's persp= ective. Someone who expects to be exposed to the eventual RFC and all the ni= tty-gritty details. My relatively terse comment ended up at the top of the a= forementioned HN thread, which didn't necessarily help. Sorry about that. =20 Now, having read Justin's initial reply - and the rest of the thread - I be= lieve I can see where the desire for polymorphism comes from. To be clear: I= am all for strict types inside an implementation, as it will add helpful gu= ard-rails to the state management code paths. However, I see this as a case = of leaky abstraction. If we take the existing oauth.xyj-java code to be the = reference implementation, the choice makes logical sense: JSON is not expres= sive enough to serialise arbitrary objects, so in order to avoid writing com= plex payload parser(s) the internal implementation details now leak to the p= rotocol itself. From a purely technical perspective, it's a cool trick. From= a distance it even looks a bit like the result of protobuf decoding, but wi= thout the generated code parts. =20 But then the downside. I don't personally expect to be able to use the refe= rence implementation, being mostly a Python user myself. A fair number of AS= implementations will be written with languages such as Go, Python, C#, Ruby= , and JavaScript (thanks to node.js), and all of them will have to deal with= the polymorphism. From what I've read over the past couple of days, I under= stand that at least Go supports custom unmarshalers from JSON to typed struc= ts, at the cost of an indirection. Normally when a Go code processes JSON to= a typed struct, the process is helped by field annotations in the type defi= nition itself. For example, if the payload for a person in JSON was =20 { "name": "", "age": , "country": "", "city": "" } =20 .. then the type definition would look like: =20 type Person struct { Name string `json:"name" Age int `json:"age"` Country string `json:"country"` City string `json:"city"` } =20 When the (possibly complex) type of a given field is fixed, unmarshaling sh= ould still be straightforward. I haven't verified, but since the annotation = only gives which field to look at for a given typed value, there should be n= othing special about that. But when the field can instead be a union of more= than one distinct types, things start to get messy. There is no union type = in the language at all, so the following construct is not even possible: =20 type Entity struct { Resources []string `json:"resources"` Client union(Client, string) `json:"client"` } =20 As I understand, the implicit expectation is that in the above case, the un= marshaler detects that "client" is a string, and so expands it from an opaqu= e handle to the expected, populated type. Even after thinking about the rami= fications over the past few days I remain confused, because I don't see how = the commonly used annotations could work. If the expectation is that protoco= l implementations should use strong types, then the use of polymorphic JSON = is very likely to make things _more_ complicated for non-reference implement= ations.=20 =20 Hence my concern. I'm afraid that the leaky abstraction, while making the r= eference implementation more robust and straightforward, contributes to maki= ng other implementations less robust. And this being a security protocol, th= e potential for brittle and/or confused implementations is terrifying.=20 =20 I am a fan of reducing complexity, and from what I can see, for the referen= ce implementation the polymorphic approach actually does that. But I'm afrai= d it does so at others' expense. Languages have their individual constraints= , idioms and best practices. If parsing a protocol payload introduces low-le= vel complexities and encourages to go against common practices, that is an i= nvitation for problems. I am aware that my choice of words in the HN thread = was likely to put people on defense, and for that I apologise. But I do beli= eve that the choice of polymorphic JSON is going to make the life and use of= other implementations notably less boring than people in general would pref= er. =20 Cheers, Mika =20 On Mon, 26 Oct 2020 at 02:04, Fabien Imbault wro= te: Hi Dick, =20 Well technically yes. Obviously the client can present any interface it see= ms fit.=20 =20 Still there's the question of the common model we want to present to the ou= tside world and supported by the protocol itself (which client libraries all= build upon).=20 =20 But beneath the polyphormism question, the HN debate seems on the surface a= lot like the original xyz (polyphormism goes along with the reduced endpoin= t model) vs xauth (a bit closer to OAuth2 in spirit, and where the client de= sign has more latitude). Just explained differently, by outside people with = different agendas.=20 =20 Which is a bit weird because many of the critics on HN (who criticize polyp= hormism) also seem to really dislike OAuth in the first place (the inconsist= encies are partially due to a bunch of different people commenting).=20 =20 Really to me there's no fundamental truth behind that question. It's a matt= er of preference and priorities in the design. Whatever choices we make, we'= ll have to be prepared to explain and justify them in the open, even to some= people that will dislike pretty much whatever we do (because it's fun to lo= ok smart and critize without proposing alternatives). And we owe these answe= rs to people like Mika, who genuinely try to make the best of it.=20 =20 Fabien=20 =20 Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a =C3=A9crit : Hi Fabien =20 A library developer can provide whatever abstraction layer makes sense for = the library's target audience and language. =20 If the client library developer wants to use polymorphism in the interface = presented to the user's of the library, the library developer can do that in= dependent of polymorphism in the protocol, and vice versa=20 =20 =3D> polymorphism in the protocol has no impact on client library developers =20 =20 =E1=90=A7 =20 On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault w= rote: I'm just realizing your "least to most important" might actually say the sa= me as what I was trying to say. So I'm not even sure what we're arguing agai= nst :-)=20 =20 In brief my point if it wasn't clear is that we should be crystal clear on = where we put the cursor of simplicity, because this can mean different thing= s for different people and different roles.=20 And as we see on HN we need to better explain our design choices.=20 =20 =20 Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a = =C3=A9crit : Hi Dick, =20 Independantly from the debate on polyphormism, I beg to differ on your orde= r preference.=20 =20 Your assumption is that AS devs matter the most, because they're doing the = important security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spec= are unable to deal with the complexity that is passed onto them.=20 =20 99% of the people that will actually use the output of the work are applica= tion developers (client or RS) and their own users.=20 =20 Our intent as well as the protocol drive the usage. Client libraries may he= lp, but they're not a silver bullet, especially because GNAP ultimately has = no control about what people do there (for better or worse). And everything = we do here will help get to the better part.=20 =20 I'm not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't forget that a= nyway.=20 =20 Fabien=20 =20 =20 Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3=A9crit : I'm confused by your logic Fabien. =20 If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=20 =20 I differ on who our stakeholders are.=20 =20 I think our stakeholders are in least to most important: =20 AS developer RS developer client developer user =20 A client library developer can expose whatever interface they want to simpl= ify implementation. =20 I list the user so that we don't lose site of a critical role. =20 /Dick =20 =20 =E1=90=A7 =20 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault w= rote: Hi there,=20 =20 Let me try to approach the issue under a different light. More like a produ= ct manager would deal with feature selection to make it intuitive for its us= ers.=20 =20 For most people, riding a bike is far easier than using a unicycle. Feels m= ore stable. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chain rin= g, etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized.=20 =20 Back to the GNAP topic.=20 Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=20 (short answer: the priority should be simplicity for spec users, not spec i= mplementers and even less spec designers).=20 =20 The initial question that is asked is very interesting: isn't the design fl= awed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are look= ing for a global unique identifier? The argument stems of the fact that is s= till arguably harder and more error prone to implement. Fair enough.=20 =20 >From a spec implementer's perspective, it may well be more complex. It most= ly impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite not e= xactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I= mean, I wished it could be simpler, but it's manageable and there are other= ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still ea= sier from an implementation perspective than say, json-ld, which is massivel= y used in the SSI community.=20 =20 But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot? =20 The job to be done (JTBD), from the end-developer's perspective, is to effi= ciently ship an application. And provide authN/authZ capabilities for end-us= ers by relying on some well known implementation.=20 In turn, this spec implementer will rely on cryptographic utility libraries= that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts with= the title "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=20 Note that any decent flamewar will be efficiently fueled by people hating m= edium. Is it outrageous for blog posts to be behind a paywall? Maybe but it'= s even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the contrary = by to not paying a subscription if you believe that surveillance capitalism,= to reuse Zuboff's terms, should be eradicated.=20 What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, yo= u might not want to deal with hosting your own blog. But maybe as a reader y= ou'll find that annoying. Different audiences, different JTBD, different tra= deoffs.=20 =20 Polyphormism is a tool that enables the end-developer to have minimal knowl= edge of what it means to deal with a GNAP client library. You prepare the re= quest, send to the endpoint and you're good to go. Massively simpler than OA= uth2 or any similar protocol by the way (as anyone with teaching experience = on the subject might acknowledge). And there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-use= r.=20 =20 If we find a better way to deal with that simplicity balance, I'm all in. B= ut the arguments need to be way more convincing than just saying that it may= be difficult to implement or validate.=20 =20 Cheers. Fabien =20 =20 =20 =20 =20 Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9crit : =20 On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: =20 Justin =20 I did note that I was the one that argued for instance_id being in the obje= ct. Since it is in the object in the current draft, not including a pass by = reference option would be preferable.=20 =20 As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on =20 These are all attributes of the client that an AS may require on the initia= l grant request, and in future grant requests (which is when an instance_id)= would be used. =20 =20 This is where our interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattribu= tes of the client=E2=80=9D in the same way that the key, display information, clas= s identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t modify = the instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a sepa= rate object, so you=E2=80=99d have something like this strawman: =20 { =20 posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, =20 client: =E2=80=9Cclient-541-ab" =20 } =20 This is a more fundamental question about GNAP than whether the syntax uses= polymorphism: this is about GNAP being very explicit about the data model o= f its elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the ter= m =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. = We=E2=80=99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in GNAP w= ith explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be mo= re precise about what exactly a client instance includes, and what it does n= ot. =20 =E2=80=94 Justin =20 /Dick =20 =E1=90=A7 =20 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: Dick, =20 As you=E2=80=99ll recall, I argued against including the client instance identifi= er inside of the object as a mutually-exclusive field precisely because of t= he principle violation that you are pointing out here, and so it=E2=80=99s importa= nt to point out that the current text is a compromise that needs to be exami= ned in the wider experience of the working group. I am on the side of removi= ng the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored. =20 The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Cclient in= stance=E2=80=9D value itself but rather belong outside of that object in a another= part of the request. As stated in the editorial notes in this section, we n= eed to look carefully at how these concepts fit within the model and where w= e would want to put them. Without concrete examples of what these extensions= look like and how they=E2=80=99re generated, that is nearly impossible to do at t= his stage. I look forward to seeing examples of this kind of data and how it= can fit into the protocol. =20 =E2=80=94 Justin On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: =20 Hey Justin, =20 As the draft has evolved, I question the continued use of polymorphism. Not= e that I appreciate the elegance of using a string for pass-by-reference, an= d an object for pass-by-value. =20 In the current draft, the=20 =20 Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question.=20 =20 is violated in 2.3.1. Identifying the RC Instance =20 =20 instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. =20 "client": { "instance_id": "client-541-ab" } =20 If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. =20 "client": "client-541-ab" =20 The instance identifier can be sent two ways. Polymorphism is a convenience= for the client, but requires the server to have two code paths for "instanc= e_id". We discussed this in the design team, and I argued for having "insta= nce_id" in the "client" object so that any updates, such as new devices asse= rtions, could be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference. =20 In your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe: =20 {=20 "key": {=20 "proof": "bearer"=20 }=20 } =20 In your example, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "proof= " property. In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "key" object. =20 Not being a Java programmer, I don't know how this would work in a Java imp= lementation, but node.js, the processing would need to be done as above. =20 On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D= 24855750=20 =20 /Dick =20 =20 On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: Hi Mika, =20 Thanks for bringing this topic here =E2=80=94 I was able to see the forum discuss= ion that brought you here, and hopefully I can help clear up what I mean wit= h how polymorphism is used in the proposal. The short version is that the go= al is to avoid the kinds of ambiguity that make insecure protocols, and so i= n that goal we=E2=80=99re fully aligned. I think that using polymorphism in very s= pecific ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems. =20 Some background: I built out the XYZ protocol (one of the predecessors to t= he initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made an= y sense in the code. (My own open source implementation is at https://github= .com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the G= NAP spec). It was important to me that I be able to use the system-wide conf= igured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the hooks = into the right places (especially with the Jackson parser that I used), but = it is definitely possible to create a deterministic and strongly-typed parse= r and serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft document= (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name= -json-structures-and-polymor), but it=E2=80=99s still good to discuss this here as= the working group decides which approaches to take.=20 =20 The driving reason for using polymorphism at the protocol level was to simp= lify the protocol and make it :more: deterministic to create and process, no= t less. Every time you create or process a field it will mean only one thing= , and there=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fiel= ds, which is prone to failure and requires additional error checking. Take f= or example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way. = Without that, you=E2=80=99d need to have different fields for the options and incl= ude additional checks in your parser to make sure they weren=E2=80=99t sent simult= aneously, otherwise you could get hit with this potential security vulnerabi= lity in an object: =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } =20 This would be an illegal object as per this alternate proposal, but then yo= u=E2=80=99d have to check each field and make sure it wasn=E2=80=99t put next to others = in the same object. I=E2=80=99ve done this exercise with many other protocols and = it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples= would pass code that doesn=E2=80=99t check this. With the polymorphic approach to= this same field, each of these three mutually-exclusive states is written i= n a way that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s i= mpossible and enforced by the syntax of JSON itself. =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } =20 // bearer token =20 { key: false } =20 // bound to the RC=E2=80=99s presented key =20 { key: true } =20 If someone sends a different type for this field, like an array or number o= r a null, this doesn=E2=80=99t have a defined interpretation in the protocol and w= ould be a protocol level error. =20 While it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly typed= , it=E2=80=99s just that there are potentially different types that express meanin= g for the field. This applies to all members of all objects (dictionaries) a= s well as all members of an array (list). Every time you process a field val= ue or other element, you look at the type and then the value to determine wh= at to do with that typed value. =20 In your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its meaning= . To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be d= efined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what exactl= y the encoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number ther= e means exactly one interpretation and seeing a string means exactly one (di= fferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80= =9D, since that=E2=80=99s the field that determines the type. An implementation woul= d likely use an internal BigInteger type of object to represent the field va= lue after parsing, so the question is how to go from the JSON value (which i= s typed) into the BigInteger value.You don=E2=80=99t just apply the type rules on = the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object.=20 =20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take advantage of JSON=E2=80=99s polymorph= ic nature. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing er= rors in more strict components downstream. This is something that protocol d= esigners need to be aware of and guard against in the design of the protocol= to reduce possible ambiguities. Within GNAP today, we generally have things= that branch whether they=E2=80=99re an object (for a rich description of somethin= g) or some non-structured special value (for a reference or other item).=20 =20 The design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design document d= ue to both lack of time to keep it updated with the rapid changes to the pro= tocol during the design team discussion, and not knowing if there would be i= nterest in such material. I personally think it would be helpful to include = as an informative reference in the final document, but that=E2=80=99s something fo= r the working group to take up eventually. =20 =E2=80=94 Justin On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m wrote: =20 Hello, everyone. =20 For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments t= o this working group. =20 In short, I believe that the use of polymorphic JSON in the protocol invite= s subtle and confusing implementation problems. I also searched through the = WG archives, and noticed that similar concerns were noted, briefly, in a thr= ead in July.=20 =20 The problem with polymorphic values, as I see it, is that implementations w= ill need to branch on the (inferred) type of a given field. This isn't quite= as bad if the types are strictly different, but allows for subtle bugs when= the value in question is a dictionary. What makes this unappealing is that = "subtle bugs" in security protocols have a habit of turning into vulnerabili= ties. =20 Let's say we have these imaginary payloads, both possible and valid in the = same protocol step: =20 # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } =20 # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } =20 In both cases, the type of "public_key" field is a dictionary. In both case= s, they even have the same keys. However, the values in the dictionaries are= entirely different, and an implementation will have to branch to at least t= wo possible decoding mechanisms. To make things worse, some JSON implementat= ions may choose to encode non-dictionary values as strings, so it is possibl= e for an originator to transmit what they expect and believe to be payload 1= format, but which the receiver will interpret to be in payload 2 format. An= d if the encoded string contains only digits, it will even parse correctly a= s a bignum. =20 While the above is clearly a manufactured scenario, it nonetheless demonstr= ates the potential for logic bugs with polymorphic JSON. With richer types a= nd more complex dictionaries, there will surely be more room for errors. =20 Ambiguity in protocols is always a source of implementation complexity and = interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's ter= rifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in= everyone's interest to keep implementation complexity and mistake potential= to a minimum? =20 Best regards, Mika =20 --=20 Mika Bostr=C3=B6m Smarkets --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =E1=90=A7 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 Mika Bostr=C3=B6m Smarkets -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3686762835_2038932513 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Hi Fabien,

     

    At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far wors= e than the problem. The code in the article you cite is very specific to the= use case and IMHO quite ugly. So my preferred Go implementation would be a = combination of untyped structures (Go interface{}) and run-time enforcement = of JSON Schema.

     

    Also, going back to our earlier discussion on this topic, I jus= t read Sec. 7 of gnap-00 and realized that the RC also needs to deal with po= lymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS.

     

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault &l= t;fabien.imbault@gmail.com>
    Date: Wednesday, October 28, 2020 a= t 18:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    = Cc: GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher= @mit.edu>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re:= [GNAP] Feedback on polymorphism

     

    Thanks for the gr= eat feedback. Your concern is very valid. 

     

    My impleme= ntation is in rust, which makes life easier in that specific case. 

     

    So I'm not a golang specialist but I guess the transcr= iption of json strings/arrays into go structs would work around the lines de= scribed by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade= 1e58ed1

    When we have a more = formalized json schema, I suggest we make a library of json examples and som= e related code samples in mainstream languages, to check it is feasible for = everyone. 

     

    Cheers,

    Fabien

     

     

    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote:

    Hi everyone,

     

    Looks like I stuck my finger= in a hornets' nest. First off, apologies for not chipping in earlier, but t= here was a lot of material to digest. Also, warning: lots to read ahead.

     

    I'm one of those people who end up making use of AuthN/AuthZ= functionality through a library. On top of that I can see myself being rope= d in as a server (AS) implementation help. So I'm approaching this from an o= utsider's perspective. Someone who expects to be exposed to the eventual RFC= and all the nitty-gritty details. My relatively terse comment ended up at t= he top of the aforementioned HN thread, which didn't necessarily help. Sorry= about that.

     

    Now, having read Justin's initial reply - an= d the rest of the thread - I believe I can see where the desire for polymorp= hism comes from. To be clear: I am all for strict types inside an implementa= tion, as it will add helpful guard-rails to the state management code paths.= However, I see this as a case of leaky abstraction. If we take the existing= oauth.xyj-java code to be the reference implementation, the choice makes lo= gical sense: JSON is not expressive enough to serialise arbitrary objects, s= o in order to avoid writing complex payload parser(s) the internal implement= ation details now leak to the protocol itself. From a purely technical persp= ective, it's a cool trick. From a distance it even looks a bit like the resu= lt of protobuf decoding, but without the generated code parts.

     

    But then the downside. I don't personally expect to be able to use the= reference implementation, being mostly a Python user myself. A fair number = of AS implementations will be written with languages such as Go, Python, C#,= Ruby, and JavaScript (thanks to node.js), and all of them will have to deal= with the polymorphism. From what I've read over the past couple of days, I = understand that at least Go supports custom unmarshalers from JSON to typed = structs, at the cost of an indirection. Normally when a Go code processes JS= ON to a typed struct, the process is helped by field annotations in the type= definition itself. For example, if the payload for a person in JSON was

     

    {

      "n= ame": "<string>",

      "age": <int>,

      "country": "<string>",

      "city": "<strin= g>"

    }

     

    .. then the type definition would look like:

     

    type Person= struct {

      Name string `js= on:"name"

      Age i= nt `json:"age"`

     = Country string `json:"country"`

      City string `json:"city"`

    }

    &nb= sp;

    When the (possibly complex) type = of a given field is fixed, unmarshaling should still be straightforward. I h= aven't verified, but since the annotation only gives which field to look at = for a given typed value, there should be nothing special about that. But whe= n the field can instead be a union of more than one distinct types, things s= tart to get messy. There is no union type in the language at all, so the fol= lowing construct is not even possible:

     

    type Entity struct= {

      Resources []string `js= on:"resources"`

     = Client union(Client, string) `json:"client"`

    =

    }

    &= nbsp;

    As I understand, the implicit e= xpectation is that in the above case, the unmarshaler detects that "cli= ent" is a string, and so expands it from an opaque handle to the expect= ed, populated type. Even after thinking about the ramifications over the pas= t few days I remain confused, because I don't see how the commonly used anno= tations could work. If the expectation is that protocol implementations shou= ld use strong types, then the use of polymorphic JSON is very likely to make= things _more_ complicated for non-reference implementations.

     

    Hence my concern. I'm afraid that the leaky abstraction, while making the r= eference implementation more robust and straightforward, contributes to maki= ng other implementations less robust. And this being a security protocol, th= e potential for brittle and/or confused implementations is terrifying. =

     

    I am a fan of reducing complexity, and from what I can see, for the= reference implementation the polymorphic approach actually does that. But I= 'm afraid it does so at others' expense. Languages have their individual con= straints, idioms and best practices. If parsing a protocol payload introduce= s low-level complexities and encourages to go against common practices, that= is an invitation for problems. I am aware that my choice of words in the HN= thread was likely to put people on defense, and for that I apologise. But I= do believe that the choice of polymorphic JSON is going to make the life an= d use of other implementations notably less boring than people in general wo= uld prefer.

     

    Cheers,

    Mika

     

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault = <fabien.imbault= @gmail.com> wrote:

    Hi Dick,

     

    Well techni= cally yes. Obviously the client can present any interface it seems fit. = ;

     

    Still there's the question of the common model we want = to present to the outside world and supported by the protocol itself (which = client libraries all build upon). 

     

    But beneath the p= olyphormism question, the HN debate seems on the surface a lot like the orig= inal xyz (polyphormism goes along with the reduced endpoint model) vs xauth = (a bit closer to OAuth2 in spirit, and where the client design has more lati= tude). Just explained differently, by outside people with different agendas.=  

     

    Which is a bit weird because many of the critics o= n HN (who criticize polyphormism) also seem to really dislike OAuth in the f= irst place (the inconsistencies are partially due to a bunch of different pe= ople commenting). 

    &nb= sp;

    Really to me there's no fundament= al truth behind that question. It's a matter of preference and priorities in= the design. Whatever choices we make, we'll have to be prepared to explain = and justify them in the open, even to some people that will dislike pretty m= uch whatever we do (because it's fun to look smart and critize without propo= sing alternatives). And we owe these answers to people like Mika, who genuin= ely try to make the best of it. 

     

    Fabien 

     

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit&n= bsp;:

    <= div>

    Hi Fabien

    =  

    A library developer can provid= e whatever abstraction layer makes sense for the library's target audie= nce and language.

     

    If the client library developer wa= nts to use polymorphism in the interface presented to the user's of the= library, the library developer can do that independent of polymorphism in t= he protocol, and vice versa 

     

    =3D> polymorphism in t= he protocol has no impact on client library developers

    <= div>

     

     

    3D"I==E1=90=A7

     

    On Sat, Oct 24, 2020 a= t 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    I'm just= realizing your "least to most important" might actually say the s= ame as what I was trying to say. So I'm not even sure what we're arguing aga= inst :-) 

     

    In brief my point if it wasn't clear is that we = should be crystal clear on where we put the cursor of simplicity, because th= is can mean different things for different people and different roles. =

    And as we see on HN we need to = better explain our design choices. 

     

     

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imb= ault <fabien.im= bault@gmail.com> a =C3=A9crit :

    Hi Dick,=

     

    Independantly from the debate on polyphormism, I beg to differ on your or= der preference. 

     = ;

    Your assumption is that AS devs mat= ter the most, because they= 're doing the important security implementation. But eating our own dogfood = might help a lot to change that view. Most security issues occur because use= rs of the spec are unable to deal with the complexity that is passed onto th= em. 

     

    99% of the people that will actually use= the output of the work are application developers (client or RS) and their = own users. 

     

    Our intent as well as the protocol drive the usage. Client libraries ma= y help, but they're not a silver bullet, especially because GNAP ultimately = has no control about what people do there (for better or worse). And everyth= ing we do here will help get to the better part. 

    =

     

    I'm not saying we don't intend to also care about AS developers (beginn= ing with ourselves) but it's a second order optimisation. And since it's a t= endancy we're leaning towards by default, I'm pretty sure we won't forget th= at anyway. 

     

    Fabien 

     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    I'm confused by your logic Fabien.

     

    If a client libra= ry developer wants to expose polymorphism, they can do that independent of w= hat is in the protocol. 

     

    I differ on who our stakeho= lders are. 

     

    I think our stakeholders are in least to= most important:

     

    • AS developer<= /o:p>
    • RS developer
    • client developer
    • u= ser

     

    <= /div>

    A client library developer can expose whatever = interface they want to simplify implementation.

     

    I list th= e user so that we don't lose site of a critical role.

     

    /Di= ck

     

     

    3D"Image=E1=90=A7<= /p>

     

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi there, 

     

    Let me try to approach th= e issue under a different light. More like a product manager would deal with= feature selection to make it intuitive for its users. 

    <= div>

     

    For most people, riding a bike is far easier than using a unicycle. Feels= more stable. And yet it's way easier to design for a single wheel than to b= uild with 2. Because then you'll need a lot more accessories (chain, chain r= ing, etc.). Even so producing a bike doesn't have to be a brittle process, i= t can be industrialized. 

    <= o:p> 

    Back to the GNAP topic.&nb= sp;

    Ultimately we should strive to make the spec as simple as can be.= But we need to ask: simple for whom? For the bike owner or for the bike ven= dor? 

    (short answer: the priority should be simplic= ity for spec users, not spec implementers and even less spec designers).&nbs= p;

     

    <= /div>

    The initial question that is asked is very inte= resting: isn't the design flawed if GNAP is using json polyphormism? Or if t= he AS needs to handle the state of the request? Or if we must handle token r= evocation? Or if we are looking for a global unique identifier? The argument= stems of the fact that is still arguably harder and more error prone to imp= lement. Fair enough. 

    =  

    From a spec implementer's pers= pective, it may well be more complex. It mostly impacts the json library you= 'll end up using, plus a bit of input/output decoration around it. Even gola= ng provides utilities for this, despite not exactly being made for this kind= of purpose.

    My practical experi= ence implementing it is that it's not that big a deal. I mean, I wished it c= ould be simpler, but it's manageable and there are other ways to reach level= s of insurance that it does work as intended (json schema, test cases to val= idate the implementation, etc.). Arguably it is still easier from an impleme= ntation perspective than say, json-ld, which is massively used in the SSI co= mmunity. 

     =

    But ultimately who are we designing for? A= re we striving to go easy on the spec implementer? Or are we trying to make = sure end-developers using the client libraries won't shoot themselves in the= foot?

     

    The job to be done (JTBD), from the end-developer'= s perspective, is to efficiently ship an application. And provide authN/auth= Z capabilities for end-users by relying on some well known implementation.&n= bsp;

    In turn, this spec implemen= ter will rely on cryptographic utility libraries that deals internally with = the complexity of their own domain, so that we don't have to. And here we co= uld launch another HN flame war that starts with the title "JWT sucks b= ecause". Which does have its set of very real issues but that's beyond = the point. 

    Note that any d= ecent flamewar will be efficiently fueled by people hating medium. Is it out= rageous for blog posts to be behind a paywall? Maybe but it's even more outr= ageous to lack consistency, either by not knowing how to get around a paywal= l if you're into a hacker punk movement, or on the contrary by to not paying= a subscription if you believe that surveillance capitalism, to reuse Zuboff= 's terms, should be eradicated. 

    What likely seems an unnecessary sidenote tries to illustrate the poin= t: for Justin it was easier to publish on medium, because as a blog publishe= r, you might not want to deal with hosting your own blog. But maybe as a rea= der you'll find that annoying. Different audiences, different JTBD, differen= t tradeoffs. 

     

    Polyphormism is a tool that enables th= e end-developer to have minimal knowledge of what it means to deal with a GN= AP client library. You prepare the request, send to the endpoint and you're = good to go. Massively simpler than OAuth2 or any similar protocol by the way= (as anyone with teaching experience on the subject might acknowledge). And&= nbsp; there's a lot more to be done to make sure we indeed reduce the comple= xity for the end-developer and the end-user. 

    =

     

    If we = find a better way to deal with that simplicity balance, I'm all in. But the = arguments need to be way more convincing than just saying that it may be dif= ficult to implement or validate. 

     

    Cheers.=

    Fabien

     

     

     

     

     

    Le ven. 23 oct. 2020 =C3=A0 22:3= 5, Justin Richer <jriche= r@mit.edu> a =C3=A9crit :

     



    On Oct 23, 2020, at 3:52 PM,= Dick Hardt <dick.h= ardt@gmail.com> wrote:

    &n= bsp;

    Justin

     

    I did note th= at I was the one that argued for instance_id being in the object. Since it i= s in the object in the current draft, not including a pass by reference opti= on would be preferable. 

     

    As for concrete examples:

    - version of client

    - version of OS

    - security attestation of OS / device

    - location of client device

    - network client is operating on

    <= p class=3DMsoNormal> 

    These a= re all attributes of the client that an AS may require on the initial g= rant request, and in future grant requests (which is when an instance_id) wo= uld be used.

     

     

    This is where our interpretations differ: I = don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in the same way that the= key, display information, class identifiers, and other items currently repr= esented by an instance_id are attributes of the client instance. The attesta= tion components don=E2=80=99t modify the instance so much as present additional in= formation on top of the client instance itself. This is why I argue that the= y ought to be handled in a separate object, so you=E2=80=99d have something like t= his strawman:

     <= /p>

    {

     

      posture: {=

        software_version: 1.2.= 3,

        os_version: 14.= 3.2

        device_attesta= tion: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }

        location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

      },

     

     = ; client: =E2=80=9Cclient-541-ab"

     

    }

     

    Thi= s is a more fundamental question about GNAP than whether the syntax uses pol= ymorphism: this is about GNAP being very explicit about the data model of it= s elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80= =9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. We=E2=80= =99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccreden= tialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the different a= spects that are out there. I think we=E2=80=99re getting closer here in GNAP with = explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be more p= recise about what exactly a client instance includes, and what it does not.<= o:p>

     

    =

     =E2=80=94 Justin

     



    /Dick

     

    3D"Image=E1=90=A7

    &nb= sp;

    On Fri, Oct 23, 2020 at 12:42 PM J= ustin Richer <jricher@mi= t.edu> wrote:

    Dick,

     

    As you=E2=80=99ll recall,= I argued against including the client instance identifier inside of the obj= ect as a mutually-exclusive field precisely because of the principle violati= on that you are pointing out here, and so it=E2=80=99s important to point out that= the current text is a compromise that needs to be examined in the wider exp= erience of the working group. I am on the side of removing the mutually-excl= usive =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to be explor= ed.

     

    <= div>

    The crux of my argument is that is exactly a case of = pass-by-reference vs pass-by-value, and that runtime attestations are not pa= rt of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside of th= at object in a another part of the request. As stated in the editorial notes= in this section, we need to look carefully at how these concepts fit within= the model and where we would want to put them. Without concrete examples of= what these extensions look like and how they=E2=80=99re generated, that is nearly= impossible to do at this stage. I look forward to seeing examples of this k= ind of data and how it can fit into the protocol.

    <= p class=3DMsoNormal> 

     =E2= =80=94 Justin



    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

     

    Hey Justin,

     

    As the draft has evolved, I question the= continued use of polymorphism. Note that I appreciate the elegance of = using a string for pass-by-reference, and an object for pass-by-value.<= /o:p>

     

    In the current draft, the 

     

    Every time you create or proces= s a field it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. 

     

     

     

       instance_id  = ;An identifier string that the AS can use to identify the

          particular instance of this R= C.  The content and structure of this

          identifier is opaque to the RC.

     

       "client": {

           "instance_id": "client-5= 41-ab"

       }<= /o:p>

     

       If there are no additional fields to send, the RC= MAY send the

       insta= nce identifier as a direct reference value in lieu of the

       object.

     

      &nb= sp;"client": "client-541-ab"

     

    The instance identifier can be sent two ways. Polymorphism is a conveni= ence for the client, but requires the server to have two code path= s for "instance_id".  We discussed this in the design team, a= nd I argued for having "instance_id" in the "client" obj= ect so that any updates, such as new devices assertions, could be in th= e "client" object. As noted above, while I appreciate the elegance= of using a string (handle) to reference a previously provided object, it co= mplicates how to update an existing object while providing the reference.

     

    In your example of the "key" object below, settin= g "proof" to bearer would avoid the issue you describe:=

     

    { 
     "key": { 
         &q= uot;proof": "bearer"
        }
    }

    =

     

    In your example, when processing the "key" object, code is ha= ving to check both the JSON type of the property, as well as check the value= of the "proof" property. In the example I provided, only the valu= e of "proof" needs to be checked. The "proof" property i= s acting as a type for the "key" object.

    =

     

    Not be= ing a Java programmer, I don't know how this would work in a Java implementa= tion, but node.js, the processing would need to be done as above.=

     

    On a related note, there was significant negative feedback on handl= es and polymorphism in the Hacker News article https://news.ycombinator.com= /item?id=3D24855750 

     

    /Dick

     

     

    On Fri, Oct 23, 20= 20 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

     

    = Thanks for bringing this topic here =E2=80=94 I was able to see the forum discussi= on that brought you here, and hopefully I can help clear up what I mean with= how polymorphism is used in the proposal. The short version is that the goa= l is to avoid the kinds of ambiguity that make insecure pro= tocols, and so in that goal we=E2=80=99re fully aligned. I think that using polymo= rphism in very specific ways can help that goal =E2=80=94 just as I agree that mis= using it or applying it sloppily can lead to ambiguous and insecure systems.=

     

    Some background: I built out the XYZ protocol (one of th= e predecessors to the initial GNAP Draft) in Java using strongly typed parse= rs and Java objects specifically to prove to myself that it could be done in= a way that made any sense in the code. (My own open source implementation i= s at h= ttps://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up t= o date with the GNAP spec). It was important to me that I be able to use the= system-wide configured parsers to implement this and not have to resort to = stepping through elements completely by hand. Java doesn=E2=80=99t make it simple = to get the hooks into the right places (especially with the Jackson parser t= hat I used), but it is definitely possible to create a deterministic and str= ongly-typed parser and serializer for this kind of data structure. Some of t= he rationale for using polymorphism is covered in the trailing appendix of t= he draft document (http= s://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-= structures-and-polymor), but it=E2=80=99s still good to discuss this here as t= he working group decides which approaches to take. 

     

    = The driving reason for using polymorphism at the protocol level was to simpl= ify the protocol and make it :more: deterministic to create and process, not= less. Every time you create or process a field it will mean only one thing,= and there=E2=80=99s only one field to look at to answer a question. Without polym= orphic field values, you usually need to rely on mutual exclusivity of field= s, which is prone to failure and requires additional error checking. Take fo= r example the key binding of access tokens. An access token could be bound t= o the RC=E2=80=99s key used during the request, to a different key chosen by the A= S, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D= field polymorphic, we can define it in terms of boolean values and objects = and express this set of mutually-exclusive options in a non-ambiguous way. W= ithout that, you=E2=80=99d need to have different fields for the options and inclu= de additional checks in your parser to make sure they weren=E2=80=99t sent simulta= neously, otherwise you could get hit with this potential security vulnerabil= ity in an object:

     

    { 

        key: {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

    <= div>

        },

        bearer_token: true,

        bind_to_rc_key: true

    }

     =

    This would be an illegal object as per thi= s alternate proposal, but then you=E2=80=99d have to check each field and make sur= e it wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve done this exerci= se with many other protocols and it=E2=80=99s both error prone and easy to ignore = since all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t check this.= With the polymorphic approach to this same field, each of these three mutua= lly-exclusive states is written in a way that they cannot be sent together. = It=E2=80=99s not just illegal, it=E2=80=99s impossible and enforced by the syntax of JSO= N itself.

     

    <= /div>

    { 

        key: {

    &= nbsp;     proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

        }

    }

     

    // bearer token

     

    {

    =

        key: false

    <= div>

    }

    <= o:p> 

    // bound to the RC=E2=80=99s pre= sented key

     

    =

    {

    =     key: true

    }

     

    If someone sends a different type for this field, like an array= or number or a null, this doesn=E2=80=99t have a defined interpretation in the pr= otocol and would be a protocol level error.

     

    While it migh= t sound like polymorphism means that any field could have any type or value,= the opposite is true: each possible value is explicitly typed, it=E2=80=99s just = that there are potentially different types that express meaning for the fiel= d. This applies to all members of all objects (dictionaries) as well as all = members of an array (list). Every time you process a field value or other el= ement, you look at the type and then the value to determine what to do with = that typed value.

     

    In your example below, each field withi= n the dictionary would also need to be typed, and each type would need to ha= ve a clear indication of its meaning. To take your strawman key format below= , the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as either a =E2=80=9Cbi= gint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The defi= nition would further say what exactly the encoding of the string would be. T= hat means that when you read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any= confusion on what the value was or how it was represented, regardless of th= e input format. Seeing a number there means exactly one interpretation and s= eeing a string means exactly one (different) interpretation =E2=80=94 but importan= tly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determi= nes the type. An implementation would likely use an internal BigInteger type= of object to represent the field value after parsing, so the question is ho= w to go from the JSON value (which is typed) into the BigInteger value.You d= on=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply it= to all sub-fields of that object. 

     

    So let=E2=80=99s dig i= nto the specific bug you bring up in the strawman, because it=E2=80=99s interestin= g: A JSON encoder that encodes numbers as strings, and not numbers, is not c= ompliant with the JSON definitions of the field in question. For another exa= mple, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean= value true in JSON, and they shouldn=E2=80=99t be treated the same by a parser im= plementation when mapping to a concrete object. It=E2=80=99s in this kind of autom= ated guessing that this class of bugs occur, and that=E2=80=99s going to be the ca= se whether or not you take  advantage of JSON=E2=80=99s polymorphic nature. I= =E2=80=99ve run into cases where a parser library was trying to be overly =E2=80=9Chelpf= ul=E2=80=9D in doing this kind of mapping, but ended up introducing errors in more= strict components downstream. This is something that protocol designers nee= d to be aware of and guard against in the design of the protocol to reduce p= ossible ambiguities. Within GNAP today, we generally have things that branch= whether they=E2=80=99re an object (for a rich description of something) or some n= on-structured special value (for a reference or other item). 

     

    The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in the design d= ocument due to both lack of time to keep it updated with the rapid changes t= o the protocol during the design team discussion, and not knowing if there w= ould be interest in such material. I personally think it would be helpful to= include as an informative reference in the final document, but that=E2=80=99s som= ething for the working group to take up eventually.

     

     = ;=E2=80=94 Justin



    <= /p>

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smark= ets.com@dmarc.ietf.org> wrote:

     

    Hello, everyone.

     

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussi= on forum and when I made note about certain concerns, I was requested to sen= d my comments to this working group.

     

    In short, I believe = that the use of polymorphic JSON in the protocol invites subtle and confusin= g implementation problems. I also searched through the WG archives, and noti= ced that similar concerns were noted, briefly, in a thread in July.

     

    The problem with polymorphic values, as I see it, is that implem= entations will need to branch on the (inferred) type of a given field. This = isn't quite as bad if the types are strictly different, but allows for subtl= e bugs when the value in question is a dictionary. What makes this unappeali= ng is that "subtle bugs" in security protocols have a habit of tur= ning into vulnerabilities.

    =  

    Let's say we have these imagin= ary payloads, both possible and valid in the same protocol step:<= /p>

     

    # payload 1

    {=

      ...,

      "public_key": {

        "alg": "rsa",

        "modulus": = <BIGINT>

      }

    }

     

    # payload 2

    {

      ...,

      "= public_key": {

      =   "alg": "rsa",

        "modulus": "<encoded string>= ;"

      }

    <= /div>

    }

    <= o:p> 

    In both cases, the type of= "public_key" field is a dictionary. In both cases, they even have= the same keys. However, the values in the dictionaries are entirely differe= nt, and an implementation will have to branch to at least two possible decod= ing mechanisms. To make things worse, some JSON implementations may choose t= o encode non-dictionary values as strings, so it is possible for an originat= or to transmit what they expect and believe to be payload 1 format, but whic= h the receiver will interpret to be in payload 2 format. And if the encoded = string contains only digits, it will even parse correctly as a bignum.<= /o:p>

     

    While the above is clearly a manufactured scenario, it nonethe= less demonstrates the potential for logic bugs with polymorphic JSON. With r= icher types and more complex dictionaries, there will surely be more room fo= r errors.

     

    <= /div>

    Ambiguity in protocols is always a source of im= plementation complexity and interoperability snags, but in an AuthN/AuthZ pr= otocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supersede= Oauth1/2, wouldn't it be in everyone's interest to keep implementation comp= lexity and mistake potential to a minimum?

     

    Best regards,<= o:p>

    Mika

     

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www= .ietf.org/mailman/listinfo/txauth

     

    --
    TXA= uth mailing list
    TXAuth@= ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    3D"Image=E1=90=A7

     

     

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    = =



    --

    =

    Mika Bostr=C3=B6m

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/m= ailman/listinfo/txauth

    --B_3686762835_2038932513-- From nobody Wed Oct 28 12:30:30 2020 Return-Path: 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 5B1253A0BE6 for ; Wed, 28 Oct 2020 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 g3ORnEvxTHx6 for ; Wed, 28 Oct 2020 12:30:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18FE3A0BDF for ; Wed, 28 Oct 2020 12:30:21 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SJUIAJ016288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 15:30:18 -0400 From: Justin Richer Message-Id: <809BDCD6-B71A-463F-8F37-FD177C95B5A5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3EF103B0-5445-4396-93F3-5BC6F812BBFF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 15:30:17 -0400 In-Reply-To: Cc: Fabien Imbault , =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List , Dick Hardt To: Yaron Sheffer References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 19:30:28 -0000 --Apple-Mail=_3EF103B0-5445-4396-93F3-5BC6F812BBFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron, it=E2=80=99s a good observation on the RC=E2=80=99s requirements. = You are correct that the RC would need to deal with the =E2=80=9Ckey=E2=80= =9D value having potentially different types, but In this specific case = I think it would be naturally limited by a capability the RC is able to = support, or not: Either the RC is going to be able to bind the token to an arbitrary key = from the AS (which is when it would see a non-boolean value), or it = won=E2=80=99t be able to do that, in which case it can only expect/read = a boolean there. A general purpose RC library will deal with that = polymorphism, but it would also deal with the polymorphism of the = request language. I would expect a simple client to just reject a = response with an arbitrary key in that field if it doesn=E2=80=99t know = how to handle it. I think it=E2=80=99s a feature that the RC wouldn=E2=80=99= t have to always know about every part of the protocol in order to get = something working in a secure and predictable fashion. We could also decide to limit that case in the response in order to = lessen the burden on the RC. As Dick pointed out earlier in the thread, = it wouldn=E2=80=99t be difficult to come up with a syntax to declare = bearer tokens =E2=80=94 and in fact, his proposal aligns with previous = versions of the XYZ Draft. I personally think the syntax is awkward and = has some drawbacks, but it does work for the basic use case of switching = between bearer tokens and server-provided keys. However, the missing = piece is something that I think should become the default in GNAP: = binding the resulting token to the key the client presented during the = request. This aligns with both DPoP and OAuth MTLS methods today, both = of which have been shown to work very well in production. However, = server-provided and server-referenced keys are called for by the OAuth = PoP Architecture documents. These are more complex use cases, to be = sure, but I think it=E2=80=99s possible to support them with relatively = low cost to the rest of the system. It=E2=80=99s definitely a tradeoff, but one I think lands closer to = simplicity for a wider array of software implementations and helps get = us away from bearer tokens as a default for the simple case of a client = instance binding to its own key. =E2=80=94 Justin > On Oct 28, 2020, at 2:47 PM, Yaron Sheffer = wrote: >=20 > Hi Fabien, > =20 > At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is = far worse than the problem. The code in the article you cite is very = specific to the use case and IMHO quite ugly. So my preferred Go = implementation would be a combination of untyped structures (Go = interface{}) and run-time enforcement of JSON Schema. > =20 > Also, going back to our earlier discussion on this topic, I just read = Sec. 7 of gnap-00 and realized that the RC also needs to deal with = polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. > =20 > Thanks, > Yaron > =20 > From: TXAuth > on behalf of Fabien Imbault = > > Date: Wednesday, October 28, 2020 at 18:56 > To: Mika Bostr=C3=B6m > > Cc: GNAP Mailing List >, = Justin Richer >, Dick Hardt = > > Subject: Re: [GNAP] Feedback on polymorphism > =20 > Thanks for the great feedback. Your concern is very valid.=20 > =20 > My implementation is in rust, which makes life easier in that specific = case.=20 > =20 > So I'm not a golang specialist but I guess the transcription of json = strings/arrays into go structs would work around the lines described by = https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 = > When we have a more formalized json schema, I suggest we make a = library of json examples and some related code samples in mainstream = languages, to check it is feasible for everyone.=20 > =20 > Cheers, > Fabien > =20 > =20 > On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m = > wrote: >> Hi everyone, >> =20 >> Looks like I stuck my finger in a hornets' nest. First off, apologies = for not chipping in earlier, but there was a lot of material to digest. = Also, warning: lots to read ahead. >> =20 >> I'm one of those people who end up making use of AuthN/AuthZ = functionality through a library. On top of that I can see myself being = roped in as a server (AS) implementation help. So I'm approaching this = from an outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that. >> =20 >> Now, having read Justin's initial reply - and the rest of the thread = - I believe I can see where the desire for polymorphism comes from. To = be clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts. >> =20 >> But then the downside. I don't personally expect to be able to use = the reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was >> =20 >> { >> "name": "", >> "age": , >> "country": "", >> "city": "" >> } >> =20 >> .. then the type definition would look like: >> =20 >> type Person struct { >> Name string `json:"name" >> Age int `json:"age"` >> Country string `json:"country"` >> City string `json:"city"` >> } >> =20 >> When the (possibly complex) type of a given field is fixed, = unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed = value, there should be nothing special about that. But when the field = can instead be a union of more than one distinct types, things start to = get messy. There is no union type in the language at all, so the = following construct is not even possible: >> =20 >> type Entity struct { >> Resources []string `json:"resources"` >> Client union(Client, string) `json:"client"` >> } >> =20 >> As I understand, the implicit expectation is that in the above case, = the unmarshaler detects that "client" is a string, and so expands it = from an opaque handle to the expected, populated type. Even after = thinking about the ramifications over the past few days I remain = confused, because I don't see how the commonly used annotations could = work. If the expectation is that protocol implementations should use = strong types, then the use of polymorphic JSON is very likely to make = things _more_ complicated for non-reference implementations.=20 >> =20 >> Hence my concern. I'm afraid that the leaky abstraction, while making = the reference implementation more robust and straightforward, = contributes to making other implementations less robust. And this being = a security protocol, the potential for brittle and/or confused = implementations is terrifying.=20 >> =20 >> I am a fan of reducing complexity, and from what I can see, for the = reference implementation the polymorphic approach actually does that. = But I'm afraid it does so at others' expense. Languages have their = individual constraints, idioms and best practices. If parsing a protocol = payload introduces low-level complexities and encourages to go against = common practices, that is an invitation for problems. I am aware that my = choice of words in the HN thread was likely to put people on defense, = and for that I apologise. But I do believe that the choice of = polymorphic JSON is going to make the life and use of other = implementations notably less boring than people in general would prefer. >> =20 >> Cheers, >> Mika >> =20 >> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault = > wrote: >>> Hi Dick, >>> =20 >>> Well technically yes. Obviously the client can present any interface = it seems fit.=20 >>> =20 >>> Still there's the question of the common model we want to present to = the outside world and supported by the protocol itself (which client = libraries all build upon).=20 >>> =20 >>> But beneath the polyphormism question, the HN debate seems on the = surface a lot like the original xyz (polyphormism goes along with the = reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and = where the client design has more latitude). Just explained differently, = by outside people with different agendas.=20 >>> =20 >>> Which is a bit weird because many of the critics on HN (who = criticize polyphormism) also seem to really dislike OAuth in the first = place (the inconsistencies are partially due to a bunch of different = people commenting).=20 >>> =20 >>> Really to me there's no fundamental truth behind that question. It's = a matter of preference and priorities in the design. Whatever choices we = make, we'll have to be prepared to explain and justify them in the open, = even to some people that will dislike pretty much whatever we do = (because it's fun to look smart and critize without proposing = alternatives). And we owe these answers to people like Mika, who = genuinely try to make the best of it.=20 >>> =20 >>> Fabien=20 >>> =20 >>> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt > a =C3=A9crit : >>>> Hi Fabien >>>> =20 >>>> A library developer can provide whatever abstraction layer makes = sense for the library's target audience and language. >>>> =20 >>>> If the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice versa=20= >>>> =20 >>>> =3D> polymorphism in the protocol has no impact on client library = developers >>>> =20 >>>> =20 >>>> =E1=90=A7 >>>> =20 >>>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = > wrote: >>>>> I'm just realizing your "least to most important" might actually = say the same as what I was trying to say. So I'm not even sure what = we're arguing against :-)=20 >>>>> =20 >>>>> In brief my point if it wasn't clear is that we should be crystal = clear on where we put the cursor of simplicity, because this can mean = different things for different people and different roles.=20 >>>>> And as we see on HN we need to better explain our design choices.=20= >>>>> =20 >>>>> =20 >>>>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault = > a =C3=A9crit = : >>>>>> Hi Dick, >>>>>> =20 >>>>>> Independantly from the debate on polyphormism, I beg to differ on = your order preference.=20 >>>>>> =20 >>>>>> Your assumption is that AS devs matter the most, because they're = doing the important security implementation. But eating our own dogfood = might help a lot to change that view. Most security issues occur because = users of the spec are unable to deal with the complexity that is passed = onto them.=20 >>>>>> =20 >>>>>> 99% of the people that will actually use the output of the work = are application developers (client or RS) and their own users.=20 >>>>>> =20 >>>>>> Our intent as well as the protocol drive the usage. Client = libraries may help, but they're not a silver bullet, especially because = GNAP ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >>>>>> =20 >>>>>> I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >>>>>> =20 >>>>>> Fabien=20 >>>>>> =20 >>>>>> =20 >>>>>>=20 >>>>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt = > a =C3=A9crit : >>>>>>> I'm confused by your logic Fabien. >>>>>>> =20 >>>>>>> If a client library developer wants to expose polymorphism, they = can do that independent of what is in the protocol.=20 >>>>>>> =20 >>>>>>> I differ on who our stakeholders are.=20 >>>>>>> =20 >>>>>>> I think our stakeholders are in least to most important: >>>>>>> =20 >>>>>>> AS developer >>>>>>> RS developer >>>>>>> client developer >>>>>>> user >>>>>>> =20 >>>>>>> A client library developer can expose whatever interface they = want to simplify implementation. >>>>>>> =20 >>>>>>> I list the user so that we don't lose site of a critical role. >>>>>>> =20 >>>>>>> /Dick >>>>>>> =20 >>>>>>> =20 >>>>>>> =E1=90=A7 >>>>>>> =20 >>>>>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: >>>>>>>> Hi there,=20 >>>>>>>> =20 >>>>>>>> Let me try to approach the issue under a different light. More = like a product manager would deal with feature selection to make it = intuitive for its users.=20 >>>>>>>> =20 >>>>>>>> For most people, riding a bike is far easier than using a = unicycle. Feels more stable. And yet it's way easier to design for a = single wheel than to build with 2. Because then you'll need a lot more = accessories (chain, chain ring, etc.). Even so producing a bike doesn't = have to be a brittle process, it can be industrialized.=20 >>>>>>>> =20 >>>>>>>> Back to the GNAP topic.=20 >>>>>>>> Ultimately we should strive to make the spec as simple as can = be. But we need to ask: simple for whom? For the bike owner or for the = bike vendor?=20 >>>>>>>> (short answer: the priority should be simplicity for spec = users, not spec implementers and even less spec designers).=20 >>>>>>>> =20 >>>>>>>> The initial question that is asked is very interesting: isn't = the design flawed if GNAP is using json polyphormism? Or if the AS needs = to handle the state of the request? Or if we must handle token = revocation? Or if we are looking for a global unique identifier? The = argument stems of the fact that is still arguably harder and more error = prone to implement. Fair enough.=20 >>>>>>>> =20 >>>>>>>> =46rom a spec implementer's perspective, it may well be more = complex. It mostly impacts the json library you'll end up using, plus a = bit of input/output decoration around it. Even golang provides utilities = for this, despite not exactly being made for this kind of purpose. >>>>>>>> My practical experience implementing it is that it's not that = big a deal. I mean, I wished it could be simpler, but it's manageable = and there are other ways to reach levels of insurance that it does work = as intended (json schema, test cases to validate the implementation, = etc.). Arguably it is still easier from an implementation perspective = than say, json-ld, which is massively used in the SSI community.=20 >>>>>>>> =20 >>>>>>>> But ultimately who are we designing for? Are we striving to go = easy on the spec implementer? Or are we trying to make sure = end-developers using the client libraries won't shoot themselves in the = foot? >>>>>>>> =20 >>>>>>>> The job to be done (JTBD), from the end-developer's = perspective, is to efficiently ship an application. And provide = authN/authZ capabilities for end-users by relying on some well known = implementation.=20 >>>>>>>> In turn, this spec implementer will rely on cryptographic = utility libraries that deals internally with the complexity of their own = domain, so that we don't have to. And here we could launch another HN = flame war that starts with the title "JWT sucks because". Which does = have its set of very real issues but that's beyond the point.=20 >>>>>>>> Note that any decent flamewar will be efficiently fueled by = people hating medium. Is it outrageous for blog posts to be behind a = paywall? Maybe but it's even more outrageous to lack consistency, either = by not knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 >>>>>>>> What likely seems an unnecessary sidenote tries to illustrate = the point: for Justin it was easier to publish on medium, because as a = blog publisher, you might not want to deal with hosting your own blog. = But maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >>>>>>>> =20 >>>>>>>> Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >>>>>>>> =20 >>>>>>>> If we find a better way to deal with that simplicity balance, = I'm all in. But the arguments need to be way more convincing than just = saying that it may be difficult to implement or validate.=20 >>>>>>>> =20 >>>>>>>> Cheers. >>>>>>>> Fabien >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = > a =C3=A9crit : >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt > wrote: >>>>>>>>>> =20 >>>>>>>>>> Justin >>>>>>>>>> =20 >>>>>>>>>> I did note that I was the one that argued for instance_id = being in the object. Since it is in the object in the current draft, not = including a pass by reference option would be preferable.=20 >>>>>>>>>> =20 >>>>>>>>>> As for concrete examples: >>>>>>>>>> - version of client >>>>>>>>>> - version of OS >>>>>>>>>> - security attestation of OS / device >>>>>>>>>> - location of client device >>>>>>>>>> - network client is operating on >>>>>>>>>> =20 >>>>>>>>>> These are all attributes of the client that an AS may require = on the initial grant request, and in future grant requests (which is = when an instance_id) would be used. >>>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> This is where our interpretations differ: I don=E2=80=99t see = these as =E2=80=9Cattributes of the client=E2=80=9D in the same way that = the key, display information, class identifiers, and other items = currently represented by an instance_id are attributes of the client = instance. The attestation components don=E2=80=99t modify the instance = so much as present additional information on top of the client instance = itself. This is why I argue that they ought to be handled in a separate = object, so you=E2=80=99d have something like this strawman: >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> =20 >>>>>>>>> posture: { >>>>>>>>> software_version: 1.2.3, >>>>>>>>> os_version: 14.3.2 >>>>>>>>> device_attestation: { =E2=80=A6 some structure or signed = blob? =E2=80=A6 } >>>>>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 = } >>>>>>>>> }, >>>>>>>>> =20 >>>>>>>>> client: =E2=80=9Cclient-541-ab" >>>>>>>>> =20 >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> This is a more fundamental question about GNAP than whether = the syntax uses polymorphism: this is about GNAP being very explicit = about the data model of its elements. OAuth 2=E2=80=99s incredibly loose = and broad model of what the term =E2=80=9Cclient=E2=80=9D is referring = to, exactly, is deeply problematic in practice. We=E2=80=99re even = seeing that in the OAuth 2.1 work with having to define a = =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t = fully capture the different aspects that are out there. I think we=E2=80=99= re getting closer here in GNAP with explicit definition of =E2=80=9Cclient= instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >>>>>>>>> =20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> /Dick >>>>>>>>>> =20 >>>>>>>>>> =E1=90=A7 >>>>>>>>>> =20 >>>>>>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = > wrote: >>>>>>>>>>> Dick, >>>>>>>>>>> =20 >>>>>>>>>>> As you=E2=80=99ll recall, I argued against including the = client instance identifier inside of the object as a mutually-exclusive = field precisely because of the principle violation that you are pointing = out here, and so it=E2=80=99s important to point out that the current = text is a compromise that needs to be examined in the wider experience = of the working group. I am on the side of removing the = mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an = object, but this needs to be explored. >>>>>>>>>>> =20 >>>>>>>>>>> The crux of my argument is that is exactly a case of = pass-by-reference vs pass-by-value, and that runtime attestations are = not part of the =E2=80=9Cclient instance=E2=80=9D value itself but = rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look = carefully at how these concepts fit within the model and where we would = want to put them. Without concrete examples of what these extensions = look like and how they=E2=80=99re generated, that is nearly impossible = to do at this stage. I look forward to seeing examples of this kind of = data and how it can fit into the protocol. >>>>>>>>>>> =20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt = > wrote: >>>>>>>>>>>> =20 >>>>>>>>>>>> Hey Justin, >>>>>>>>>>>> =20 >>>>>>>>>>>> As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >>>>>>>>>>>> =20 >>>>>>>>>>>> In the current draft, the=20 >>>>>>>>>>>> =20 >>>>>>>>>>>>> Every time you create or process a field it will mean only = one thing, and there=E2=80=99s only one field to look at to answer a = question.=20 >>>>>>>>>>>> =20 >>>>>>>>>>>> is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >>>>>>>>>>>> =20 >>>>>>>>>>>> =20 >>>>>>>>>>>>> instance_id An identifier string that the AS can use = to identify the >>>>>>>>>>>>> particular instance of this RC. The content and = structure of this >>>>>>>>>>>>> identifier is opaque to the RC. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> "client": { >>>>>>>>>>>>> "instance_id": "client-541-ab" >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> If there are no additional fields to send, the RC MAY = send the >>>>>>>>>>>>> instance identifier as a direct reference value in lieu = of the >>>>>>>>>>>>> object. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> "client": "client-541-ab" >>>>>>>>>>>> =20 >>>>>>>>>>>> The instance identifier can be sent two ways. Polymorphism = is a convenience for the client, but requires the server to have two = code paths for "instance_id". We discussed this in the design team, and = I argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >>>>>>>>>>>> =20 >>>>>>>>>>>> In your example of the "key" object below, setting "proof" = to bearer would avoid the issue you describe: >>>>>>>>>>>> =20 >>>>>>>>>>>> {=20 >>>>>>>>>>>> "key": {=20 >>>>>>>>>>>> "proof": "bearer"=20 >>>>>>>>>>>> }=20 >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> In your example, when processing the "key" object, code is = having to check both the JSON type of the property, as well as check the = value of the "proof" property. In the example I provided, only the value = of "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >>>>>>>>>>>> =20 >>>>>>>>>>>> Not being a Java programmer, I don't know how this would = work in a Java implementation, but node.js, the processing would need to = be done as above. >>>>>>>>>>>> =20 >>>>>>>>>>>> On a related note, there was significant negative feedback = on handles and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >>>>>>>>>>>> =20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> =20 >>>>>>>>>>>> =20 >>>>>>>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = > wrote: >>>>>>>>>>>>> Hi Mika, >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able = to see the forum discussion that brought you here, and hopefully I can = help clear up what I mean with how polymorphism is used in the proposal. = The short version is that the goal is to avoid the kinds of ambiguity = that make insecure protocols, and so in that goal we=E2=80=99re fully = aligned. I think that using polymorphism in very specific ways can help = that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Some background: I built out the XYZ protocol (one of the = predecessors to the initial GNAP Draft) in Java using strongly typed = parsers and Java objects specifically to prove to myself that it could = be done in a way that made any sense in the code. (My own open source = implementation is at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >>>>>>>>>>>>> =20 >>>>>>>>>>>>> {=20 >>>>>>>>>>>>> key: { >>>>>>>>>>>>> proof: httpsig, >>>>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>>>> }, >>>>>>>>>>>>> bearer_token: true, >>>>>>>>>>>>> bind_to_rc_key: true >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> This would be an illegal object as per this alternate = proposal, but then you=E2=80=99d have to check each field and make sure = it wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve = done this exercise with many other protocols and it=E2=80=99s both error = prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples = would pass code that doesn=E2=80=99t check this. With the polymorphic = approach to this same field, each of these three mutually-exclusive = states is written in a way that they cannot be sent together. It=E2=80=99s= not just illegal, it=E2=80=99s impossible and enforced by the syntax of = JSON itself. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> {=20 >>>>>>>>>>>>> key: { >>>>>>>>>>>>> proof: httpsig, >>>>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> // bearer token >>>>>>>>>>>>> =20 >>>>>>>>>>>>> { >>>>>>>>>>>>> key: false >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>>>>>>> =20 >>>>>>>>>>>>> { >>>>>>>>>>>>> key: true >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> If someone sends a different type for this field, like an = array or number or a null, this doesn=E2=80=99t have a defined = interpretation in the protocol and would be a protocol level error. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> While it might sound like polymorphism means that any = field could have any type or value, the opposite is true: each possible = value is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> In your example below, each field within the dictionary = would also need to be typed, and each type would need to have a clear = indication of its meaning. To take your strawman key format below, the = =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as = either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded = string=E2=80=9D (a JSON string). The definition would further say what = exactly the encoding of the string would be. That means that when you = read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any = confusion on what the value was or how it was represented, regardless of = the input format. Seeing a number there means exactly one interpretation = and seeing a string means exactly one (different) interpretation =E2=80=94= but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since = that=E2=80=99s the field that determines the type. An implementation = would likely use an internal BigInteger type of object to represent the = field value after parsing, so the question is how to go from the JSON = value (which is typed) into the BigInteger value.You don=E2=80=99t just = apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you = apply it to all sub-fields of that object.=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> So let=E2=80=99s dig into the specific bug you bring up in = the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take = advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into = cases where a parser library was trying to be overly =E2=80=9Chelpful=E2=80= =9D in doing this kind of mapping, but ended up introducing errors in = more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item).=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> The design team created some simple JSON Schemas for parts = of the protocol during our discussion, but we didn=E2=80=99t include = them in the design document due to both lack of time to keep it updated = with the rapid changes to the protocol during the design team = discussion, and not knowing if there would be interest in such material. = I personally think it would be helpful to include as an informative = reference in the final document, but that=E2=80=99s something for the = working group to take up eventually. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Hello, everyone. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a = discussion forum and when I made note about certain concerns, I was = requested to send my comments to this working group. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> In short, I believe that the use of polymorphic JSON in = the protocol invites subtle and confusing implementation problems. I = also searched through the WG archives, and noticed that similar concerns = were noted, briefly, in a thread in July.=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Let's say we have these imaginary payloads, both possible = and valid in the same protocol step: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> # payload 1 >>>>>>>>>>>>>> { >>>>>>>>>>>>>> ..., >>>>>>>>>>>>>> "public_key": { >>>>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>>>> "modulus": >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> # payload 2 >>>>>>>>>>>>>> { >>>>>>>>>>>>>> ..., >>>>>>>>>>>>>> "public_key": { >>>>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>>>> "modulus": "" >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> In both cases, the type of "public_key" field is a = dictionary. In both cases, they even have the same keys. However, the = values in the dictionaries are entirely different, and an implementation = will have to branch to at least two possible decoding mechanisms. To = make things worse, some JSON implementations may choose to encode = non-dictionary values as strings, so it is possible for an originator to = transmit what they expect and believe to be payload 1 format, but which = the receiver will interpret to be in payload 2 format. And if the = encoded string contains only digits, it will even parse correctly as a = bignum. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> While the above is clearly a manufactured scenario, it = nonetheless demonstrates the potential for logic bugs with polymorphic = JSON. With richer types and more complex dictionaries, there will surely = be more room for errors. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Ambiguity in protocols is always a source of = implementation complexity and interoperability snags, but in an = AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum? >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Mika >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> Mika Bostr=C3=B6m >>>>>>>>>>>>>> Smarkets >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>>>>> =20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> --=20 >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Mika Bostr=C3=B6m >> Smarkets >=20 > -- TXAuth mailing list TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_3EF103B0-5445-4396-93F3-5BC6F812BBFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron, it=E2=80=99s a good observation on the RC=E2=80=99s = requirements. You are correct that the RC would need to deal with the = =E2=80=9Ckey=E2=80=9D value having potentially different types, but In = this specific case I think it would be naturally limited by a capability = the RC is able to support, or not:

    Either the RC is going to be able to bind the token to an arbitrary key from the AS (which is = when it would see a non-boolean value), or it won=E2=80=99t be able to = do that, in which case it can only expect/read a boolean there. A = general purpose RC library will deal with that polymorphism, but it = would also deal with the polymorphism of the request language. I would = expect a simple client to just reject a response with an arbitrary key = in that field if it doesn=E2=80=99t know how to handle it. I think = it=E2=80=99s a feature that the RC wouldn=E2=80=99t have to always know = about every part of the protocol in order to get something working in a = secure and predictable fashion.

    We could also decide to limit that case = in the response in order to lessen the burden on the RC. As Dick pointed = out earlier in the thread, it wouldn=E2=80=99t be difficult to come up = with a syntax to declare bearer tokens =E2=80=94 and in fact, his = proposal aligns with previous versions of the XYZ Draft. I personally = think the syntax is awkward and has some drawbacks, but it does work for = the basic use case of switching between bearer tokens and = server-provided keys. However, the missing piece is something that I = think should become the default in GNAP: binding the = resulting token to the key the client presented during the request. = This aligns with both DPoP and OAuth MTLS methods today, both of which = have been shown to work very well in production. However, = server-provided and server-referenced keys are called for by the OAuth = PoP Architecture documents. These are more complex use cases, to be = sure, but I think it=E2=80=99s possible to support them with relatively = low cost to the rest of the system.

    It=E2=80=99s definitely a tradeoff, but = one I think lands closer to simplicity for a wider array of software = implementations and helps get us away from bearer tokens as a default = for the simple case of a client instance binding to its own = key.

     =E2=80= =94 Justin

    On Oct 28, 2020, at 2:47 PM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,
     
    At least in the case of = Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than the = problem. The code in the article you cite is very specific to the use = case and IMHO quite ugly. So my preferred Go implementation would be a = combination of untyped structures (Go interface{}) and run-time = enforcement of JSON Schema.
     
    Also, going back to our earlier discussion on = this topic, I just read Sec. 7 of gnap-00 and realized that the RC also = needs to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D value), not = only the AS.
     
    Thanks,
              &nb= sp;     Yaron
     
    From: TXAuth <txauth-bounces@ietf.org> = on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, October 28, = 2020 at 18:56
    To: Mika Bostr=C3=B6m = <mika.bostrom@smarkets.com>
    Cc: GNAP = Mailing List <txauth@ietf.org>, = Justin Richer <jricher@mit.edu>, = Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback on = polymorphism
     
    Thanks for the great feedback. Your = concern is very valid. 
     
    My = implementation is in rust, which makes life easier in that specific = case. 
     
    So I'm not a golang specialist but I = guess the transcription of json strings/arrays into go structs would = work around the lines described by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58= ed1
    When we have a more formalized json schema, I = suggest we make a library of json examples and some related code samples = in mainstream languages, to check it is feasible for everyone. 
     
    Cheers,
    Fabien
     
     
    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m = <mika.bostrom@smarkets.com> = wrote:
    Hi everyone,
     
    Looks = like I stuck my finger in a hornets' nest. First off, apologies for not = chipping in earlier, but there was a lot of material to digest. Also, = warning: lots to read ahead.
     
    I'm = one of those people who end up making use of AuthN/AuthZ functionality = through a library. On top of that I can see myself being roped in as a = server (AS) implementation help. So I'm approaching this from an = outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that.
     
    Now, = having read Justin's initial reply - and the rest of the thread - I = believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts.
     
    But = then the downside. I don't personally expect to be able to use the = reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was
     
    {
      = "name": "<string>",
      "age": <int>,
      = "country": "<string>",
      "city": "<string>"
    }
     
    .. = then the type definition would look like:
     
    type = Person struct {
      Name string `json:"name"
      = Age int `json:"age"`
      Country string `json:"country"`
      = City string `json:"city"`
    }
     
    When = the (possibly complex) type of a given field is fixed, unmarshaling = should still be straightforward. I haven't verified, but since the = annotation only gives which field to look at for a given typed value, = there should be nothing special about that. But when the field can = instead be a union of more than one distinct types, things start to get = messy. There is no union type in the language at all, so the following = construct is not even possible:
     
    type = Entity struct {
      Resources []string `json:"resources"`
      = Client union(Client, string) `json:"client"`
    }
     
    As I = understand, the implicit expectation is that in the above case, the = unmarshaler detects that "client" is a string, and so expands it from an = opaque handle to the expected, populated type. Even after thinking about = the ramifications over the past few days I remain confused, because I = don't see how the commonly used annotations could work. If the = expectation is that protocol implementations should use strong types, = then the use of polymorphic JSON is very likely to make things _more_ = complicated for non-reference implementations. 
     
    Hence my concern. = I'm afraid that the leaky abstraction, while making the reference = implementation more robust and straightforward, contributes to making = other implementations less robust. And this being a security protocol, = the potential for brittle and/or confused implementations is = terrifying. 
     
    I am = a fan of reducing complexity, and from what I can see, for the reference = implementation the polymorphic approach actually does that. But I'm = afraid it does so at others' expense. Languages have their individual = constraints, idioms and best practices. If parsing a protocol payload = introduces low-level complexities and encourages to go against common = practices, that is an invitation for problems. I am aware that my choice = of words in the HN thread was likely to put people on defense, and for = that I apologise. But I do believe that the choice of polymorphic JSON = is going to make the life and use of other implementations notably less = boring than people in general would prefer.
     
    Cheers,
    Mika
     
    On Mon, 26 Oct 2020 at = 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Dick,
     
    Well = technically yes. Obviously the client can present any interface it seems = fit. 
     
    Still there's the question of the = common model we want to present to the outside world and supported by = the protocol itself (which client libraries all build upon). 
     
    But = beneath the polyphormism question, the HN debate seems on the surface a = lot like the original xyz (polyphormism goes along with the reduced = endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where = the client design has more latitude). Just explained differently, by = outside people with different agendas. 
     
    Which = is a bit weird because many of the critics on HN (who criticize = polyphormism) also seem to really dislike OAuth in the first place (the = inconsistencies are partially due to a bunch of different people = commenting). 
     
    Really to me there's no fundamental = truth behind that question. It's a matter of preference and priorities = in the design. Whatever choices we make, we'll have to be prepared to = explain and justify them in the open, even to some people that will = dislike pretty much whatever we do (because it's fun to look smart and = critize without proposing alternatives). And we owe these answers to = people like Mika, who genuinely try to make the best of it. 
     
    Fabien 
     
    Le lun. 26 oct. 2020 =C3=A0 = 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    Hi = Fabien
     
    A = library developer can provide whatever abstraction layer makes sense for = the library's target audience and language.
     
    If = the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice = versa 
     
    =3D> polymorphism in the protocol = has no impact on client library developers
     
     
    3D"Image=E1=90=A7
     
    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    I'm = just realizing your "least to most important" might actually say the = same as what I was trying to say. So I'm not even sure what we're = arguing against :-) 
     
    In brief my point if it wasn't clear is = that we should be crystal clear on where we put the cursor of = simplicity, because this can mean different things for different people = and different roles. 
    And as we see on HN we need to better = explain our design choices. 
     
     
    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien = Imbault <fabien.imbault@gmail.com> a =C3=A9crit :
    Hi = Dick,
     
    Independantly from the debate on polyphormism, I beg to = differ on your order preference. 
     
    Your = assumption is that AS devs matter the most, because they're doing the important = security implementation. But eating our own dogfood might help a lot to = change that view. Most security issues occur because users of the spec = are unable to deal with the complexity that is passed onto = them. 
     
    99% of the people that will actually = use the output of the work are application developers (client or RS) and = their own users. 
     
    Our intent as well = as the protocol drive the usage. Client libraries may help, but they're = not a silver bullet, especially because GNAP ultimately has no control = about what people do there (for better or worse). And everything we do = here will help get to the better part. 
     
    I'm = not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a = tendancy we're leaning towards by default, I'm pretty sure we won't = forget that anyway. 
     
    Fabien 
     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick = Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    I'm = confused by your logic Fabien.
     
    If a = client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol. 
     
    I = differ on who our stakeholders are. 
     
    I = think our stakeholders are in least to most important:
     
    • AS developer
    • RS developer
    • client developer
    • user
     
    A = client library developer can expose whatever interface they want to = simplify implementation.
     
    I = list the user so that we don't lose site of a critical role.
     
    /Dick
     
     
    3D"Image=E1=90=A7
     
    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi there, 
     
    Let me try to = approach the issue under a different light. More like a product manager = would deal with feature selection to make it intuitive for its = users. 
     
    For most people, riding a = bike is far easier than using a unicycle. Feels more stable. And yet = it's way easier to design for a single wheel than to build with 2. = Because then you'll need a lot more accessories (chain, chain ring, = etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized. 
     
    Back = to the GNAP topic. 
    Ultimately we should strive to make the spec as simple as can = be. But we need to ask: simple for whom? For the bike owner or for the = bike vendor? 
    (short answer: the priority should be simplicity = for spec users, not spec implementers and even less spec = designers). 
     
    The = initial question that is asked is very interesting: isn't the design = flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the = fact that is still arguably harder and more error prone to implement. = Fair enough. 
     
    =46rom a spec implementer's = perspective, it may well be more complex. It mostly impacts the json = library you'll end up using, plus a bit of input/output decoration = around it. Even golang provides utilities for this, despite not exactly = being made for this kind of purpose.
    My practical experience implementing it = is that it's not that big a deal. I mean, I wished it could be simpler, = but it's manageable and there are other ways to reach levels of = insurance that it does work as intended (json schema, test cases to = validate the implementation, etc.). Arguably it is still easier from an = implementation perspective than say, json-ld, which is massively used in = the SSI community. 
     
    But = ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the = client libraries won't shoot themselves in the foot?
     
    The = job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation. 
    In turn, = this spec implementer will rely on cryptographic utility libraries that = deals internally with the complexity of their own domain, so that we = don't have to. And here we could launch another HN flame war that starts = with the title "JWT sucks because". Which does have its set of very real = issues but that's beyond the point. 
    Note that = any decent flamewar will be efficiently fueled by people hating medium. = Is it outrageous for blog posts to be behind a paywall? Maybe but it's = even more outrageous to lack consistency, either by not knowing how to = get around a paywall if you're into a hacker punk movement, or on the = contrary by to not paying a subscription if you believe that = surveillance capitalism, to reuse Zuboff's terms, should be = eradicated. 
    What likely seems an unnecessary sidenote tries = to illustrate the point: for Justin it was easier to publish on medium, = because as a blog publisher, you might not want to deal with hosting = your own blog. But maybe as a reader you'll find that annoying. = Different audiences, different JTBD, different tradeoffs. 
     
    Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). = And  there's a lot more to be done to make sure we indeed reduce = the complexity for the end-developer and the end-user. 
     
    If = we find a better way to deal with that simplicity balance, I'm all in. = But the arguments need to be way more convincing than just saying that = it may be difficult to implement or validate. 
     
    Cheers.
    Fabien
     
     
     
     
     
    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = <jricher@mit.edu> a = =C3=A9crit :
     


    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
     
    Justin
     
    I = did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable. 
     
    As = for concrete examples:
    - version of client
    - version = of OS
    - security attestation of OS / device
    - = location of client device
    - network client is operating on
     
    These = are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used.
     
     
    This = is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman:
     
    {
     
     = posture: {
        software_version: 1.2.3,
      =   os_version: 14.3.2
        device_attestation: { =E2=80= =A6 some structure or signed blob? =E2=80=A6 }
      =   location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
      = },
     
     = client: =E2=80=9Cclient-541-ab"
     
    }
     
    This = is a more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.
     
     =E2=80=94 Justin
     


    /Dick
     
    3D"Image=E1=90=A7
     
    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = <jricher@mit.edu> = wrote:
    Dick,
     
    As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.
     
    The crux of my argument is that is = exactly a case of pass-by-reference vs pass-by-value, and that runtime = attestations are not part of the =E2=80=9Cclient instance=E2=80=9D value = itself but rather belong outside of that object in a another part of the = request. As stated in the editorial notes in this section, we need to = look carefully at how these concepts fit within the model and where we = would want to put them. Without concrete examples of what these = extensions look like and how they=E2=80=99re generated, that is nearly = impossible to do at this stage. I look forward to seeing examples of = this kind of data and how it can fit into the protocol.
     
     =E2=80=94 Justin


    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
     
    Hey Justin,
     
    As = the draft has evolved, I question the continued use of polymorphism. = Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value.
     
    In = the current draft, the 
     
    Every time you create or process a field it will = mean only one thing, and there=E2=80=99s only one field to look at to = answer a question. 
     
    is violated in 2.3.1.  Identifying the RC Instance
     
     
       instance_id  An identifier = string that the AS can use to identify the
      =     particular instance of this RC.  The content and = structure of this
          identifier is opaque to the = RC.
     
     =  "client": {
           "instance_id": = "client-541-ab"
       }
     
     =  If there are no additional fields to send, the RC MAY send = the
       instance identifier as a direct reference value = in lieu of the
       object.
     
     =  "client": "client-541-ab"
     
    The instance identifier can be sent two = ways. Polymorphism is a convenience for the client, but requires the = server to have two code paths for "instance_id".  We = discussed this in the design team, and I argued for having "instance_id" = in the "client" object so that any updates, such as new devices = assertions, could be in the "client" object. As noted above, while I = appreciate the elegance of using a string (handle) to reference a = previously provided object, it complicates how to update an existing = object while providing the reference.
     
    In = your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe:
     
    { 
     "key": { 
     =    "proof": "bearer" 
      =   } 
    }
     
    In your example, when processing the = "key" object, code is having to check both the JSON type of the = property, as well as check the value of the "proof" property. In the = example I provided, only the value of "proof" needs to be checked. The = "proof" property is acting as a type for the "key" object.
     
    Not = being a Java programmer, I don't know how this would work in a Java = implementation, but node.js, the processing would need to be done as = above.
     
    On a related note, there was = significant negative feedback on handles and polymorphism in the Hacker = News article https://news.ycombinator.com/item?id=3D24855750 
     
    /Dick
     
     
    On Fri, Oct 23, 2020 at 10:20 AM Justin = Richer <jricher@mit.edu> wrote:
    Hi = Mika,
     
    Thanks= for bringing this topic here =E2=80=94 I was able to see the forum = discussion that brought you here, and hopefully I can help clear up what = I mean with how polymorphism is used in the proposal. The short version = is that the goal is to avoid the kinds of = ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can = help that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems.
     
    Some = background: I built out the XYZ protocol (one of the predecessors to the = initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 
     
    The driving reason for using = polymorphism at the protocol level was to simplify the protocol and make = it :more: deterministic to create and process, not less. Every time you = create or process a field it will mean only one thing, and there=E2=80=99s= only one field to look at to answer a question. Without polymorphic = field values, you usually need to rely on mutual exclusivity of fields, = which is prone to failure and requires additional error checking. Take = for example the key binding of access tokens. An access token could be = bound to the RC=E2=80=99s key used during the request, to a different = key chosen by the AS, or it could be a bearer token with no key at all. = By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it = in terms of boolean values and objects and express this set of = mutually-exclusive options in a non-ambiguous way. Without that, you=E2=80= =99d need to have different fields for the options and include = additional checks in your parser to make sure they weren=E2=80=99t sent = simultaneously, otherwise you could get hit with this potential security = vulnerability in an object:
     
    { 
        key: {
      =     proof: httpsig,
          jwk: { =E2=80=A6 = key value =E2=80=A6 }
        },
      =   bearer_token: true,
        bind_to_rc_key: true
    }
     
    This = would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself.
     
    { 
        key: {
      =     proof: httpsig,
          jwk: { =E2=80=A6 = key value =E2=80=A6 }
        }
    }
     
    // = bearer token
     
    {
        key: false
    }
     
    // = bound to the RC=E2=80=99s presented key
     
    {
      =   key: true
    }
     
    If = someone sends a different type for this field, like an array or number = or a null, this doesn=E2=80=99t have a defined interpretation in the = protocol and would be a protocol level error.
     
    While = it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly = typed, it=E2=80=99s just that there are potentially different types that = express meaning for the field. This applies to all members of all = objects (dictionaries) as well as all members of an array (list). Every = time you process a field value or other element, you look at the type = and then the value to determine what to do with that typed value.
     
    In = your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 
     
    So let=E2=80=99s dig into the specific = bug you bring up in the strawman, because it=E2=80=99s interesting: A = JSON encoder that encodes numbers as strings, and not numbers, is not = compliant with the JSON definitions of the field in question. For = another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is = not equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated the same by a parser implementation when mapping to a = concrete object. It=E2=80=99s in this kind of automated guessing that = this class of bugs occur, and that=E2=80=99s going to be the case = whether or not you take  advantage of JSON=E2=80=99s polymorphic = nature. I=E2=80=99ve run into cases where a parser library was trying to = be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but = ended up introducing errors in more strict components downstream. This = is something that protocol designers need to be aware of and guard = against in the design of the protocol to reduce possible ambiguities. = Within GNAP today, we generally have things that branch whether = they=E2=80=99re an object (for a rich description of something) or some = non-structured special value (for a reference or other item). 
     
    The = design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design = document due to both lack of time to keep it updated with the rapid = changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually.
     
     =E2=80=94 Justin


    On Oct 23, 2020, at = 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:
     
    Hello, everyone.
     
    For = background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and = when I made note about certain concerns, I was requested to send my = comments to this working group.
     
    In = short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July. 
     
    The = problem with polymorphic values, as I see it, is that implementations = will need to branch on the (inferred) type of a given field. This isn't = quite as bad if the types are strictly different, but allows for subtle = bugs when the value in question is a dictionary. What makes this = unappealing is that "subtle bugs" in security protocols have a habit of = turning into vulnerabilities.
     
    Let's = say we have these imaginary payloads, both possible and valid in the = same protocol step:
     
    # payload 1
    {
      = ...,
      "public_key": {
        "alg": "rsa",
        "modulus": <BIGINT>
      = }
    }
     
    # = payload 2
    {
      ...,
      = "public_key": {
        "alg": "rsa",
        "modulus": "<encoded string>"
      = }
    }
     
    In = both cases, the type of "public_key" field is a dictionary. In both = cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum.
     
    While = the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors.
     
    Ambiguity in protocols is always a = source of implementation complexity and interoperability snags, but in = an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum?
     
    Best = regards,
    Mika
     
    -- 
    Mika Bostr=C3=B6m
    Smarkets
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
     
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    3D"Image=E1=90=A7
     
     
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =


    -- 
    Mika = Bostr=C3=B6m
    Smarkets
    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    = --Apple-Mail=_3EF103B0-5445-4396-93F3-5BC6F812BBFF-- From nobody Wed Oct 28 12:55:04 2020 Return-Path: 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 0231B3A044A for ; Wed, 28 Oct 2020 12:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LjflsHQMRRnP for ; Wed, 28 Oct 2020 12:54:57 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431A53A03FA for ; Wed, 28 Oct 2020 12:54:56 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SJsr4N025583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 15:54:54 -0400 From: Justin Richer Message-Id: <4DC27068-923C-471B-B0CA-6A94BA865E6F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_632EE809-3FF2-4F38-9BAD-A80CF074E55E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 15:54:53 -0400 In-Reply-To: <809BDCD6-B71A-463F-8F37-FD177C95B5A5@mit.edu> Cc: Fabien Imbault , =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List , Dick Hardt To: Yaron Sheffer References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <809BDCD6-B71A-463F-8F37-FD177C95B5A5@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 19:55:03 -0000 --Apple-Mail=_632EE809-3FF2-4F38-9BAD-A80CF074E55E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To Yaron=E2=80=99s point on JSON Schema, I just pushed a pull request = that includes a JSON Schema for the main request and response messages = as currently defined in the protocol. I=E2=80=99m sure it=E2=80=99s not = perfect, but it seems to work against both positive and negative = examples that I=E2=80=99ve thrown at it so far, and I=E2=80=99d be glad = to see others play with it and improve it.=20 https://github.com/ietf-wg-gnap/core-protocol/pull/4 A question for the WG, do we want to include this resource as a = non-normative addition to the document? I=E2=80=99m in favor of having = it in there and keeping it updated through protocol changes, as it will = help those who want to use it and can be ignored by those who don=E2=80=99= t care about it. =E2=80=94 Justin > On Oct 28, 2020, at 3:30 PM, Justin Richer wrote: >=20 > Yaron, it=E2=80=99s a good observation on the RC=E2=80=99s = requirements. You are correct that the RC would need to deal with the = =E2=80=9Ckey=E2=80=9D value having potentially different types, but In = this specific case I think it would be naturally limited by a capability = the RC is able to support, or not: >=20 > Either the RC is going to be able to bind the token to an arbitrary = key from the AS (which is when it would see a non-boolean value), or it = won=E2=80=99t be able to do that, in which case it can only expect/read = a boolean there. A general purpose RC library will deal with that = polymorphism, but it would also deal with the polymorphism of the = request language. I would expect a simple client to just reject a = response with an arbitrary key in that field if it doesn=E2=80=99t know = how to handle it. I think it=E2=80=99s a feature that the RC wouldn=E2=80=99= t have to always know about every part of the protocol in order to get = something working in a secure and predictable fashion. >=20 > We could also decide to limit that case in the response in order to = lessen the burden on the RC. As Dick pointed out earlier in the thread, = it wouldn=E2=80=99t be difficult to come up with a syntax to declare = bearer tokens =E2=80=94 and in fact, his proposal aligns with previous = versions of the XYZ Draft. I personally think the syntax is awkward and = has some drawbacks, but it does work for the basic use case of switching = between bearer tokens and server-provided keys. However, the missing = piece is something that I think should become the default in GNAP: = binding the resulting token to the key the client presented during the = request. This aligns with both DPoP and OAuth MTLS methods today, both = of which have been shown to work very well in production. However, = server-provided and server-referenced keys are called for by the OAuth = PoP Architecture documents. These are more complex use cases, to be = sure, but I think it=E2=80=99s possible to support them with relatively = low cost to the rest of the system. >=20 > It=E2=80=99s definitely a tradeoff, but one I think lands closer to = simplicity for a wider array of software implementations and helps get = us away from bearer tokens as a default for the simple case of a client = instance binding to its own key. >=20 > =E2=80=94 Justin >=20 >> On Oct 28, 2020, at 2:47 PM, Yaron Sheffer > wrote: >>=20 >> Hi Fabien, >> =20 >> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is = far worse than the problem. The code in the article you cite is very = specific to the use case and IMHO quite ugly. So my preferred Go = implementation would be a combination of untyped structures (Go = interface{}) and run-time enforcement of JSON Schema. >> =20 >> Also, going back to our earlier discussion on this topic, I just read = Sec. 7 of gnap-00 and realized that the RC also needs to deal with = polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >> =20 >> Thanks, >> Yaron >> =20 >> From: TXAuth > on behalf of Fabien Imbault = > >> Date: Wednesday, October 28, 2020 at 18:56 >> To: Mika Bostr=C3=B6m > >> Cc: GNAP Mailing List >, = Justin Richer >, Dick Hardt = > >> Subject: Re: [GNAP] Feedback on polymorphism >> =20 >> Thanks for the great feedback. Your concern is very valid.=20 >> =20 >> My implementation is in rust, which makes life easier in that = specific case.=20 >> =20 >> So I'm not a golang specialist but I guess the transcription of json = strings/arrays into go structs would work around the lines described by = https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 = >> When we have a more formalized json schema, I suggest we make a = library of json examples and some related code samples in mainstream = languages, to check it is feasible for everyone.=20 >> =20 >> Cheers, >> Fabien >> =20 >> =20 >> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m = > wrote: >>> Hi everyone, >>> =20 >>> Looks like I stuck my finger in a hornets' nest. First off, = apologies for not chipping in earlier, but there was a lot of material = to digest. Also, warning: lots to read ahead. >>> =20 >>> I'm one of those people who end up making use of AuthN/AuthZ = functionality through a library. On top of that I can see myself being = roped in as a server (AS) implementation help. So I'm approaching this = from an outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that. >>> =20 >>> Now, having read Justin's initial reply - and the rest of the thread = - I believe I can see where the desire for polymorphism comes from. To = be clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts. >>> =20 >>> But then the downside. I don't personally expect to be able to use = the reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was >>> =20 >>> { >>> "name": "", >>> "age": , >>> "country": "", >>> "city": "" >>> } >>> =20 >>> .. then the type definition would look like: >>> =20 >>> type Person struct { >>> Name string `json:"name" >>> Age int `json:"age"` >>> Country string `json:"country"` >>> City string `json:"city"` >>> } >>> =20 >>> When the (possibly complex) type of a given field is fixed, = unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed = value, there should be nothing special about that. But when the field = can instead be a union of more than one distinct types, things start to = get messy. There is no union type in the language at all, so the = following construct is not even possible: >>> =20 >>> type Entity struct { >>> Resources []string `json:"resources"` >>> Client union(Client, string) `json:"client"` >>> } >>> =20 >>> As I understand, the implicit expectation is that in the above case, = the unmarshaler detects that "client" is a string, and so expands it = from an opaque handle to the expected, populated type. Even after = thinking about the ramifications over the past few days I remain = confused, because I don't see how the commonly used annotations could = work. If the expectation is that protocol implementations should use = strong types, then the use of polymorphic JSON is very likely to make = things _more_ complicated for non-reference implementations.=20 >>> =20 >>> Hence my concern. I'm afraid that the leaky abstraction, while = making the reference implementation more robust and straightforward, = contributes to making other implementations less robust. And this being = a security protocol, the potential for brittle and/or confused = implementations is terrifying.=20 >>> =20 >>> I am a fan of reducing complexity, and from what I can see, for the = reference implementation the polymorphic approach actually does that. = But I'm afraid it does so at others' expense. Languages have their = individual constraints, idioms and best practices. If parsing a protocol = payload introduces low-level complexities and encourages to go against = common practices, that is an invitation for problems. I am aware that my = choice of words in the HN thread was likely to put people on defense, = and for that I apologise. But I do believe that the choice of = polymorphic JSON is going to make the life and use of other = implementations notably less boring than people in general would prefer. >>> =20 >>> Cheers, >>> Mika >>> =20 >>> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault = > wrote: >>>> Hi Dick, >>>> =20 >>>> Well technically yes. Obviously the client can present any = interface it seems fit.=20 >>>> =20 >>>> Still there's the question of the common model we want to present = to the outside world and supported by the protocol itself (which client = libraries all build upon).=20 >>>> =20 >>>> But beneath the polyphormism question, the HN debate seems on the = surface a lot like the original xyz (polyphormism goes along with the = reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and = where the client design has more latitude). Just explained differently, = by outside people with different agendas.=20 >>>> =20 >>>> Which is a bit weird because many of the critics on HN (who = criticize polyphormism) also seem to really dislike OAuth in the first = place (the inconsistencies are partially due to a bunch of different = people commenting).=20 >>>> =20 >>>> Really to me there's no fundamental truth behind that question. = It's a matter of preference and priorities in the design. Whatever = choices we make, we'll have to be prepared to explain and justify them = in the open, even to some people that will dislike pretty much whatever = we do (because it's fun to look smart and critize without proposing = alternatives). And we owe these answers to people like Mika, who = genuinely try to make the best of it.=20 >>>> =20 >>>> Fabien=20 >>>> =20 >>>> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt > a =C3=A9crit : >>>>> Hi Fabien >>>>> =20 >>>>> A library developer can provide whatever abstraction layer makes = sense for the library's target audience and language. >>>>> =20 >>>>> If the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice versa=20= >>>>> =20 >>>>> =3D> polymorphism in the protocol has no impact on client library = developers >>>>> =20 >>>>> =20 >>>>> =E1=90=A7 >>>>> =20 >>>>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = > wrote: >>>>>> I'm just realizing your "least to most important" might actually = say the same as what I was trying to say. So I'm not even sure what = we're arguing against :-)=20 >>>>>> =20 >>>>>> In brief my point if it wasn't clear is that we should be crystal = clear on where we put the cursor of simplicity, because this can mean = different things for different people and different roles.=20 >>>>>> And as we see on HN we need to better explain our design choices.=20= >>>>>> =20 >>>>>> =20 >>>>>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault = > a =C3=A9crit = : >>>>>>> Hi Dick, >>>>>>> =20 >>>>>>> Independantly from the debate on polyphormism, I beg to differ = on your order preference.=20 >>>>>>> =20 >>>>>>> Your assumption is that AS devs matter the most, because they're = doing the important security implementation. But eating our own dogfood = might help a lot to change that view. Most security issues occur because = users of the spec are unable to deal with the complexity that is passed = onto them.=20 >>>>>>> =20 >>>>>>> 99% of the people that will actually use the output of the work = are application developers (client or RS) and their own users.=20 >>>>>>> =20 >>>>>>> Our intent as well as the protocol drive the usage. Client = libraries may help, but they're not a silver bullet, especially because = GNAP ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >>>>>>> =20 >>>>>>> I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >>>>>>> =20 >>>>>>> Fabien=20 >>>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt = > a =C3=A9crit : >>>>>>>> I'm confused by your logic Fabien. >>>>>>>> =20 >>>>>>>> If a client library developer wants to expose polymorphism, = they can do that independent of what is in the protocol.=20 >>>>>>>> =20 >>>>>>>> I differ on who our stakeholders are.=20 >>>>>>>> =20 >>>>>>>> I think our stakeholders are in least to most important: >>>>>>>> =20 >>>>>>>> AS developer >>>>>>>> RS developer >>>>>>>> client developer >>>>>>>> user >>>>>>>> =20 >>>>>>>> A client library developer can expose whatever interface they = want to simplify implementation. >>>>>>>> =20 >>>>>>>> I list the user so that we don't lose site of a critical role. >>>>>>>> =20 >>>>>>>> /Dick >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =E1=90=A7 >>>>>>>> =20 >>>>>>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: >>>>>>>>> Hi there,=20 >>>>>>>>> =20 >>>>>>>>> Let me try to approach the issue under a different light. More = like a product manager would deal with feature selection to make it = intuitive for its users.=20 >>>>>>>>> =20 >>>>>>>>> For most people, riding a bike is far easier than using a = unicycle. Feels more stable. And yet it's way easier to design for a = single wheel than to build with 2. Because then you'll need a lot more = accessories (chain, chain ring, etc.). Even so producing a bike doesn't = have to be a brittle process, it can be industrialized.=20 >>>>>>>>> =20 >>>>>>>>> Back to the GNAP topic.=20 >>>>>>>>> Ultimately we should strive to make the spec as simple as can = be. But we need to ask: simple for whom? For the bike owner or for the = bike vendor?=20 >>>>>>>>> (short answer: the priority should be simplicity for spec = users, not spec implementers and even less spec designers).=20 >>>>>>>>> =20 >>>>>>>>> The initial question that is asked is very interesting: isn't = the design flawed if GNAP is using json polyphormism? Or if the AS needs = to handle the state of the request? Or if we must handle token = revocation? Or if we are looking for a global unique identifier? The = argument stems of the fact that is still arguably harder and more error = prone to implement. Fair enough.=20 >>>>>>>>> =20 >>>>>>>>> =46rom a spec implementer's perspective, it may well be more = complex. It mostly impacts the json library you'll end up using, plus a = bit of input/output decoration around it. Even golang provides utilities = for this, despite not exactly being made for this kind of purpose. >>>>>>>>> My practical experience implementing it is that it's not that = big a deal. I mean, I wished it could be simpler, but it's manageable = and there are other ways to reach levels of insurance that it does work = as intended (json schema, test cases to validate the implementation, = etc.). Arguably it is still easier from an implementation perspective = than say, json-ld, which is massively used in the SSI community.=20 >>>>>>>>> =20 >>>>>>>>> But ultimately who are we designing for? Are we striving to go = easy on the spec implementer? Or are we trying to make sure = end-developers using the client libraries won't shoot themselves in the = foot? >>>>>>>>> =20 >>>>>>>>> The job to be done (JTBD), from the end-developer's = perspective, is to efficiently ship an application. And provide = authN/authZ capabilities for end-users by relying on some well known = implementation.=20 >>>>>>>>> In turn, this spec implementer will rely on cryptographic = utility libraries that deals internally with the complexity of their own = domain, so that we don't have to. And here we could launch another HN = flame war that starts with the title "JWT sucks because". Which does = have its set of very real issues but that's beyond the point.=20 >>>>>>>>> Note that any decent flamewar will be efficiently fueled by = people hating medium. Is it outrageous for blog posts to be behind a = paywall? Maybe but it's even more outrageous to lack consistency, either = by not knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 >>>>>>>>> What likely seems an unnecessary sidenote tries to illustrate = the point: for Justin it was easier to publish on medium, because as a = blog publisher, you might not want to deal with hosting your own blog. = But maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >>>>>>>>> =20 >>>>>>>>> Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >>>>>>>>> =20 >>>>>>>>> If we find a better way to deal with that simplicity balance, = I'm all in. But the arguments need to be way more convincing than just = saying that it may be difficult to implement or validate.=20 >>>>>>>>> =20 >>>>>>>>> Cheers. >>>>>>>>> Fabien >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = > a =C3=A9crit : >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt = > wrote: >>>>>>>>>>> =20 >>>>>>>>>>> Justin >>>>>>>>>>> =20 >>>>>>>>>>> I did note that I was the one that argued for instance_id = being in the object. Since it is in the object in the current draft, not = including a pass by reference option would be preferable.=20 >>>>>>>>>>> =20 >>>>>>>>>>> As for concrete examples: >>>>>>>>>>> - version of client >>>>>>>>>>> - version of OS >>>>>>>>>>> - security attestation of OS / device >>>>>>>>>>> - location of client device >>>>>>>>>>> - network client is operating on >>>>>>>>>>> =20 >>>>>>>>>>> These are all attributes of the client that an AS may = require on the initial grant request, and in future grant requests = (which is when an instance_id) would be used. >>>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> This is where our interpretations differ: I don=E2=80=99t see = these as =E2=80=9Cattributes of the client=E2=80=9D in the same way that = the key, display information, class identifiers, and other items = currently represented by an instance_id are attributes of the client = instance. The attestation components don=E2=80=99t modify the instance = so much as present additional information on top of the client instance = itself. This is why I argue that they ought to be handled in a separate = object, so you=E2=80=99d have something like this strawman: >>>>>>>>>> =20 >>>>>>>>>> { >>>>>>>>>> =20 >>>>>>>>>> posture: { >>>>>>>>>> software_version: 1.2.3, >>>>>>>>>> os_version: 14.3.2 >>>>>>>>>> device_attestation: { =E2=80=A6 some structure or signed = blob? =E2=80=A6 } >>>>>>>>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 = } >>>>>>>>>> }, >>>>>>>>>> =20 >>>>>>>>>> client: =E2=80=9Cclient-541-ab" >>>>>>>>>> =20 >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> This is a more fundamental question about GNAP than whether = the syntax uses polymorphism: this is about GNAP being very explicit = about the data model of its elements. OAuth 2=E2=80=99s incredibly loose = and broad model of what the term =E2=80=9Cclient=E2=80=9D is referring = to, exactly, is deeply problematic in practice. We=E2=80=99re even = seeing that in the OAuth 2.1 work with having to define a = =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t = fully capture the different aspects that are out there. I think we=E2=80=99= re getting closer here in GNAP with explicit definition of =E2=80=9Cclient= instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >>>>>>>>>> =20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> /Dick >>>>>>>>>>> =20 >>>>>>>>>>> =E1=90=A7 >>>>>>>>>>> =20 >>>>>>>>>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = > wrote: >>>>>>>>>>>> Dick, >>>>>>>>>>>> =20 >>>>>>>>>>>> As you=E2=80=99ll recall, I argued against including the = client instance identifier inside of the object as a mutually-exclusive = field precisely because of the principle violation that you are pointing = out here, and so it=E2=80=99s important to point out that the current = text is a compromise that needs to be examined in the wider experience = of the working group. I am on the side of removing the = mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an = object, but this needs to be explored. >>>>>>>>>>>> =20 >>>>>>>>>>>> The crux of my argument is that is exactly a case of = pass-by-reference vs pass-by-value, and that runtime attestations are = not part of the =E2=80=9Cclient instance=E2=80=9D value itself but = rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look = carefully at how these concepts fit within the model and where we would = want to put them. Without concrete examples of what these extensions = look like and how they=E2=80=99re generated, that is nearly impossible = to do at this stage. I look forward to seeing examples of this kind of = data and how it can fit into the protocol. >>>>>>>>>>>> =20 >>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt = > wrote: >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Hey Justin, >>>>>>>>>>>>> =20 >>>>>>>>>>>>> As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> In the current draft, the=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question.=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> is violated in 2.3.1.=C2=A0 Identifying the RC Instance = >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>>> instance_id An identifier string that the AS can use = to identify the >>>>>>>>>>>>>> particular instance of this RC. The content and = structure of this >>>>>>>>>>>>>> identifier is opaque to the RC. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> "client": { >>>>>>>>>>>>>> "instance_id": "client-541-ab" >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> If there are no additional fields to send, the RC MAY = send the >>>>>>>>>>>>>> instance identifier as a direct reference value in = lieu of the >>>>>>>>>>>>>> object. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> "client": "client-541-ab" >>>>>>>>>>>>> =20 >>>>>>>>>>>>> The instance identifier can be sent two ways. Polymorphism = is a convenience for the client, but requires the server to have two = code paths for "instance_id". We discussed this in the design team, and = I argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> In your example of the "key" object below, setting "proof" = to bearer would avoid the issue you describe: >>>>>>>>>>>>> =20 >>>>>>>>>>>>> {=20 >>>>>>>>>>>>> "key": {=20 >>>>>>>>>>>>> "proof": "bearer"=20 >>>>>>>>>>>>> }=20 >>>>>>>>>>>>> } >>>>>>>>>>>>> =20 >>>>>>>>>>>>> In your example, when processing the "key" object, code is = having to check both the JSON type of the property, as well as check the = value of the "proof" property. In the example I provided, only the value = of "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Not being a Java programmer, I don't know how this would = work in a Java implementation, but node.js, the processing would need to = be done as above. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> On a related note, there was significant negative feedback = on handles and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> /Dick >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer = > wrote: >>>>>>>>>>>>>> Hi Mika, >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Thanks for bringing this topic here =E2=80=94 I was able = to see the forum discussion that brought you here, and hopefully I can = help clear up what I mean with how polymorphism is used in the proposal. = The short version is that the goal is to avoid the kinds of ambiguity = that make insecure protocols, and so in that goal we=E2=80=99re fully = aligned. I think that using polymorphism in very specific ways can help = that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Some background: I built out the XYZ protocol (one of the = predecessors to the initial GNAP Draft) in Java using strongly typed = parsers and Java objects specifically to prove to myself that it could = be done in a way that made any sense in the code. (My own open source = implementation is at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> The driving reason for using polymorphism at the protocol = level was to simplify the protocol and make it :more: deterministic to = create and process, not less. Every time you create or process a field = it will mean only one thing, and there=E2=80=99s only one field to look = at to answer a question. Without polymorphic field values, you usually = need to rely on mutual exclusivity of fields, which is prone to failure = and requires additional error checking. Take for example the key binding = of access tokens. An access token could be bound to the RC=E2=80=99s key = used during the request, to a different key chosen by the AS, or it = could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> {=20 >>>>>>>>>>>>>> key: { >>>>>>>>>>>>>> proof: httpsig, >>>>>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>>>>> }, >>>>>>>>>>>>>> bearer_token: true, >>>>>>>>>>>>>> bind_to_rc_key: true >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> This would be an illegal object as per this alternate = proposal, but then you=E2=80=99d have to check each field and make sure = it wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve = done this exercise with many other protocols and it=E2=80=99s both error = prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples = would pass code that doesn=E2=80=99t check this. With the polymorphic = approach to this same field, each of these three mutually-exclusive = states is written in a way that they cannot be sent together. It=E2=80=99s= not just illegal, it=E2=80=99s impossible and enforced by the syntax of = JSON itself. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> {=20 >>>>>>>>>>>>>> key: { >>>>>>>>>>>>>> proof: httpsig, >>>>>>>>>>>>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> // bearer token >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> { >>>>>>>>>>>>>> key: false >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> // bound to the RC=E2=80=99s presented key >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> { >>>>>>>>>>>>>> key: true >>>>>>>>>>>>>> } >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> If someone sends a different type for this field, like an = array or number or a null, this doesn=E2=80=99t have a defined = interpretation in the protocol and would be a protocol level error. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> While it might sound like polymorphism means that any = field could have any type or value, the opposite is true: each possible = value is explicitly typed, it=E2=80=99s just that there are potentially = different types that express meaning for the field. This applies to all = members of all objects (dictionaries) as well as all members of an array = (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed = value. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> In your example below, each field within the dictionary = would also need to be typed, and each type would need to have a clear = indication of its meaning. To take your strawman key format below, the = =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically as = either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded = string=E2=80=9D (a JSON string). The definition would further say what = exactly the encoding of the string would be. That means that when you = read the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any = confusion on what the value was or how it was represented, regardless of = the input format. Seeing a number there means exactly one interpretation = and seeing a string means exactly one (different) interpretation =E2=80=94= but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since = that=E2=80=99s the field that determines the type. An implementation = would likely use an internal BigInteger type of object to represent the = field value after parsing, so the question is how to go from the JSON = value (which is typed) into the BigInteger value.You don=E2=80=99t just = apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you = apply it to all sub-fields of that object.=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> So let=E2=80=99s dig into the specific bug you bring up = in the strawman, because it=E2=80=99s interesting: A JSON encoder that = encodes numbers as strings, and not numbers, is not compliant with the = JSON definitions of the field in question. For another example, the = quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the = same by a parser implementation when mapping to a concrete object. = It=E2=80=99s in this kind of automated guessing that this class of bugs = occur, and that=E2=80=99s going to be the case whether or not you take = advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into = cases where a parser library was trying to be overly =E2=80=9Chelpful=E2=80= =9D in doing this kind of mapping, but ended up introducing errors in = more strict components downstream. This is something that protocol = designers need to be aware of and guard against in the design of the = protocol to reduce possible ambiguities. Within GNAP today, we generally = have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a = reference or other item).=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> The design team created some simple JSON Schemas for = parts of the protocol during our discussion, but we didn=E2=80=99t = include them in the design document due to both lack of time to keep it = updated with the rapid changes to the protocol during the design team = discussion, and not knowing if there would be interest in such material. = I personally think it would be helpful to include as an informative = reference in the final document, but that=E2=80=99s something for the = working group to take up eventually. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> Hello, everyone. >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a = discussion forum and when I made note about certain concerns, I was = requested to send my comments to this working group. >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> In short, I believe that the use of polymorphic JSON in = the protocol invites subtle and confusing implementation problems. I = also searched through the WG archives, and noticed that similar concerns = were noted, briefly, in a thread in July.=20 >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> The problem with polymorphic values, as I see it, is = that implementations will need to branch on the (inferred) type of a = given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into vulnerabilities. >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> Let's say we have these imaginary payloads, both = possible and valid in the same protocol step: >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> # payload 1 >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> ..., >>>>>>>>>>>>>>> "public_key": { >>>>>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>>>>> "modulus": >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> # payload 2 >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> ..., >>>>>>>>>>>>>>> "public_key": { >>>>>>>>>>>>>>> "alg": "rsa", >>>>>>>>>>>>>>> "modulus": "" >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> In both cases, the type of "public_key" field is a = dictionary. In both cases, they even have the same keys. However, the = values in the dictionaries are entirely different, and an implementation = will have to branch to at least two possible decoding mechanisms. To = make things worse, some JSON implementations may choose to encode = non-dictionary values as strings, so it is possible for an originator to = transmit what they expect and believe to be payload 1 format, but which = the receiver will interpret to be in payload 2 format. And if the = encoded string contains only digits, it will even parse correctly as a = bignum. >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> While the above is clearly a manufactured scenario, it = nonetheless demonstrates the potential for logic bugs with polymorphic = JSON. With richer types and more complex dictionaries, there will surely = be more room for errors. >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> Ambiguity in protocols is always a source of = implementation complexity and interoperability snags, but in an = AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum? >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Mika >>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> Mika Bostr=C3=B6m >>>>>>>>>>>>>>> Smarkets >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> TXAuth mailing list >>>>>>>>>>>>>> TXAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>>>>>> =E1=90=A7 >>>>>>>>>>>>=20 >>>>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> TXAuth mailing list >>>>>>>>>> TXAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>>=20 >>> --=20 >>> Mika Bostr=C3=B6m >>> Smarkets >>=20 >> -- TXAuth mailing list TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_632EE809-3FF2-4F38-9BAD-A80CF074E55E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = Yaron=E2=80=99s point on JSON Schema, I just pushed a pull request that = includes a JSON Schema for the main request and response messages as = currently defined in the protocol. I=E2=80=99m sure it=E2=80=99s not = perfect, but it seems to work against both positive and negative = examples that I=E2=80=99ve thrown at it so far, and I=E2=80=99d be glad = to see others play with it and improve it. 

    https://github.com/ietf-wg-gnap/core-protocol/pull/4
    <= div class=3D"">
    A = question for the WG, do we want to include this resource as a = non-normative addition to the document? I=E2=80=99m in favor of having = it in there and keeping it updated through protocol changes, as it will = help those who want to use it and can be ignored by those who don=E2=80=99= t care about it.

     =E2=80=94 Justin

    On Oct = 28, 2020, at 3:30 PM, Justin Richer <jricher@mit.edu> wrote:

    Yaron, it=E2=80=99s a = good observation on the RC=E2=80=99s requirements. You are correct that = the RC would need to deal with the =E2=80=9Ckey=E2=80=9D value having = potentially different types, but In this specific case I think it would = be naturally limited by a capability the RC is able to support, or = not:

    Either the RC = is going to be able to bind the token to an arbitrary = key from the AS (which is when it would see a non-boolean value), or = it won=E2=80=99t be able to do that, in which case it can only = expect/read a boolean there. A general purpose RC library will deal with = that polymorphism, but it would also deal with the polymorphism of the = request language. I would expect a simple client to just reject a = response with an arbitrary key in that field if it doesn=E2=80=99t know = how to handle it. I think it=E2=80=99s a feature that the RC wouldn=E2=80=99= t have to always know about every part of the protocol in order to get = something working in a secure and predictable fashion.

    We could also decide to = limit that case in the response in order to lessen the burden on the RC. = As Dick pointed out earlier in the thread, it wouldn=E2=80=99t be = difficult to come up with a syntax to declare bearer tokens =E2=80=94 = and in fact, his proposal aligns with previous versions of the XYZ = Draft. I personally think the syntax is awkward and has some drawbacks, = but it does work for the basic use case of switching between bearer = tokens and server-provided keys. However, the missing piece is something = that I think should become the default in GNAP: binding = the resulting token to the key the client presented during the = request. This aligns with both DPoP and OAuth MTLS methods today, both = of which have been shown to work very well in production. However, = server-provided and server-referenced keys are called for by the OAuth = PoP Architecture documents. These are more complex use cases, to be = sure, but I think it=E2=80=99s possible to support them with relatively = low cost to the rest of the system.

    It=E2=80=99s definitely a tradeoff, but = one I think lands closer to simplicity for a wider array of software = implementations and helps get us away from bearer tokens as a default = for the simple case of a client instance binding to its own = key.

     =E2=80= =94 Justin

    On Oct 28, 2020, at 2:47 PM, = Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,
     
    At least in the case of = Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than the = problem. The code in the article you cite is very specific to the use = case and IMHO quite ugly. So my preferred Go implementation would be a = combination of untyped structures (Go interface{}) and run-time = enforcement of JSON Schema.
     
    Also, going back to our earlier discussion on = this topic, I just read Sec. 7 of gnap-00 and realized that the RC also = needs to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D value), not = only the AS.
     
    Thanks,
              &nb= sp;     Yaron
     
    From: TXAuth <txauth-bounces@ietf.org> = on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, October 28, = 2020 at 18:56
    To: Mika Bostr=C3=B6m = <mika.bostrom@smarkets.com>
    Cc: GNAP = Mailing List <txauth@ietf.org>, = Justin Richer <jricher@mit.edu>, = Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback on = polymorphism
     
    Thanks for the great feedback. Your = concern is very valid. 
     
    My = implementation is in rust, which makes life easier in that specific = case. 
     
    So I'm not a golang specialist but I = guess the transcription of json strings/arrays into go structs would = work around the lines described by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58= ed1
    When we have a more formalized json schema, I = suggest we make a library of json examples and some related code samples = in mainstream languages, to check it is feasible for everyone. 
     
    Cheers,
    Fabien
     
     
    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m = <mika.bostrom@smarkets.com> = wrote:
    Hi everyone,
     
    Looks = like I stuck my finger in a hornets' nest. First off, apologies for not = chipping in earlier, but there was a lot of material to digest. Also, = warning: lots to read ahead.
     
    I'm = one of those people who end up making use of AuthN/AuthZ functionality = through a library. On top of that I can see myself being roped in as a = server (AS) implementation help. So I'm approaching this from an = outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that.
     
    Now, = having read Justin's initial reply - and the rest of the thread - I = believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts.
     
    But = then the downside. I don't personally expect to be able to use the = reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was
     
    {
      = "name": "<string>",
      "age": <int>,
      = "country": "<string>",
      "city": "<string>"
    }
     
    .. = then the type definition would look like:
     
    type = Person struct {
      Name string `json:"name"
      = Age int `json:"age"`
      Country string `json:"country"`
      = City string `json:"city"`
    }
     
    When = the (possibly complex) type of a given field is fixed, unmarshaling = should still be straightforward. I haven't verified, but since the = annotation only gives which field to look at for a given typed value, = there should be nothing special about that. But when the field can = instead be a union of more than one distinct types, things start to get = messy. There is no union type in the language at all, so the following = construct is not even possible:
     
    type = Entity struct {
      Resources []string `json:"resources"`
      = Client union(Client, string) `json:"client"`
    }
     
    As I = understand, the implicit expectation is that in the above case, the = unmarshaler detects that "client" is a string, and so expands it from an = opaque handle to the expected, populated type. Even after thinking about = the ramifications over the past few days I remain confused, because I = don't see how the commonly used annotations could work. If the = expectation is that protocol implementations should use strong types, = then the use of polymorphic JSON is very likely to make things _more_ = complicated for non-reference implementations. 
     
    Hence my concern. = I'm afraid that the leaky abstraction, while making the reference = implementation more robust and straightforward, contributes to making = other implementations less robust. And this being a security protocol, = the potential for brittle and/or confused implementations is = terrifying. 
     
    I am = a fan of reducing complexity, and from what I can see, for the reference = implementation the polymorphic approach actually does that. But I'm = afraid it does so at others' expense. Languages have their individual = constraints, idioms and best practices. If parsing a protocol payload = introduces low-level complexities and encourages to go against common = practices, that is an invitation for problems. I am aware that my choice = of words in the HN thread was likely to put people on defense, and for = that I apologise. But I do believe that the choice of polymorphic JSON = is going to make the life and use of other implementations notably less = boring than people in general would prefer.
     
    Cheers,
    Mika
     
    On Mon, 26 Oct 2020 at = 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Dick,
     
    Well = technically yes. Obviously the client can present any interface it seems = fit. 
     
    Still there's the question of the = common model we want to present to the outside world and supported by = the protocol itself (which client libraries all build upon). 
     
    But = beneath the polyphormism question, the HN debate seems on the surface a = lot like the original xyz (polyphormism goes along with the reduced = endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where = the client design has more latitude). Just explained differently, by = outside people with different agendas. 
     
    Which = is a bit weird because many of the critics on HN (who criticize = polyphormism) also seem to really dislike OAuth in the first place (the = inconsistencies are partially due to a bunch of different people = commenting). 
     
    Really to me there's no fundamental = truth behind that question. It's a matter of preference and priorities = in the design. Whatever choices we make, we'll have to be prepared to = explain and justify them in the open, even to some people that will = dislike pretty much whatever we do (because it's fun to look smart and = critize without proposing alternatives). And we owe these answers to = people like Mika, who genuinely try to make the best of it. 
     
    Fabien 
     
    Le lun. 26 oct. 2020 =C3=A0 = 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    Hi = Fabien
     
    A = library developer can provide whatever abstraction layer makes sense for = the library's target audience and language.
     
    If = the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice = versa 
     
    =3D> polymorphism in the protocol = has no impact on client library developers
     
     
    3D"Image=E1=90=A7
     
    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    I'm = just realizing your "least to most important" might actually say the = same as what I was trying to say. So I'm not even sure what we're = arguing against :-) 
     
    In brief my point if it wasn't clear is = that we should be crystal clear on where we put the cursor of = simplicity, because this can mean different things for different people = and different roles. 
    And as we see on HN we need to better = explain our design choices. 
     
     
    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien = Imbault <fabien.imbault@gmail.com> a =C3=A9crit :
    Hi = Dick,
     
    Independantly from the debate on polyphormism, I beg to = differ on your order preference. 
     
    Your = assumption is that AS devs matter the most, because they're doing the important = security implementation. But eating our own dogfood might help a lot to = change that view. Most security issues occur because users of the spec = are unable to deal with the complexity that is passed onto = them. 
     
    99% of the people that will actually = use the output of the work are application developers (client or RS) and = their own users. 
     
    Our intent as well = as the protocol drive the usage. Client libraries may help, but they're = not a silver bullet, especially because GNAP ultimately has no control = about what people do there (for better or worse). And everything we do = here will help get to the better part. 
     
    I'm = not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a = tendancy we're leaning towards by default, I'm pretty sure we won't = forget that anyway. 
     
    Fabien 
     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick = Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    I'm = confused by your logic Fabien.
     
    If a = client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol. 
     
    I = differ on who our stakeholders are. 
     
    I = think our stakeholders are in least to most important:
     
    • AS developer
    • RS developer
    • client developer
    • user
     
    A = client library developer can expose whatever interface they want to = simplify implementation.
     
    I = list the user so that we don't lose site of a critical role.
     
    /Dick
     
     
    3D"Image=E1=90=A7
     
    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    Hi there, 
     
    Let me try to = approach the issue under a different light. More like a product manager = would deal with feature selection to make it intuitive for its = users. 
     
    For most people, riding a = bike is far easier than using a unicycle. Feels more stable. And yet = it's way easier to design for a single wheel than to build with 2. = Because then you'll need a lot more accessories (chain, chain ring, = etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized. 
     
    Back = to the GNAP topic. 
    Ultimately we should strive to make the spec as simple as can = be. But we need to ask: simple for whom? For the bike owner or for the = bike vendor? 
    (short answer: the priority should be simplicity = for spec users, not spec implementers and even less spec = designers). 
     
    The = initial question that is asked is very interesting: isn't the design = flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the = fact that is still arguably harder and more error prone to implement. = Fair enough. 
     
    =46rom a spec implementer's = perspective, it may well be more complex. It mostly impacts the json = library you'll end up using, plus a bit of input/output decoration = around it. Even golang provides utilities for this, despite not exactly = being made for this kind of purpose.
    My practical experience implementing it = is that it's not that big a deal. I mean, I wished it could be simpler, = but it's manageable and there are other ways to reach levels of = insurance that it does work as intended (json schema, test cases to = validate the implementation, etc.). Arguably it is still easier from an = implementation perspective than say, json-ld, which is massively used in = the SSI community. 
     
    But = ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the = client libraries won't shoot themselves in the foot?
     
    The = job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation. 
    In turn, = this spec implementer will rely on cryptographic utility libraries that = deals internally with the complexity of their own domain, so that we = don't have to. And here we could launch another HN flame war that starts = with the title "JWT sucks because". Which does have its set of very real = issues but that's beyond the point. 
    Note that = any decent flamewar will be efficiently fueled by people hating medium. = Is it outrageous for blog posts to be behind a paywall? Maybe but it's = even more outrageous to lack consistency, either by not knowing how to = get around a paywall if you're into a hacker punk movement, or on the = contrary by to not paying a subscription if you believe that = surveillance capitalism, to reuse Zuboff's terms, should be = eradicated. 
    What likely seems an unnecessary sidenote tries = to illustrate the point: for Justin it was easier to publish on medium, = because as a blog publisher, you might not want to deal with hosting = your own blog. But maybe as a reader you'll find that annoying. = Different audiences, different JTBD, different tradeoffs. 
     
    Polyphormism is a tool that enables the end-developer to have = minimal knowledge of what it means to deal with a GNAP client library. = You prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). = And  there's a lot more to be done to make sure we indeed reduce = the complexity for the end-developer and the end-user. 
     
    If = we find a better way to deal with that simplicity balance, I'm all in. = But the arguments need to be way more convincing than just saying that = it may be difficult to implement or validate. 
     
    Cheers.
    Fabien
     
     
     
     
     
    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer = <jricher@mit.edu> a = =C3=A9crit :
     


    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
     
    Justin
     
    I = did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable. 
     
    As = for concrete examples:
    - version of client
    - version = of OS
    - security attestation of OS / device
    - = location of client device
    - network client is operating on
     
    These = are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used.
     
     
    This = is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman:
     
    {
     
     = posture: {
        software_version: 1.2.3,
      =   os_version: 14.3.2
        device_attestation: { =E2=80= =A6 some structure or signed blob? =E2=80=A6 }
      =   location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }
      = },
     
     = client: =E2=80=9Cclient-541-ab"
     
    }
     
    This = is a more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.
     
     =E2=80=94 Justin
     


    /Dick
     
    3D"Image=E1=90=A7
     
    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = <jricher@mit.edu> = wrote:
    Dick,
     
    As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.
     
    The crux of my argument is that is = exactly a case of pass-by-reference vs pass-by-value, and that runtime = attestations are not part of the =E2=80=9Cclient instance=E2=80=9D value = itself but rather belong outside of that object in a another part of the = request. As stated in the editorial notes in this section, we need to = look carefully at how these concepts fit within the model and where we = would want to put them. Without concrete examples of what these = extensions look like and how they=E2=80=99re generated, that is nearly = impossible to do at this stage. I look forward to seeing examples of = this kind of data and how it can fit into the protocol.
     
     =E2=80=94 Justin


    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
     
    Hey Justin,
     
    As = the draft has evolved, I question the continued use of polymorphism. = Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value.
     
    In = the current draft, the 
     
    Every time you create or process a field it will = mean only one thing, and there=E2=80=99s only one field to look at to = answer a question. 
     
    is violated in 2.3.1.  Identifying the RC Instance
     
     
       instance_id  An identifier = string that the AS can use to identify the
      =     particular instance of this RC.  The content and = structure of this
          identifier is opaque to the = RC.
     
     =  "client": {
           "instance_id": = "client-541-ab"
       }
     
     =  If there are no additional fields to send, the RC MAY send = the
       instance identifier as a direct reference value = in lieu of the
       object.
     
     =  "client": "client-541-ab"
     
    The instance identifier can be sent two = ways. Polymorphism is a convenience for the client, but requires the = server to have two code paths for "instance_id".  We = discussed this in the design team, and I argued for having "instance_id" = in the "client" object so that any updates, such as new devices = assertions, could be in the "client" object. As noted above, while I = appreciate the elegance of using a string (handle) to reference a = previously provided object, it complicates how to update an existing = object while providing the reference.
     
    In = your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe:
     
    { 
     "key": { 
     =    "proof": "bearer" 
      =   } 
    }
     
    In your example, when processing the = "key" object, code is having to check both the JSON type of the = property, as well as check the value of the "proof" property. In the = example I provided, only the value of "proof" needs to be checked. The = "proof" property is acting as a type for the "key" object.
     
    Not = being a Java programmer, I don't know how this would work in a Java = implementation, but node.js, the processing would need to be done as = above.
     
    On a related note, there was = significant negative feedback on handles and polymorphism in the Hacker = News article https://news.ycombinator.com/item?id=3D24855750 
     
    /Dick
     
     
    On Fri, Oct 23, 2020 at 10:20 AM Justin = Richer <jricher@mit.edu> wrote:
    Hi = Mika,
     
    Thanks= for bringing this topic here =E2=80=94 I was able to see the forum = discussion that brought you here, and hopefully I can help clear up what = I mean with how polymorphism is used in the proposal. The short version = is that the goal is to avoid the kinds of = ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can = help that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems.
     
    Some = background: I built out the XYZ protocol (one of the predecessors to the = initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 
     
    The driving reason for using = polymorphism at the protocol level was to simplify the protocol and make = it :more: deterministic to create and process, not less. Every time you = create or process a field it will mean only one thing, and there=E2=80=99s= only one field to look at to answer a question. Without polymorphic = field values, you usually need to rely on mutual exclusivity of fields, = which is prone to failure and requires additional error checking. Take = for example the key binding of access tokens. An access token could be = bound to the RC=E2=80=99s key used during the request, to a different = key chosen by the AS, or it could be a bearer token with no key at all. = By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it = in terms of boolean values and objects and express this set of = mutually-exclusive options in a non-ambiguous way. Without that, you=E2=80= =99d need to have different fields for the options and include = additional checks in your parser to make sure they weren=E2=80=99t sent = simultaneously, otherwise you could get hit with this potential security = vulnerability in an object:
     
    { 
        key: {
      =     proof: httpsig,
          jwk: { =E2=80=A6 = key value =E2=80=A6 }
        },
      =   bearer_token: true,
        bind_to_rc_key: true
    }
     
    This = would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself.
     
    { 
        key: {
      =     proof: httpsig,
          jwk: { =E2=80=A6 = key value =E2=80=A6 }
        }
    }
     
    // = bearer token
     
    {
        key: false
    }
     
    // = bound to the RC=E2=80=99s presented key
     
    {
      =   key: true
    }
     
    If = someone sends a different type for this field, like an array or number = or a null, this doesn=E2=80=99t have a defined interpretation in the = protocol and would be a protocol level error.
     
    While = it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly = typed, it=E2=80=99s just that there are potentially different types that = express meaning for the field. This applies to all members of all = objects (dictionaries) as well as all members of an array (list). Every = time you process a field value or other element, you look at the type = and then the value to determine what to do with that typed value.
     
    In = your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its = meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2=80= =9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 
     
    So let=E2=80=99s dig into the specific = bug you bring up in the strawman, because it=E2=80=99s interesting: A = JSON encoder that encodes numbers as strings, and not numbers, is not = compliant with the JSON definitions of the field in question. For = another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is = not equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated the same by a parser implementation when mapping to a = concrete object. It=E2=80=99s in this kind of automated guessing that = this class of bugs occur, and that=E2=80=99s going to be the case = whether or not you take  advantage of JSON=E2=80=99s polymorphic = nature. I=E2=80=99ve run into cases where a parser library was trying to = be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but = ended up introducing errors in more strict components downstream. This = is something that protocol designers need to be aware of and guard = against in the design of the protocol to reduce possible ambiguities. = Within GNAP today, we generally have things that branch whether = they=E2=80=99re an object (for a rich description of something) or some = non-structured special value (for a reference or other item). 
     
    The = design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design = document due to both lack of time to keep it updated with the rapid = changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually.
     
     =E2=80=94 Justin


    On Oct 23, 2020, at = 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> = wrote:
     
    Hello, everyone.
     
    For = background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and = when I made note about certain concerns, I was requested to send my = comments to this working group.
     
    In = short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July. 
     
    The = problem with polymorphic values, as I see it, is that implementations = will need to branch on the (inferred) type of a given field. This isn't = quite as bad if the types are strictly different, but allows for subtle = bugs when the value in question is a dictionary. What makes this = unappealing is that "subtle bugs" in security protocols have a habit of = turning into vulnerabilities.
     
    Let's = say we have these imaginary payloads, both possible and valid in the = same protocol step:
     
    # payload 1
    {
      = ...,
      "public_key": {
        "alg": "rsa",
        "modulus": <BIGINT>
      = }
    }
     
    # = payload 2
    {
      ...,
      = "public_key": {
        "alg": "rsa",
        "modulus": "<encoded string>"
      = }
    }
     
    In = both cases, the type of "public_key" field is a dictionary. In both = cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum.
     
    While = the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors.
     
    Ambiguity in protocols is always a = source of implementation complexity and interoperability snags, but in = an AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum?
     
    Best = regards,
    Mika
     
    -- 
    Mika Bostr=C3=B6m
    Smarkets
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
     
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    3D"Image=E1=90=A7
     
     
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    =


    -- 
    Mika = Bostr=C3=B6m
    Smarkets
    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    = --Apple-Mail=_632EE809-3FF2-4F38-9BAD-A80CF074E55E-- From nobody Wed Oct 28 12:58:04 2020 Return-Path: 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 2F39A3A064A for ; Wed, 28 Oct 2020 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 EF2i2xSNsl94 for ; Wed, 28 Oct 2020 12:57:56 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 69B973A0A88 for ; Wed, 28 Oct 2020 12:57:51 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id x20so660293ilj.8 for ; Wed, 28 Oct 2020 12:57:51 -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=g4lWuFMatihARjkbjWu4vsTXCaJ1WaFXPA0mwbr9lwI=; b=bllnjE7buRE4/cEKOmMu3tms/Zxwd9s7F4799PTn41QcO4hBRzlvElnunXtu0LWu2o M514hm9vRkOyF5z7xMT2o/VRY4ig+2bTlaDCUtmm0TBqd+MZVAKZSIlpJ52/AHZWI6h3 C4MBkww0kgWUraeg2l2TJvBnMPSc1pioQ+ltIjpmwwY1VNzK2YpMRzyHYKkKoWLEKaLm c3SH9Wm4KX+K7QY6BW4WCZR/H9zJglOLCVvY/WW8ExXJ0duXi1q3rJZigMuu08SGSJNy In8PYsO4lCircM5Fl2GJwG4OAMsmkrIAN1YgDYsppXbmgnQX0Po99XMlHZyFm/QEhzJo 7Peg== 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=g4lWuFMatihARjkbjWu4vsTXCaJ1WaFXPA0mwbr9lwI=; b=S/VfYFMM1ehUGf+ohCNEafskifHbpcZmlHEd7su2dUBvmekfwP4FfXk5SWoErIwa9O cGvqXmYL9MCn0y2EvrkfTvueN6sRhcA2RDxIjk9hOG5z8H4aRJqQWqsm8qAs5grog0nm j/ykRt7wxwOkAUWkYhUJAVpEbsvMvArfZ7YI6rJgnRmTjUC37/wHr6yzghct6lJZej1A 6rqXDbtnID1rzDRBMwJD3uPlfKbW6Q8BDcaewNVCFceDbWgAaE4UvvxcXelbDHF1Jpms pGHFtO+4y1n+GkolUa8cbO6zzWxJCRpAK3mVDowLPXGyaHZRoxre3khEGXlD4G1IaDWh kP3w== X-Gm-Message-State: AOAM531CLkV+UYdxuq4sNbLdZ98T9OQAO8MzDNSE0ixRgAmqyXIgiN+i sJlcRop79qYkHQgUkkS5Zi95qycAAp5UlRzftqo= X-Google-Smtp-Source: ABdhPJy4Tc0RXvyMPHCfBXoa9pdPHvDoI4mg/RJeUViVMlXrXXhmvB4m52uZhiSaRNuH4CMours/KLLUCucvA+fWQ88= X-Received: by 2002:a92:9106:: with SMTP id t6mr634121ild.178.1603915070421; Wed, 28 Oct 2020 12:57:50 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 28 Oct 2020 20:57:37 +0100 Message-ID: To: Yaron Sheffer Cc: =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="00000000000005c28d05b2c094d9" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 19:58:02 -0000 --00000000000005c28d05b2c094d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, We'll indeed have to check how make it as idiomatic as possible with experts of each language (help welcome). Regarding the client, the variations are more limited but they do exist. Here I believe it's much more problematic than on the server side and there are at least a few actions we should take: A) check in sec 7 if we really have a compelling reason for key and proof variants. This is derived from larger discussions on key binding as per the related note. There are quite a few open questions related to this theme. B) there is also the choice between value/reference that may generate complexity. C) More generally, as many feedbacks already have noticed, we need to have a systematic review and reduce the set of available options in the protocol. Unless we have a clear idea why runtime behavior requires mutability, it might be useful to have a way to define the chosen variant before hand, so that the expected behavior becomes deterministic on the client side. There are various ways it could be done in practice. For sure several independant implementations would help, especially if we make sure they can work together. Anyway all this open to improvement. Cheers Fabien Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer a =C3=A9crit : > Hi Fabien, > > > > At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far= worse than the > problem. The code in the article you cite is very specific to the use cas= e > and IMHO quite ugly. So my preferred Go implementation would be a > combination of untyped structures (Go interface{}) and run-time enforceme= nt > of JSON Schema. > > > > Also, going back to our earlier discussion on this topic, I just read Sec= . > 7 of gnap-00 and realized that the RC also needs to deal with polymorphis= m > (the =E2=80=9Ckey=E2=80=9D value), not only the AS. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Wednesday, October 28, 2020 at 18:56 > *To: *Mika Bostr=C3=B6m > *Cc: *GNAP Mailing List , Justin Richer , > Dick Hardt > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Thanks for the great feedback. Your concern is very valid. > > > > My implementation is in rust, which makes life easier in that specific > case. > > > > So I'm not a golang specialist but I guess the transcription of json > strings/arrays into go structs would work around the lines described by > https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 > > When we have a more formalized json schema, I suggest we make a library o= f > json examples and some related code samples in mainstream languages, to > check it is feasible for everyone. > > > > Cheers, > > Fabien > > > > > > On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m > wrote: > > Hi everyone, > > > > Looks like I stuck my finger in a hornets' nest. First off, apologies for > not chipping in earlier, but there was a lot of material to digest. Also, > warning: lots to read ahead. > > > > I'm one of those people who end up making use of AuthN/AuthZ functionalit= y > through a library. On top of that I can see myself being roped in as a > server (AS) implementation help. So I'm approaching this from an outsider= 's > perspective. Someone who expects to be exposed to the eventual RFC and al= l > the nitty-gritty details. My relatively terse comment ended up at the top > of the aforementioned HN thread, which didn't necessarily help. Sorry abo= ut > that. > > > > Now, having read Justin's initial reply - and the rest of the thread - I > believe I can see where the desire for polymorphism comes from. To be > clear: I am all for strict types inside an implementation, as it will add > helpful guard-rails to the state management code paths. However, I see th= is > as a case of leaky abstraction. If we take the existing oauth.xyj-java co= de > to be the reference implementation, the choice makes logical sense: JSON = is > not expressive enough to serialise arbitrary objects, so in order to avoi= d > writing complex payload parser(s) the internal implementation details now > leak to the protocol itself. From a purely technical perspective, it's a > cool trick. From a distance it even looks a bit like the result of protob= uf > decoding, but without the generated code parts. > > > > But then the downside. I don't personally expect to be able to use the > reference implementation, being mostly a Python user myself. A fair numbe= r > of AS implementations will be written with languages such as Go, Python, > C#, Ruby, and JavaScript (thanks to node.js), and all of them will have t= o > deal with the polymorphism. From what I've read over the past couple of > days, I understand that at least Go supports custom unmarshalers from JSO= N > to typed structs, at the cost of an indirection. Normally when a Go code > processes JSON to a typed struct, the process is helped by field > annotations in the type definition itself. For example, if the payload fo= r > a person in JSON was > > > > { > > "name": "", > > "age": , > > "country": "", > > "city": "" > > } > > > > .. then the type definition would look like: > > > > type Person struct { > > Name string `json:"name" > > Age int `json:"age"` > > Country string `json:"country"` > > City string `json:"city"` > > } > > > > When the (possibly complex) type of a given field is fixed, unmarshaling > should still be straightforward. I haven't verified, but since the > annotation only gives which field to look at for a given typed value, the= re > should be nothing special about that. But when the field can instead be a > union of more than one distinct types, things start to get messy. There i= s > no union type in the language at all, so the following construct is not > even possible: > > > > type Entity struct { > > Resources []string `json:"resources"` > > Client union(Client, string) `json:"client"` > > } > > > > As I understand, the implicit expectation is that in the above case, the > unmarshaler detects that "client" is a string, and so expands it from an > opaque handle to the expected, populated type. Even after thinking about > the ramifications over the past few days I remain confused, because I don= 't > see how the commonly used annotations could work. If the expectation is > that protocol implementations should use strong types, then the use of > polymorphic JSON is very likely to make things _more_ complicated for > non-reference implementations. > > > > Hence my concern. I'm afraid that the leaky abstraction, while making the > reference implementation more robust and straightforward, contributes to > making other implementations less robust. And this being a security > protocol, the potential for brittle and/or confused implementations is > terrifying. > > > > I am a fan of reducing complexity, and from what I can see, for the > reference implementation the polymorphic approach actually does that. But > I'm afraid it does so at others' expense. Languages have their individual > constraints, idioms and best practices. If parsing a protocol payload > introduces low-level complexities and encourages to go against common > practices, that is an invitation for problems. I am aware that my choice = of > words in the HN thread was likely to put people on defense, and for that = I > apologise. But I do believe that the choice of polymorphic JSON is going = to > make the life and use of other implementations notably less boring than > people in general would prefer. > > > > Cheers, > > Mika > > > > On Mon, 26 Oct 2020 at 02:04, Fabien Imbault > wrote: > > Hi Dick, > > > > Well technically yes. Obviously the client can present any interface it > seems fit. > > > > Still there's the question of the common model we want to present to the > outside world and supported by the protocol itself (which client librarie= s > all build upon). > > > > But beneath the polyphormism question, the HN debate seems on the surface > a lot like the original xyz (polyphormism goes along with the reduced > endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where the > client design has more latitude). Just explained differently, by outside > people with different agendas. > > > > Which is a bit weird because many of the critics on HN (who criticize > polyphormism) also seem to really dislike OAuth in the first place (the > inconsistencies are partially due to a bunch of different people > commenting). > > > > Really to me there's no fundamental truth behind that question. It's a > matter of preference and priorities in the design. Whatever choices we > make, we'll have to be prepared to explain and justify them in the open, > even to some people that will dislike pretty much whatever we do (because > it's fun to look smart and critize without proposing alternatives). And w= e > owe these answers to people like Mika, who genuinely try to make the best > of it. > > > > Fabien > > > > Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : > > Hi Fabien > > > > A library developer can provide whatever abstraction layer makes sense fo= r > the library's target audience and language. > > > > If the client library developer wants to use polymorphism in the interfac= e > presented to the user's of the library, the library developer can do that > independent of polymorphism in the protocol, and vice versa > > > > =3D> polymorphism in the protocol has no impact on client library develop= ers > > > > > > [image: Image removed by sender.]=E1=90=A7 > > > > On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault > wrote: > > I'm just realizing your "least to most important" might actually say the > same as what I was trying to say. So I'm not even sure what we're arguing > against :-) > > > > In brief my point if it wasn't clear is that we should be crystal clear o= n > where we put the cursor of simplicity, because this can mean different > things for different people and different roles. > > And as we see on HN we need to better explain our design choices. > > > > > > Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a > =C3=A9crit : > > Hi Dick, > > > > Independantly from the debate on polyphormism, I beg to differ on your > order preference. > > > > Your assumption is that AS devs matter the most, because they're doing > the important security implementation. But eating our own dogfood might > help a lot to change that view. Most security issues occur because users = of > the spec are unable to deal with the complexity that is passed onto them. > > > > 99% of the people that will actually use the output of the work are > application developers (client or RS) and their own users. > > > > Our intent as well as the protocol drive the usage. Client libraries may > help, but they're not a silver bullet, especially because GNAP ultimately > has no control about what people do there (for better or worse). And > everything we do here will help get to the better part. > > > > I'm not saying we don't intend to also care about AS developers (beginnin= g > with ourselves) but it's a second order optimisation. And since it's a > tendancy we're leaning towards by default, I'm pretty sure we won't forge= t > that anyway. > > > > Fabien > > > > > > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : > > I'm confused by your logic Fabien. > > > > If a client library developer wants to expose polymorphism, they can do > that independent of what is in the protocol. > > > > I differ on who our stakeholders are. > > > > I think our stakeholders are in least to most important: > > > > - AS developer > - RS developer > - client developer > - user > > > > A client library developer can expose whatever interface they want to > simplify implementation. > > > > I list the user so that we don't lose site of a critical role. > > > > /Dick > > > > > > [image: Image removed by sender.]=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault > wrote: > > Hi there, > > > > Let me try to approach the issue under a different light. More like a > product manager would deal with feature selection to make it intuitive fo= r > its users. > > > > For most people, riding a bike is far easier than using a unicycle. Feels > more stable. And yet it's way easier to design for a single wheel than to > build with 2. Because then you'll need a lot more accessories (chain, cha= in > ring, etc.). Even so producing a bike doesn't have to be a brittle proces= s, > it can be industrialized. > > > > Back to the GNAP topic. > > Ultimately we should strive to make the spec as simple as can be. But we > need to ask: simple for whom? For the bike owner or for the bike vendor? > > (short answer: the priority should be simplicity for spec users, not spec > implementers and even less spec designers). > > > > The initial question that is asked is very interesting: isn't the design > flawed if GNAP is using json polyphormism? Or if the AS needs to handle t= he > state of the request? Or if we must handle token revocation? Or if we are > looking for a global unique identifier? The argument stems of the fact th= at > is still arguably harder and more error prone to implement. Fair enough. > > > > From a spec implementer's perspective, it may well be more complex. It > mostly impacts the json library you'll end up using, plus a bit of > input/output decoration around it. Even golang provides utilities for thi= s, > despite not exactly being made for this kind of purpose. > > My practical experience implementing it is that it's not that big a deal. > I mean, I wished it could be simpler, but it's manageable and there are > other ways to reach levels of insurance that it does work as intended (js= on > schema, test cases to validate the implementation, etc.). Arguably it is > still easier from an implementation perspective than say, json-ld, which = is > massively used in the SSI community. > > > > But ultimately who are we designing for? Are we striving to go easy on th= e > spec implementer? Or are we trying to make sure end-developers using the > client libraries won't shoot themselves in the foot? > > > > The job to be done (JTBD), from the end-developer's perspective, is to > efficiently ship an application. And provide authN/authZ capabilities for > end-users by relying on some well known implementation. > > In turn, this spec implementer will rely on cryptographic utility > libraries that deals internally with the complexity of their own domain, = so > that we don't have to. And here we could launch another HN flame war that > starts with the title "JWT sucks because". Which does have its set of ver= y > real issues but that's beyond the point. > > Note that any decent flamewar will be efficiently fueled by people hating > medium. Is it outrageous for blog posts to be behind a paywall? Maybe but > it's even more outrageous to lack consistency, either by not knowing how = to > get around a paywall if you're into a hacker punk movement, or on the > contrary by to not paying a subscription if you believe that surveillance > capitalism, to reuse Zuboff's terms, should be eradicated. > > What likely seems an unnecessary sidenote tries to illustrate the point: > for Justin it was easier to publish on medium, because as a blog publishe= r, > you might not want to deal with hosting your own blog. But maybe as a > reader you'll find that annoying. Different audiences, different JTBD, > different tradeoffs. > > > > Polyphormism is a tool that enables the end-developer to have minimal > knowledge of what it means to deal with a GNAP client library. You prepar= e > the request, send to the endpoint and you're good to go. Massively simple= r > than OAuth2 or any similar protocol by the way (as anyone with teaching > experience on the subject might acknowledge). And there's a lot more to = be > done to make sure we indeed reduce the complexity for the end-developer a= nd > the end-user. > > > > If we find a better way to deal with that simplicity balance, I'm all in. > But the arguments need to be way more convincing than just saying that it > may be difficult to implement or validate. > > > > Cheers. > > Fabien > > > > > > > > > > > > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : > > > > > > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: > > > > Justin > > > > I did note that I was the one that argued for instance_id being in the > object. Since it is in the object in the current draft, not including a > pass by reference option would be preferable. > > > > As for concrete examples: > > - version of client > > - version of OS > > - security attestation of OS / device > > - location of client device > > - network client is operating on > > > > These are all attributes of the client that an AS may require on the > initial grant request, and in future grant requests (which is when an > instance_id) would be used. > > > > > > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes > of the client=E2=80=9D in the same way that the key, display information,= class > identifiers, and other items currently represented by an instance_id are > attributes of the client instance. The attestation components don=E2=80= =99t modify > the instance so much as present additional information on top of the clie= nt > instance itself. This is why I argue that they ought to be handled in a > separate object, so you=E2=80=99d have something like this strawman: > > > > { > > > > posture: { > > software_version: 1.2.3, > > os_version: 14.3.2 > > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > > }, > > > > client: =E2=80=9Cclient-541-ab" > > > > } > > > > This is a more fundamental question about GNAP than whether the syntax > uses polymorphism: this is about GNAP being very explicit about the data > model of its elements. OAuth 2=E2=80=99s incredibly loose and broad model= of what > the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pro= blematic in > practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to > define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture > the different aspects that are out there. I think we=E2=80=99re getting c= loser here > in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, bu= t we still need to > be more precise about what exactly a client instance includes, and what i= t > does not. > > > > =E2=80=94 Justin > > > > > > /Dick > > > > [image: Image removed by sender.]=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > > Dick, > > > > As you=E2=80=99ll recall, I argued against including the client instance > identifier inside of the object as a mutually-exclusive field precisely > because of the principle violation that you are pointing out here, and so > it=E2=80=99s important to point out that the current text is a compromise= that > needs to be examined in the wider experience of the working group. I am o= n > the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D= option within an > object, but this needs to be explored. > > > > The crux of my argument is that is exactly a case of pass-by-reference vs > pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient > instance=E2=80=9D value itself but rather belong outside of that object i= n a > another part of the request. As stated in the editorial notes in this > section, we need to look carefully at how these concepts fit within the > model and where we would want to put them. Without concrete examples of > what these extensions look like and how they=E2=80=99re generated, that i= s nearly > impossible to do at this stage. I look forward to seeing examples of this > kind of data and how it can fit into the protocol. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: > > > > Hey Justin, > > > > As the draft has evolved, I question the continued use of polymorphism. > Note that I appreciate the elegance of using a string for > pass-by-reference, and an object for pass-by-value. > > > > In the current draft, the > > > > Every time you create or process a field it will mean only one thing, and > there=E2=80=99s only one field to look at to answer a question. > > > > is violated in 2.3.1. Identifying the RC Instance > > > > > > > instance_id An identifier string that the AS can use to identify the > > particular instance of this RC. The content and structure of this > > identifier is opaque to the RC. > > > > "client": { > > "instance_id": "client-541-ab" > > } > > > > If there are no additional fields to send, the RC MAY send the > > instance identifier as a direct reference value in lieu of the > > object. > > > > "client": "client-541-ab" > > > > The instance identifier can be sent two ways. Polymorphism is a > convenience for the client, but requires the server to have two code path= s > for "instance_id". We discussed this in the design team, and I argued fo= r > having "instance_id" in the "client" object so that any updates, such as > new devices assertions, could be in the "client" object. As noted above, > while I appreciate the elegance of using a string (handle) to reference a > previously provided object, it complicates how to update an existing obje= ct > while providing the reference. > > > > In your example of the "key" object below, setting "proof" to bearer woul= d > avoid the issue you describe: > > > > { > "key": { > "proof": "bearer" > } > } > > > > In your example, when processing the "key" object, code is having to chec= k > both the JSON type of the property, as well as check the value of the > "proof" property. In the example I provided, only the value of "proof" > needs to be checked. The "proof" property is acting as a type for the "ke= y" > object. > > > > Not being a Java programmer, I don't know how this would work in a Java > implementation, but node.js, the processing would need to be done as abov= e. > > > > On a related note, there was significant negative feedback on handles and > polymorphism in the Hacker News article > https://news.ycombinator.com/item?id=3D24855750 > > > > /Dick > > > > > > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > > Hi Mika, > > > > Thanks for bringing this topic here =E2=80=94 I was able to see the forum > discussion that brought you here, and hopefully I can help clear up what = I > mean with how polymorphism is used in the proposal. The short version is > that the goal is to *avoid* the kinds of ambiguity that make insecure > protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using > polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree > that misusing it or applying it sloppily can lead to ambiguous and insecu= re > systems. > > > > Some background: I built out the XYZ protocol (one of the predecessors to > the initial GNAP Draft) in Java using strongly typed parsers and Java > objects specifically to prove to myself that it could be done in a way th= at > made any sense in the code. (My own open source implementation is at > https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not ye= t up to > date with the GNAP spec). It was important to me that I be able to use th= e > system-wide configured parsers to implement this and not have to resort t= o > stepping through elements completely by hand. Java doesn=E2=80=99t make i= t simple > to get the hooks into the right places (especially with the Jackson parse= r > that I used), but it is definitely possible to create a deterministic and > strongly-typed parser and serializer for this kind of data structure. Som= e > of the rationale for using polymorphism is covered in the trailing append= ix > of the draft document ( > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), > but it=E2=80=99s still good to discuss this here as the working group dec= ides which > approaches to take. > > > > The driving reason for using polymorphism at the protocol level was to > simplify the protocol and make it :more: deterministic to create and > process, not less. Every time you create or process a field it will mean > only one thing, and there=E2=80=99s only one field to look at to answer a= question. > Without polymorphic field values, you usually need to rely on mutual > exclusivity of fields, which is prone to failure and requires additional > error checking. Take for example the key binding of access tokens. An > access token could be bound to the RC=E2=80=99s key used during the reque= st, to a > different key chosen by the AS, or it could be a bearer token with no key > at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of > boolean values and objects and express this set of mutually-exclusive > options in a non-ambiguous way. Without that, you=E2=80=99d need to have = different > fields for the options and include additional checks in your parser to ma= ke > sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with > this potential security vulnerability in an object: > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > }, > > bearer_token: true, > > bind_to_rc_key: true > > } > > > > This would be an illegal object as per this alternate proposal, but then > you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others > in the same object. I=E2=80=99ve done this exercise with many other proto= cols and > it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cg= ood=E2=80=9D examples > would pass code that doesn=E2=80=99t check this. With the polymorphic app= roach to > this same field, each of these three mutually-exclusive states is written > in a way that they cannot be sent together. It=E2=80=99s not just illegal= , it=E2=80=99s > impossible and enforced by the syntax of JSON itself. > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > } > > } > > > > // bearer token > > > > { > > key: false > > } > > > > // bound to the RC=E2=80=99s presented key > > > > { > > key: true > > } > > > > If someone sends a different type for this field, like an array or number > or a null, this doesn=E2=80=99t have a defined interpretation in the prot= ocol and > would be a protocol level error. > > > > While it might sound like polymorphism means that any field could have an= y > type or value, the opposite is true: each possible value is explicitly > typed, it=E2=80=99s just that there are potentially different types that = express > meaning for the field. This applies to all members of all objects > (dictionaries) as well as all members of an array (list). Every time you > process a field value or other element, you look at the type and then the > value to determine what to do with that typed value. > > > > In your example below, each field within the dictionary would also need t= o > be typed, and each type would need to have a clear indication of its > meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could > be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON n= umber) or an > =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would fu= rther say what > exactly the encoding of the string would be. That means that when you rea= d > the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was > or how it was represented, regardless of the input format. Seeing a numbe= r > there means exactly one interpretation and seeing a string means exactly > one (different) interpretation =E2=80=94 but importantly, both of them ar= e a > =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines= the type. An > implementation would likely use an internal BigInteger type of object to > represent the field value after parsing, so the question is how to go fro= m > the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just > apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply= it to all > sub-fields of that object. > > > > So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because > it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings,= and not > numbers, is not compliant with the JSON definitions of the field in > question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not > equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t = be treated > the same by a parser implementation when mapping to a concrete object. It= =E2=80=99s > in this kind of automated guessing that this class of bugs occur, and > that=E2=80=99s going to be the case whether or not you take advantage of= JSON=E2=80=99s > polymorphic nature. I=E2=80=99ve run into cases where a parser library wa= s trying > to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but= ended up > introducing errors in more strict components downstream. This is somethin= g > that protocol designers need to be aware of and guard against in the desi= gn > of the protocol to reduce possible ambiguities. Within GNAP today, we > generally have things that branch whether they=E2=80=99re an object (for = a rich > description of something) or some non-structured special value (for a > reference or other item). > > > > The design team created some simple JSON Schemas for parts of the protoco= l > during our discussion, but we didn=E2=80=99t include them in the design d= ocument > due to both lack of time to keep it updated with the rapid changes to the > protocol during the design team discussion, and not knowing if there woul= d > be interest in such material. I personally think it would be helpful to > include as an informative reference in the final document, but that=E2=80= =99s > something for the working group to take up eventually. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < > mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: > > > > Hello, everyone. > > > > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and > when I made note about certain concerns, I was requested to send my > comments to this working group. > > > > In short, I believe that the use of polymorphic JSON in the protocol > invites subtle and confusing implementation problems. I also searched > through the WG archives, and noticed that similar concerns were noted, > briefly, in a thread in July. > > > > The problem with polymorphic values, as I see it, is that implementations > will need to branch on the (inferred) type of a given field. This isn't > quite as bad if the types are strictly different, but allows for subtle > bugs when the value in question is a dictionary. What makes this > unappealing is that "subtle bugs" in security protocols have a habit of > turning into vulnerabilities. > > > > Let's say we have these imaginary payloads, both possible and valid in th= e > same protocol step: > > > > # payload 1 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": > > } > > } > > > > # payload 2 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": "" > > } > > } > > > > In both cases, the type of "public_key" field is a dictionary. In both > cases, they even have the same keys. However, the values in the > dictionaries are entirely different, and an implementation will have to > branch to at least two possible decoding mechanisms. To make things worse= , > some JSON implementations may choose to encode non-dictionary values as > strings, so it is possible for an originator to transmit what they expect > and believe to be payload 1 format, but which the receiver will interpret > to be in payload 2 format. And if the encoded string contains only digits= , > it will even parse correctly as a bignum. > > > > While the above is clearly a manufactured scenario, it nonetheless > demonstrates the potential for logic bugs with polymorphic JSON. With > richer types and more complex dictionaries, there will surely be more roo= m > for errors. > > > > Ambiguity in protocols is always a source of implementation complexity an= d > interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's > terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it > be in everyone's interest to keep implementation complexity and mistake > potential to a minimum? > > > > Best regards, > > Mika > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > [image: Image removed by sender.]=E1=90=A7 > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000005c28d05b2c094d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Yaron,

    We= 'll indeed have to check how make it as idiomatic as possible with expe= rts of each language (help welcome).=C2=A0

    Regarding the client, the variations are more limited bu= t they do exist. Here I believe it's much more problematic than on the = server side and there are at least a few actions we should take:

    A) check in sec 7 if we really hav= e a compelling reason for key and proof variants. This is derived from larg= er discussions on key binding as per the related note. There are quite a fe= w open questions related to this theme.=C2=A0

    B) there is also the choice between value/reference t= hat may generate complexity.=C2=A0

    C) More generally, as many feedbacks already have noticed, we ne= ed to have a systematic review and reduce the set of available options in t= he protocol.=C2=A0

    Unless we have a clear idea why runtime b= ehavior requires mutability, it might be useful to have a way to define the= chosen variant before hand, so that the expected behavior becomes determin= istic on the client side. There are various ways it could be done in practi= ce.=C2=A0

    For= sure several independant implementations would help, especially if we make= sure they can work together.=C2=A0

    Anyway all this open to improvement.=C2=A0

    Cheers=C2=A0
    Fabien= =C2=A0


    Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer <= ;yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:

    Hi Fabien,<= /u>

    =C2=A0

    At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far= worse than the problem. The code in the article you cite is very specific = to the use case and IMHO quite ugly. So my preferred Go implementation woul= d be a combination of untyped structures (Go interface{}) and run-time enfo= rcement of JSON Schema.

    =C2= =A0

    Also, going back to our earlier discus= sion on this topic, I just read Sec. 7 of gnap-00 and realized that the RC = also needs to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D value), not= only the AS.

    =C2=A0<= /p>

    Thanks,

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Yaron

    =C2=A0=

    From: TXAuth <txauth-bounces@ietf.org> on behalf of = Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Wednesday, October 28, 2020 at 18:56
    To: Mika Bostr=C3= =B6m <mika.bostrom@smarkets.com>
    Cc: = GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail= .com>
    Subject: Re: [GNAP] Feedback on polymorphism<= u>

    =C2=A0

    =

    Thanks for the great feedback. Your conce= rn is very valid.=C2=A0

    <= u>=C2=A0

    My implementation = is in rust, which makes life easier in that specific case.=C2=A0<= /u>

    =C2=A0

    Hi everyone,<= u>

    =C2=A0

    <= div>

    Looks like I stuck my finger in a hornets' n= est. First off, apologies for not chipping in earlier, but there was a lot = of material to digest. Also, warning: lots to read ahead.

    =

    =C2=A0

    I'm one of those people who end up making use of AuthN= /AuthZ functionality through a library. On top of that I can see myself bei= ng roped in as a server (AS) implementation help. So I'm approaching th= is from an outsider's perspective. Someone who expects to be exposed to= the eventual RFC and all the nitty-gritty details. My relatively terse com= ment ended up at the top of the aforementioned HN thread, which didn't = necessarily help. Sorry about that.

    =C2=A0

    Now, = having read Justin's initial reply - and the rest of the thread - I bel= ieve I can see where the desire for polymorphism comes from. To be clear: I= am all for strict types inside an implementation, as it will add helpful g= uard-rails to the state management code paths. However, I see this as a cas= e of leaky abstraction. If we take the existing oauth.xyj-java code to be t= he reference implementation, the choice makes logical sense: JSON is not ex= pressive enough to serialise arbitrary objects, so in order to avoid writin= g complex payload parser(s) the internal implementation details now leak to= the protocol itself. From a purely technical perspective, it's a cool = trick. From a distance it even looks a bit like the result of protobuf deco= ding, but without the generated code parts.

    =C2=A0

    But then the downside. I don't personally expect to be able to use t= he reference implementation, being mostly a Python user myself. A fair numb= er of AS implementations will be written with languages such as Go, Python,= C#, Ruby, and JavaScript (thanks to node.js), and all of them will have to= deal with the polymorphism. From what I've read over the past couple o= f days, I understand that at least Go supports custom unmarshalers from JSO= N to typed structs, at the cost of an indirection. Normally when a Go code = processes JSON to a typed struct, the process is helped by field annotation= s in the type definition itself. For example, if the payload for a person i= n JSON was

    =C2=A0=

    {

    =

    =C2=A0 "name": "<string>",=

    =C2=A0 "age":= <int>,

    =C2=A0 &qu= ot;country": "<string>",

    <= p class=3D"MsoNormal">=C2=A0 "city": "<string>"

    }

    =

    =C2=A0

    .. then the type definition would look like:

    =C2=A0

    type Person struct {

    =C2=A0 Name string `json:"name"

    =C2=A0 Age int `json:"age"`<= u>

    =C2=A0 Country string `json:&qu= ot;country"`

    =C2=A0= City string `json:"city"`

    }

    = =C2=A0

    When the (possibly compl= ex) type of a given field is fixed, unmarshaling should still be straightfo= rward. I haven't verified, but since the annotation only gives which fi= eld to look at for a given typed value, there should be nothing special abo= ut that. But when the field can instead be a union of more than one distinc= t types, things start to get messy. There is no union type in the language = at all, so the following construct is not even possible:

    <= /div>

    =C2=A0

    type Entity struct {

    =C2=A0 Resources []string `json:"resources"`

    =C2=A0 Client union(Client, s= tring) `json:"client"`

    }

    =C2=A0=

    As I understand, the implicit = expectation is that in the above case, the unmarshaler detects that "c= lient" is a string, and so expands it from an opaque handle to the exp= ected, populated type. Even after thinking about the ramifications over the= past few days I remain confused, because I don't see how the commonly = used annotations could work. If the expectation is that protocol implementa= tions should use strong types, then the use of polymorphic JSON is very lik= ely to make things _more_ complicated for non-reference implementations.

    =C2=A0

    <= /div>

    Hence my concern. I'm afraid that the leaky= abstraction, while making the reference implementation more robust and str= aightforward, contributes to making other implementations less robust. And = this being a security protocol, the potential for brittle and/or confused i= mplementations is terrifying.

    =C2=A0

    I am a fan of re= ducing complexity, and from what I can see, for the reference implementatio= n the polymorphic approach actually does that. But I'm afraid it does s= o at others' expense. Languages have their individual constraints, idio= ms and best practices. If parsing a protocol payload introduces low-level c= omplexities and encourages to go against common practices, that is an invit= ation for problems. I am aware that my choice of words in the HN thread was= likely to put people on defense, and for that I apologise. But I do believ= e that the choice of polymorphic JSON is going to make the life and use of = other implementations notably less boring than people in general would pref= er.

    =C2=A0=

    Cheers,

    <= p class=3D"MsoNormal">Mika

    =C2=A0

    On Mon, 26 Oct= 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.co= m> wrote:

    Hi Dick,

    =C2=A0

    Well technically yes. Obviously the client can present any interface= it seems fit.=C2=A0

    = =C2=A0

    Still there's th= e question of the common model we want to present to the outside world and = supported by the protocol itself (which client libraries all build upon).= =C2=A0

    =C2=A0<= /u>

    But beneath the polyphormism quest= ion, the HN debate seems on the surface a lot like the original xyz (polyph= ormism goes along with the reduced endpoint model) vs xauth (a bit closer t= o OAuth2 in spirit, and where the client design has more latitude). Just ex= plained differently, by outside people with different agendas.=C2=A0=

    =C2=A0

    =

    Which is a bit weird because many of the critic= s on HN (who criticize polyphormism) also seem to really dislike OAuth in t= he first place (the inconsistencies are partially due to a bunch of differe= nt people commenting).=C2=A0

    =C2=A0

    Really to me= there's no fundamental truth behind that question. It's a matter o= f preference and priorities in the design. Whatever choices we make, we'= ;ll have to be prepared to explain and justify them in the open, even to so= me people that will dislike pretty much whatever we do (because it's fu= n to look smart and critize without proposing alternatives). And we owe the= se answers to people like Mika, who genuinely try to make the best of it.= =C2=A0

    =C2=A0<= /u>

    Fabien=C2=A0

    =C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

    =

    Hi Fabien

    =C2=A0

    A library developer can provide = whatever abstraction layer makes sense for the library's target=C2=A0au= dience and language.

    = =C2=A0

    If the client librar= y=C2=A0developer wants to use polymorphism=C2=A0in the interface presented = to the user's of the library, the library developer can do that indepen= dent of polymorphism in the protocol, and vice versa=C2=A0

    =C2=A0

    =3D> polymorphism in the protocol has no impact on cli= ent library developers

    <= u>=C2=A0

    =C2=A0

    3D"Image=E1=90=A7

    = =C2=A0

    On Sat, Oct 24, 2020 at 3= :40 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:

    I'm just realizing your "lea= st to most important" might actually say the same as what I was trying= to say. So I'm not even sure what we're arguing against :-)=C2=A0<= u>

    =C2=A0

    =

    In brief my point if it wasn't clear is tha= t we should be crystal clear on where we put the cursor of simplicity, beca= use this can mean different things for different people and different roles= .=C2=A0

    And as we see on= HN we need to better explain our design choices.=C2=A0

    =C2=A0

    =C2=A0

    Le= dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault <fabien= .imbault@gmail.com> a =C3=A9crit=C2=A0:

    = Hi Dick,

    =C2=A0<= /p>

    Independantly from the debate on polyp= hormism, I beg to differ on your order preference.=C2=A0

    <= /div>

    =C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're doi= ng the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users of= the spec are unable to deal with the complexity that is passed onto them.= =C2=A0

    =C2= =A0

    99% of the people that will= actually use the output of the work are application developers (client or = RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the pr= otocol drive the usage. Client libraries may help, but they're not a si= lver bullet, especially because GNAP ultimately has no control about what p= eople do there (for better or worse). And everything we do here will help g= et to the better part.=C2=A0

    =C2=A0

    I'= ;m not saying we don't intend to also care about AS developers (beginni= ng with ourselves) but it's a second order optimisation. And since it&#= 39;s a tendancy we're leaning towards by default, I'm pretty sure w= e won't forget that anyway.=C2=A0

    =C2=A0

    Fabien=C2=A0

    = =C2=A0

    =C2=A0

    Le sam. 24= oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

    =C2= =A0

    Hi there,=C2=A0

    =C2=A0

    Let me try to approach the issue under a different light. More like= a product manager would deal with feature selection to make it intuitive f= or its users.=C2=A0

    =C2= =A0

    For most people, ridin= g a bike is far easier than using a unicycle. Feels more stable. And yet it= 's way easier to design for a single wheel than to build with 2. Becaus= e then you'll need a lot more accessories (chain, chain ring, etc.). Ev= en so producing a bike doesn't have to be a brittle process, it can be = industrialized.=C2=A0

    =C2=A0

    Back to the GNAP to= pic.=C2=A0

    Ultimately we should strive to make t= he spec as simple as can be. But we need to ask: simple for whom? For the b= ike owner or for the bike vendor?=C2=A0

    =

    (short answer: the priority should be simplicity for spec users, not s= pec implementers and even less spec designers).=C2=A0<= /p>

    =C2=A0

    The initial question that is asked is very interesting:= isn't the design flawed if GNAP is using json polyphormism? Or if the = AS needs to handle the state of the request? Or if we must handle token rev= ocation? Or if we are looking for a global unique identifier? The argument = stems of the fact that is still arguably harder and more error prone to imp= lement. Fair enough.=C2=A0

    =C2=A0

    From a spec im= plementer's perspective, it may well be more complex. It mostly impacts= the json library you'll end up using, plus a bit of input/output decor= ation around it. Even golang provides utilities for this, despite not exact= ly being made for this kind of purpose.

    My practical experience implementing it is that it's no= t that big a deal. I mean, I wished it could be simpler, but it's manag= eable and there are other ways to reach levels of insurance that it does wo= rk as intended (json schema, test cases to validate the implementation, etc= .). Arguably it is still easier from an implementation perspective than say= , json-ld, which is massively used in the SSI community.=C2=A0

    =C2=A0

    <= p class=3D"MsoNormal">But ultimately who are we designing for? Are we striv= ing to go easy on the spec implementer? Or are we trying to make sure end-d= evelopers using the client libraries won't shoot themselves in the foot= ?

    =C2=A0

    The job to be done (JTBD), from the end= -developer's perspective, is to efficiently ship an application. And pr= ovide authN/authZ capabilities for end-users by relying on some well known = implementation.=C2=A0

    In= turn, this spec implementer will rely on cryptographic utility libraries t= hat deals internally with the complexity of their own domain, so that we do= n't have to. And here we could launch another HN flame war that starts = with the title "JWT sucks because". Which does have its set of ve= ry real issues but that's beyond the point.=C2=A0

    Note that any decent flamewar will be efficie= ntly fueled by people hating medium. Is it outrageous for blog posts to be = behind a paywall? Maybe but it's even more outrageous to lack consisten= cy, either by not knowing how to get around a paywall if you're into a = hacker punk movement, or on the contrary by to not paying a subscription if= you believe that surveillance capitalism, to reuse Zuboff's terms, sho= uld be eradicated.=C2=A0

    What likely seems an unnecessary sidenote tries to illustrate the point: f= or Justin it was easier to publish on medium, because as a blog publisher, = you might not want to deal with hosting your own blog. But maybe as a reade= r you'll find that annoying. Different audiences, different JTBD, diffe= rent tradeoffs.=C2=A0

    =C2=A0

    Polyphormism is a t= ool that enables the end-developer to have minimal knowledge of what it mea= ns to deal with a GNAP client library. You prepare the request, send to the= endpoint and you're good to go. Massively simpler than OAuth2 or any s= imilar protocol by the way (as anyone with teaching experience on the subje= ct might acknowledge). And=C2=A0 there's a lot more to be done to make = sure we indeed reduce the complexity for the end-developer and the end-user= .=C2=A0

    =C2=A0=

    If we find a better way to deal w= ith that simplicity balance, I'm all in. But the arguments need to be w= ay more convincing than just saying that it may be difficult to implement o= r validate.=C2=A0

    =C2=A0

    Cheers.

    Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" rel=3D"noreferrer noreferrer" target=3D"_= blank">jricher@mit.edu> a =C3=A9crit=C2=A0:

    <= blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">

    =C2=A0



    <= /u>

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    Justin<= /u>

    =C2=A0

    I did note that I was the one that argued for inst= ance_id being in the object. Since it is in the object in the current draft= , not including a pass by reference option would be preferable.=C2=A0

    =C2=A0

    As for concrete examples:

    - version of client

    <= div>

    - version of OS

    - security attestation of OS / device

    <= /div>

    - location of client device<= /p>

    - network client is operating on

    =C2=A0

    These are all attributes of the client that an= AS may require=C2=A0on the initial grant request, and in future grant requ= ests (which is when an instance_id) would be used.

    <= div>

    =C2=A0

    =C2=A0

    This is where our interpretations differ: I don=E2=80=99t= see these as =E2=80=9Cattributes of the client=E2=80=9D in the same way th= at the key, display information, class identifiers, and other items current= ly represented by an instance_id are attributes of the client instance. The= attestation components don=E2=80=99t modify the instance so much as presen= t additional information on top of the client instance itself. This is why = I argue that they ought to be handled in a separate object, so you=E2=80=99= d have something like this strawman:

    =C2=A0

    {<= u>

    =C2=A0

    =

    =C2=A0 posture: {

    =

    =C2=A0 =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2=

    =C2=A0 =C2=A0 device_at= testation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }=

    =C2=A0 =C2=A0 location: { lat: = =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    =C2=A0

    =C2=A0 clie= nt: =E2=80=9Cclient-541-ab"

    =C2=A0

    }=

    =C2=A0

    =

    This is a more fundamental question about GNAP = than whether the syntax uses polymorphism: this is about GNAP being very ex= plicit about the data model of its elements. OAuth 2=E2=80=99s incredibly l= oose and broad model of what the term =E2=80=9Cclient=E2=80=9D is referring= to, exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed cl= ient=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in= GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we= still need to be more precise about what exactly a client instance include= s, and what it does not.

    =C2=A0

    =C2=A0=E2=80=94 = Justin

    =C2=A0<= /u>



    /Dick

    = =C2=A0

    3D"Image=E1=90=A7

    =C2=A0

    On Fri, Oct 23, = 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:=

    Dick,

    =C2=A0

    As you=E2=80= =99ll recall, I argued against including the client instance identifier ins= ide of the object as a mutually-exclusive field precisely because of the pr= inciple violation that you are pointing out here, and so it=E2=80=99s impor= tant to point out that the current text is a compromise that needs to be ex= amined in the wider experience of the working group. I am on the side of re= moving the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within a= n object, but this needs to be explored.

    =C2=A0

    = The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Ccl= ient instance=E2=80=9D value itself but rather belong outside of that objec= t in a another part of the request. As stated in the editorial notes in thi= s section, we need to look carefully at how these concepts fit within the m= odel and where we would want to put them. Without concrete examples of what= these extensions look like and how they=E2=80=99re generated, that is near= ly impossible to do at this stage. I look forward to seeing examples of thi= s kind of data and how it can fit into the protocol.

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 3= :07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= /u>

    =C2=A0

    Hey Justin,

    =C2=A0

    As th= e draft has evolved, I question the continued use of polymorphism. Note tha= t I appreciate the elegance=C2=A0of using a string for pass-by-reference, a= nd an object for pass-by-value.

    =C2=A0

    In the cu= rrent draft, the=C2=A0

    <= u>=C2=A0

    Every time you create or process a = field it will mean only one thing, and there=E2=80=99s only one field to lo= ok at to answer a question.=C2=A0

    =

    =C2=A0

    <= div>

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0instance_id= =C2=A0An identifier string that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 particular ins= tance of this RC.=C2=A0 The content and structure of this

    =

    =C2=A0 =C2=A0 =C2=A0 identifier is opaque= to the RC.

    =C2= =A0

    =C2=A0 =C2=A0"client&q= uot;: {

    =C2=A0 =C2=A0 = =C2=A0 =C2=A0"instance_id": "client-541-ab"

    =C2=A0 =C2=A0}

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fields to send, the = RC MAY send the

    =C2=A0 = =C2=A0instance identifier as a direct reference value in lieu of the=

    =C2=A0 =C2=A0object.=

    =C2=A0

    =C2=A0 =C2=A0"client": "client-541-= ab"

    =C2=A0

    The instance identi= fier can be sent two ways. Polymorphism is a convenience for the client, bu= t requires the server=C2=A0to have two code=C2=A0paths for "instance_i= d".=C2=A0 We discussed this in the design team, and I argued for havin= g "instance_id" in the "client" object=C2=A0so that any= updates, such as new devices assertions, could be in the "client"= ; object. As noted above, while I appreciate the elegance of using a string= (handle) to reference a previously provided object, it complicates how to = update an existing object while providing the reference.

    <= /div>

    =C2=A0

    In your example of the "key" object below, settin= g "proof" to bearer would avoid the issue you describe:=

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2= =A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2=A0 } =
    }

    =C2=A0

    In your example, when processing th= e "key" object, code is having to check both the JSON type of the= property, as well as check the value of the "proof" property. In= the example I provided, only the value of "proof" needs to be ch= ecked. The "proof" property is acting as a type for the "key= " object.

    = =C2=A0

    Not being a Java program= mer, I don't know how this would work in a Java implementation, but nod= e.js, the processing would need to be done as above.

    =C2=A0

    On a related note, there was significant negative feedback on h= andles and polymorphism in the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24855750=C2=A0<= /u>

    =C2=A0

    /Dick

    =C2=A0

    =C2=A0

    On Fri, = Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> = wrote:

    Hi Mika,

    =C2=A0

    Th= anks for bringing this topic here =E2=80=94 I was able to see the forum dis= cussion that brought you here, and hopefully I can help clear up what I mea= n with how polymorphism is used in the proposal. The short version is that = the goal is to=C2=A0avoid=C2=A0the kinds of ambiguity that make inse= cure protocols, and so in that goal we=E2=80=99re fully aligned. I think th= at using polymorphism in very specific ways can help that goal =E2=80=94 ju= st as I agree that misusing it or applying it sloppily can lead to ambiguou= s and insecure systems.

    = =C2=A0

    Some background: = I built out the XYZ protocol (one of the predecessors to the initial GNAP D= raft) in Java using strongly typed parsers and Java objects specifically to= prove to myself that it could be done in a way that made any sense in the = code. (My own open source implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not= yet up to date with the GNAP spec). It was important to me that I be able = to use the system-wide configured parsers to implement this and not have to= resort to stepping through elements completely by hand. Java doesn=E2=80= =99t make it simple to get the hooks into the right places (especially with= the Jackson parser that I used), but it is definitely possible to create a= deterministic and strongly-typed parser and serializer for this kind of da= ta structure. Some of the rationale for using polymorphism is covered in th= e trailing appendix of the draft document (https://www.ietf.or= g/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and= -polymor), but it=E2=80=99s still good to discuss this here as the work= ing group decides which approaches to take.=C2=A0

    =C2=A0

    The driving reason for using polymorphism at the protocol level wa= s to simplify the protocol and make it :more: deterministic to create and p= rocess, not less. Every time you create or process a field it will mean onl= y one thing, and there=E2=80=99s only one field to look at to answer a ques= tion. Without polymorphic field values, you usually need to rely on mutual = exclusivity of fields, which is prone to failure and requires additional er= ror checking. Take for example the key binding of access tokens. An access = token could be bound to the RC=E2=80=99s key used during the request, to a = different key chosen by the AS, or it could be a bearer token with no key a= t all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define= it in terms of boolean values and objects and express this set of mutually= -exclusive options in a non-ambiguous way. Without that, you=E2=80=99d need= to have different fields for the options and include additional checks in = your parser to make sure they weren=E2=80=99t sent simultaneously, otherwis= e you could get hit with this potential security vulnerability in an object= :

    =C2=A0

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key val= ue =E2=80=A6 }

    =C2=A0 = =C2=A0 },

    =C2=A0 =C2=A0 = bearer_token: true,

    =C2= =A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0<= u>

    This would be an illegal object= as per this alternate proposal, but then you=E2=80=99d have to check each = field and make sure it wasn=E2=80=99t put next to others in the same object= . I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99= s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the polymorp= hic approach to this same field, each of these three mutually-exclusive sta= tes is written in a way that they cannot be sent together. It=E2=80=99s not= just illegal, it=E2=80=99s impossible and enforced by the syntax of JSON i= tself.

    =C2=A0<= /u>

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    <= div>

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80= =A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // bearer token

    <= p class=3D"MsoNormal">=C2=A0

    {

    =C2=A0 =C2=A0 key= : false

    }<= /p>

    =C2=A0

    // bound to the RC=E2=80=99s presented key=

    =C2=A0

    =

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0=

    If someone sends a different type= for this field, like an array or number or a null, this doesn=E2=80=99t ha= ve a defined interpretation in the protocol and would be a protocol level e= rror.

    =C2=A0

    While it might sound like polymorph= ism means that any field could have any type or value, the opposite is true= : each possible value is explicitly typed, it=E2=80=99s just that there are= potentially different types that express meaning for the field. This appli= es to all members of all objects (dictionaries) as well as all members of a= n array (list). Every time you process a field value or other element, you = look at the type and then the value to determine what to do with that typed= value.

    =C2=A0=

    In your example below, each field= within the dictionary would also need to be typed, and each type would nee= d to have a clear indication of its meaning. To take your strawman key form= at below, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphica= lly as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what= exactly the encoding of the string would be. That means that when you read= the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusio= n on what the value was or how it was represented, regardless of the input = format. Seeing a number there means exactly one interpretation and seeing a= string means exactly one (different) interpretation =E2=80=94 but importan= tly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the= field that determines the type. An implementation would likely use an inte= rnal BigInteger type of object to represent the field value after parsing, = so the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the =E2=80= =9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object= .=C2=A0

    =C2=A0=

    So let=E2=80=99s dig into the spe= cific bug you bring up in the strawman, because it=E2=80=99s interesting: A= JSON encoder that encodes numbers as strings, and not numbers, is not comp= liant with the JSON definitions of the field in question. For another examp= le, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to = the boolean value true in JSON, and they shouldn=E2=80=99t be treated the s= ame by a parser implementation when mapping to a concrete object. It=E2=80= =99s in this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take =C2=A0advantage= of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a = parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing t= his kind of mapping, but ended up introducing errors in more strict compone= nts downstream. This is something that protocol designers need to be aware = of and guard against in the design of the protocol to reduce possible ambig= uities. Within GNAP today, we generally have things that branch whether the= y=E2=80=99re an object (for a rich description of something) or some non-st= ructured special value (for a reference or other item).=C2=A0=

    =C2=A0

    The design team created some simple JSON Schemas for p= arts of the protocol during our discussion, but we didn=E2=80=99t include t= hem in the design document due to both lack of time to keep it updated with= the rapid changes to the protocol during the design team discussion, and n= ot knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final doc= ument, but that=E2=80=99s something for the working group to take up eventu= ally.

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:=

    =C2=A0

    Hello, everyone.

    <= div>

    =C2=A0

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion fo= rum and when I made note about certain concerns, I was requested to send my= comments to this working group.

    =C2=A0

    In short= , I believe that the use of polymorphic JSON in the protocol invites subtle= and confusing implementation problems. I also searched through the WG arch= ives, and noticed that similar concerns were noted, briefly, in a thread in= July.

    =C2=A0=

    The problem with polymorphic valu= es, as I see it, is that implementations will need to branch on the (inferr= ed) type of a given field. This isn't quite as bad if the types are str= ictly different, but allows for subtle bugs when the value in question is a= dictionary. What makes this unappealing is that "subtle bugs" in= security protocols have a habit of turning into vulnerabilities.=

    =C2=A0

    Let's say we have these imaginary payloads, bo= th possible and valid in the same protocol step:

    =C2=A0

    # payload 1

    {=

    =C2=A0 ...,<= /p>

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg&= quot;: "rsa",

    = =C2=A0=C2=A0=C2=A0 "modulus": <BIGINT>

    =C2=A0 }

    }

    =C2=A0

    # payload 2

    {

    =C2=A0 ...,

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",<= u>

    =C2=A0=C2=A0=C2=A0 "modulu= s": "<encoded string>"

    =C2=A0 }

    }

    =C2=A0<= /u>

    In both cases, the type of "p= ublic_key" field is a dictionary. In both cases, they even have the sa= me keys. However, the values in the dictionaries are entirely different, an= d an implementation will have to branch to at least two possible decoding m= echanisms. To make things worse, some JSON implementations may choose to en= code non-dictionary values as strings, so it is possible for an originator = to transmit what they expect and believe to be payload 1 format, but which = the receiver will interpret to be in payload 2 format. And if the encoded s= tring contains only digits, it will even parse correctly as a bignum.

    =C2=A0

    While the above is clearly a manufactured scen= ario, it nonetheless demonstrates the potential for logic bugs with polymor= phic JSON. With richer types and more complex dictionaries, there will sure= ly be more room for errors.

    =C2=A0

    Ambiguity in = protocols is always a source of implementation complexity and interoperabil= ity snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying.= If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in ev= eryone's interest to keep implementation complexity and mistake potenti= al to a minimum?

    = =C2=A0

    Best regards,<= /u>

    Mika

    <= p class=3D"MsoNormal">=C2=A0

    = --

    Mika Bostr=C3=B6m

    Smarket= s

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    =C2= =A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf= .org/mailman/listinfo/txauth

    =

    3D"Image=E1=90=A7

    =C2=A0

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    <= /blockquote>
    =



    --

    Mika Bostr=C3=B6m

    <= /div>

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mai= lman/listinfo/txauth

    --00000000000005c28d05b2c094d9-- From nobody Thu Oct 29 12:23:34 2020 Return-Path: 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 BE84F3A09E1 for ; Thu, 29 Oct 2020 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 swD4xb3dUrWr for ; Thu, 29 Oct 2020 12:23:22 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 2A1C53A07D7 for ; Thu, 29 Oct 2020 12:23:22 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id w27so5404469ejb.3 for ; Thu, 29 Oct 2020 12:23:21 -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=wvbAGjpM7NhmvWURM8PA9vkp1tsI4ZfLQySo7mAAZkE=; b=YJpaz+j1MAVnKSqxfJJXiyoX61qlaNpz9Mwv29ey8Z+JBk//BwIURrFczFtebbZsAs 7vlY+CIjLEJzYnHnDXWISpSG6iLuCt5N0WDnIaf1LY/StT5yXgob9DKXQy6kojIIhnRI +sx8q4ZQEKPh5Dly/921WuY1y7DfFJ1G1JJ811fR5WAg9nqQz26wcu5adt2hWNI/JRJx d6mDl8q7AFd8SAVizKRhLHsY/5dBg6hHwoL/6DGSImV+w03k//b3IBdVbNd2xeSNJQ/M nUiwCia9hujx+rcMzzXvf9nZNZvG5lhElb3v40+uyBQiPX2wQdL/wh3h6W0SFbWuyNzN pW5w== 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=wvbAGjpM7NhmvWURM8PA9vkp1tsI4ZfLQySo7mAAZkE=; b=JtllvEjrgz9OguzeosFUBd+FwhxIUpsqOfOy42pbQiBCzHaqXb4lIG0wdbCj2dCTP+ KNVqGsiEJhjjCpijdSHQbUB0tBNGHM6dO/WuzFsW4gtZy0FijzLmYD6VTzJ8L50sT66l SlENaClb+7ljUVQ1q9+so2ePWqPosASwF2lsL8yTvijAzyw8Qq41KSSHrrmIyx8U89Zg VsEeWU/jqh1RAwUGIoxAI62LomjQjTO0w0nFLDqr6RcMY/51VZBIvtuRO8/O4y7MG/CU a5n8zNIW8UtPbJ99hhevh/+UUzmIz6i0PkCVWDduETiibMByPwQ78JCnPa8lBhqk+r21 L7nA== X-Gm-Message-State: AOAM533BziiG0w7tOHtmjIKfll9MzFIdAG5bc0jxxpxLopkyiofKXfe5 EA9hEqqs6gYYKr72UXMK002vYPdxNovso8rkt/g= X-Google-Smtp-Source: ABdhPJzoBE4ey4Rj+PLIhdm3h/P/D/ItgIV93UDPlSyUxvDWlP6TTE4hvQQnOf9hEQ+/2bv/fPs0iVWQI/p1TjJkG44= X-Received: by 2002:a17:906:8891:: with SMTP id ak17mr5542374ejc.176.1603999400152; Thu, 29 Oct 2020 12:23:20 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Andrii Deinega Date: Thu, 29 Oct 2020 12:23:08 -0700 Message-ID: To: =?UTF-8?Q?Mika_Bostr=C3=B6m?= , Justin Richer Cc: Yaron Sheffer , GNAP Mailing List , Dick Hardt , Fabien Imbault Content-Type: multipart/alternative; boundary="00000000000077529905b2d436af" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org 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, 29 Oct 2020 19:23:30 -0000 --00000000000077529905b2d436af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mika, Justin, and WG, The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) has a JSON object as its value. This claim could be a part of AT JWT or a token introspection response and has the same semantics in both cases. The JSON object as its value may look like this "act": { "sub":"admin@example.com" } or even be nested like in "act": { "sub":"https://service16.example.com", "act": { "sub":"https://service77.example.com" } } Personally, I find it to be a very expressive approach. Also, as far I as know, several (oAuth2) client libraries have good support of things like "aud":"https://service1.example.com" and "aud":[" https://service1.example.com","https://service2.example.com"] in AT JWTs for a quite long time. Regards, Andrii On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault wrote: > Hi Yaron, > > We'll indeed have to check how make it as idiomatic as possible with > experts of each language (help welcome). > > Regarding the client, the variations are more limited but they do exist. > Here I believe it's much more problematic than on the server side and the= re > are at least a few actions we should take: > > A) check in sec 7 if we really have a compelling reason for key and proof > variants. This is derived from larger discussions on key binding as per t= he > related note. There are quite a few open questions related to this theme. > > B) there is also the choice between value/reference that may generate > complexity. > > C) More generally, as many feedbacks already have noticed, we need to hav= e > a systematic review and reduce the set of available options in the > protocol. > > Unless we have a clear idea why runtime behavior requires mutability, it > might be useful to have a way to define the chosen variant before hand, s= o > that the expected behavior becomes deterministic on the client side. Ther= e > are various ways it could be done in practice. > > For sure several independant implementations would help, especially if we > make sure they can work together. > > Anyway all this open to improvement. > > Cheers > Fabien > > > Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = a > =C3=A9crit : > >> Hi Fabien, >> >> >> >> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is fa= r worse than the >> problem. The code in the article you cite is very specific to the use ca= se >> and IMHO quite ugly. So my preferred Go implementation would be a >> combination of untyped structures (Go interface{}) and run-time enforcem= ent >> of JSON Schema. >> >> >> >> Also, going back to our earlier discussion on this topic, I just read >> Sec. 7 of gnap-00 and realized that the RC also needs to deal with >> polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Date: *Wednesday, October 28, 2020 at 18:56 >> *To: *Mika Bostr=C3=B6m >> *Cc: *GNAP Mailing List , Justin Richer , >> Dick Hardt >> *Subject: *Re: [GNAP] Feedback on polymorphism >> >> >> >> Thanks for the great feedback. Your concern is very valid. >> >> >> >> My implementation is in rust, which makes life easier in that specific >> case. >> >> >> >> So I'm not a golang specialist but I guess the transcription of json >> strings/arrays into go structs would work around the lines described by >> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 >> >> When we have a more formalized json schema, I suggest we make a library >> of json examples and some related code samples in mainstream languages, = to >> check it is feasible for everyone. >> >> >> >> Cheers, >> >> Fabien >> >> >> >> >> >> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m >> wrote: >> >> Hi everyone, >> >> >> >> Looks like I stuck my finger in a hornets' nest. First off, apologies fo= r >> not chipping in earlier, but there was a lot of material to digest. Also= , >> warning: lots to read ahead. >> >> >> >> I'm one of those people who end up making use of AuthN/AuthZ >> functionality through a library. On top of that I can see myself being >> roped in as a server (AS) implementation help. So I'm approaching this f= rom >> an outsider's perspective. Someone who expects to be exposed to the >> eventual RFC and all the nitty-gritty details. My relatively terse comme= nt >> ended up at the top of the aforementioned HN thread, which didn't >> necessarily help. Sorry about that. >> >> >> >> Now, having read Justin's initial reply - and the rest of the thread - I >> believe I can see where the desire for polymorphism comes from. To be >> clear: I am all for strict types inside an implementation, as it will ad= d >> helpful guard-rails to the state management code paths. However, I see t= his >> as a case of leaky abstraction. If we take the existing oauth.xyj-java c= ode >> to be the reference implementation, the choice makes logical sense: JSON= is >> not expressive enough to serialise arbitrary objects, so in order to avo= id >> writing complex payload parser(s) the internal implementation details no= w >> leak to the protocol itself. From a purely technical perspective, it's a >> cool trick. From a distance it even looks a bit like the result of proto= buf >> decoding, but without the generated code parts. >> >> >> >> But then the downside. I don't personally expect to be able to use the >> reference implementation, being mostly a Python user myself. A fair numb= er >> of AS implementations will be written with languages such as Go, Python, >> C#, Ruby, and JavaScript (thanks to node.js), and all of them will have = to >> deal with the polymorphism. From what I've read over the past couple of >> days, I understand that at least Go supports custom unmarshalers from JS= ON >> to typed structs, at the cost of an indirection. Normally when a Go code >> processes JSON to a typed struct, the process is helped by field >> annotations in the type definition itself. For example, if the payload f= or >> a person in JSON was >> >> >> >> { >> >> "name": "", >> >> "age": , >> >> "country": "", >> >> "city": "" >> >> } >> >> >> >> .. then the type definition would look like: >> >> >> >> type Person struct { >> >> Name string `json:"name" >> >> Age int `json:"age"` >> >> Country string `json:"country"` >> >> City string `json:"city"` >> >> } >> >> >> >> When the (possibly complex) type of a given field is fixed, unmarshaling >> should still be straightforward. I haven't verified, but since the >> annotation only gives which field to look at for a given typed value, th= ere >> should be nothing special about that. But when the field can instead be = a >> union of more than one distinct types, things start to get messy. There = is >> no union type in the language at all, so the following construct is not >> even possible: >> >> >> >> type Entity struct { >> >> Resources []string `json:"resources"` >> >> Client union(Client, string) `json:"client"` >> >> } >> >> >> >> As I understand, the implicit expectation is that in the above case, the >> unmarshaler detects that "client" is a string, and so expands it from an >> opaque handle to the expected, populated type. Even after thinking about >> the ramifications over the past few days I remain confused, because I do= n't >> see how the commonly used annotations could work. If the expectation is >> that protocol implementations should use strong types, then the use of >> polymorphic JSON is very likely to make things _more_ complicated for >> non-reference implementations. >> >> >> >> Hence my concern. I'm afraid that the leaky abstraction, while making th= e >> reference implementation more robust and straightforward, contributes to >> making other implementations less robust. And this being a security >> protocol, the potential for brittle and/or confused implementations is >> terrifying. >> >> >> >> I am a fan of reducing complexity, and from what I can see, for the >> reference implementation the polymorphic approach actually does that. Bu= t >> I'm afraid it does so at others' expense. Languages have their individua= l >> constraints, idioms and best practices. If parsing a protocol payload >> introduces low-level complexities and encourages to go against common >> practices, that is an invitation for problems. I am aware that my choice= of >> words in the HN thread was likely to put people on defense, and for that= I >> apologise. But I do believe that the choice of polymorphic JSON is going= to >> make the life and use of other implementations notably less boring than >> people in general would prefer. >> >> >> >> Cheers, >> >> Mika >> >> >> >> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault >> wrote: >> >> Hi Dick, >> >> >> >> Well technically yes. Obviously the client can present any interface it >> seems fit. >> >> >> >> Still there's the question of the common model we want to present to the >> outside world and supported by the protocol itself (which client librari= es >> all build upon). >> >> >> >> But beneath the polyphormism question, the HN debate seems on the surfac= e >> a lot like the original xyz (polyphormism goes along with the reduced >> endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where th= e >> client design has more latitude). Just explained differently, by outside >> people with different agendas. >> >> >> >> Which is a bit weird because many of the critics on HN (who criticize >> polyphormism) also seem to really dislike OAuth in the first place (the >> inconsistencies are partially due to a bunch of different people >> commenting). >> >> >> >> Really to me there's no fundamental truth behind that question. It's a >> matter of preference and priorities in the design. Whatever choices we >> make, we'll have to be prepared to explain and justify them in the open, >> even to some people that will dislike pretty much whatever we do (becaus= e >> it's fun to look smart and critize without proposing alternatives). And = we >> owe these answers to people like Mika, who genuinely try to make the bes= t >> of it. >> >> >> >> Fabien >> >> >> >> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : >> >> Hi Fabien >> >> >> >> A library developer can provide whatever abstraction layer makes sense >> for the library's target audience and language. >> >> >> >> If the client library developer wants to use polymorphism in the >> interface presented to the user's of the library, the library developer = can >> do that independent of polymorphism in the protocol, and vice versa >> >> >> >> =3D> polymorphism in the protocol has no impact on client library develo= pers >> >> >> >> >> >> [image: Image removed by sender.]=E1=90=A7 >> >> >> >> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >> wrote: >> >> I'm just realizing your "least to most important" might actually say the >> same as what I was trying to say. So I'm not even sure what we're arguin= g >> against :-) >> >> >> >> In brief my point if it wasn't clear is that we should be crystal clear >> on where we put the cursor of simplicity, because this can mean differen= t >> things for different people and different roles. >> >> And as we see on HN we need to better explain our design choices. >> >> >> >> >> >> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >> a =C3=A9crit : >> >> Hi Dick, >> >> >> >> Independantly from the debate on polyphormism, I beg to differ on your >> order preference. >> >> >> >> Your assumption is that AS devs matter the most, because they're doing >> the important security implementation. But eating our own dogfood might >> help a lot to change that view. Most security issues occur because users= of >> the spec are unable to deal with the complexity that is passed onto them= . >> >> >> >> 99% of the people that will actually use the output of the work are >> application developers (client or RS) and their own users. >> >> >> >> Our intent as well as the protocol drive the usage. Client libraries may >> help, but they're not a silver bullet, especially because GNAP ultimatel= y >> has no control about what people do there (for better or worse). And >> everything we do here will help get to the better part. >> >> >> >> I'm not saying we don't intend to also care about AS developers >> (beginning with ourselves) but it's a second order optimisation. And sin= ce >> it's a tendancy we're leaning towards by default, I'm pretty sure we won= 't >> forget that anyway. >> >> >> >> Fabien >> >> >> >> >> >> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : >> >> I'm confused by your logic Fabien. >> >> >> >> If a client library developer wants to expose polymorphism, they can do >> that independent of what is in the protocol. >> >> >> >> I differ on who our stakeholders are. >> >> >> >> I think our stakeholders are in least to most important: >> >> >> >> - AS developer >> - RS developer >> - client developer >> - user >> >> >> >> A client library developer can expose whatever interface they want to >> simplify implementation. >> >> >> >> I list the user so that we don't lose site of a critical role. >> >> >> >> /Dick >> >> >> >> >> >> [image: Image removed by sender.]=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >> wrote: >> >> Hi there, >> >> >> >> Let me try to approach the issue under a different light. More like a >> product manager would deal with feature selection to make it intuitive f= or >> its users. >> >> >> >> For most people, riding a bike is far easier than using a unicycle. Feel= s >> more stable. And yet it's way easier to design for a single wheel than t= o >> build with 2. Because then you'll need a lot more accessories (chain, ch= ain >> ring, etc.). Even so producing a bike doesn't have to be a brittle proce= ss, >> it can be industrialized. >> >> >> >> Back to the GNAP topic. >> >> Ultimately we should strive to make the spec as simple as can be. But we >> need to ask: simple for whom? For the bike owner or for the bike vendor? >> >> (short answer: the priority should be simplicity for spec users, not spe= c >> implementers and even less spec designers). >> >> >> >> The initial question that is asked is very interesting: isn't the design >> flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the >> state of the request? Or if we must handle token revocation? Or if we ar= e >> looking for a global unique identifier? The argument stems of the fact t= hat >> is still arguably harder and more error prone to implement. Fair enough. >> >> >> >> From a spec implementer's perspective, it may well be more complex. It >> mostly impacts the json library you'll end up using, plus a bit of >> input/output decoration around it. Even golang provides utilities for th= is, >> despite not exactly being made for this kind of purpose. >> >> My practical experience implementing it is that it's not that big a deal= . >> I mean, I wished it could be simpler, but it's manageable and there are >> other ways to reach levels of insurance that it does work as intended (j= son >> schema, test cases to validate the implementation, etc.). Arguably it is >> still easier from an implementation perspective than say, json-ld, which= is >> massively used in the SSI community. >> >> >> >> But ultimately who are we designing for? Are we striving to go easy on >> the spec implementer? Or are we trying to make sure end-developers using >> the client libraries won't shoot themselves in the foot? >> >> >> >> The job to be done (JTBD), from the end-developer's perspective, is to >> efficiently ship an application. And provide authN/authZ capabilities fo= r >> end-users by relying on some well known implementation. >> >> In turn, this spec implementer will rely on cryptographic utility >> libraries that deals internally with the complexity of their own domain,= so >> that we don't have to. And here we could launch another HN flame war tha= t >> starts with the title "JWT sucks because". Which does have its set of ve= ry >> real issues but that's beyond the point. >> >> Note that any decent flamewar will be efficiently fueled by people hatin= g >> medium. Is it outrageous for blog posts to be behind a paywall? Maybe bu= t >> it's even more outrageous to lack consistency, either by not knowing how= to >> get around a paywall if you're into a hacker punk movement, or on the >> contrary by to not paying a subscription if you believe that surveillanc= e >> capitalism, to reuse Zuboff's terms, should be eradicated. >> >> What likely seems an unnecessary sidenote tries to illustrate the point: >> for Justin it was easier to publish on medium, because as a blog publish= er, >> you might not want to deal with hosting your own blog. But maybe as a >> reader you'll find that annoying. Different audiences, different JTBD, >> different tradeoffs. >> >> >> >> Polyphormism is a tool that enables the end-developer to have minimal >> knowledge of what it means to deal with a GNAP client library. You prepa= re >> the request, send to the endpoint and you're good to go. Massively simpl= er >> than OAuth2 or any similar protocol by the way (as anyone with teaching >> experience on the subject might acknowledge). And there's a lot more to= be >> done to make sure we indeed reduce the complexity for the end-developer = and >> the end-user. >> >> >> >> If we find a better way to deal with that simplicity balance, I'm all in= . >> But the arguments need to be way more convincing than just saying that i= t >> may be difficult to implement or validate. >> >> >> >> Cheers. >> >> Fabien >> >> >> >> >> >> >> >> >> >> >> >> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : >> >> >> >> >> >> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >> >> >> >> Justin >> >> >> >> I did note that I was the one that argued for instance_id being in the >> object. Since it is in the object in the current draft, not including a >> pass by reference option would be preferable. >> >> >> >> As for concrete examples: >> >> - version of client >> >> - version of OS >> >> - security attestation of OS / device >> >> - location of client device >> >> - network client is operating on >> >> >> >> These are all attributes of the client that an AS may require on the >> initial grant request, and in future grant requests (which is when an >> instance_id) would be used. >> >> >> >> >> >> This is where our interpretations differ: I don=E2=80=99t see these as >> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key,= display >> information, class identifiers, and other items currently represented by= an >> instance_id are attributes of the client instance. The attestation >> components don=E2=80=99t modify the instance so much as present addition= al >> information on top of the client instance itself. This is why I argue th= at >> they ought to be handled in a separate object, so you=E2=80=99d have som= ething like >> this strawman: >> >> >> >> { >> >> >> >> posture: { >> >> software_version: 1.2.3, >> >> os_version: 14.3.2 >> >> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >> >> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >> >> }, >> >> >> >> client: =E2=80=9Cclient-541-ab" >> >> >> >> } >> >> >> >> This is a more fundamental question about GNAP than whether the syntax >> uses polymorphism: this is about GNAP being very explicit about the data >> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mode= l of what >> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pr= oblematic in >> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havi= ng to >> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture >> the different aspects that are out there. I think we=E2=80=99re getting = closer here >> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, b= ut we still need to >> be more precise about what exactly a client instance includes, and what = it >> does not. >> >> >> >> =E2=80=94 Justin >> >> >> >> >> >> /Dick >> >> >> >> [image: Image removed by sender.]=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >> >> Dick, >> >> >> >> As you=E2=80=99ll recall, I argued against including the client instance >> identifier inside of the object as a mutually-exclusive field precisely >> because of the principle violation that you are pointing out here, and s= o >> it=E2=80=99s important to point out that the current text is a compromis= e that >> needs to be examined in the wider experience of the working group. I am = on >> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >> object, but this needs to be explored. >> >> >> >> The crux of my argument is that is exactly a case of pass-by-reference v= s >> pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient >> instance=E2=80=9D value itself but rather belong outside of that object = in a >> another part of the request. As stated in the editorial notes in this >> section, we need to look carefully at how these concepts fit within the >> model and where we would want to put them. Without concrete examples of >> what these extensions look like and how they=E2=80=99re generated, that = is nearly >> impossible to do at this stage. I look forward to seeing examples of thi= s >> kind of data and how it can fit into the protocol. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >> >> >> >> Hey Justin, >> >> >> >> As the draft has evolved, I question the continued use of polymorphism. >> Note that I appreciate the elegance of using a string for >> pass-by-reference, and an object for pass-by-value. >> >> >> >> In the current draft, the >> >> >> >> Every time you create or process a field it will mean only one thing, an= d >> there=E2=80=99s only one field to look at to answer a question. >> >> >> >> is violated in 2.3.1. Identifying the RC Instance >> >> >> >> >> >> >> instance_id An identifier string that the AS can use to identify the >> >> particular instance of this RC. The content and structure of this >> >> identifier is opaque to the RC. >> >> >> >> "client": { >> >> "instance_id": "client-541-ab" >> >> } >> >> >> >> If there are no additional fields to send, the RC MAY send the >> >> instance identifier as a direct reference value in lieu of the >> >> object. >> >> >> >> "client": "client-541-ab" >> >> >> >> The instance identifier can be sent two ways. Polymorphism is a >> convenience for the client, but requires the server to have two code pat= hs >> for "instance_id". We discussed this in the design team, and I argued f= or >> having "instance_id" in the "client" object so that any updates, such as >> new devices assertions, could be in the "client" object. As noted above, >> while I appreciate the elegance of using a string (handle) to reference = a >> previously provided object, it complicates how to update an existing obj= ect >> while providing the reference. >> >> >> >> In your example of the "key" object below, setting "proof" to bearer >> would avoid the issue you describe: >> >> >> >> { >> "key": { >> "proof": "bearer" >> } >> } >> >> >> >> In your example, when processing the "key" object, code is having to >> check both the JSON type of the property, as well as check the value of = the >> "proof" property. In the example I provided, only the value of "proof" >> needs to be checked. The "proof" property is acting as a type for the "k= ey" >> object. >> >> >> >> Not being a Java programmer, I don't know how this would work in a Java >> implementation, but node.js, the processing would need to be done as abo= ve. >> >> >> >> On a related note, there was significant negative feedback on handles an= d >> polymorphism in the Hacker News article >> https://news.ycombinator.com/item?id=3D24855750 >> >> >> >> /Dick >> >> >> >> >> >> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >> >> Hi Mika, >> >> >> >> Thanks for bringing this topic here =E2=80=94 I was able to see the foru= m >> discussion that brought you here, and hopefully I can help clear up what= I >> mean with how polymorphism is used in the proposal. The short version is >> that the goal is to *avoid* the kinds of ambiguity that make insecure >> protocols, and so in that goal we=E2=80=99re fully aligned. I think that= using >> polymorphism in very specific ways can help that goal =E2=80=94 just as = I agree >> that misusing it or applying it sloppily can lead to ambiguous and insec= ure >> systems. >> >> >> >> Some background: I built out the XYZ protocol (one of the predecessors t= o >> the initial GNAP Draft) in Java using strongly typed parsers and Java >> objects specifically to prove to myself that it could be done in a way t= hat >> made any sense in the code. (My own open source implementation is at >> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not y= et up to >> date with the GNAP spec). It was important to me that I be able to use t= he >> system-wide configured parsers to implement this and not have to resort = to >> stepping through elements completely by hand. Java doesn=E2=80=99t make = it simple >> to get the hooks into the right places (especially with the Jackson pars= er >> that I used), but it is definitely possible to create a deterministic an= d >> strongly-typed parser and serializer for this kind of data structure. So= me >> of the rationale for using polymorphism is covered in the trailing appen= dix >> of the draft document ( >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#na= me-json-structures-and-polymor), >> but it=E2=80=99s still good to discuss this here as the working group de= cides which >> approaches to take. >> >> >> >> The driving reason for using polymorphism at the protocol level was to >> simplify the protocol and make it :more: deterministic to create and >> process, not less. Every time you create or process a field it will mean >> only one thing, and there=E2=80=99s only one field to look at to answer = a question. >> Without polymorphic field values, you usually need to rely on mutual >> exclusivity of fields, which is prone to failure and requires additional >> error checking. Take for example the key binding of access tokens. An >> access token could be bound to the RC=E2=80=99s key used during the requ= est, to a >> different key chosen by the AS, or it could be a bearer token with no ke= y >> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can de= fine it in terms of >> boolean values and objects and express this set of mutually-exclusive >> options in a non-ambiguous way. Without that, you=E2=80=99d need to have= different >> fields for the options and include additional checks in your parser to m= ake >> sure they weren=E2=80=99t sent simultaneously, otherwise you could get h= it with >> this potential security vulnerability in an object: >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> }, >> >> bearer_token: true, >> >> bind_to_rc_key: true >> >> } >> >> >> >> This would be an illegal object as per this alternate proposal, but then >> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t p= ut next to others >> in the same object. I=E2=80=99ve done this exercise with many other prot= ocols and >> it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9C= good=E2=80=9D examples >> would pass code that doesn=E2=80=99t check this. With the polymorphic ap= proach to >> this same field, each of these three mutually-exclusive states is writte= n >> in a way that they cannot be sent together. It=E2=80=99s not just illega= l, it=E2=80=99s >> impossible and enforced by the syntax of JSON itself. >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> } >> >> } >> >> >> >> // bearer token >> >> >> >> { >> >> key: false >> >> } >> >> >> >> // bound to the RC=E2=80=99s presented key >> >> >> >> { >> >> key: true >> >> } >> >> >> >> If someone sends a different type for this field, like an array or numbe= r >> or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and >> would be a protocol level error. >> >> >> >> While it might sound like polymorphism means that any field could have >> any type or value, the opposite is true: each possible value is explicit= ly >> typed, it=E2=80=99s just that there are potentially different types that= express >> meaning for the field. This applies to all members of all objects >> (dictionaries) as well as all members of an array (list). Every time you >> process a field value or other element, you look at the type and then th= e >> value to determine what to do with that typed value. >> >> >> >> In your example below, each field within the dictionary would also need >> to be typed, and each type would need to have a clear indication of its >> meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could >> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON = number) or an >> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would f= urther say what >> exactly the encoding of the string would be. That means that when you re= ad >> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confus= ion on what the value was >> or how it was represented, regardless of the input format. Seeing a numb= er >> there means exactly one interpretation and seeing a string means exactly >> one (different) interpretation =E2=80=94 but importantly, both of them a= re a >> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An >> implementation would likely use an internal BigInteger type of object to >> represent the field value after parsing, so the question is how to go fr= om >> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you appl= y it to all >> sub-fields of that object. >> >> >> >> So let=E2=80=99s dig into the specific bug you bring up in the strawman,= because >> it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings= , and not >> numbers, is not compliant with the JSON definitions of the field in >> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t= be treated >> the same by a parser implementation when mapping to a concrete object. I= t=E2=80=99s >> in this kind of automated guessing that this class of bugs occur, and >> that=E2=80=99s going to be the case whether or not you take advantage o= f JSON=E2=80=99s >> polymorphic nature. I=E2=80=99ve run into cases where a parser library w= as trying >> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up >> introducing errors in more strict components downstream. This is somethi= ng >> that protocol designers need to be aware of and guard against in the des= ign >> of the protocol to reduce possible ambiguities. Within GNAP today, we >> generally have things that branch whether they=E2=80=99re an object (for= a rich >> description of something) or some non-structured special value (for a >> reference or other item). >> >> >> >> The design team created some simple JSON Schemas for parts of the >> protocol during our discussion, but we didn=E2=80=99t include them in th= e design >> document due to both lack of time to keep it updated with the rapid chan= ges >> to the protocol during the design team discussion, and not knowing if th= ere >> would be interest in such material. I personally think it would be helpf= ul >> to include as an informative reference in the final document, but that= =E2=80=99s >> something for the working group to take up eventually. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >> >> >> >> Hello, everyone. >> >> >> >> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and >> when I made note about certain concerns, I was requested to send my >> comments to this working group. >> >> >> >> In short, I believe that the use of polymorphic JSON in the protocol >> invites subtle and confusing implementation problems. I also searched >> through the WG archives, and noticed that similar concerns were noted, >> briefly, in a thread in July. >> >> >> >> The problem with polymorphic values, as I see it, is that implementation= s >> will need to branch on the (inferred) type of a given field. This isn't >> quite as bad if the types are strictly different, but allows for subtle >> bugs when the value in question is a dictionary. What makes this >> unappealing is that "subtle bugs" in security protocols have a habit of >> turning into vulnerabilities. >> >> >> >> Let's say we have these imaginary payloads, both possible and valid in >> the same protocol step: >> >> >> >> # payload 1 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": >> >> } >> >> } >> >> >> >> # payload 2 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": "" >> >> } >> >> } >> >> >> >> In both cases, the type of "public_key" field is a dictionary. In both >> cases, they even have the same keys. However, the values in the >> dictionaries are entirely different, and an implementation will have to >> branch to at least two possible decoding mechanisms. To make things wors= e, >> some JSON implementations may choose to encode non-dictionary values as >> strings, so it is possible for an originator to transmit what they expec= t >> and believe to be payload 1 format, but which the receiver will interpre= t >> to be in payload 2 format. And if the encoded string contains only digit= s, >> it will even parse correctly as a bignum. >> >> >> >> While the above is clearly a manufactured scenario, it nonetheless >> demonstrates the potential for logic bugs with polymorphic JSON. With >> richer types and more complex dictionaries, there will surely be more ro= om >> for errors. >> >> >> >> Ambiguity in protocols is always a source of implementation complexity >> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, would= n't >> it be in everyone's interest to keep implementation complexity and mista= ke >> potential to a minimum? >> >> >> >> Best regards, >> >> Mika >> >> >> >> -- >> >> Mika Bostr=C3=B6m >> >> Smarkets >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> [image: Image removed by sender.]=E1=90=A7 >> >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> >> Mika Bostr=C3=B6m >> >> Smarkets >> >> -- TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000077529905b2d436af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi=C2=A0Mika, Justin, and WG,

    The= act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) has a = JSON object as its value. This claim could be a part of AT JWT or a token i= ntrospection response and has the same semantics in both cases. The JSON ob= ject as its value may look like this

    "act":
    {
    =C2=A0= "sub":"admin@example.c= om"
    }

    or even be nested like in

    "act":<= br>{
    =C2=A0"sub":"https://service16.example.com",
    =C2=A0 =C2=A0"act"= :
    =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0"sub":"https://service77.example.com"
    = =C2=A0 =C2=A0}
    }

    Personally, I find it to be a very expressive ap= proach. Also, as far I as know, several (oAuth2) client libraries have good= support of things like

    "aud":"https://service1.example.com" and "aud&quo= t;:["https://service1.example= .com","https://servi= ce2.example.com"]

    in AT JWTs for a quite long time.

    Regards,
    Andrii

    On Wed, Oct 28, 2020 at 12:5= 8 PM Fabien Imbault <fabien.= imbault@gmail.com> wrote:
    Hi Yaron,

    We'll indeed have to check how make it as idiomatic as p= ossible with experts of each language (help welcome).=C2=A0

    Regarding the client, the variations = are more limited but they do exist. Here I believe it's much more probl= ematic than on the server side and there are at least a few actions we shou= ld take:

    A) check in sec= 7 if we really have a compelling reason for key and proof variants. This i= s derived from larger discussions on key binding as per the related note. T= here are quite a few open questions related to this theme.=C2=A0

    B) there is also the choice betwee= n value/reference that may generate complexity.=C2=A0

    C) More generally, as many feedbacks already = have noticed, we need to have a systematic review and reduce the set of ava= ilable options in the protocol.=C2=A0

    Unless we have a clear= idea why runtime behavior requires mutability, it might be useful to have = a way to define the chosen variant before hand, so that the expected behavi= or becomes deterministic on the client side. There are various ways it coul= d be done in practice.=C2=A0

    For sure several independant implementations would help, es= pecially if we make sure they can work together.=C2=A0



    --

    Mika Bostr=C3=B6m

    =

    Smarkets

    -- TXAuth mailing list TXAu= th@ietf.org https://www.ietf.org/mailman/= listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000077529905b2d436af-- From nobody Fri Oct 30 05:53:59 2020 Return-Path: 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 5F4013A0E6E for ; Fri, 30 Oct 2020 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 VhqMIH_uFyaZ for ; Fri, 30 Oct 2020 05:53:52 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 9397C3A0E6D for ; Fri, 30 Oct 2020 05:53:52 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id k21so7346820ioa.9 for ; Fri, 30 Oct 2020 05:53:52 -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=jvKpQVZYqgu0oLzKEIerr9bAE1o3jRwaIckHx2sDleE=; b=SUHHERudIwDpOObXmTxDUEfoFXW3Su5UON+bJKpn1kS/mPY8uDFB09pz0LgwbvsjiZ vCpDe/kR2XfyERWYu9B4nL00TydlzorjY0G40KRghqPa+TvE4FvpCZLruEQ+vcTGgxjv HMgfMhMfq3uZGC+OKLQPe0Y+K7UDTaPXW+Hl0xXApC59YbqZJCMEDMjKZsnpNVXTb4ky tUi4WNqLFVFu1QGl34NT1LtJyI9GcDt3zacBN3YYUAAhxq7iRHcssN5lLzCdGMCYzhNi 428Ioy+cSZwNbx6o+kJVEXwb+nmtSwcu0s8kUEZc1BYf70lMUhzx8jGvw1zkRcwXsDaZ JN3g== 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=jvKpQVZYqgu0oLzKEIerr9bAE1o3jRwaIckHx2sDleE=; b=Aq7I88yAVEZCFSs5N0d5Xri0JGydnmehYo8lI46/5StvoppWheeNdLq+QQ8NOJdTTk qtXnO2XSoRHGv8Cv98D+qXcfayImBRzy1F272jVcTWove0gE5K0kvzXCQLJr0xegQOIL XGhQrm+cVNGSwMrJyOeOe49e5dFt03hSmACa8uS/e93BnFxLwTol5pPsZdTnwUwn2DTp bMYuzxHnXz1DU9eir5hfy76rj4Kawbf6taaqUVSqg5fyzjvDRXxojN9gHf+3xh9EMUha qKMdMdqidr5POyrfng/epVJ1RZfqFUB9Z4ZqiUYnuSMUHrQaf1DYpEjE2o4LIy6yzbKV PAeA== X-Gm-Message-State: AOAM530XO/CkVAjqhn6ZPlFPSUUalGZjQBQG1X2tJksRbqRbXH9KlSug iu6BL9mlDAT13sSN13bDou0+AJA25vISBXxN/94= X-Google-Smtp-Source: ABdhPJxIohxU5m3bAu1+mBFhD/xyqo1J7C4+3FJt/M7Edru00dbo8yEs47VTlUNuaYKUsRqp+TaGl+bc8LqdlAmHA3c= X-Received: by 2002:a6b:6001:: with SMTP id r1mr1639465iog.144.1604062431612; Fri, 30 Oct 2020 05:53:51 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 30 Oct 2020 13:53:38 +0100 Message-ID: To: Andrii Deinega Cc: =?UTF-8?Q?Mika_Bostr=C3=B6m?= , Justin Richer , Yaron Sheffer , GNAP Mailing List , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000006f125b05b2e2e300" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 12:53:58 -0000 --0000000000006f125b05b2e2e300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, > Regarding your question, what else could we propose? I've started a review of possibilities at https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md to be followed by actual code testing. Cheers, Fabien On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega wrote: > Hi Mika, Justin, and WG, > > The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) > has a JSON object as its value. This claim could be a part of AT JWT or a > token introspection response and has the same semantics in both cases. Th= e > JSON object as its value may look like this > > "act": > { > "sub":"admin@example.com" > } > > or even be nested like in > > "act": > { > "sub":"https://service16.example.com", > "act": > { > "sub":"https://service77.example.com" > } > } > > Personally, I find it to be a very expressive approach. Also, as far I as > know, several (oAuth2) client libraries have good support of things like > > "aud":"https://service1.example.com" and "aud":[" > https://service1.example.com","https://service2.example.com"] > > in AT JWTs for a quite long time. > > Regards, > Andrii > > On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault > wrote: > >> Hi Yaron, >> >> We'll indeed have to check how make it as idiomatic as possible with >> experts of each language (help welcome). >> >> Regarding the client, the variations are more limited but they do exist. >> Here I believe it's much more problematic than on the server side and th= ere >> are at least a few actions we should take: >> >> A) check in sec 7 if we really have a compelling reason for key and proo= f >> variants. This is derived from larger discussions on key binding as per = the >> related note. There are quite a few open questions related to this theme= . >> >> B) there is also the choice between value/reference that may generate >> complexity. >> >> C) More generally, as many feedbacks already have noticed, we need to >> have a systematic review and reduce the set of available options in the >> protocol. >> >> Unless we have a clear idea why runtime behavior requires mutability, it >> might be useful to have a way to define the chosen variant before hand, = so >> that the expected behavior becomes deterministic on the client side. The= re >> are various ways it could be done in practice. >> >> For sure several independant implementations would help, especially if w= e >> make sure they can work together. >> >> Anyway all this open to improvement. >> >> Cheers >> Fabien >> >> >> Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = a >> =C3=A9crit : >> >>> Hi Fabien, >>> >>> >>> >>> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is f= ar worse than the >>> problem. The code in the article you cite is very specific to the use c= ase >>> and IMHO quite ugly. So my preferred Go implementation would be a >>> combination of untyped structures (Go interface{}) and run-time enforce= ment >>> of JSON Schema. >>> >>> >>> >>> Also, going back to our earlier discussion on this topic, I just read >>> Sec. 7 of gnap-00 and realized that the RC also needs to deal with >>> polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *TXAuth on behalf of Fabien Imbault < >>> fabien.imbault@gmail.com> >>> *Date: *Wednesday, October 28, 2020 at 18:56 >>> *To: *Mika Bostr=C3=B6m >>> *Cc: *GNAP Mailing List , Justin Richer < >>> jricher@mit.edu>, Dick Hardt >>> *Subject: *Re: [GNAP] Feedback on polymorphism >>> >>> >>> >>> Thanks for the great feedback. Your concern is very valid. >>> >>> >>> >>> My implementation is in rust, which makes life easier in that specific >>> case. >>> >>> >>> >>> So I'm not a golang specialist but I guess the transcription of json >>> strings/arrays into go structs would work around the lines described by >>> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 >>> >>> When we have a more formalized json schema, I suggest we make a library >>> of json examples and some related code samples in mainstream languages,= to >>> check it is feasible for everyone. >>> >>> >>> >>> Cheers, >>> >>> Fabien >>> >>> >>> >>> >>> >>> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m >>> wrote: >>> >>> Hi everyone, >>> >>> >>> >>> Looks like I stuck my finger in a hornets' nest. First off, apologies >>> for not chipping in earlier, but there was a lot of material to digest. >>> Also, warning: lots to read ahead. >>> >>> >>> >>> I'm one of those people who end up making use of AuthN/AuthZ >>> functionality through a library. On top of that I can see myself being >>> roped in as a server (AS) implementation help. So I'm approaching this = from >>> an outsider's perspective. Someone who expects to be exposed to the >>> eventual RFC and all the nitty-gritty details. My relatively terse comm= ent >>> ended up at the top of the aforementioned HN thread, which didn't >>> necessarily help. Sorry about that. >>> >>> >>> >>> Now, having read Justin's initial reply - and the rest of the thread - = I >>> believe I can see where the desire for polymorphism comes from. To be >>> clear: I am all for strict types inside an implementation, as it will a= dd >>> helpful guard-rails to the state management code paths. However, I see = this >>> as a case of leaky abstraction. If we take the existing oauth.xyj-java = code >>> to be the reference implementation, the choice makes logical sense: JSO= N is >>> not expressive enough to serialise arbitrary objects, so in order to av= oid >>> writing complex payload parser(s) the internal implementation details n= ow >>> leak to the protocol itself. From a purely technical perspective, it's = a >>> cool trick. From a distance it even looks a bit like the result of prot= obuf >>> decoding, but without the generated code parts. >>> >>> >>> >>> But then the downside. I don't personally expect to be able to use the >>> reference implementation, being mostly a Python user myself. A fair num= ber >>> of AS implementations will be written with languages such as Go, Python= , >>> C#, Ruby, and JavaScript (thanks to node.js), and all of them will have= to >>> deal with the polymorphism. From what I've read over the past couple of >>> days, I understand that at least Go supports custom unmarshalers from J= SON >>> to typed structs, at the cost of an indirection. Normally when a Go cod= e >>> processes JSON to a typed struct, the process is helped by field >>> annotations in the type definition itself. For example, if the payload = for >>> a person in JSON was >>> >>> >>> >>> { >>> >>> "name": "", >>> >>> "age": , >>> >>> "country": "", >>> >>> "city": "" >>> >>> } >>> >>> >>> >>> .. then the type definition would look like: >>> >>> >>> >>> type Person struct { >>> >>> Name string `json:"name" >>> >>> Age int `json:"age"` >>> >>> Country string `json:"country"` >>> >>> City string `json:"city"` >>> >>> } >>> >>> >>> >>> When the (possibly complex) type of a given field is fixed, unmarshalin= g >>> should still be straightforward. I haven't verified, but since the >>> annotation only gives which field to look at for a given typed value, t= here >>> should be nothing special about that. But when the field can instead be= a >>> union of more than one distinct types, things start to get messy. There= is >>> no union type in the language at all, so the following construct is not >>> even possible: >>> >>> >>> >>> type Entity struct { >>> >>> Resources []string `json:"resources"` >>> >>> Client union(Client, string) `json:"client"` >>> >>> } >>> >>> >>> >>> As I understand, the implicit expectation is that in the above case, th= e >>> unmarshaler detects that "client" is a string, and so expands it from a= n >>> opaque handle to the expected, populated type. Even after thinking abou= t >>> the ramifications over the past few days I remain confused, because I d= on't >>> see how the commonly used annotations could work. If the expectation is >>> that protocol implementations should use strong types, then the use of >>> polymorphic JSON is very likely to make things _more_ complicated for >>> non-reference implementations. >>> >>> >>> >>> Hence my concern. I'm afraid that the leaky abstraction, while making >>> the reference implementation more robust and straightforward, contribut= es >>> to making other implementations less robust. And this being a security >>> protocol, the potential for brittle and/or confused implementations is >>> terrifying. >>> >>> >>> >>> I am a fan of reducing complexity, and from what I can see, for the >>> reference implementation the polymorphic approach actually does that. B= ut >>> I'm afraid it does so at others' expense. Languages have their individu= al >>> constraints, idioms and best practices. If parsing a protocol payload >>> introduces low-level complexities and encourages to go against common >>> practices, that is an invitation for problems. I am aware that my choic= e of >>> words in the HN thread was likely to put people on defense, and for tha= t I >>> apologise. But I do believe that the choice of polymorphic JSON is goin= g to >>> make the life and use of other implementations notably less boring than >>> people in general would prefer. >>> >>> >>> >>> Cheers, >>> >>> Mika >>> >>> >>> >>> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault >>> wrote: >>> >>> Hi Dick, >>> >>> >>> >>> Well technically yes. Obviously the client can present any interface it >>> seems fit. >>> >>> >>> >>> Still there's the question of the common model we want to present to th= e >>> outside world and supported by the protocol itself (which client librar= ies >>> all build upon). >>> >>> >>> >>> But beneath the polyphormism question, the HN debate seems on the >>> surface a lot like the original xyz (polyphormism goes along with the >>> reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and >>> where the client design has more latitude). Just explained differently,= by >>> outside people with different agendas. >>> >>> >>> >>> Which is a bit weird because many of the critics on HN (who criticize >>> polyphormism) also seem to really dislike OAuth in the first place (the >>> inconsistencies are partially due to a bunch of different people >>> commenting). >>> >>> >>> >>> Really to me there's no fundamental truth behind that question. It's a >>> matter of preference and priorities in the design. Whatever choices we >>> make, we'll have to be prepared to explain and justify them in the open= , >>> even to some people that will dislike pretty much whatever we do (becau= se >>> it's fun to look smart and critize without proposing alternatives). And= we >>> owe these answers to people like Mika, who genuinely try to make the be= st >>> of it. >>> >>> >>> >>> Fabien >>> >>> >>> >>> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a >>> =C3=A9crit : >>> >>> Hi Fabien >>> >>> >>> >>> A library developer can provide whatever abstraction layer makes sense >>> for the library's target audience and language. >>> >>> >>> >>> If the client library developer wants to use polymorphism in the >>> interface presented to the user's of the library, the library developer= can >>> do that independent of polymorphism in the protocol, and vice versa >>> >>> >>> >>> =3D> polymorphism in the protocol has no impact on client library >>> developers >>> >>> >>> >>> >>> >>> [image: Image removed by sender.]=E1=90=A7 >>> >>> >>> >>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >>> wrote: >>> >>> I'm just realizing your "least to most important" might actually say th= e >>> same as what I was trying to say. So I'm not even sure what we're argui= ng >>> against :-) >>> >>> >>> >>> In brief my point if it wasn't clear is that we should be crystal clear >>> on where we put the cursor of simplicity, because this can mean differe= nt >>> things for different people and different roles. >>> >>> And as we see on HN we need to better explain our design choices. >>> >>> >>> >>> >>> >>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >>> a =C3=A9crit : >>> >>> Hi Dick, >>> >>> >>> >>> Independantly from the debate on polyphormism, I beg to differ on your >>> order preference. >>> >>> >>> >>> Your assumption is that AS devs matter the most, because they're doing >>> the important security implementation. But eating our own dogfood might >>> help a lot to change that view. Most security issues occur because user= s of >>> the spec are unable to deal with the complexity that is passed onto the= m. >>> >>> >>> >>> 99% of the people that will actually use the output of the work are >>> application developers (client or RS) and their own users. >>> >>> >>> >>> Our intent as well as the protocol drive the usage. Client libraries ma= y >>> help, but they're not a silver bullet, especially because GNAP ultimate= ly >>> has no control about what people do there (for better or worse). And >>> everything we do here will help get to the better part. >>> >>> >>> >>> I'm not saying we don't intend to also care about AS developers >>> (beginning with ourselves) but it's a second order optimisation. And si= nce >>> it's a tendancy we're leaning towards by default, I'm pretty sure we wo= n't >>> forget that anyway. >>> >>> >>> >>> Fabien >>> >>> >>> >>> >>> >>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a >>> =C3=A9crit : >>> >>> I'm confused by your logic Fabien. >>> >>> >>> >>> If a client library developer wants to expose polymorphism, they can do >>> that independent of what is in the protocol. >>> >>> >>> >>> I differ on who our stakeholders are. >>> >>> >>> >>> I think our stakeholders are in least to most important: >>> >>> >>> >>> - AS developer >>> - RS developer >>> - client developer >>> - user >>> >>> >>> >>> A client library developer can expose whatever interface they want to >>> simplify implementation. >>> >>> >>> >>> I list the user so that we don't lose site of a critical role. >>> >>> >>> >>> /Dick >>> >>> >>> >>> >>> >>> [image: Image removed by sender.]=E1=90=A7 >>> >>> >>> >>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >>> wrote: >>> >>> Hi there, >>> >>> >>> >>> Let me try to approach the issue under a different light. More like a >>> product manager would deal with feature selection to make it intuitive = for >>> its users. >>> >>> >>> >>> For most people, riding a bike is far easier than using a unicycle. >>> Feels more stable. And yet it's way easier to design for a single wheel >>> than to build with 2. Because then you'll need a lot more accessories >>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be = a >>> brittle process, it can be industrialized. >>> >>> >>> >>> Back to the GNAP topic. >>> >>> Ultimately we should strive to make the spec as simple as can be. But w= e >>> need to ask: simple for whom? For the bike owner or for the bike vendor= ? >>> >>> (short answer: the priority should be simplicity for spec users, not >>> spec implementers and even less spec designers). >>> >>> >>> >>> The initial question that is asked is very interesting: isn't the desig= n >>> flawed if GNAP is using json polyphormism? Or if the AS needs to handle= the >>> state of the request? Or if we must handle token revocation? Or if we a= re >>> looking for a global unique identifier? The argument stems of the fact = that >>> is still arguably harder and more error prone to implement. Fair enough= . >>> >>> >>> >>> From a spec implementer's perspective, it may well be more complex. It >>> mostly impacts the json library you'll end up using, plus a bit of >>> input/output decoration around it. Even golang provides utilities for t= his, >>> despite not exactly being made for this kind of purpose. >>> >>> My practical experience implementing it is that it's not that big a >>> deal. I mean, I wished it could be simpler, but it's manageable and the= re >>> are other ways to reach levels of insurance that it does work as intend= ed >>> (json schema, test cases to validate the implementation, etc.). Arguabl= y it >>> is still easier from an implementation perspective than say, json-ld, w= hich >>> is massively used in the SSI community. >>> >>> >>> >>> But ultimately who are we designing for? Are we striving to go easy on >>> the spec implementer? Or are we trying to make sure end-developers usin= g >>> the client libraries won't shoot themselves in the foot? >>> >>> >>> >>> The job to be done (JTBD), from the end-developer's perspective, is to >>> efficiently ship an application. And provide authN/authZ capabilities f= or >>> end-users by relying on some well known implementation. >>> >>> In turn, this spec implementer will rely on cryptographic utility >>> libraries that deals internally with the complexity of their own domain= , so >>> that we don't have to. And here we could launch another HN flame war th= at >>> starts with the title "JWT sucks because". Which does have its set of v= ery >>> real issues but that's beyond the point. >>> >>> Note that any decent flamewar will be efficiently fueled by people >>> hating medium. Is it outrageous for blog posts to be behind a paywall? >>> Maybe but it's even more outrageous to lack consistency, either by not >>> knowing how to get around a paywall if you're into a hacker punk moveme= nt, >>> or on the contrary by to not paying a subscription if you believe that >>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated. >>> >>> What likely seems an unnecessary sidenote tries to illustrate the point= : >>> for Justin it was easier to publish on medium, because as a blog publis= her, >>> you might not want to deal with hosting your own blog. But maybe as a >>> reader you'll find that annoying. Different audiences, different JTBD, >>> different tradeoffs. >>> >>> >>> >>> Polyphormism is a tool that enables the end-developer to have minimal >>> knowledge of what it means to deal with a GNAP client library. You prep= are >>> the request, send to the endpoint and you're good to go. Massively simp= ler >>> than OAuth2 or any similar protocol by the way (as anyone with teaching >>> experience on the subject might acknowledge). And there's a lot more t= o be >>> done to make sure we indeed reduce the complexity for the end-developer= and >>> the end-user. >>> >>> >>> >>> If we find a better way to deal with that simplicity balance, I'm all >>> in. But the arguments need to be way more convincing than just saying t= hat >>> it may be difficult to implement or validate. >>> >>> >>> >>> Cheers. >>> >>> Fabien >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a = =C3=A9crit : >>> >>> >>> >>> >>> >>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>> >>> >>> >>> Justin >>> >>> >>> >>> I did note that I was the one that argued for instance_id being in the >>> object. Since it is in the object in the current draft, not including a >>> pass by reference option would be preferable. >>> >>> >>> >>> As for concrete examples: >>> >>> - version of client >>> >>> - version of OS >>> >>> - security attestation of OS / device >>> >>> - location of client device >>> >>> - network client is operating on >>> >>> >>> >>> These are all attributes of the client that an AS may require on the >>> initial grant request, and in future grant requests (which is when an >>> instance_id) would be used. >>> >>> >>> >>> >>> >>> This is where our interpretations differ: I don=E2=80=99t see these as >>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key= , display >>> information, class identifiers, and other items currently represented b= y an >>> instance_id are attributes of the client instance. The attestation >>> components don=E2=80=99t modify the instance so much as present additio= nal >>> information on top of the client instance itself. This is why I argue t= hat >>> they ought to be handled in a separate object, so you=E2=80=99d have so= mething like >>> this strawman: >>> >>> >>> >>> { >>> >>> >>> >>> posture: { >>> >>> software_version: 1.2.3, >>> >>> os_version: 14.3.2 >>> >>> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >>> >>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>> >>> }, >>> >>> >>> >>> client: =E2=80=9Cclient-541-ab" >>> >>> >>> >>> } >>> >>> >>> >>> This is a more fundamental question about GNAP than whether the syntax >>> uses polymorphism: this is about GNAP being very explicit about the dat= a >>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mod= el of what >>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply p= roblematic in >>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with hav= ing to >>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that does= n=E2=80=99t fully capture >>> the different aspects that are out there. I think we=E2=80=99re getting= closer here >>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, = but we still need to >>> be more precise about what exactly a client instance includes, and what= it >>> does not. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> >>> >>> /Dick >>> >>> >>> >>> [image: Image removed by sender.]=E1=90=A7 >>> >>> >>> >>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >>> >>> Dick, >>> >>> >>> >>> As you=E2=80=99ll recall, I argued against including the client instanc= e >>> identifier inside of the object as a mutually-exclusive field precisely >>> because of the principle violation that you are pointing out here, and = so >>> it=E2=80=99s important to point out that the current text is a compromi= se that >>> needs to be examined in the wider experience of the working group. I am= on >>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >>> object, but this needs to be explored. >>> >>> >>> >>> The crux of my argument is that is exactly a case of pass-by-reference >>> vs pass-by-value, and that runtime attestations are not part of the =E2= =80=9Cclient >>> instance=E2=80=9D value itself but rather belong outside of that object= in a >>> another part of the request. As stated in the editorial notes in this >>> section, we need to look carefully at how these concepts fit within the >>> model and where we would want to put them. Without concrete examples of >>> what these extensions look like and how they=E2=80=99re generated, that= is nearly >>> impossible to do at this stage. I look forward to seeing examples of th= is >>> kind of data and how it can fit into the protocol. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>> >>> >>> >>> Hey Justin, >>> >>> >>> >>> As the draft has evolved, I question the continued use of polymorphism. >>> Note that I appreciate the elegance of using a string for >>> pass-by-reference, and an object for pass-by-value. >>> >>> >>> >>> In the current draft, the >>> >>> >>> >>> Every time you create or process a field it will mean only one thing, >>> and there=E2=80=99s only one field to look at to answer a question. >>> >>> >>> >>> is violated in 2.3.1. Identifying the RC Instance >>> >>> >>> >>> >>> >>> >>> instance_id An identifier string that the AS can use to identify th= e >>> >>> particular instance of this RC. The content and structure of thi= s >>> >>> identifier is opaque to the RC. >>> >>> >>> >>> "client": { >>> >>> "instance_id": "client-541-ab" >>> >>> } >>> >>> >>> >>> If there are no additional fields to send, the RC MAY send the >>> >>> instance identifier as a direct reference value in lieu of the >>> >>> object. >>> >>> >>> >>> "client": "client-541-ab" >>> >>> >>> >>> The instance identifier can be sent two ways. Polymorphism is a >>> convenience for the client, but requires the server to have two code pa= ths >>> for "instance_id". We discussed this in the design team, and I argued = for >>> having "instance_id" in the "client" object so that any updates, such a= s >>> new devices assertions, could be in the "client" object. As noted above= , >>> while I appreciate the elegance of using a string (handle) to reference= a >>> previously provided object, it complicates how to update an existing ob= ject >>> while providing the reference. >>> >>> >>> >>> In your example of the "key" object below, setting "proof" to bearer >>> would avoid the issue you describe: >>> >>> >>> >>> { >>> "key": { >>> "proof": "bearer" >>> } >>> } >>> >>> >>> >>> In your example, when processing the "key" object, code is having to >>> check both the JSON type of the property, as well as check the value of= the >>> "proof" property. In the example I provided, only the value of "proof" >>> needs to be checked. The "proof" property is acting as a type for the "= key" >>> object. >>> >>> >>> >>> Not being a Java programmer, I don't know how this would work in a Java >>> implementation, but node.js, the processing would need to be done as ab= ove. >>> >>> >>> >>> On a related note, there was significant negative feedback on handles >>> and polymorphism in the Hacker News article >>> https://news.ycombinator.com/item?id=3D24855750 >>> >>> >>> >>> /Dick >>> >>> >>> >>> >>> >>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >>> >>> Hi Mika, >>> >>> >>> >>> Thanks for bringing this topic here =E2=80=94 I was able to see the for= um >>> discussion that brought you here, and hopefully I can help clear up wha= t I >>> mean with how polymorphism is used in the proposal. The short version i= s >>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>> protocols, and so in that goal we=E2=80=99re fully aligned. I think tha= t using >>> polymorphism in very specific ways can help that goal =E2=80=94 just as= I agree >>> that misusing it or applying it sloppily can lead to ambiguous and inse= cure >>> systems. >>> >>> >>> >>> Some background: I built out the XYZ protocol (one of the predecessors >>> to the initial GNAP Draft) in Java using strongly typed parsers and Jav= a >>> objects specifically to prove to myself that it could be done in a way = that >>> made any sense in the code. (My own open source implementation is at >>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not = yet up >>> to date with the GNAP spec). It was important to me that I be able to u= se >>> the system-wide configured parsers to implement this and not have to re= sort >>> to stepping through elements completely by hand. Java doesn=E2=80=99t m= ake it >>> simple to get the hooks into the right places (especially with the Jack= son >>> parser that I used), but it is definitely possible to create a >>> deterministic and strongly-typed parser and serializer for this kind of >>> data structure. Some of the rationale for using polymorphism is covered= in >>> the trailing appendix of the draft document ( >>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#n= ame-json-structures-and-polymor), >>> but it=E2=80=99s still good to discuss this here as the working group d= ecides which >>> approaches to take. >>> >>> >>> >>> The driving reason for using polymorphism at the protocol level was to >>> simplify the protocol and make it :more: deterministic to create and >>> process, not less. Every time you create or process a field it will mea= n >>> only one thing, and there=E2=80=99s only one field to look at to answer= a question. >>> Without polymorphic field values, you usually need to rely on mutual >>> exclusivity of fields, which is prone to failure and requires additiona= l >>> error checking. Take for example the key binding of access tokens. An >>> access token could be bound to the RC=E2=80=99s key used during the req= uest, to a >>> different key chosen by the AS, or it could be a bearer token with no k= ey >>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can d= efine it in terms of >>> boolean values and objects and express this set of mutually-exclusive >>> options in a non-ambiguous way. Without that, you=E2=80=99d need to hav= e different >>> fields for the options and include additional checks in your parser to = make >>> sure they weren=E2=80=99t sent simultaneously, otherwise you could get = hit with >>> this potential security vulnerability in an object: >>> >>> >>> >>> { >>> >>> key: { >>> >>> proof: httpsig, >>> >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> >>> }, >>> >>> bearer_token: true, >>> >>> bind_to_rc_key: true >>> >>> } >>> >>> >>> >>> This would be an illegal object as per this alternate proposal, but the= n >>> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others >>> in the same object. I=E2=80=99ve done this exercise with many other pro= tocols and >>> it=E2=80=99s both error prone and easy to ignore since all the =E2=80= =9Cgood=E2=80=9D examples >>> would pass code that doesn=E2=80=99t check this. With the polymorphic a= pproach to >>> this same field, each of these three mutually-exclusive states is writt= en >>> in a way that they cannot be sent together. It=E2=80=99s not just illeg= al, it=E2=80=99s >>> impossible and enforced by the syntax of JSON itself. >>> >>> >>> >>> { >>> >>> key: { >>> >>> proof: httpsig, >>> >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> >>> } >>> >>> } >>> >>> >>> >>> // bearer token >>> >>> >>> >>> { >>> >>> key: false >>> >>> } >>> >>> >>> >>> // bound to the RC=E2=80=99s presented key >>> >>> >>> >>> { >>> >>> key: true >>> >>> } >>> >>> >>> >>> If someone sends a different type for this field, like an array or >>> number or a null, this doesn=E2=80=99t have a defined interpretation in= the >>> protocol and would be a protocol level error. >>> >>> >>> >>> While it might sound like polymorphism means that any field could have >>> any type or value, the opposite is true: each possible value is explici= tly >>> typed, it=E2=80=99s just that there are potentially different types tha= t express >>> meaning for the field. This applies to all members of all objects >>> (dictionaries) as well as all members of an array (list). Every time yo= u >>> process a field value or other element, you look at the type and then t= he >>> value to determine what to do with that typed value. >>> >>> >>> >>> In your example below, each field within the dictionary would also need >>> to be typed, and each type would need to have a clear indication of its >>> meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could >>> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON= number) or an >>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would = further say what >>> exactly the encoding of the string would be. That means that when you r= ead >>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confu= sion on what the value was >>> or how it was represented, regardless of the input format. Seeing a num= ber >>> there means exactly one interpretation and seeing a string means exactl= y >>> one (different) interpretation =E2=80=94 but importantly, both of them = are a >>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determin= es the type. An >>> implementation would likely use an internal BigInteger type of object t= o >>> represent the field value after parsing, so the question is how to go f= rom >>> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you app= ly it to all >>> sub-fields of that object. >>> >>> >>> >>> So let=E2=80=99s dig into the specific bug you bring up in the strawman= , because >>> it=E2=80=99s interesting: A JSON encoder that encodes numbers as string= s, and not >>> numbers, is not compliant with the JSON definitions of the field in >>> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >>> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated >>> the same by a parser implementation when mapping to a concrete object. = It=E2=80=99s >>> in this kind of automated guessing that this class of bugs occur, and >>> that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s >>> polymorphic nature. I=E2=80=99ve run into cases where a parser library = was trying >>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, b= ut ended up >>> introducing errors in more strict components downstream. This is someth= ing >>> that protocol designers need to be aware of and guard against in the de= sign >>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>> generally have things that branch whether they=E2=80=99re an object (fo= r a rich >>> description of something) or some non-structured special value (for a >>> reference or other item). >>> >>> >>> >>> The design team created some simple JSON Schemas for parts of the >>> protocol during our discussion, but we didn=E2=80=99t include them in t= he design >>> document due to both lack of time to keep it updated with the rapid cha= nges >>> to the protocol during the design team discussion, and not knowing if t= here >>> would be interest in such material. I personally think it would be help= ful >>> to include as an informative reference in the final document, but that= =E2=80=99s >>> something for the working group to take up eventually. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>> >>> >>> >>> Hello, everyone. >>> >>> >>> >>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum an= d >>> when I made note about certain concerns, I was requested to send my >>> comments to this working group. >>> >>> >>> >>> In short, I believe that the use of polymorphic JSON in the protocol >>> invites subtle and confusing implementation problems. I also searched >>> through the WG archives, and noticed that similar concerns were noted, >>> briefly, in a thread in July. >>> >>> >>> >>> The problem with polymorphic values, as I see it, is that >>> implementations will need to branch on the (inferred) type of a given >>> field. This isn't quite as bad if the types are strictly different, but >>> allows for subtle bugs when the value in question is a dictionary. What >>> makes this unappealing is that "subtle bugs" in security protocols have= a >>> habit of turning into vulnerabilities. >>> >>> >>> >>> Let's say we have these imaginary payloads, both possible and valid in >>> the same protocol step: >>> >>> >>> >>> # payload 1 >>> >>> { >>> >>> ..., >>> >>> "public_key": { >>> >>> "alg": "rsa", >>> >>> "modulus": >>> >>> } >>> >>> } >>> >>> >>> >>> # payload 2 >>> >>> { >>> >>> ..., >>> >>> "public_key": { >>> >>> "alg": "rsa", >>> >>> "modulus": "" >>> >>> } >>> >>> } >>> >>> >>> >>> In both cases, the type of "public_key" field is a dictionary. In both >>> cases, they even have the same keys. However, the values in the >>> dictionaries are entirely different, and an implementation will have to >>> branch to at least two possible decoding mechanisms. To make things wor= se, >>> some JSON implementations may choose to encode non-dictionary values as >>> strings, so it is possible for an originator to transmit what they expe= ct >>> and believe to be payload 1 format, but which the receiver will interpr= et >>> to be in payload 2 format. And if the encoded string contains only digi= ts, >>> it will even parse correctly as a bignum. >>> >>> >>> >>> While the above is clearly a manufactured scenario, it nonetheless >>> demonstrates the potential for logic bugs with polymorphic JSON. With >>> richer types and more complex dictionaries, there will surely be more r= oom >>> for errors. >>> >>> >>> >>> Ambiguity in protocols is always a source of implementation complexity >>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, woul= dn't >>> it be in everyone's interest to keep implementation complexity and mist= ake >>> potential to a minimum? >>> >>> >>> >>> Best regards, >>> >>> Mika >>> >>> >>> >>> -- >>> >>> Mika Bostr=C3=B6m >>> >>> Smarkets >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> [image: Image removed by sender.]=E1=90=A7 >>> >>> >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> >>> Mika Bostr=C3=B6m >>> >>> Smarkets >>> >>> -- TXAuth mailing list TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006f125b05b2e2e300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Justin,=C2=A0

    > Regarding your qu= estion, what else could we propose?=C2=A0

    I've= started a review of possibilities at=C2=A0https://github.com/fimba= ult/reasonably-polymorphic/blob/main/README.md to be followed by actual= code testing.=C2=A0

    Cheers,
    Fabien<= /div>

    On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega <andrii.deinega@gmail.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    Hi= =C2=A0Mika, Justin, and WG,

    The act (actor) claim intro= duced in RFC 8693 (OAuth 2.0 Token Exchange) has a JSON object as its value= . This claim could be a part of AT JWT or a token introspection response an= d has the same semantics in both cases. The JSON object as its value may lo= ok like this

    "act":
    {
    =C2=A0 "sub":"<= a href=3D"mailto:admin@example.com" target=3D"_blank">admin@example.com= "
    }

    or even be nested like in

    "act":
    {=C2=A0"sub":"https://service16.example.com",
    =C2=A0 =C2=A0&qu= ot;act":
    =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0"sub":&quo= t;https://servi= ce77.example.com"
    =C2=A0 =C2=A0}
    }

    Personally, I find= it to be a very expressive approach. Also, as far I as know, several (oAut= h2) client libraries have good support of things like

    "aud"= ;:"https://= service1.example.com" and "aud":["https://service1.example.com&= quot;,"http= s://service2.example.com"]

    in AT JWTs for a quite long time= .

    Regards,
    Andrii

    On Wed, Oct 28, 202= 0 at 12:58 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron,
    We'll indeed have to check ho= w make it as idiomatic as possible with experts of each language (help welc= ome).=C2=A0

    Regarding th= e client, the variations are more limited but they do exist. Here I believe= it's much more problematic than on the server side and there are at le= ast a few actions we should take:

    A) check in sec 7 if we really have a compelling reason for key a= nd proof variants. This is derived from larger discussions on key binding a= s per the related note. There are quite a few open questions related to thi= s theme.=C2=A0

    B) there = is also the choice between value/reference that may generate complexity.=C2= =A0

    C) More generally, a= s many feedbacks already have noticed, we need to have a systematic review = and reduce the set of available options in the protocol.=C2=A0

    Unless we have a clear idea why runtime behavior requires mutability, it= might be useful to have a way to define the chosen variant before hand, so= that the expected behavior becomes deterministic on the client side. There= are various ways it could be done in practice.=C2=A0

    For sure several independant imple= mentations would help, especially if we make sure they can work together.= =C2=A0

    Anyway all this o= pen to improvement.=C2=A0

    Cheers=C2=A0
    Fabien=C2=A0


    Le mer.= 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.com&= gt; a =C3=A9crit=C2=A0:

    Hi Fabien,

    =C2=A0

    At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is f= ar worse than the problem. The code in the article you cite is very specifi= c to the use case and IMHO quite ugly. So my preferred Go implementation wo= uld be a combination of untyped structures (Go interface{}) and run-time en= forcement of JSON Schema.

    = =C2=A0

    Also, going back to our earlier dis= cussion on this topic, I just read Sec. 7 of gnap-00 and realized that the = RC also needs to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D value), = not only the AS.

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Yaron

    =C2= =A0

    From: <= /b>TXAuth <tx= auth-bounces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, October 28,= 2020 at 18:56
    To: Mika Bostr=C3=B6m <mika.b= ostrom@smarkets.com>
    Cc: GNAP Mailing List <txa= uth@ietf.org>, Justin Richer <jricher@mit.edu>, Di= ck Hardt <dick.hardt@gmail.com>
    Subject: R= e: [GNAP] Feedback on polymorphism

    =C2=A0

    Thanks for the great feedback. Your concern is very valid.=C2=A0=

    =C2=A0

    My implementation is in rust, which makes life easi= er in that specific case.=C2=A0

    =C2=A0

    So= I'm not a golang specialist but I guess the transcription of json stri= ngs/arrays into go structs would work around the lines described by=C2=A0https://medium.com/@alexk= appa/json-polymorphism-in-go-4cade1e58ed1

    <= p class=3D"MsoNormal">When we have a more formalized json schema, I suggest= we make a library of json examples and some related code samples in mainst= ream languages, to check it is feasible for everyone.=C2=A0

    =C2=A0

    Cheers,

    Fabien

    =C2=A0<= u>

    =C2=A0

    <= div>

    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6= m <mika.bostrom@smarkets.com> wrote:<= /u>

    Hi eve= ryone,

    =C2=A0<= /u>

    Looks like I stuck my finger in a = hornets' nest. First off, apologies for not chipping in earlier, but th= ere was a lot of material to digest. Also, warning: lots to read ahead.<= /u>

    =C2=A0

    I'm one of those people who end up makin= g use of AuthN/AuthZ functionality through a library. On top of that I can = see myself being roped in as a server (AS) implementation help. So I'm = approaching this from an outsider's perspective. Someone who expects to= be exposed to the eventual RFC and all the nitty-gritty details. My relati= vely terse comment ended up at the top of the aforementioned HN thread, whi= ch didn't necessarily help. Sorry about that.

    =C2=A0

    Now, having read Justin's initial reply - and the rest of the = thread - I believe I can see where the desire for polymorphism comes from. = To be clear: I am all for strict types inside an implementation, as it will= add helpful guard-rails to the state management code paths. However, I see= this as a case of leaky abstraction. If we take the existing oauth.xyj-jav= a code to be the reference implementation, the choice makes logical sense: = JSON is not expressive enough to serialise arbitrary objects, so in order t= o avoid writing complex payload parser(s) the internal implementation detai= ls now leak to the protocol itself. From a purely technical perspective, it= 's a cool trick. From a distance it even looks a bit like the result of= protobuf decoding, but without the generated code parts.

    =

    =C2=A0

    But then the downside. I don't personally expect to be= able to use the reference implementation, being mostly a Python user mysel= f. A fair number of AS implementations will be written with languages such = as Go, Python, C#, Ruby, and JavaScript (thanks to node.js), and all of the= m will have to deal with the polymorphism. From what I've read over the= past couple of days, I understand that at least Go supports custom unmarsh= alers from JSON to typed structs, at the cost of an indirection. Normally w= hen a Go code processes JSON to a typed struct, the process is helped by fi= eld annotations in the type definition itself. For example, if the payload = for a person in JSON was

    =C2=A0

    {<= /p>

    =C2=A0 "name": "<str= ing>",

    =C2=A0 &q= uot;age": <int>,

    =C2=A0 "country": "<string>",

    =C2=A0 "city": "<stri= ng>"

    }=

    =C2=A0

    .. then the type definition would look like:

    =C2=A0

    type Person struct {

    =C2=A0 Name string `json:"name"<= u>

    =C2=A0 Age int `json:"age&= quot;`

    =C2=A0 Country st= ring `json:"country"`

    =C2=A0 City string `json:"city"`

    <= div>

    }

    =C2=A0

    When the (po= ssibly complex) type of a given field is fixed, unmarshaling should still b= e straightforward. I haven't verified, but since the annotation only gi= ves which field to look at for a given typed value, there should be nothing= special about that. But when the field can instead be a union of more than= one distinct types, things start to get messy. There is no union type in t= he language at all, so the following construct is not even possible:=

    =C2=A0

    =

    type Entity struct {

    =C2=A0 Resources []string `json:"resources&qu= ot;`

    =C2=A0 Client union= (Client, string) `json:"client"`

    }

    = =C2=A0

    As I understand, the= implicit expectation is that in the above case, the unmarshaler detects th= at "client" is a string, and so expands it from an opaque handle = to the expected, populated type. Even after thinking about the ramification= s over the past few days I remain confused, because I don't see how the= commonly used annotations could work. If the expectation is that protocol = implementations should use strong types, then the use of polymorphic JSON i= s very likely to make things _more_ complicated for non-reference implement= ations.

    =C2=A0

    Hence my concern. I'm afraid that= the leaky abstraction, while making the reference implementation more robu= st and straightforward, contributes to making other implementations less ro= bust. And this being a security protocol, the potential for brittle and/or = confused implementations is terrifying.

    =C2=A0

    I am a= fan of reducing complexity, and from what I can see, for the reference imp= lementation the polymorphic approach actually does that. But I'm afraid= it does so at others' expense. Languages have their individual constra= ints, idioms and best practices. If parsing a protocol payload introduces l= ow-level complexities and encourages to go against common practices, that i= s an invitation for problems. I am aware that my choice of words in the HN = thread was likely to put people on defense, and for that I apologise. But I= do believe that the choice of polymorphic JSON is going to make the life a= nd use of other implementations notably less boring than people in general = would prefer.

    =C2= =A0

    Cheers,

    Mika

    =C2=A0

    On = Mon, 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:

    <= div>

    Hi Dick,

    =C2=A0

    Well techni= cally yes. Obviously the client can present any interface it seems fit.=C2= =A0

    =C2=A0=

    Still there's the question of the= common model we want to present to the outside world and supported by the = protocol itself (which client libraries all build upon).=C2=A0

    =C2=A0

    <= p class=3D"MsoNormal">But beneath the polyphormism question, the HN debate = seems on the surface a lot like the original xyz (polyphormism goes along w= ith the reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit,= and where the client design has more latitude). Just explained differently= , by outside people with different agendas.=C2=A0

    =C2=A0

    Which is a bit weird because many of the critics on HN (who critic= ize polyphormism) also seem to really dislike OAuth in the first place (the= inconsistencies are partially due to a bunch of different people commentin= g).=C2=A0

    =C2=A0<= u>

    Really to me there's no fun= damental truth behind that question. It's a matter of preference and pr= iorities in the design. Whatever choices we make, we'll have to be prep= ared to explain and justify them in the open, even to some people that will= dislike pretty much whatever we do (because it's fun to look smart and= critize without proposing alternatives). And we owe these answers to peopl= e like Mika, who genuinely try to make the best of it.=C2=A0<= /p>

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    Le lun. = 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:

    =

    Hi Fabien

    =C2=A0

    A library= developer can provide whatever abstraction layer makes sense for the libra= ry's target=C2=A0audience and language.

    =C2=A0

    If the client library=C2=A0developer wants to use polymorphism=C2=A0in t= he interface presented to the user's of the library, the library develo= per can do that independent of polymorphism in the protocol, and vice versa= =C2=A0

    =C2=A0<= /u>

    =3D> polymorphism in the protoc= ol has no impact on client library developers

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0

    3D"Image<= span style=3D"font-size:7.5pt;font-family:Gadugi,sans-serif;color:white">= =E1=90=A7

    =C2= =A0

    On Sat, Oct 24, 2020 at 3:40= PM Fabien Imbault <fabien.imbault@gmail.com> wr= ote:

    I'm just realizing your "least to most important" might a= ctually say the same as what I was trying to say. So I'm not even sure = what we're arguing against :-)=C2=A0

    =C2=A0

    In bri= ef my point if it wasn't clear is that we should be crystal clear on wh= ere we put the cursor of simplicity, because this can mean different things= for different people and different roles.=C2=A0

    And as we see on HN we need to better explain our = design choices.=C2=A0

    =C2=A0

    =C2=A0

    Le dim. 25 oct. 2020 =C3=A0 00:25, F= abien Imbault <fabien.imbault@gmail.com> a =C3= =A9crit=C2=A0:

    Hi Dick,

    =C2=A0

    Independantly from the = debate on polyphormism, I beg to differ on your order preference.=C2=A0<= /u>

    =C2=A0

    Your assumption is that AS devs matter the m= ost,=C2=A0because they're = doing the important security implementation. But eating our own dogfood mig= ht help a lot to change that view. Most security issues occur because users= of the spec are unable to deal with the complexity that is passed onto the= m.=C2=A0

    = =C2=A0

    99% of the people that w= ill actually use the output of the work are application developers (client = or RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the protocol dr= ive the usage. Client libraries may help, but they're not a silver bull= et, especially because GNAP ultimately has no control about what people do = there (for better or worse). And everything we do here will help get to the= better part.=C2=A0

    =C2=A0

    I'm not sa= ying we don't intend to also care about AS developers (beginning with o= urselves) but it's a second order optimisation. And since it's a te= ndancy we're leaning towards by default, I'm pretty sure we won'= ;t forget that anyway.=C2=A0

    =C2=A0

    Fabien= =C2=A0

    =C2=A0<= /u>

    <= /u>=C2=A0

    Le sam. 24 oct. 2020 = =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a = =C3=A9crit=C2=A0:

    I'm confused by your logic Fabien.

    =C2=A0

    If a client library developer wants to expose polymorphism, they c= an do that independent of what is in the protocol.=C2=A0

    <= /div>

    =C2=A0

    I differ on who our stakeholders are.=C2=A0

    =C2=A0

    I think our stakeholders are in least to most important:=

    =C2=A0

    • AS developer
    • RS developer
    • client developer
    • u= ser

    =C2=A0<= u>

    A client library developer can = expose whatever interface they want to simplify implementation.

    =C2=A0

    =

    I list the user so that we don't lose site of a = critical role.

    = =C2=A0

    /Dick

    <= /div>

    =C2=A0

    =C2=A0

    3D"Image=E1=90=A7

    =C2=A0

    On Fri, Oct 23, 2020 at= 6:27 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:

    Hi there,=C2=A0

    =C2=A0

    Let me try to a= pproach the issue under a different light. More like a product manager woul= d deal with feature selection to make it intuitive for its users.=C2=A0<= /u>

    =C2=A0

    For most people, riding a bike is far easier = than using a unicycle. Feels more stable. And yet it's way easier to de= sign for a single wheel than to build with 2. Because then you'll need = a lot more accessories (chain, chain ring, etc.). Even so producing a bike = doesn't have to be a brittle process, it can be industrialized.=C2=A0

    =C2=A0

    <= /div>

    Back to the GNAP topic.=C2=A0

    Ultimately we should strive to make the spec as simple as can be. But we= need to ask: simple for whom? For the bike owner or for the bike vendor?= =C2=A0

    (short answer: the priority should be si= mplicity for spec users, not spec implementers and even less spec designers= ).=C2=A0

    = =C2=A0

    The initial question tha= t is asked is very interesting: isn't the design flawed if GNAP is usin= g json polyphormism? Or if the AS needs to handle the state of the request?= Or if we must handle token revocation? Or if we are looking for a global u= nique identifier? The argument stems of the fact that is still arguably har= der and more error prone to implement. Fair enough.=C2=A0

    =

    =C2=A0

    From a spec implementer's perspective, it may well be = more complex. It mostly impacts the json library you'll end up using, p= lus a bit of input/output decoration around it. Even golang provides utilit= ies for this, despite not exactly being made for this kind of purpose.

    My practical experience impl= ementing it is that it's not that big a deal. I mean, I wished it could= be simpler, but it's manageable and there are other ways to reach leve= ls of insurance that it does work as intended (json schema, test cases to v= alidate the implementation, etc.). Arguably it is still easier from an impl= ementation perspective than say, json-ld, which is massively used in the SS= I community.=C2=A0

    =C2=A0

    But ultimately who are= we designing for? Are we striving to go easy on the spec implementer? Or a= re we trying to make sure end-developers using the client libraries won'= ;t shoot themselves in the foot?

    =C2=A0

    The job = to be done (JTBD), from the end-developer's perspective, is to efficien= tly ship an application. And provide authN/authZ capabilities for end-users= by relying on some well known implementation.=C2=A0

    In turn, this spec implementer will rely on cr= yptographic utility libraries that deals internally with the complexity of = their own domain, so that we don't have to. And here we could launch an= other HN flame war that starts with the title "JWT sucks because"= . Which does have its set of very real issues but that's beyond the poi= nt.=C2=A0

    Note that any = decent flamewar will be efficiently fueled by people hating medium. Is it o= utrageous for blog posts to be behind a paywall? Maybe but it's even mo= re outrageous to lack consistency, either by not knowing how to get around = a paywall if you're into a hacker punk movement, or on the contrary by = to not paying a subscription if you believe that surveillance capitalism, t= o reuse Zuboff's terms, should be eradicated.=C2=A0

    What likely seems an unnecessary sidenote t= ries to illustrate the point: for Justin it was easier to publish on medium= , because as a blog publisher, you might not want to deal with hosting your= own blog. But maybe as a reader you'll find that annoying. Different a= udiences, different JTBD, different tradeoffs.=C2=A0

    =C2=A0

    Polyphormism is a tool that enables the end-developer to have m= inimal knowledge of what it means to deal with a GNAP client library. You p= repare the request, send to the endpoint and you're good to go. Massive= ly simpler than OAuth2 or any similar protocol by the way (as anyone with t= eaching experience on the subject might acknowledge). And=C2=A0 there's= a lot more to be done to make sure we indeed reduce the complexity for the= end-developer and the end-user.=C2=A0

    =C2=A0

    If= we find a better way to deal with that simplicity balance, I'm all in.= But the arguments need to be way more convincing than just saying that it = may be difficult to implement or validate.=C2=A0

    =C2=A0

    Cheers.

    Fabien

    =C2=A0

    <= /div>

    =C2=A0

    =C2=A0

    <= u>=C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 = =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9cri= t=C2=A0:

    =C2=A0



    =

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    Justin<= /u>

    =C2=A0

    I did note that I was the one that argued for inst= ance_id being in the object. Since it is in the object in the current draft= , not including a pass by reference option would be preferable.=C2=A0

    =C2=A0

    As for concrete examples:

    - version of client

    <= div>

    - version of OS

    - security attestation of OS / device

    <= /div>

    - location of client device<= /p>

    - network client is operating on

    =C2=A0

    These are all attributes of the client that an= AS may require=C2=A0on the initial grant request, and in future grant requ= ests (which is when an instance_id) would be used.

    <= div>

    =C2=A0

    =C2=A0

    This is where our interpretations differ: I don=E2=80=99t= see these as =E2=80=9Cattributes of the client=E2=80=9D in the same way th= at the key, display information, class identifiers, and other items current= ly represented by an instance_id are attributes of the client instance. The= attestation components don=E2=80=99t modify the instance so much as presen= t additional information on top of the client instance itself. This is why = I argue that they ought to be handled in a separate object, so you=E2=80=99= d have something like this strawman:

    =C2=A0

    {<= u>

    =C2=A0

    =

    =C2=A0 posture: {

    =

    =C2=A0 =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2=

    =C2=A0 =C2=A0 device_at= testation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 }=

    =C2=A0 =C2=A0 location: { lat: = =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    =C2=A0

    =C2=A0 clie= nt: =E2=80=9Cclient-541-ab"

    =C2=A0

    }=

    =C2=A0

    =

    This is a more fundamental question about GNAP = than whether the syntax uses polymorphism: this is about GNAP being very ex= plicit about the data model of its elements. OAuth 2=E2=80=99s incredibly l= oose and broad model of what the term =E2=80=9Cclient=E2=80=9D is referring= to, exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed cl= ient=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in= GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we= still need to be more precise about what exactly a client instance include= s, and what it does not.

    =C2=A0

    =C2=A0=E2=80=94 = Justin

    =C2=A0<= /u>



    /Dick

    =C2=A0=

    3D"Image=E1=90=A7

    =C2=A0

    =

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" rel=3D"noreferrer noreferrer" target=3D"_= blank">jricher@mit.edu> wrote:

    Dick,

    =C2=A0

    As= you=E2=80=99ll recall, I argued against including the client instance iden= tifier inside of the object as a mutually-exclusive field precisely because= of the principle violation that you are pointing out here, and so it=E2=80= =99s important to point out that the current text is a compromise that need= s to be examined in the wider experience of the working group. I am on the = side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D optio= n within an object, but this needs to be explored.

    <= div>

    =C2=A0

    The crux of my argument is that is exactly a case of pass-by-refe= rence vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside of= that object in a another part of the request. As stated in the editorial n= otes in this section, we need to look carefully at how these concepts fit w= ithin the model and where we would want to put them. Without concrete examp= les of what these extensions look like and how they=E2=80=99re generated, t= hat is nearly impossible to do at this stage. I look forward to seeing exam= ples of this kind of data and how it can fit into the protocol.

    =C2=A0

    =

    =C2=A0=E2=80=94 Justin

    <= div>



    On Oct 23, 202= 0, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:

    =C2=A0

    Hey Justin,

    =C2=A0

    As the draft has evolved, I question the continued use of polymorphism.= Note that I appreciate the elegance=C2=A0of using a string for pass-by-ref= erence, and an object for pass-by-value.

    =C2=A0

    = In the current draft, the=C2=A0

    =C2=A0

    Every time you create or pro= cess a field it will mean only one thing, and there=E2=80=99s only one fiel= d to look at to answer a question.=C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0inst= ance_id =C2=A0An identifier string that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 particu= lar instance of this RC.=C2=A0 The content and structure of this<= /u>

    =C2=A0 =C2=A0 =C2=A0 identifier is= opaque to the RC.

    =C2=A0

    =C2=A0 =C2=A0"cli= ent": {

    =C2=A0 =C2= =A0 =C2=A0 =C2=A0"instance_id": "client-541-ab"<= u>

    =C2=A0 =C2=A0}

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fields to send, t= he RC MAY send the

    =C2= =A0 =C2=A0instance identifier as a direct reference value in lieu of the=

    =C2=A0 =C2=A0object.

    =C2=A0

    =C2=A0 =C2=A0"client": "client-= 541-ab"

    =C2=A0

    The instance id= entifier can be sent two ways. Polymorphism is a convenience for the client= , but requires the server=C2=A0to have two code=C2=A0paths for "instan= ce_id".=C2=A0 We discussed this in the design team, and I argued for h= aving "instance_id" in the "client" object=C2=A0so that= any updates, such as new devices assertions, could be in the "client&= quot; object. As noted above, while I appreciate the elegance of using a st= ring (handle) to reference a previously provided object, it complicates how= to update an existing object while providing the reference.<= /p>

    =C2=A0

    In your example of the "key" object below, se= tting "proof" to bearer would avoid the issue you describe:

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0
    = =C2=A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2=A0= }
    }

    =C2=A0

    In your example, when processing= the "key" object, code is having to check both the JSON type of = the property, as well as check the value of the "proof" property.= In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "= key" object.

    =C2=A0

    Not being a Java progra= mmer, I don't know how this would work in a Java implementation, but no= de.js, the processing would need to be done as above.

    =C2=A0

    On a related note, there was significant negative feedback o= n handles and polymorphism in the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24855750=C2=A0<= u>

    =C2=A0

    =

    /Dick

    =C2=A0

    <= u>=C2=A0

    On Fri,= Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu>= wrote:

    Hi Mika,

    =C2=A0<= u>

    Thanks for bringing this topic = here =E2=80=94 I was able to see the forum discussion that brought you here= , and hopefully I can help clear up what I mean with how polymorphism is us= ed in the proposal. The short version is that the goal is to=C2=A0avoid<= /b>=C2=A0the kinds of ambiguity that make insecure protocols, and so in tha= t goal we=E2=80=99re fully aligned. I think that using polymorphism in very= specific ways can help that goal =E2=80=94 just as I agree that misusing i= t or applying it sloppily can lead to ambiguous and insecure systems.

    =C2=A0

    Some background: I built out the XYZ protocol = (one of the predecessors to the initial GNAP Draft) in Java using strongly = typed parsers and Java objects specifically to prove to myself that it coul= d be done in a way that made any sense in the code. (My own open source imp= lementation is at=C2=A0https://github.com/bspk/oaut= h.xyz-java, but note that it=E2=80=99s not yet up to date with the GNAP= spec). It was important to me that I be able to use the system-wide config= ured parsers to implement this and not have to resort to stepping through e= lements completely by hand. Java doesn=E2=80=99t make it simple to get the = hooks into the right places (especially with the Jackson parser that I used= ), but it is definitely possible to create a deterministic and strongly-typ= ed parser and serializer for this kind of data structure. Some of the ratio= nale for using polymorphism is covered in the trailing appendix of the draf= t document (https://www.ietf.org/archive/id/draft-ietf-gnap-co= re-protocol-00.html#name-json-structures-and-polymor), but it=E2=80=99s= still good to discuss this here as the working group decides which approac= hes to take.=C2=A0

    =C2=A0

    The driving reason for= using polymorphism at the protocol level was to simplify the protocol and = make it :more: deterministic to create and process, not less. Every time yo= u create or process a field it will mean only one thing, and there=E2=80=99= s only one field to look at to answer a question. Without polymorphic field= values, you usually need to rely on mutual exclusivity of fields, which is= prone to failure and requires additional error checking. Take for example = the key binding of access tokens. An access token could be bound to the RC= =E2=80=99s key used during the request, to a different key chosen by the AS= , or it could be a bearer token with no key at all. By making the =E2=80=9C= key=E2=80=9D field polymorphic, we can define it in terms of boolean values= and objects and express this set of mutually-exclusive options in a non-am= biguous way. Without that, you=E2=80=99d need to have different fields for = the options and include additional checks in your parser to make sure they = weren=E2=80=99t sent simultaneously, otherwise you could get hit with this = potential security vulnerability in an object:

    =

    =C2=A0

    {=C2=A0

    =C2=A0 =C2= =A0 key: {

    =C2=A0 =C2=A0= =C2=A0 proof: httpsig,

    = =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    =C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    }

    =

    =C2=A0

    This would be an illegal object as per this alternate proposal, = but then you=E2=80=99d have to check each field and make sure it wasn=E2=80= =99t put next to others in the same object. I=E2=80=99ve done this exercise= with many other protocols and it=E2=80=99s both error prone and easy to ig= nore since all the =E2=80=9Cgood=E2=80=9D examples would pass code that doe= sn=E2=80=99t check this. With the polymorphic approach to this same field, = each of these three mutually-exclusive states is written in a way that they= cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impos= sible and enforced by the syntax of JSON itself.

    =C2=A0

    {=C2=A0

    = =C2=A0 =C2=A0 key: {

    =C2= =A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }=

    }

    =C2=A0

    /= / bearer token

    = =C2=A0

    {

    =C2=A0 =C2=A0 key: false

    }

    =C2=A0

    //= bound to the RC=E2=80=99s presented key

    =C2=A0

    = {

    =C2=A0 =C2=A0 key: tru= e

    }

    =C2=A0

    If someone sends a different type for this field, like an ar= ray or number or a null, this doesn=E2=80=99t have a defined interpretation= in the protocol and would be a protocol level error.

    =C2=A0

    While it might sound like polymorphism means that any field = could have any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different ty= pes that express meaning for the field. This applies to all members of all = objects (dictionaries) as well as all members of an array (list). Every tim= e you process a field value or other element, you look at the type and then= the value to determine what to do with that typed value.

    =

    =C2=A0

    In your example below, each field within the dictionary wo= uld also need to be typed, and each type would need to have a clear indicat= ion of its meaning. To take your strawman key format below, the =E2=80=9Cmo= dulus=E2=80=9D field could be defined polymorphically as either a =E2=80=9C= bigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a J= SON string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value was = or how it was represented, regardless of the input format. Seeing a number = there means exactly one interpretation and seeing a string means exactly on= e (different) interpretation =E2=80=94 but importantly, both of them are a = =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines t= he type. An implementation would likely use an internal BigInteger type of = object to represent the field value after parsing, so the question is how t= o go from the JSON value (which is typed) into the BigInteger value.You don= =E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D fi= eld, you apply it to all sub-fields of that object.=C2=A0

    =

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up in= the strawman, because it=E2=80=99s interesting: A JSON encoder that encode= s numbers as strings, and not numbers, is not compliant with the JSON defin= itions of the field in question. For another example, the quoted string val= ue of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in= JSON, and they shouldn=E2=80=99t be treated the same by a parser implement= ation when mapping to a concrete object. It=E2=80=99s in this kind of autom= ated guessing that this class of bugs occur, and that=E2=80=99s going to be= the case whether or not you take =C2=A0advantage of JSON=E2=80=99s polymor= phic nature. I=E2=80=99ve run into cases where a parser library was trying = to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but e= nded up introducing errors in more strict components downstream. This is so= mething that protocol designers need to be aware of and guard against in th= e design of the protocol to reduce possible ambiguities. Within GNAP today,= we generally have things that branch whether they=E2=80=99re an object (fo= r a rich description of something) or some non-structured special value (fo= r a reference or other item).=C2=A0

    =C2=A0

    The d= esign team created some simple JSON Schemas for parts of the protocol durin= g our discussion, but we didn=E2=80=99t include them in the design document= due to both lack of time to keep it updated with the rapid changes to the = protocol during the design team discussion, and not knowing if there would = be interest in such material. I personally think it would be helpful to inc= lude as an informative reference in the final document, but that=E2=80=99s = something for the working group to take up eventually.

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 10:18 = AM, Mika Bostr=C3=B6m <mika.bostrom= =3D40smarkets.com@dmarc.ietf.org> wrote:

    =C2=A0

    Hello, everyone.

    <= u>=C2=A0

    For background: GN= AP/TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made note abo= ut certain concerns, I was requested to send my comments to this working gr= oup.

    =C2=A0

    In short, I believe that the use of = polymorphic JSON in the protocol invites subtle and confusing implementatio= n problems. I also searched through the WG archives, and noticed that simil= ar concerns were noted, briefly, in a thread in July.

    =C2=A0

    The problem with polymorphic values, as I see it, is that im= plementations will need to branch on the (inferred) type of a given field. = This isn't quite as bad if the types are strictly different, but allows= for subtle bugs when the value in question is a dictionary. What makes thi= s unappealing is that "subtle bugs" in security protocols have a = habit of turning into vulnerabilities.

    =C2=A0

    Le= t's say we have these imaginary payloads, both possible and valid in th= e same protocol step:

    =C2=A0

    # payload 1<= u>

    {

    <= p class=3D"MsoNormal">=C2=A0 ...,

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",<= /u>

    =C2=A0=C2=A0=C2=A0 "mo= dulus": <BIGINT>

    =C2=A0 }

    }=

    =C2=A0

    # payload 2

    {

    =C2=A0 = ...,

    =C2=A0 "public= _key": {

    =C2=A0=C2= =A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<encod= ed string>"

    =C2= =A0 }

    }

    =C2=A0

    In both cases, the type of "public_key" field i= s a dictionary. In both cases, they even have the same keys. However, the v= alues in the dictionaries are entirely different, and an implementation wil= l have to branch to at least two possible decoding mechanisms. To make thin= gs worse, some JSON implementations may choose to encode non-dictionary val= ues as strings, so it is possible for an originator to transmit what they e= xpect and believe to be payload 1 format, but which the receiver will inter= pret to be in payload 2 format. And if the encoded string contains only dig= its, it will even parse correctly as a bignum.

    =

    =C2=A0

    While the above is clearly a manufactured scenario, it nonetheless de= monstrates the potential for logic bugs with polymorphic JSON. With richer = types and more complex dictionaries, there will surely be more room for err= ors.

    =C2=A0

    Ambiguity in protocols is always a s= ource of implementation complexity and interoperability snags, but in an Au= thN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is inte= nded to supersede Oauth1/2, wouldn't it be in everyone's interest t= o keep implementation complexity and mistake potential to a minimum?=

    =C2=A0

    =

    Best regards,

    Mika

    <= u>=C2=A0

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    <= /blockquote>

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth

    3D"Image= =E1=90=A7

    =C2=A0

    <= /div>

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.= org
    https://www.ietf.org/mailman/listi= nfo/txauth



    --

    Mika Bostr=C3= =B6m

    Smarkets

    -- TXAu= th mailing list TXAuth@ietf.org h= ttps://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000006f125b05b2e2e300-- From nobody Fri Oct 30 07:19:12 2020 Return-Path: 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 6A2AB3A0EDA for ; Fri, 30 Oct 2020 07:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 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, MALFORMED_FREEMAIL=2.292, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 T9IpD3fZo0k6 for ; Fri, 30 Oct 2020 07:19:05 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 80B653A0ED9 for ; Fri, 30 Oct 2020 07:19:04 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id c16so3115072wmd.2 for ; Fri, 30 Oct 2020 07:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=EoHHSuJF8AQvTJAKc/Rxw249gXyUj/42794atFGnDXA=; b=ujr4s+ZbGgt4ByJRrnbIR3tEk8b2Pjxpwm9zQEEnWlUiSNOUanqvt1GJIhIOjZs56o jMEdmhtUW55r3nITaHqaXIV7r/y+WHiEFrbnNJ6YZjkOf1M9oZicYFLyr+BrQVqvzHC+ ubdc/xCWYDN5LskEol002p8CncyiGY4/h/PVcn0UWhOLSjkNvOfat4dpMYbghvVDwJKe 82fWUqkvI+biclFrhbw90l+b2po2Ih3q2/Fgon/hj+p6e472qkrL6m4xVkIM+8SBkzkd QaEhg17fo9ygxaCWgjSXdAm+1M22awNZMRCddXf8bmRJzmyNv7ayK5A2E7vA6Squ3IY8 vPeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=EoHHSuJF8AQvTJAKc/Rxw249gXyUj/42794atFGnDXA=; b=YlppAEk0vfXaMJbnSruv5aP0aUuoN/1YbfTz2Zvi4KlLJUzOEzwMUh6zrFndGXq//Z goOG0Qhx34t7f7/vjl1Z9dML8zNUnU8DlR7b/5AP2WSKC5zqRmEc4pEpc0589KM4o1u8 3afygTksl43ZbZWQRTbzKxbHkEglh+ycR6tc5N/OKY1rkzP7IC5pm275XsyT0PnoCbFL zJ+m7GTO9T/ALmOu0BTLD9H4kv2CdWAgWQBsRgtmkqY70cdl+/Ino9/t3hDeJsl4vwgU jpEp+CDhCohInUBD3jcoFVbftb+GW8c4p3VtTncAKO465DPJ1dv8piqyVSFKwUlcZ+1b /MyQ== X-Gm-Message-State: AOAM533ddMth3NLheGSMcha9DKua4CkQCMz9FcPSnqXYek6a13hqYJYU yxOega47HSD78xKD/SD7oNQ= X-Google-Smtp-Source: ABdhPJw/RK3MhArC08H1+wDav/fRwNivBOOLQdOfHlZq/vaylEQhwB/a12b2AUyfiTm8w5paS7r0KQ== X-Received: by 2002:a1c:9a49:: with SMTP id c70mr2988363wme.117.1604067542170; Fri, 30 Oct 2020 07:19:02 -0700 (PDT) Received: from [172.26.223.43] (pub-corp-lon-8.intuit.com. [91.102.40.8]) by smtp.gmail.com with ESMTPSA id f2sm9586326wre.63.2020.10.30.07.18.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2020 07:19:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Fri, 30 Oct 2020 16:18:57 +0200 From: Yaron Sheffer To: Fabien Imbault , Andrii Deinega CC: Mika =?UTF-8?B?Qm9zdHLDtm0=?= , Justin Richer , GNAP Mailing List , Dick Hardt Message-ID: <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> Thread-Topic: [GNAP] Feedback on polymorphism References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3686919539_664918686" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 14:19:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3686919539_664918686 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 One correction, JSON Schema (which I am personally advocating for, but stil= l) does not have an IETF spec. They claim on their web site that they want i= t standardized, but in practice are not (yet?) moving in this direction. The= ir Internet Draft is unmaintained. =20 At a higher level, I think your discussion conflates two things: the repres= entation of data on the wire (JSON or various mostly binary encodings) and t= he data modeling language, a.k.a. schema. Personally I think JSON is almost = a must in our case, and if this is true, the playing field is *much* more na= rrow. =20 A major strength of JSON which you don=E2=80=99t mention in your comparison is th= e cryptographic ecosystem (JOSE): standard formats for encryption, signature= etc. =20 I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a good fit for us, still a = very interesting direction. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Fabien Imbault Date: Friday, October 30, 2020 at 14:53 To: Andrii Deinega Cc: Mika Bostr=C3=B6m , Justin Richer , Yaron Sheffer , GNAP Mailing List , Dick Hardt Subject: Re: [GNAP] Feedback on polymorphism =20 Hi Justin,=20 =20 > Regarding your question, what else could we propose?=20 =20 I've started a review of possibilities at https://github.com/fimbault/reaso= nably-polymorphic/blob/main/README.md to be followed by actual code testing.= =20 =20 Cheers, Fabien =20 On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega w= rote: Hi Mika, Justin, and WG, =20 The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) has= a JSON object as its value. This claim could be a part of AT JWT or a token= introspection response and has the same semantics in both cases. The JSON o= bject as its value may look like this "act": { "sub":"admin@example.com" } or even be nested like in "act": { "sub":"https://service16.example.com", "act": { "sub":"https://service77.example.com" } } Personally, I find it to be a very expressive approach. Also, as far I as k= now, several (oAuth2) client libraries have good support of things like "aud":"https://service1.example.com" and "aud":["https://service1.example.c= om","https://service2.example.com"] in AT JWTs for a quite long time. =20 Regards, Andrii =20 On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault = wrote: Hi Yaron, =20 We'll indeed have to check how make it as idiomatic as possible with expert= s of each language (help welcome).=20 =20 Regarding the client, the variations are more limited but they do exist. He= re I believe it's much more problematic than on the server side and there ar= e at least a few actions we should take: =20 A) check in sec 7 if we really have a compelling reason for key and proof v= ariants. This is derived from larger discussions on key binding as per the r= elated note. There are quite a few open questions related to this theme.=20 =20 B) there is also the choice between value/reference that may generate compl= exity.=20 =20 C) More generally, as many feedbacks already have noticed, we need to have = a systematic review and reduce the set of available options in the protocol.= =20 =20 Unless we have a clear idea why runtime behavior requires mutability, it mi= ght be useful to have a way to define the chosen variant before hand, so tha= t the expected behavior becomes deterministic on the client side. There are = various ways it could be done in practice.=20 =20 For sure several independant implementations would help, especially if we m= ake sure they can work together.=20 =20 Anyway all this open to improvement.=20 =20 Cheers=20 Fabien=20 =20 Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer a =C3=A9cr= it : Hi Fabien, =20 At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than th= e problem. The code in the article you cite is very specific to the use case= and IMHO quite ugly. So my preferred Go implementation would be a combinati= on of untyped structures (Go interface{}) and run-time enforcement of JSON S= chema. =20 Also, going back to our earlier discussion on this topic, I just read Sec. = 7 of gnap-00 and realized that the RC also needs to deal with polymorphism (= the =E2=80=9Ckey=E2=80=9D value), not only the AS. =20 Thanks, Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Wednesday, October 28, 2020 at 18:56 To: Mika Bostr=C3=B6m Cc: GNAP Mailing List , Justin Richer , D= ick Hardt Subject: Re: [GNAP] Feedback on polymorphism =20 Thanks for the great feedback. Your concern is very valid.=20 =20 My implementation is in rust, which makes life easier in that specific case= .=20 =20 So I'm not a golang specialist but I guess the transcription of json string= s/arrays into go structs would work around the lines described by https://me= dium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 When we have a more formalized json schema, I suggest we make a library of = json examples and some related code samples in mainstream languages, to chec= k it is feasible for everyone.=20 =20 Cheers, Fabien =20 =20 On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m w= rote: Hi everyone, =20 Looks like I stuck my finger in a hornets' nest. First off, apologies for n= ot chipping in earlier, but there was a lot of material to digest. Also, war= ning: lots to read ahead. =20 I'm one of those people who end up making use of AuthN/AuthZ functionality = through a library. On top of that I can see myself being roped in as a serve= r (AS) implementation help. So I'm approaching this from an outsider's persp= ective. Someone who expects to be exposed to the eventual RFC and all the ni= tty-gritty details. My relatively terse comment ended up at the top of the a= forementioned HN thread, which didn't necessarily help. Sorry about that. =20 Now, having read Justin's initial reply - and the rest of the thread - I be= lieve I can see where the desire for polymorphism comes from. To be clear: I= am all for strict types inside an implementation, as it will add helpful gu= ard-rails to the state management code paths. However, I see this as a case = of leaky abstraction. If we take the existing oauth.xyj-java code to be the = reference implementation, the choice makes logical sense: JSON is not expres= sive enough to serialise arbitrary objects, so in order to avoid writing com= plex payload parser(s) the internal implementation details now leak to the p= rotocol itself. From a purely technical perspective, it's a cool trick. From= a distance it even looks a bit like the result of protobuf decoding, but wi= thout the generated code parts. =20 But then the downside. I don't personally expect to be able to use the refe= rence implementation, being mostly a Python user myself. A fair number of AS= implementations will be written with languages such as Go, Python, C#, Ruby= , and JavaScript (thanks to node.js), and all of them will have to deal with= the polymorphism. From what I've read over the past couple of days, I under= stand that at least Go supports custom unmarshalers from JSON to typed struc= ts, at the cost of an indirection. Normally when a Go code processes JSON to= a typed struct, the process is helped by field annotations in the type defi= nition itself. For example, if the payload for a person in JSON was =20 { "name": "", "age": , "country": "", "city": "" } =20 .. then the type definition would look like: =20 type Person struct { Name string `json:"name" Age int `json:"age"` Country string `json:"country"` City string `json:"city"` } =20 When the (possibly complex) type of a given field is fixed, unmarshaling sh= ould still be straightforward. I haven't verified, but since the annotation = only gives which field to look at for a given typed value, there should be n= othing special about that. But when the field can instead be a union of more= than one distinct types, things start to get messy. There is no union type = in the language at all, so the following construct is not even possible: =20 type Entity struct { Resources []string `json:"resources"` Client union(Client, string) `json:"client"` } =20 As I understand, the implicit expectation is that in the above case, the un= marshaler detects that "client" is a string, and so expands it from an opaqu= e handle to the expected, populated type. Even after thinking about the rami= fications over the past few days I remain confused, because I don't see how = the commonly used annotations could work. If the expectation is that protoco= l implementations should use strong types, then the use of polymorphic JSON = is very likely to make things _more_ complicated for non-reference implement= ations.=20 =20 Hence my concern. I'm afraid that the leaky abstraction, while making the r= eference implementation more robust and straightforward, contributes to maki= ng other implementations less robust. And this being a security protocol, th= e potential for brittle and/or confused implementations is terrifying.=20 =20 I am a fan of reducing complexity, and from what I can see, for the referen= ce implementation the polymorphic approach actually does that. But I'm afrai= d it does so at others' expense. Languages have their individual constraints= , idioms and best practices. If parsing a protocol payload introduces low-le= vel complexities and encourages to go against common practices, that is an i= nvitation for problems. I am aware that my choice of words in the HN thread = was likely to put people on defense, and for that I apologise. But I do beli= eve that the choice of polymorphic JSON is going to make the life and use of= other implementations notably less boring than people in general would pref= er. =20 Cheers, Mika =20 On Mon, 26 Oct 2020 at 02:04, Fabien Imbault wro= te: Hi Dick, =20 Well technically yes. Obviously the client can present any interface it see= ms fit.=20 =20 Still there's the question of the common model we want to present to the ou= tside world and supported by the protocol itself (which client libraries all= build upon).=20 =20 But beneath the polyphormism question, the HN debate seems on the surface a= lot like the original xyz (polyphormism goes along with the reduced endpoin= t model) vs xauth (a bit closer to OAuth2 in spirit, and where the client de= sign has more latitude). Just explained differently, by outside people with = different agendas.=20 =20 Which is a bit weird because many of the critics on HN (who criticize polyp= hormism) also seem to really dislike OAuth in the first place (the inconsist= encies are partially due to a bunch of different people commenting).=20 =20 Really to me there's no fundamental truth behind that question. It's a matt= er of preference and priorities in the design. Whatever choices we make, we'= ll have to be prepared to explain and justify them in the open, even to some= people that will dislike pretty much whatever we do (because it's fun to lo= ok smart and critize without proposing alternatives). And we owe these answe= rs to people like Mika, who genuinely try to make the best of it.=20 =20 Fabien=20 =20 Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a =C3=A9crit : Hi Fabien =20 A library developer can provide whatever abstraction layer makes sense for = the library's target audience and language. =20 If the client library developer wants to use polymorphism in the interface = presented to the user's of the library, the library developer can do that in= dependent of polymorphism in the protocol, and vice versa=20 =20 =3D> polymorphism in the protocol has no impact on client library developers =20 =20 Error! Filename not specified.=E1=90=A7 =20 On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault w= rote: I'm just realizing your "least to most important" might actually say the sa= me as what I was trying to say. So I'm not even sure what we're arguing agai= nst :-)=20 =20 In brief my point if it wasn't clear is that we should be crystal clear on = where we put the cursor of simplicity, because this can mean different thing= s for different people and different roles.=20 And as we see on HN we need to better explain our design choices.=20 =20 =20 Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a = =C3=A9crit : Hi Dick, =20 Independantly from the debate on polyphormism, I beg to differ on your orde= r preference.=20 =20 Your assumption is that AS devs matter the most, because they're doing the = important security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spec= are unable to deal with the complexity that is passed onto them.=20 =20 99% of the people that will actually use the output of the work are applica= tion developers (client or RS) and their own users.=20 =20 Our intent as well as the protocol drive the usage. Client libraries may he= lp, but they're not a silver bullet, especially because GNAP ultimately has = no control about what people do there (for better or worse). And everything = we do here will help get to the better part.=20 =20 I'm not saying we don't intend to also care about AS developers (beginning = with ourselves) but it's a second order optimisation. And since it's a tenda= ncy we're leaning towards by default, I'm pretty sure we won't forget that a= nyway.=20 =20 Fabien=20 =20 =20 Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a =C3=A9crit : I'm confused by your logic Fabien. =20 If a client library developer wants to expose polymorphism, they can do tha= t independent of what is in the protocol.=20 =20 I differ on who our stakeholders are.=20 =20 I think our stakeholders are in least to most important: =20 AS developer RS developer client developer user =20 A client library developer can expose whatever interface they want to simpl= ify implementation. =20 I list the user so that we don't lose site of a critical role. =20 /Dick =20 =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault w= rote: Hi there,=20 =20 Let me try to approach the issue under a different light. More like a produ= ct manager would deal with feature selection to make it intuitive for its us= ers.=20 =20 For most people, riding a bike is far easier than using a unicycle. Feels m= ore stable. And yet it's way easier to design for a single wheel than to bui= ld with 2. Because then you'll need a lot more accessories (chain, chain rin= g, etc.). Even so producing a bike doesn't have to be a brittle process, it = can be industrialized.=20 =20 Back to the GNAP topic.=20 Ultimately we should strive to make the spec as simple as can be. But we ne= ed to ask: simple for whom? For the bike owner or for the bike vendor?=20 (short answer: the priority should be simplicity for spec users, not spec i= mplementers and even less spec designers).=20 =20 The initial question that is asked is very interesting: isn't the design fl= awed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are look= ing for a global unique identifier? The argument stems of the fact that is s= till arguably harder and more error prone to implement. Fair enough.=20 =20 >From a spec implementer's perspective, it may well be more complex. It most= ly impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite not e= xactly being made for this kind of purpose. My practical experience implementing it is that it's not that big a deal. I= mean, I wished it could be simpler, but it's manageable and there are other= ways to reach levels of insurance that it does work as intended (json schem= a, test cases to validate the implementation, etc.). Arguably it is still ea= sier from an implementation perspective than say, json-ld, which is massivel= y used in the SSI community.=20 =20 But ultimately who are we designing for? Are we striving to go easy on the = spec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot? =20 The job to be done (JTBD), from the end-developer's perspective, is to effi= ciently ship an application. And provide authN/authZ capabilities for end-us= ers by relying on some well known implementation.=20 In turn, this spec implementer will rely on cryptographic utility libraries= that deals internally with the complexity of their own domain, so that we d= on't have to. And here we could launch another HN flame war that starts with= the title "JWT sucks because". Which does have its set of very real issues = but that's beyond the point.=20 Note that any decent flamewar will be efficiently fueled by people hating m= edium. Is it outrageous for blog posts to be behind a paywall? Maybe but it'= s even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the contrary = by to not paying a subscription if you believe that surveillance capitalism,= to reuse Zuboff's terms, should be eradicated.=20 What likely seems an unnecessary sidenote tries to illustrate the point: fo= r Justin it was easier to publish on medium, because as a blog publisher, yo= u might not want to deal with hosting your own blog. But maybe as a reader y= ou'll find that annoying. Different audiences, different JTBD, different tra= deoffs.=20 =20 Polyphormism is a tool that enables the end-developer to have minimal knowl= edge of what it means to deal with a GNAP client library. You prepare the re= quest, send to the endpoint and you're good to go. Massively simpler than OA= uth2 or any similar protocol by the way (as anyone with teaching experience = on the subject might acknowledge). And there's a lot more to be done to mak= e sure we indeed reduce the complexity for the end-developer and the end-use= r.=20 =20 If we find a better way to deal with that simplicity balance, I'm all in. B= ut the arguments need to be way more convincing than just saying that it may= be difficult to implement or validate.=20 =20 Cheers. Fabien =20 =20 =20 =20 =20 Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3=A9crit : =20 =20 On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: =20 Justin =20 I did note that I was the one that argued for instance_id being in the obje= ct. Since it is in the object in the current draft, not including a pass by = reference option would be preferable.=20 =20 As for concrete examples: - version of client - version of OS - security attestation of OS / device - location of client device - network client is operating on =20 These are all attributes of the client that an AS may require on the initia= l grant request, and in future grant requests (which is when an instance_id)= would be used. =20 =20 This is where our interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattribu= tes of the client=E2=80=9D in the same way that the key, display information, clas= s identifiers, and other items currently represented by an instance_id are a= ttributes of the client instance. The attestation components don=E2=80=99t modify = the instance so much as present additional information on top of the client = instance itself. This is why I argue that they ought to be handled in a sepa= rate object, so you=E2=80=99d have something like this strawman: =20 { =20 posture: { software_version: 1.2.3, os_version: 14.3.2 device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80=A6 } location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } }, =20 client: =E2=80=9Cclient-541-ab" =20 } =20 This is a more fundamental question about GNAP than whether the syntax uses= polymorphism: this is about GNAP being very explicit about the data model o= f its elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the ter= m =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in practice. = We=E2=80=99re even seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccr= edentialed client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the differe= nt aspects that are out there. I think we=E2=80=99re getting closer here in GNAP w= ith explicit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be mo= re precise about what exactly a client instance includes, and what it does n= ot. =20 =E2=80=94 Justin =20 =20 /Dick =20 Error! Filename not specified.=E1=90=A7 =20 On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: Dick, =20 As you=E2=80=99ll recall, I argued against including the client instance identifi= er inside of the object as a mutually-exclusive field precisely because of t= he principle violation that you are pointing out here, and so it=E2=80=99s importa= nt to point out that the current text is a compromise that needs to be exami= ned in the wider experience of the working group. I am on the side of removi= ng the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but thi= s needs to be explored. =20 The crux of my argument is that is exactly a case of pass-by-reference vs p= ass-by-value, and that runtime attestations are not part of the =E2=80=9Cclient in= stance=E2=80=9D value itself but rather belong outside of that object in a another= part of the request. As stated in the editorial notes in this section, we n= eed to look carefully at how these concepts fit within the model and where w= e would want to put them. Without concrete examples of what these extensions= look like and how they=E2=80=99re generated, that is nearly impossible to do at t= his stage. I look forward to seeing examples of this kind of data and how it= can fit into the protocol. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: =20 Hey Justin, =20 As the draft has evolved, I question the continued use of polymorphism. Not= e that I appreciate the elegance of using a string for pass-by-reference, an= d an object for pass-by-value. =20 In the current draft, the=20 =20 Every time you create or process a field it will mean only one thing, and t= here=E2=80=99s only one field to look at to answer a question.=20 =20 is violated in 2.3.1. Identifying the RC Instance =20 =20 instance_id An identifier string that the AS can use to identify the particular instance of this RC. The content and structure of this identifier is opaque to the RC. =20 "client": { "instance_id": "client-541-ab" } =20 If there are no additional fields to send, the RC MAY send the instance identifier as a direct reference value in lieu of the object. =20 "client": "client-541-ab" =20 The instance identifier can be sent two ways. Polymorphism is a convenience= for the client, but requires the server to have two code paths for "instanc= e_id". We discussed this in the design team, and I argued for having "insta= nce_id" in the "client" object so that any updates, such as new devices asse= rtions, could be in the "client" object. As noted above, while I appreciate = the elegance of using a string (handle) to reference a previously provided o= bject, it complicates how to update an existing object while providing the r= eference. =20 In your example of the "key" object below, setting "proof" to bearer would = avoid the issue you describe: =20 {=20 "key": {=20 "proof": "bearer"=20 }=20 } =20 In your example, when processing the "key" object, code is having to check = both the JSON type of the property, as well as check the value of the "proof= " property. In the example I provided, only the value of "proof" needs to be= checked. The "proof" property is acting as a type for the "key" object. =20 Not being a Java programmer, I don't know how this would work in a Java imp= lementation, but node.js, the processing would need to be done as above. =20 On a related note, there was significant negative feedback on handles and p= olymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D= 24855750=20 =20 /Dick =20 =20 On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: Hi Mika, =20 Thanks for bringing this topic here =E2=80=94 I was able to see the forum discuss= ion that brought you here, and hopefully I can help clear up what I mean wit= h how polymorphism is used in the proposal. The short version is that the go= al is to avoid the kinds of ambiguity that make insecure protocols, and so i= n that goal we=E2=80=99re fully aligned. I think that using polymorphism in very s= pecific ways can help that goal =E2=80=94 just as I agree that misusing it or appl= ying it sloppily can lead to ambiguous and insecure systems. =20 Some background: I built out the XYZ protocol (one of the predecessors to t= he initial GNAP Draft) in Java using strongly typed parsers and Java objects= specifically to prove to myself that it could be done in a way that made an= y sense in the code. (My own open source implementation is at https://github= .com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the G= NAP spec). It was important to me that I be able to use the system-wide conf= igured parsers to implement this and not have to resort to stepping through = elements completely by hand. Java doesn=E2=80=99t make it simple to get the hooks = into the right places (especially with the Jackson parser that I used), but = it is definitely possible to create a deterministic and strongly-typed parse= r and serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft document= (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#name= -json-structures-and-polymor), but it=E2=80=99s still good to discuss this here as= the working group decides which approaches to take.=20 =20 The driving reason for using polymorphism at the protocol level was to simp= lify the protocol and make it :more: deterministic to create and process, no= t less. Every time you create or process a field it will mean only one thing= , and there=E2=80=99s only one field to look at to answer a question. Without poly= morphic field values, you usually need to rely on mutual exclusivity of fiel= ds, which is prone to failure and requires additional error checking. Take f= or example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen by the = AS, or it could be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and objects= and express this set of mutually-exclusive options in a non-ambiguous way. = Without that, you=E2=80=99d need to have different fields for the options and incl= ude additional checks in your parser to make sure they weren=E2=80=99t sent simult= aneously, otherwise you could get hit with this potential security vulnerabi= lity in an object: =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } }, bearer_token: true, bind_to_rc_key: true } =20 This would be an illegal object as per this alternate proposal, but then yo= u=E2=80=99d have to check each field and make sure it wasn=E2=80=99t put next to others = in the same object. I=E2=80=99ve done this exercise with many other protocols and = it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples= would pass code that doesn=E2=80=99t check this. With the polymorphic approach to= this same field, each of these three mutually-exclusive states is written i= n a way that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s i= mpossible and enforced by the syntax of JSON itself. =20 {=20 key: { proof: httpsig, jwk: { =E2=80=A6 key value =E2=80=A6 } } } =20 // bearer token =20 { key: false } =20 // bound to the RC=E2=80=99s presented key =20 { key: true } =20 If someone sends a different type for this field, like an array or number o= r a null, this doesn=E2=80=99t have a defined interpretation in the protocol and w= ould be a protocol level error. =20 While it might sound like polymorphism means that any field could have any = type or value, the opposite is true: each possible value is explicitly typed= , it=E2=80=99s just that there are potentially different types that express meanin= g for the field. This applies to all members of all objects (dictionaries) a= s well as all members of an array (list). Every time you process a field val= ue or other element, you look at the type and then the value to determine wh= at to do with that typed value. =20 In your example below, each field within the dictionary would also need to = be typed, and each type would need to have a clear indication of its meaning= . To take your strawman key format below, the =E2=80=9Cmodulus=E2=80=9D field could be d= efined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what exactl= y the encoding of the string would be. That means that when you read the =E2=80=9C= modulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value was or = how it was represented, regardless of the input format. Seeing a number ther= e means exactly one interpretation and seeing a string means exactly one (di= fferent) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80= =9D, since that=E2=80=99s the field that determines the type. An implementation woul= d likely use an internal BigInteger type of object to represent the field va= lue after parsing, so the question is how to go from the JSON value (which i= s typed) into the BigInteger value.You don=E2=80=99t just apply the type rules on = the =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object.=20 =20 So let=E2=80=99s dig into the specific bug you bring up in the strawman, because = it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings, and not = numbers, is not compliant with the JSON definitions of the field in question= . For another example, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivale= nt to the boolean value true in JSON, and they shouldn=E2=80=99t be treated the sa= me by a parser implementation when mapping to a concrete object. It=E2=80=99s in t= his kind of automated guessing that this class of bugs occur, and that=E2=80=99s g= oing to be the case whether or not you take advantage of JSON=E2=80=99s polymorph= ic nature. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up introducing er= rors in more strict components downstream. This is something that protocol d= esigners need to be aware of and guard against in the design of the protocol= to reduce possible ambiguities. Within GNAP today, we generally have things= that branch whether they=E2=80=99re an object (for a rich description of somethin= g) or some non-structured special value (for a reference or other item).=20 =20 The design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design document d= ue to both lack of time to keep it updated with the rapid changes to the pro= tocol during the design team discussion, and not knowing if there would be i= nterest in such material. I personally think it would be helpful to include = as an informative reference in the final document, but that=E2=80=99s something fo= r the working group to take up eventually. =20 =E2=80=94 Justin =20 On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m wrote: =20 Hello, everyone. =20 For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments t= o this working group. =20 In short, I believe that the use of polymorphic JSON in the protocol invite= s subtle and confusing implementation problems. I also searched through the = WG archives, and noticed that similar concerns were noted, briefly, in a thr= ead in July.=20 =20 The problem with polymorphic values, as I see it, is that implementations w= ill need to branch on the (inferred) type of a given field. This isn't quite= as bad if the types are strictly different, but allows for subtle bugs when= the value in question is a dictionary. What makes this unappealing is that = "subtle bugs" in security protocols have a habit of turning into vulnerabili= ties. =20 Let's say we have these imaginary payloads, both possible and valid in the = same protocol step: =20 # payload 1 { ..., "public_key": { "alg": "rsa", "modulus": } } =20 # payload 2 { ..., "public_key": { "alg": "rsa", "modulus": "" } } =20 In both cases, the type of "public_key" field is a dictionary. In both case= s, they even have the same keys. However, the values in the dictionaries are= entirely different, and an implementation will have to branch to at least t= wo possible decoding mechanisms. To make things worse, some JSON implementat= ions may choose to encode non-dictionary values as strings, so it is possibl= e for an originator to transmit what they expect and believe to be payload 1= format, but which the receiver will interpret to be in payload 2 format. An= d if the encoded string contains only digits, it will even parse correctly a= s a bignum. =20 While the above is clearly a manufactured scenario, it nonetheless demonstr= ates the potential for logic bugs with polymorphic JSON. With richer types a= nd more complex dictionaries, there will surely be more room for errors. =20 Ambiguity in protocols is always a source of implementation complexity and = interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's ter= rifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in= everyone's interest to keep implementation complexity and mistake potential= to a minimum? =20 Best regards, Mika =20 --=20 Mika Bostr=C3=B6m Smarkets --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth Error! Filename not specified.=E1=90=A7 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 Mika Bostr=C3=B6m Smarkets -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --B_3686919539_664918686 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Hi Fabien,=

     

    One correctio= n, JSON Schema (which I am personally advocating for, but still) does not ha= ve an IETF spec. They claim on their web site that they want it standardized= , but in practice are not (yet?) moving in this direction. Their Internet Dr= aft is unmaintained.

     

    <= p class=3DMsoNormal>At a higher level, I think your discussion conflates two t= hings: the representation of data on the wire (JSON or various mostly binary= encodings) and the data modeling language, a.k.a. schema. Personally I thin= k JSON is almost a must in our case, and if this is true, the playing field = is *much* more narrow.

     

    A major strength of JSON which you don=E2=80=99t mentio= n in your comparison is the cryptographic ecosystem (JOSE): standard formats= for encryption, signature etc.

     =

    I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s= a good fit for us, still a very interesting direction.

     

    Thanks,

    <= p class=3DMsoNormal>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

     

    From: Fabien Imbault <fabien.imbault@gmail.com>
    Date: = Friday, October 30, 2020 at 14:53
    To: Andrii Deinega <andrii.de= inega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarkets.co= m>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@= gmail.com>, GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dic= k.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback on polymorphism=

     

    Hi Justin, 

     

    > Regarding your= question, what else could we propose? 

     

    I've started= a review of possibilities at https://github.com/fimbault/reasonab= ly-polymorphic/blob/main/README.md to be followed by actual code testing= . 

     

    Cheers,

    Fabien

     

    =

    On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega = <andrii.deinega@gmail.com&g= t; wrote:

    Hi Mika, Justin, and WG,

    =

     

    = The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) has = a JSON object as its value. This claim could be a part of AT JWT or a token = introspection response and has the same semantics in both cases. The JSON ob= ject as its value may look like this

    "act":
    {
      = "sub":"adm= in@example.com"
    }

    or even be nested like in

    "= act":
    {
     "sub":"https://service16.example.com",
     = ;  "act":
       {
         "sub&= quot;:"https://= service77.example.com"
       }
    }

    Personally, I = find it to be a very expressive approach. Also, as far I as know, several (o= Auth2) client libraries have good support of things like

    "aud&qu= ot;:"https://ser= vice1.example.com" and "aud":["https://service1.example.com",&qu= ot;https://service2.e= xample.com"]

    in AT JWTs for a quite long time.

     

    = Regards,

    Andrii

     

    On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    <= p class=3DMsoNormal>Hi Yaron,

     = ;

    We'll indeed have to check how make= it as idiomatic as possible with experts of each language (help welcome).&n= bsp;

     

    =

    Regarding the client, the variations are more limite= d but they do exist. Here I believe it's much more problematic than on the s= erver side and there are at least a few actions we should take:

     

    A) check in sec 7 if we really have a compelling reason for key and p= roof variants. This is derived from larger discussions on key binding as per= the related note. There are quite a few open questions related to this them= e. 

     

    B) there is also the choice between value/refere= nce that may generate complexity. 

     

    C) More generally= , as many feedbacks already have noticed, we need to have a systematic revie= w and reduce the set of available options in the protocol. <= /p>

     

    Unless we have a clear = idea why runtime behavior requires mutability, it might be useful to have a = way to define the chosen variant before hand, so that the expected behavior = becomes deterministic on the client side. There are various ways it could be= done in practice. 

    =  

    For sure several independ= ant implementations would help, especially if we make sure they can work tog= ether. 

     

    Anyway all this open to improvement. 

     

    <= p class=3DMsoNormal>Cheers 

    F= abien 

     

    Le mer. 28 oct. 2020 =C3= =A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit :

    Hi Fabien,

     

    At least in the case of Go, I think the =E2=80=9Cso= lution=E2=80=9D is far worse than the problem. The code in the article you cite is= very specific to the use case and IMHO quite ugly. So my preferred Go imple= mentation would be a combination of untyped structures (Go interface{}) and = run-time enforcement of JSON Schema.

     

    = Also, going back to our earlier discussion on this topic, I just read Sec. 7= of gnap-00 and realized that the RC also needs to deal with polymorphism (t= he =E2=80=9Ckey=E2=80=9D value), not only the AS.

     

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >Thanks,

            &nb= sp;       Yaron

     

    From: TXAuth <txauth-bounces@ietf.org> on beha= lf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, October 2= 8, 2020 at 18:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: = GNAP Mailing List <t= xauth@ietf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
    Subject:= Re: [GNAP] Feedback on polymorphism

    &= nbsp;

    Thanks for the great feedback. Your concern= is very valid. 

     

    <= div>

    My implementation is in rust, which makes life easier in that specific= case. 

     

    So I'm not a golang specialist but I guess the transcription of json str= ings/arrays into go structs would work around the lines described by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e= 58ed1

    When we have a more formalized json sch= ema, I suggest we make a library of json examples and some related code samp= les in mainstream languages, to check it is feasible for everyone. 

     

    Cheers,=

    Fabien

     

     

    On Wed, Oct 28, 2020 at 5:28 PM M= ika Bostr=C3=B6m <= mika.bostrom@smarkets.com> wrote:

    =

    Hi everyone,

     

    Looks like I stuck my finger in a hornets' nest. First off, apologies f= or not chipping in earlier, but there was a lot of material to digest. Also,= warning: lots to read ahead.

     

    I'm one of those people who end up making use of AuthN/AuthZ = functionality through a library. On top of that I can see myself being roped= in as a server (AS) implementation help. So I'm approaching this from an ou= tsider's perspective. Someone who expects to be exposed to the eventual RFC = and all the nitty-gritty details. My relatively terse comment ended up at th= e top of the aforementioned HN thread, which didn't necessarily help. Sorry = about that.

     

    Now= , having read Justin's initial reply - and the rest of the thread - I believ= e I can see where the desire for polymorphism comes from. To be clear: I am = all for strict types inside an implementation, as it will add helpful guard-= rails to the state management code paths. However, I see this as a case of l= eaky abstraction. If we take the existing oauth.xyj-java code to be the refe= rence implementation, the choice makes logical sense: JSON is not expressive= enough to serialise arbitrary objects, so in order to avoid writing complex= payload parser(s) the internal implementation details now leak to the proto= col itself. From a purely technical perspective, it's a cool trick. From a d= istance it even looks a bit like the result of protobuf decoding, but withou= t the generated code parts.

     

    =

    But then the downside. I don't personally expect to be able to = use the reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, Pyth= on, C#, Ruby, and JavaScript (thanks to node.js), and all of them will have = to deal with the polymorphism. From what I've read over the past couple of d= ays, I understand that at least Go supports custom unmarshalers from JSON to= typed structs, at the cost of an indirection. Normally when a Go code proce= sses JSON to a typed struct, the process is helped by field annotations in t= he type definition itself. For example, if the payload for a person in JSON = was

     

    {

      "name": "<string>",<= /o:p>

      "age": <int>,

      "country": "<string>",=

      "city": "<string>"

    }

     

    =

    .. then the type definition would look like:

     

    type Person struct {

      Name string `json:"name"

    =

      Age int `json:"age"`

      Co= untry string `json:"country"`

      Ci= ty string `json:"city"`

    }

     

    When the (possibly complex) = type of a given field is fixed, unmarshaling should still be straightforward= . I haven't verified, but since the annotation only gives which field to loo= k at for a given typed value, there should be nothing special about that. Bu= t when the field can instead be a union of more than one distinct types, thi= ngs start to get messy. There is no union type in the language at all, so th= e following construct is not even possible:

     = ;

    type Entity struct {

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >  Resources []string `json:"resources"`

    =

      Client union(Client, string) `json:"client"`

    }

     

    =

    As I understand, the implicit expectation is that in the above case, = the unmarshaler detects that "client" is a string, and so expands = it from an opaque handle to the expected, populated type. Even after thinkin= g about the ramifications over the past few days I remain confused, because = I don't see how the commonly used annotations could work. If the expectation= is that protocol implementations should use strong types, then the use of p= olymorphic JSON is very likely to make things _more_ complicated for non-ref= erence implementations.

     

    Hence my concern. I'm afraid that the leaky abstraction, while making t= he reference implementation more robust and straightforward, contributes to = making other implementations less robust. And this being a security protocol= , the potential for brittle and/or confused implementations is terrifying. <= o:p>

     

    I am a fan of reducin= g complexity, and from what I can see, for the reference implementation the = polymorphic approach actually does that. But I'm afraid it does so at others= ' expense. Languages have their individual constraints, idioms and best prac= tices. If parsing a protocol payload introduces low-level complexities and e= ncourages to go against common practices, that is an invitation for problems= . I am aware that my choice of words in the HN thread was likely to put peop= le on defense, and for that I apologise. But I do believe that the choice of= polymorphic JSON is going to make the life and use of other implementations= notably less boring than people in general would prefer.

     

    Cheers,

    =

    Mika

     

    On Mon, = 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Dick,

     

    <= /div>

    Well technically yes. Obviously the client can present any inter= face it seems fit. 

     

    Still there's the question of the common model we want to present = to the outside world and supported by the protocol itself (which client libr= aries all build upon). 

     

    But beneath the polyphormism question, the HN debate seems on = the surface a lot like the original xyz (polyphormism goes along with the re= duced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where = the client design has more latitude). Just explained differently, by outside= people with different agendas. 

     =

    Which is a bit weird because many of the critics on H= N (who criticize polyphormism) also seem to really dislike OAuth in the firs= t place (the inconsistencies are partially due to a bunch of different peopl= e commenting). 

     

    <= div>

    Really to me there's no fundamental truth behind that question. It's a= matter of preference and priorities in the design. Whatever choices we make= , we'll have to be prepared to explain and justify them in the open, even to= some people that will dislike pretty much whatever we do (because it's fun = to look smart and critize without proposing alternatives). And we owe these = answers to people like Mika, who genuinely try to make the best of it. =

     

    Fabien 

     

    Le lun. 26 oct. = 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    Hi Fabien

     

    A library developer can provide whatever abstraction layer makes sense fo= r the library's target audience and language.

    =

     

    If the client library developer wan= ts to use polymorphism in the interface presented to the user's of the = library, the library developer can do that independent of polymorphism in th= e protocol, and vice versa 

     

    =3D> polymorphism in the protocol has no impact on client= library developers

     

     

    Error! Filename not specified.=E1=90=A7

     

    On Sat, Oct 24, 202= 0 at 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    I'm just realizing your "least to most important" m= ight actually say the same as what I was trying to say. So I'm not even sure= what we're arguing against :-) 

     =

    In brief my point if it wasn't clear is that we should be c= rystal clear on where we put the cursor of simplicity, because this can mean= different things for different people and different roles. =

    And as we see on HN we need to better explain our design ch= oices. 

     

    &= nbsp;

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbaul= t <fabien.imbau= lt@gmail.com> a =C3=A9crit :

    Hi= Dick,

     

    Independantly = from the debate on polyphormism, I beg to differ on your order preference.&n= bsp;

     

    Your assum= ption is that AS devs matter the most, because they're doing the important security implementation. Bu= t eating our own dogfood might help a lot to change that view. Most security= issues occur because users of the spec are unable to deal with the complexi= ty that is passed onto them. 

     <= o:p>

    99% of the people that will actually use the outp= ut of the work are application developers (client or RS) and their own users= . 

     

    Our intent as well as the protocol dri= ve the usage. Client libraries may help, but they're not a silver bullet, es= pecially because GNAP ultimately has no control about what people do there (= for better or worse). And everything we do here will help get to the better = part. 

     

    I'm not saying we don't intend to also care about AS developers (beginni= ng with ourselves) but it's a second order optimisation. And since it's a te= ndancy we're leaning towards by default, I'm pretty sure we won't forget tha= t anyway. 

     

    <= div>

    Fabien 

     

    &= nbsp;

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt &l= t;dick.hardt@gmail.com= > a =C3=A9crit :

    I'm confused b= y your logic Fabien.

     

    = If a client library developer wants to expose polymorphism, they can do that= independent of what is in the protocol. 

    &n= bsp;

    I differ on who our stakeholders are. <= o:p>

     

    I think our sta= keholders are in least to most important:

     <= o:p>

    • AS develop= er
    • RS developer
      • client developer
    • user

     

    A client library developer can expose whatever interface they want to sim= plify implementation.

     

    =

    I list the user so that we don't lose site of a critical role.

     

    /Dick

    <= /div>

     

     

    Error! = Filename not specified.=E1=90=A7

     =

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.= com> wrote:

    Hi there, =

     

    Let me try to appro= ach the issue under a different light. More like a product manager would dea= l with feature selection to make it intuitive for its users. 

     

    For most people, riding a= bike is far easier than using a unicycle. Feels more stable. And yet it's w= ay easier to design for a single wheel than to build with 2. Because then yo= u'll need a lot more accessories (chain, chain ring, etc.). Even so producin= g a bike doesn't have to be a brittle process, it can be industrialized.&nbs= p;

     

    Back to the = GNAP topic. 

    Ultimately we should strive to make the spec as simple as can be. Bu= t we need to ask: simple for whom? For the bike owner or for the bike vendor= ? 

    (short answer: the priority should be simplicity for spec users, = not spec implementers and even less spec designers). =

     

    The initial question that= is asked is very interesting: isn't the design flawed if GNAP is using json= polyphormism? Or if the AS needs to handle the state of the request? Or if = we must handle token revocation? Or if we are looking for a global unique id= entifier? The argument stems of the fact that is still arguably harder and m= ore error prone to implement. Fair enough. 

    =  

    From a spec implementer's perspective, it = may well be more complex. It mostly impacts the json library you'll end up u= sing, plus a bit of input/output decoration around it. Even golang provides = utilities for this, despite not exactly being made for this kind of purpose.=

    My practical experience implementing it is that = it's not that big a deal. I mean, I wished it could be simpler, but it's man= ageable and there are other ways to reach levels of insurance that it does w= ork as intended (json schema, test cases to validate the implementation, etc= .). Arguably it is still easier from an implementation perspective than say,= json-ld, which is massively used in the SSI community. 

    =

     

    But ultimately who are we des= igning for? Are we striving to go easy on the spec implementer? Or are we tr= ying to make sure end-developers using the client libraries won't shoot them= selves in the foot?

     

    The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities for en= d-users by relying on some well known implementation. 

    In turn, this spec implementer will rely on cryptographic utility= libraries that deals internally with the complexity of their own domain, so= that we don't have to. And here we could launch another HN flame war that s= tarts with the title "JWT sucks because". Which does have its set = of very real issues but that's beyond the point. 

    <= div>

    Note that any decent flamewar will be efficiently fueled by people hat= ing medium. Is it outrageous for blog posts to be behind a paywall? Maybe bu= t it's even more outrageous to lack consistency, either by not knowing how t= o get around a paywall if you're into a hacker punk movement, or on the cont= rary by to not paying a subscription if you believe that surveillance capita= lism, to reuse Zuboff's terms, should be eradicated. 

    What likely seems an unnecessary sidenote tries to illustrate the = point: for Justin it was easier to publish on medium, because as a blog publ= isher, you might not want to deal with hosting your own blog. But maybe as a= reader you'll find that annoying. Different audiences, different JTBD, diff= erent tradeoffs. 

     

    Polyphormism is a tool that enables the end-developer to have minima= l knowledge of what it means to deal with a GNAP client library. You prepare= the request, send to the endpoint and you're good to go. Massively simpler = than OAuth2 or any similar protocol by the way (as anyone with teaching expe= rience on the subject might acknowledge). And  there's a lot more to be= done to make sure we indeed reduce the complexity for the end-developer and= the end-user. 

     

    <= div>

    If we find a better way to deal with that simplicity balance, I'm all = in. But the arguments need to be way more convincing than just saying that i= t may be difficult to implement or validate. 

    =

     

    Cheers.

    Fabie= n

     

     

     

     

    =

     

    Le ven. 23 oct. 2= 020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit :

    <= div>

     

     

    On Oct 23, 2020, at 3:52 PM, Dick Hardt= <dick.hardt@gmail.= com> wrote:

     

    Ju= stin

     

    I did note that = I was the one that argued for instance_id being in the object. Since it is i= n the object in the current draft, not including a pass by reference option = would be preferable. 

     

    <= /div>

    As for concrete examples:

    - version o= f client

    - version of OS

    - security attestation of OS / device

    - locati= on of client device

    - network client is operating= on

     

    These are a= ll attributes of the client that an AS may require on the initial grant= request, and in future grant requests (which is when an instance_id) would = be used.

     

    <= /blockquote>

     

    This is where our inter= pretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D in = the same way that the key, display information, class identifiers, and other= items currently represented by an instance_id are attributes of the client = instance. The attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. This is= why I argue that they ought to be handled in a separate object, so you=E2=80=99d = have something like this strawman:

     

    {

     

    =

      posture: {

        software_v= ersion: 1.2.3,

        os_version: 14.3.2

        device_attestation: { =E2=80=A6 some struc= ture or signed blob? =E2=80=A6 }

        location= : { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

      },=

     

      client: =E2=80=9Cc= lient-541-ab"

     

    }

     

    This is a= more fundamental question about GNAP than whether the syntax uses polymorph= ism: this is about GNAP being very explicit about the data model of its elem= ents. OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80=9Cclien= t=E2=80=9D is referring to, exactly, is deeply problematic in practice. We=E2=80=99re ev= en seeing that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed= client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the different aspects= that are out there. I think we=E2=80=99re getting closer here in GNAP with explic= it definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to be more precise= about what exactly a client instance includes, and what it does not.

     

     =E2=80=94 Justin=

     

     

    /Dick<= /o:p>

     

    Error! Filename not specified.<= /b>=E1=90=A7

     

    On= Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:

    Dick,

     

    A= s you=E2=80=99ll recall, I argued against including the client instance identifier= inside of the object as a mutually-exclusive field precisely because of the= principle violation that you are pointing out here, and so it=E2=80=99s important= to point out that the current text is a compromise that needs to be examine= d in the wider experience of the working group. I am on the side of removing= the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but this = needs to be explored.

     

    =

    The crux of my argument is that is exactly a case of pass-by-referenc= e vs pass-by-value, and that runtime attestations are not part of the =E2=80=9Ccli= ent instance=E2=80=9D value itself but rather belong outside of that object in a a= nother part of the request. As stated in the editorial notes in this section= , we need to look carefully at how these concepts fit within the model and w= here we would want to put them. Without concrete examples of what these exte= nsions look like and how they=E2=80=99re generated, that is nearly impossible to d= o at this stage. I look forward to seeing examples of this kind of data and = how it can fit into the protocol.

     

     =E2=80=94 Justin

     

    On Oc= t 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    &= nbsp;

    Hey Justin,

     =

    As the draft has evolved, I question the continu= ed use of polymorphism. Note that I appreciate the elegance of using a = string for pass-by-reference, and an object for pass-by-value.

     

    In the current draft, the&nb= sp;

     

    <= div>

    Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question. 

     

     

     

       instance_id  An identif= ier string that the AS can use to identify the

    &n= bsp;     particular instance of this RC.  The content and str= ucture of this

          identifier is= opaque to the RC.

     

       "client": {

      &nb= sp;    "instance_id": "client-541-ab"

       }

     

       If there are no additional fields to send, t= he RC MAY send the

       instance identifi= er as a direct reference value in lieu of the

    &nb= sp;  object.

     

       "client": "client-541-ab"

    =

     

    The instance ide= ntifier can be sent two ways. Polymorphism is a convenience for the client, = but requires the server to have two code paths for "instance_= id".  We discussed this in the design team, and I argued for havin= g "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a string (h= andle) to reference a previously provided object, it complicates how to upda= te an existing object while providing the reference.

     

    In your example of the "key"= object below, setting "proof" to bearer would avoid the issue you= describe:

     

    {&nb= sp;
     "key": { 
         "proof&quo= t;: "bearer"
        }
    }

    =  

    In your example, when processing the "= ;key" object, code is having to check both the JSON type of the propert= y, as well as check the value of the "proof" property. In the exam= ple I provided, only the value of "proof" needs to be checked. The= "proof" property is acting as a type for the "key" obje= ct.

     

    Not being a= Java programmer, I don't know how this would work in a Java implementation,= but node.js, the processing would need to be done as above.

    <= /div>

     

    On a related note, there was s= ignificant negative feedback on handles and polymorphism in the Hacker News = article https://news.ycombinator.com/item?id=3D24855750 <= /p>

     

    /Dick

    =

     

     

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:<= /p>

    Hi Mika,

     

    Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear up wh= at I mean with how polymorphism is used in the proposal. The short version i= s that the goal is to avoid the kinds of ambiguity that mak= e insecure protocols, and so in that goal we=E2=80=99re fully aligned. I think tha= t using polymorphism in very specific ways can help that goal =E2=80=94 just as I = agree that misusing it or applying it sloppily can lead to ambiguous and ins= ecure systems.

     

    = Some background: I built out the XYZ protocol (one of the predecessors to th= e initial GNAP Draft) in Java using strongly typed parsers and Java objects = specifically to prove to myself that it could be done in a way that made any= sense in the code. (My own open source implementation is at https://github.com/bs= pk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with the GNAP= spec). It was important to me that I be able to use the system-wide configu= red parsers to implement this and not have to resort to stepping through ele= ments completely by hand. Java doesn=E2=80=99t make it simple to get the hooks int= o the right places (especially with the Jackson parser that I used), but it = is definitely possible to create a deterministic and strongly-typed parser a= nd serializer for this kind of data structure. Some of the rationale for usi= ng polymorphism is covered in the trailing appendix of the draft document (<= a href=3D"https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.htm= l#name-json-structures-and-polymor" target=3D"_blank">https://www.ietf.org/arc= hive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polym= or), but it=E2=80=99s still good to discuss this here as the working group dec= ides which approaches to take. 

     <= /o:p>

    The driving reason for using polymorphism at the proto= col level was to simplify the protocol and make it :more: deterministic to c= reate and process, not less. Every time you create or process a field it wil= l mean only one thing, and there=E2=80=99s only one field to look at to answer a q= uestion. Without polymorphic field values, you usually need to rely on mutua= l exclusivity of fields, which is prone to failure and requires additional e= rror checking. Take for example the key binding of access tokens. An access = token could be bound to the RC=E2=80=99s key used during the request, to a differe= nt key chosen by the AS, or it could be a bearer token with no key at all. B= y making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in terms of boole= an values and objects and express this set of mutually-exclusive options in = a non-ambiguous way. Without that, you=E2=80=99d need to have different fields for= the options and include additional checks in your parser to make sure they = weren=E2=80=99t sent simultaneously, otherwise you could get hit with this potenti= al security vulnerability in an object:

     

    { 

        ke= y: {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80=A6 }

        },

       = bearer_token: true,

        bind_to_rc_key= : true

    }

     

    This would be an illegal object as per this alternate p= roposal, but then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t= put next to others in the same object. I=E2=80=99ve done this exercise with many = other protocols and it=E2=80=99s both error prone and easy to ignore since all the= =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2=80=99t check this. With the pol= ymorphic approach to this same field, each of these three mutually-exclusive= states is written in a way that they cannot be sent together. It=E2=80=99s not ju= st illegal, it=E2=80=99s impossible and enforced by the syntax of JSON itself.

     

    { <= /o:p>

        key: {

     =     proof: httpsig,

        &nbs= p; jwk: { =E2=80=A6 key value =E2=80=A6 }

        }

    }

     

    // bearer token

     

    <= /div>

    {

        key: false=

    }

     

    // bound to the RC=E2=80=99s presented key

    &n= bsp;

    {

        k= ey: true

    }

     =

    If someone sends a different type for this field, lik= e an array or number or a null, this doesn=E2=80=99t have a defined interpretation= in the protocol and would be a protocol level error.

     

    While it might sound like polymorphis= m means that any field could have any type or value, the opposite is true: e= ach possible value is explicitly typed, it=E2=80=99s just that there are potential= ly different types that express meaning for the field. This applies to all m= embers of all objects (dictionaries) as well as all members of an array (lis= t). Every time you process a field value or other element, you look at the t= ype and then the value to determine what to do with that typed value.

     

    In your example below= , each field within the dictionary would also need to be typed, and each typ= e would need to have a clear indication of its meaning. To take your strawma= n key format below, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically= as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON= string). The definition would further say what exactly the encoding of the = string would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D field there= wouldn=E2=80=99t be any confusion on what the value was or how it was represented= , regardless of the input format. Seeing a number there means exactly one in= terpretation and seeing a string means exactly one (different) interpretatio= n =E2=80=94 but importantly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the = field that determines the type. An implementation would likely use an intern= al BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the BigI= nteger value.You don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D f= ield, you apply it to all sub-fields of that object. 

     

    So let=E2=80=99s dig into the specific= bug you bring up in the strawman, because it=E2=80=99s interesting: A JSON encode= r that encodes numbers as strings, and not numbers, is not compliant with th= e JSON definitions of the field in question. For another example, the quoted= string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in J= SON, and they shouldn=E2=80=99t be treated the same by a parser implementation whe= n mapping to a concrete object. It=E2=80=99s in this kind of automated guessing th= at this class of bugs occur, and that=E2=80=99s going to be the case whether or no= t you take  advantage of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into c= ases where a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing t= his kind of mapping, but ended up introducing errors in more strict componen= ts downstream. This is something that protocol designers need to be aware of= and guard against in the design of the protocol to reduce possible ambiguit= ies. Within GNAP today, we generally have things that branch whether they=E2=80=99= re an object (for a rich description of something) or some non-structured sp= ecial value (for a reference or other item). 

    =

     

    The design team created some simple JSON= Schemas for parts of the protocol during our discussion, but we didn=E2=80=99t in= clude them in the design document due to both lack of time to keep it update= d with the rapid changes to the protocol during the design team discussion, = and not knowing if there would be interest in such material. I personally th= ink it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up eventually= .

     

     =E2=80=94 Jus= tin

     

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6= m <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:

     

    Hello, everyone.<= /p>

     

    For background: GNAP/TxAut= h/XYZ/Oauth3 came up on a discussion forum and when I made note about certai= n concerns, I was requested to send my comments to this working group.<= /o:p>

     

    In short, I believe = that the use of polymorphic JSON in the protocol invites subtle and confusin= g implementation problems. I also searched through the WG archives, and noti= ced that similar concerns were noted, briefly, in a thread in July.

     

    The problem with polym= orphic values, as I see it, is that implementations will need to branch on t= he (inferred) type of a given field. This isn't quite as bad if the types ar= e strictly different, but allows for subtle bugs when the value in question = is a dictionary. What makes this unappealing is that "subtle bugs"= in security protocols have a habit of turning into vulnerabilities.

     

    Let's say we have thes= e imaginary payloads, both possible and valid in the same protocol step:

     

    # payload 1

    {

      ...,

    =

      "public_key": {

    &nb= sp;   "alg": "rsa",

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >    "modulus": <BIGINT>

    =

      }

    }

    &nbs= p;

    # payload 2

    {<= /o:p>

      ...,

      "pu= blic_key": {

        "alg&qu= ot;: "rsa",

        "mo= dulus": "<encoded string>"

    &= nbsp; }

    }

     <= /o:p>

    In both cases, the type of "public_key" fiel= d is a dictionary. In both cases, they even have the same keys. However, the= values in the dictionaries are entirely different, and an implementation wi= ll have to branch to at least two possible decoding mechanisms. To make thin= gs worse, some JSON implementations may choose to encode non-dictionary valu= es as strings, so it is possible for an originator to transmit what they exp= ect and believe to be payload 1 format, but which the receiver will interpre= t to be in payload 2 format. And if the encoded string contains only digits,= it will even parse correctly as a bignum.

     =

    While the above is clearly a manufactured scenar= io, it nonetheless demonstrates the potential for logic bugs with polymorphi= c JSON. With richer types and more complex dictionaries, there will surely b= e more room for errors.

     

    Ambiguity in protocols is always a source of implementation complex= ity and interoperability snags, but in an AuthN/AuthZ protocol it is worse: = it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't = it be in everyone's interest to keep implementation complexity and mistake p= otential to a minimum?

     

    Best regards,

    Mika

     

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.iet= f.org/mailman/listinfo/txauth

    &= nbsp;

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailma= n/listinfo/txauth

    Error! Filename not speci= fied.=E1=90=A7

    &nbs= p;

    &= nbsp;

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailma= n/listinfo/txauth



    --

    =

    Mika Bostr=C3=B6m

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mail= man/listinfo/txauth

    =

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinf= o/txauth

    --B_3686919539_664918686-- From nobody Fri Oct 30 08:13:49 2020 Return-Path: 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 36AA83A0844 for ; Fri, 30 Oct 2020 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 ogCCPqKvhnCd for ; Fri, 30 Oct 2020 08:13:36 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 855553A00E0 for ; Fri, 30 Oct 2020 08:13:36 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k6so7881095ior.2 for ; Fri, 30 Oct 2020 08:13:36 -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=V5c0Hmh1iYxxcd2iEEVm2Dt7HZgsHZRaUcdKbsPSqAM=; b=hXenQqHI8LsVjuqKC5z/iGFKlYYqdB0eJIOlnHW2Dlnbvxuay6ouicqkGYc1c/IoXH 3UVKC1vGbwj2ckY43XKGg2BpbHIiKUN+okeKQ1tv1Tcc5PGG8GZmNtXLd0wXQid5XjJD eWbUNNXvGjTD+iQcNMSyWU1xO8gD2rua9CfOtafBgW7qP/dnpG5Aly/TvIxPMBBqkn19 NoNnCbpLqgs8p1YtdBMsH5u6A0JjS6mET4dCP2wVS3V3V7ZMGExNt5NAGLYTUjij/N0c YnxXb/JqZey8NH1NjHHykRelFdMCJcR2//JvlHZBLvg3AwZr7tcroSXepkYpv4qctAX/ DVYw== 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=V5c0Hmh1iYxxcd2iEEVm2Dt7HZgsHZRaUcdKbsPSqAM=; b=TXOeXQ4R0MVEvKZkNWnAd0FLMCWMtCc6a730v1E/greFVX/AM7nezCeUJQR9eIeDd0 bebGFpmc1eUBFDKzfgghHgLU8paZOI+aOi0TAw9NU5RsGoM8OykLQH3zIv1W0lgAzzBY MdWpCGtzAxrkDzQ0rjZQS7b8dTb6ci2zjpoz6ax8eTKPmLY1BvzxF0H1uBhBoAbhD25n DtkFcZx/x2B7ziVh9qUUcC6nymgOWJm5blDHZIof3mt8VJwjb/od9pu5wOZIOS9GA5/N iSzXylWrrUQiOwKwqYrrR12LWvdEE6QWmVhsKG9T23GKRaCH5Wrry8FLHMu2La9J00gm eRhA== X-Gm-Message-State: AOAM533O4ZE3v4zuyCNO2z/tbH9veaLjOK88MfPfzqFW3nWf57yySHg0 iKZWPKiAaM9h/wQlUBnq7D5BC9WzOfspnKKmtCg= X-Google-Smtp-Source: ABdhPJwCSm4OF5LarZ9Z8mzpT9rIVOOsJ8hLdfmeNVJhHVgQQr+4cWGhCVpixe+tzWYiido1utQbs4KIyC5Viol9SCM= X-Received: by 2002:a6b:3f88:: with SMTP id m130mr2159117ioa.78.1604070815476; Fri, 30 Oct 2020 08:13:35 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> In-Reply-To: <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> From: Fabien Imbault Date: Fri, 30 Oct 2020 16:13:21 +0100 Message-ID: To: Yaron Sheffer Cc: Andrii Deinega , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , Justin Richer , GNAP Mailing List , Dick Hardt Content-Type: multipart/alternative; boundary="00000000000026b1f305b2e4d750" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 15:13:46 -0000 --00000000000026b1f305b2e4d750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Thanks a lot for the feedback, I fixed the issue related to the standardisation status (I guess there's some historic background that I don't know ;-)). Is JSON the only real possible format? Probably, at least for compatibility with pretty much everything that exists. Only TJSON could maybe be used as an alternative (and kind of removes the need for a schema), with the downsides that you don't have so many existing libraries and that the community seems much smaller: 2k stars for JSON schema spec vs 65 for TJSON spec (and the expired website SSL certificate doesn't help). The main problem I see is that for constrained cases, CBOR won't have a schema in a foreseeable future (at least I'm not aware of any work on that). I know it's not our main focus right now and might not even be covered by the current WG, but still it might become an issue at some point. Best, Fabien On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer wrote= : > Hi Fabien, > > > > One correction, JSON Schema (which I am personally advocating for, but > still) does not have an IETF spec. They claim on their web site that they > want it standardized, but in practice are not (yet?) moving in this > direction. Their Internet Draft is unmaintained. > > > > At a higher level, I think your discussion conflates two things: the > representation of data on the wire (JSON or various mostly binary > encodings) and the data modeling language, a.k.a. schema. Personally I > think JSON is almost a must in our case, and if this is true, the playing > field is **much** more narrow. > > > > A major strength of JSON which you don=E2=80=99t mention in your comparis= on is the > cryptographic ecosystem (JOSE): standard formats for encryption, signatur= e > etc. > > > > I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a good = fit for us, still a very > interesting direction. > > > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Friday, October 30, 2020 at 14:53 > *To: *Andrii Deinega > *Cc: *Mika Bostr=C3=B6m , Justin Richer < > jricher@mit.edu>, Yaron Sheffer , GNAP Mailing > List , Dick Hardt > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Hi Justin, > > > > > Regarding your question, what else could we propose? > > > > I've started a review of possibilities at > https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md to > be followed by actual code testing. > > > > Cheers, > > Fabien > > > > On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega > wrote: > > Hi Mika, Justin, and WG, > > > > The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) > has a JSON object as its value. This claim could be a part of AT JWT or a > token introspection response and has the same semantics in both cases. Th= e > JSON object as its value may look like this > > "act": > { > "sub":"admin@example.com" > } > > or even be nested like in > > "act": > { > "sub":"https://service16.example.com", > "act": > { > "sub":"https://service77.example.com" > } > } > > Personally, I find it to be a very expressive approach. Also, as far I as > know, several (oAuth2) client libraries have good support of things like > > "aud":"https://service1.example.com" and "aud":[" > https://service1.example.com","https://service2.example.com"] > > in AT JWTs for a quite long time. > > > > Regards, > > Andrii > > > > On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault > wrote: > > Hi Yaron, > > > > We'll indeed have to check how make it as idiomatic as possible with > experts of each language (help welcome). > > > > Regarding the client, the variations are more limited but they do exist. > Here I believe it's much more problematic than on the server side and the= re > are at least a few actions we should take: > > > > A) check in sec 7 if we really have a compelling reason for key and proof > variants. This is derived from larger discussions on key binding as per t= he > related note. There are quite a few open questions related to this theme. > > > > B) there is also the choice between value/reference that may generate > complexity. > > > > C) More generally, as many feedbacks already have noticed, we need to hav= e > a systematic review and reduce the set of available options in the > protocol. > > > > Unless we have a clear idea why runtime behavior requires mutability, it > might be useful to have a way to define the chosen variant before hand, s= o > that the expected behavior becomes deterministic on the client side. Ther= e > are various ways it could be done in practice. > > > > For sure several independant implementations would help, especially if we > make sure they can work together. > > > > Anyway all this open to improvement. > > > > Cheers > > Fabien > > > > Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = a > =C3=A9crit : > > Hi Fabien, > > > > At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is far= worse than the > problem. The code in the article you cite is very specific to the use cas= e > and IMHO quite ugly. So my preferred Go implementation would be a > combination of untyped structures (Go interface{}) and run-time enforceme= nt > of JSON Schema. > > > > Also, going back to our earlier discussion on this topic, I just read Sec= . > 7 of gnap-00 and realized that the RC also needs to deal with polymorphis= m > (the =E2=80=9Ckey=E2=80=9D value), not only the AS. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Wednesday, October 28, 2020 at 18:56 > *To: *Mika Bostr=C3=B6m > *Cc: *GNAP Mailing List , Justin Richer , > Dick Hardt > *Subject: *Re: [GNAP] Feedback on polymorphism > > > > Thanks for the great feedback. Your concern is very valid. > > > > My implementation is in rust, which makes life easier in that specific > case. > > > > So I'm not a golang specialist but I guess the transcription of json > strings/arrays into go structs would work around the lines described by > https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 > > When we have a more formalized json schema, I suggest we make a library o= f > json examples and some related code samples in mainstream languages, to > check it is feasible for everyone. > > > > Cheers, > > Fabien > > > > > > On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m > wrote: > > Hi everyone, > > > > Looks like I stuck my finger in a hornets' nest. First off, apologies for > not chipping in earlier, but there was a lot of material to digest. Also, > warning: lots to read ahead. > > > > I'm one of those people who end up making use of AuthN/AuthZ functionalit= y > through a library. On top of that I can see myself being roped in as a > server (AS) implementation help. So I'm approaching this from an outsider= 's > perspective. Someone who expects to be exposed to the eventual RFC and al= l > the nitty-gritty details. My relatively terse comment ended up at the top > of the aforementioned HN thread, which didn't necessarily help. Sorry abo= ut > that. > > > > Now, having read Justin's initial reply - and the rest of the thread - I > believe I can see where the desire for polymorphism comes from. To be > clear: I am all for strict types inside an implementation, as it will add > helpful guard-rails to the state management code paths. However, I see th= is > as a case of leaky abstraction. If we take the existing oauth.xyj-java co= de > to be the reference implementation, the choice makes logical sense: JSON = is > not expressive enough to serialise arbitrary objects, so in order to avoi= d > writing complex payload parser(s) the internal implementation details now > leak to the protocol itself. From a purely technical perspective, it's a > cool trick. From a distance it even looks a bit like the result of protob= uf > decoding, but without the generated code parts. > > > > But then the downside. I don't personally expect to be able to use the > reference implementation, being mostly a Python user myself. A fair numbe= r > of AS implementations will be written with languages such as Go, Python, > C#, Ruby, and JavaScript (thanks to node.js), and all of them will have t= o > deal with the polymorphism. From what I've read over the past couple of > days, I understand that at least Go supports custom unmarshalers from JSO= N > to typed structs, at the cost of an indirection. Normally when a Go code > processes JSON to a typed struct, the process is helped by field > annotations in the type definition itself. For example, if the payload fo= r > a person in JSON was > > > > { > > "name": "", > > "age": , > > "country": "", > > "city": "" > > } > > > > .. then the type definition would look like: > > > > type Person struct { > > Name string `json:"name" > > Age int `json:"age"` > > Country string `json:"country"` > > City string `json:"city"` > > } > > > > When the (possibly complex) type of a given field is fixed, unmarshaling > should still be straightforward. I haven't verified, but since the > annotation only gives which field to look at for a given typed value, the= re > should be nothing special about that. But when the field can instead be a > union of more than one distinct types, things start to get messy. There i= s > no union type in the language at all, so the following construct is not > even possible: > > > > type Entity struct { > > Resources []string `json:"resources"` > > Client union(Client, string) `json:"client"` > > } > > > > As I understand, the implicit expectation is that in the above case, the > unmarshaler detects that "client" is a string, and so expands it from an > opaque handle to the expected, populated type. Even after thinking about > the ramifications over the past few days I remain confused, because I don= 't > see how the commonly used annotations could work. If the expectation is > that protocol implementations should use strong types, then the use of > polymorphic JSON is very likely to make things _more_ complicated for > non-reference implementations. > > > > Hence my concern. I'm afraid that the leaky abstraction, while making the > reference implementation more robust and straightforward, contributes to > making other implementations less robust. And this being a security > protocol, the potential for brittle and/or confused implementations is > terrifying. > > > > I am a fan of reducing complexity, and from what I can see, for the > reference implementation the polymorphic approach actually does that. But > I'm afraid it does so at others' expense. Languages have their individual > constraints, idioms and best practices. If parsing a protocol payload > introduces low-level complexities and encourages to go against common > practices, that is an invitation for problems. I am aware that my choice = of > words in the HN thread was likely to put people on defense, and for that = I > apologise. But I do believe that the choice of polymorphic JSON is going = to > make the life and use of other implementations notably less boring than > people in general would prefer. > > > > Cheers, > > Mika > > > > On Mon, 26 Oct 2020 at 02:04, Fabien Imbault > wrote: > > Hi Dick, > > > > Well technically yes. Obviously the client can present any interface it > seems fit. > > > > Still there's the question of the common model we want to present to the > outside world and supported by the protocol itself (which client librarie= s > all build upon). > > > > But beneath the polyphormism question, the HN debate seems on the surface > a lot like the original xyz (polyphormism goes along with the reduced > endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where the > client design has more latitude). Just explained differently, by outside > people with different agendas. > > > > Which is a bit weird because many of the critics on HN (who criticize > polyphormism) also seem to really dislike OAuth in the first place (the > inconsistencies are partially due to a bunch of different people > commenting). > > > > Really to me there's no fundamental truth behind that question. It's a > matter of preference and priorities in the design. Whatever choices we > make, we'll have to be prepared to explain and justify them in the open, > even to some people that will dislike pretty much whatever we do (because > it's fun to look smart and critize without proposing alternatives). And w= e > owe these answers to people like Mika, who genuinely try to make the best > of it. > > > > Fabien > > > > Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : > > Hi Fabien > > > > A library developer can provide whatever abstraction layer makes sense fo= r > the library's target audience and language. > > > > If the client library developer wants to use polymorphism in the interfac= e > presented to the user's of the library, the library developer can do that > independent of polymorphism in the protocol, and vice versa > > > > =3D> polymorphism in the protocol has no impact on client library develop= ers > > > > > > *Error! Filename not specified.*=E1=90=A7 > > > > On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault > wrote: > > I'm just realizing your "least to most important" might actually say the > same as what I was trying to say. So I'm not even sure what we're arguing > against :-) > > > > In brief my point if it wasn't clear is that we should be crystal clear o= n > where we put the cursor of simplicity, because this can mean different > things for different people and different roles. > > And as we see on HN we need to better explain our design choices. > > > > > > Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault a > =C3=A9crit : > > Hi Dick, > > > > Independantly from the debate on polyphormism, I beg to differ on your > order preference. > > > > Your assumption is that AS devs matter the most, because they're doing > the important security implementation. But eating our own dogfood might > help a lot to change that view. Most security issues occur because users = of > the spec are unable to deal with the complexity that is passed onto them. > > > > 99% of the people that will actually use the output of the work are > application developers (client or RS) and their own users. > > > > Our intent as well as the protocol drive the usage. Client libraries may > help, but they're not a silver bullet, especially because GNAP ultimately > has no control about what people do there (for better or worse). And > everything we do here will help get to the better part. > > > > I'm not saying we don't intend to also care about AS developers (beginnin= g > with ourselves) but it's a second order optimisation. And since it's a > tendancy we're leaning towards by default, I'm pretty sure we won't forge= t > that anyway. > > > > Fabien > > > > > > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : > > I'm confused by your logic Fabien. > > > > If a client library developer wants to expose polymorphism, they can do > that independent of what is in the protocol. > > > > I differ on who our stakeholders are. > > > > I think our stakeholders are in least to most important: > > > > - AS developer > - RS developer > - client developer > - user > > > > A client library developer can expose whatever interface they want to > simplify implementation. > > > > I list the user so that we don't lose site of a critical role. > > > > /Dick > > > > > > *Error! Filename not specified.*=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault > wrote: > > Hi there, > > > > Let me try to approach the issue under a different light. More like a > product manager would deal with feature selection to make it intuitive fo= r > its users. > > > > For most people, riding a bike is far easier than using a unicycle. Feels > more stable. And yet it's way easier to design for a single wheel than to > build with 2. Because then you'll need a lot more accessories (chain, cha= in > ring, etc.). Even so producing a bike doesn't have to be a brittle proces= s, > it can be industrialized. > > > > Back to the GNAP topic. > > Ultimately we should strive to make the spec as simple as can be. But we > need to ask: simple for whom? For the bike owner or for the bike vendor? > > (short answer: the priority should be simplicity for spec users, not spec > implementers and even less spec designers). > > > > The initial question that is asked is very interesting: isn't the design > flawed if GNAP is using json polyphormism? Or if the AS needs to handle t= he > state of the request? Or if we must handle token revocation? Or if we are > looking for a global unique identifier? The argument stems of the fact th= at > is still arguably harder and more error prone to implement. Fair enough. > > > > From a spec implementer's perspective, it may well be more complex. It > mostly impacts the json library you'll end up using, plus a bit of > input/output decoration around it. Even golang provides utilities for thi= s, > despite not exactly being made for this kind of purpose. > > My practical experience implementing it is that it's not that big a deal. > I mean, I wished it could be simpler, but it's manageable and there are > other ways to reach levels of insurance that it does work as intended (js= on > schema, test cases to validate the implementation, etc.). Arguably it is > still easier from an implementation perspective than say, json-ld, which = is > massively used in the SSI community. > > > > But ultimately who are we designing for? Are we striving to go easy on th= e > spec implementer? Or are we trying to make sure end-developers using the > client libraries won't shoot themselves in the foot? > > > > The job to be done (JTBD), from the end-developer's perspective, is to > efficiently ship an application. And provide authN/authZ capabilities for > end-users by relying on some well known implementation. > > In turn, this spec implementer will rely on cryptographic utility > libraries that deals internally with the complexity of their own domain, = so > that we don't have to. And here we could launch another HN flame war that > starts with the title "JWT sucks because". Which does have its set of ver= y > real issues but that's beyond the point. > > Note that any decent flamewar will be efficiently fueled by people hating > medium. Is it outrageous for blog posts to be behind a paywall? Maybe but > it's even more outrageous to lack consistency, either by not knowing how = to > get around a paywall if you're into a hacker punk movement, or on the > contrary by to not paying a subscription if you believe that surveillance > capitalism, to reuse Zuboff's terms, should be eradicated. > > What likely seems an unnecessary sidenote tries to illustrate the point: > for Justin it was easier to publish on medium, because as a blog publishe= r, > you might not want to deal with hosting your own blog. But maybe as a > reader you'll find that annoying. Different audiences, different JTBD, > different tradeoffs. > > > > Polyphormism is a tool that enables the end-developer to have minimal > knowledge of what it means to deal with a GNAP client library. You prepar= e > the request, send to the endpoint and you're good to go. Massively simple= r > than OAuth2 or any similar protocol by the way (as anyone with teaching > experience on the subject might acknowledge). And there's a lot more to = be > done to make sure we indeed reduce the complexity for the end-developer a= nd > the end-user. > > > > If we find a better way to deal with that simplicity balance, I'm all in. > But the arguments need to be way more convincing than just saying that it > may be difficult to implement or validate. > > > > Cheers. > > Fabien > > > > > > > > > > > > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : > > > > > > On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: > > > > Justin > > > > I did note that I was the one that argued for instance_id being in the > object. Since it is in the object in the current draft, not including a > pass by reference option would be preferable. > > > > As for concrete examples: > > - version of client > > - version of OS > > - security attestation of OS / device > > - location of client device > > - network client is operating on > > > > These are all attributes of the client that an AS may require on the > initial grant request, and in future grant requests (which is when an > instance_id) would be used. > > > > > > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes > of the client=E2=80=9D in the same way that the key, display information,= class > identifiers, and other items currently represented by an instance_id are > attributes of the client instance. The attestation components don=E2=80= =99t modify > the instance so much as present additional information on top of the clie= nt > instance itself. This is why I argue that they ought to be handled in a > separate object, so you=E2=80=99d have something like this strawman: > > > > { > > > > posture: { > > software_version: 1.2.3, > > os_version: 14.3.2 > > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } > > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } > > }, > > > > client: =E2=80=9Cclient-541-ab" > > > > } > > > > This is a more fundamental question about GNAP than whether the syntax > uses polymorphism: this is about GNAP being very explicit about the data > model of its elements. OAuth 2=E2=80=99s incredibly loose and broad model= of what > the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pro= blematic in > practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havin= g to > define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture > the different aspects that are out there. I think we=E2=80=99re getting c= loser here > in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, bu= t we still need to > be more precise about what exactly a client instance includes, and what i= t > does not. > > > > =E2=80=94 Justin > > > > > > /Dick > > > > *Error! Filename not specified.*=E1=90=A7 > > > > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: > > Dick, > > > > As you=E2=80=99ll recall, I argued against including the client instance > identifier inside of the object as a mutually-exclusive field precisely > because of the principle violation that you are pointing out here, and so > it=E2=80=99s important to point out that the current text is a compromise= that > needs to be examined in the wider experience of the working group. I am o= n > the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D= option within an > object, but this needs to be explored. > > > > The crux of my argument is that is exactly a case of pass-by-reference vs > pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient > instance=E2=80=9D value itself but rather belong outside of that object i= n a > another part of the request. As stated in the editorial notes in this > section, we need to look carefully at how these concepts fit within the > model and where we would want to put them. Without concrete examples of > what these extensions look like and how they=E2=80=99re generated, that i= s nearly > impossible to do at this stage. I look forward to seeing examples of this > kind of data and how it can fit into the protocol. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: > > > > Hey Justin, > > > > As the draft has evolved, I question the continued use of polymorphism. > Note that I appreciate the elegance of using a string for > pass-by-reference, and an object for pass-by-value. > > > > In the current draft, the > > > > Every time you create or process a field it will mean only one thing, and > there=E2=80=99s only one field to look at to answer a question. > > > > is violated in 2.3.1. Identifying the RC Instance > > > > > > > instance_id An identifier string that the AS can use to identify the > > particular instance of this RC. The content and structure of this > > identifier is opaque to the RC. > > > > "client": { > > "instance_id": "client-541-ab" > > } > > > > If there are no additional fields to send, the RC MAY send the > > instance identifier as a direct reference value in lieu of the > > object. > > > > "client": "client-541-ab" > > > > The instance identifier can be sent two ways. Polymorphism is a > convenience for the client, but requires the server to have two code path= s > for "instance_id". We discussed this in the design team, and I argued fo= r > having "instance_id" in the "client" object so that any updates, such as > new devices assertions, could be in the "client" object. As noted above, > while I appreciate the elegance of using a string (handle) to reference a > previously provided object, it complicates how to update an existing obje= ct > while providing the reference. > > > > In your example of the "key" object below, setting "proof" to bearer woul= d > avoid the issue you describe: > > > > { > "key": { > "proof": "bearer" > } > } > > > > In your example, when processing the "key" object, code is having to chec= k > both the JSON type of the property, as well as check the value of the > "proof" property. In the example I provided, only the value of "proof" > needs to be checked. The "proof" property is acting as a type for the "ke= y" > object. > > > > Not being a Java programmer, I don't know how this would work in a Java > implementation, but node.js, the processing would need to be done as abov= e. > > > > On a related note, there was significant negative feedback on handles and > polymorphism in the Hacker News article > https://news.ycombinator.com/item?id=3D24855750 > > > > /Dick > > > > > > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: > > Hi Mika, > > > > Thanks for bringing this topic here =E2=80=94 I was able to see the forum > discussion that brought you here, and hopefully I can help clear up what = I > mean with how polymorphism is used in the proposal. The short version is > that the goal is to *avoid* the kinds of ambiguity that make insecure > protocols, and so in that goal we=E2=80=99re fully aligned. I think that = using > polymorphism in very specific ways can help that goal =E2=80=94 just as I= agree > that misusing it or applying it sloppily can lead to ambiguous and insecu= re > systems. > > > > Some background: I built out the XYZ protocol (one of the predecessors to > the initial GNAP Draft) in Java using strongly typed parsers and Java > objects specifically to prove to myself that it could be done in a way th= at > made any sense in the code. (My own open source implementation is at > https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not ye= t up to > date with the GNAP spec). It was important to me that I be able to use th= e > system-wide configured parsers to implement this and not have to resort t= o > stepping through elements completely by hand. Java doesn=E2=80=99t make i= t simple > to get the hooks into the right places (especially with the Jackson parse= r > that I used), but it is definitely possible to create a deterministic and > strongly-typed parser and serializer for this kind of data structure. Som= e > of the rationale for using polymorphism is covered in the trailing append= ix > of the draft document ( > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor), > but it=E2=80=99s still good to discuss this here as the working group dec= ides which > approaches to take. > > > > The driving reason for using polymorphism at the protocol level was to > simplify the protocol and make it :more: deterministic to create and > process, not less. Every time you create or process a field it will mean > only one thing, and there=E2=80=99s only one field to look at to answer a= question. > Without polymorphic field values, you usually need to rely on mutual > exclusivity of fields, which is prone to failure and requires additional > error checking. Take for example the key binding of access tokens. An > access token could be bound to the RC=E2=80=99s key used during the reque= st, to a > different key chosen by the AS, or it could be a bearer token with no key > at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of > boolean values and objects and express this set of mutually-exclusive > options in a non-ambiguous way. Without that, you=E2=80=99d need to have = different > fields for the options and include additional checks in your parser to ma= ke > sure they weren=E2=80=99t sent simultaneously, otherwise you could get hi= t with > this potential security vulnerability in an object: > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > }, > > bearer_token: true, > > bind_to_rc_key: true > > } > > > > This would be an illegal object as per this alternate proposal, but then > you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others > in the same object. I=E2=80=99ve done this exercise with many other proto= cols and > it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9Cg= ood=E2=80=9D examples > would pass code that doesn=E2=80=99t check this. With the polymorphic app= roach to > this same field, each of these three mutually-exclusive states is written > in a way that they cannot be sent together. It=E2=80=99s not just illegal= , it=E2=80=99s > impossible and enforced by the syntax of JSON itself. > > > > { > > key: { > > proof: httpsig, > > jwk: { =E2=80=A6 key value =E2=80=A6 } > > } > > } > > > > // bearer token > > > > { > > key: false > > } > > > > // bound to the RC=E2=80=99s presented key > > > > { > > key: true > > } > > > > If someone sends a different type for this field, like an array or number > or a null, this doesn=E2=80=99t have a defined interpretation in the prot= ocol and > would be a protocol level error. > > > > While it might sound like polymorphism means that any field could have an= y > type or value, the opposite is true: each possible value is explicitly > typed, it=E2=80=99s just that there are potentially different types that = express > meaning for the field. This applies to all members of all objects > (dictionaries) as well as all members of an array (list). Every time you > process a field value or other element, you look at the type and then the > value to determine what to do with that typed value. > > > > In your example below, each field within the dictionary would also need t= o > be typed, and each type would need to have a clear indication of its > meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could > be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON n= umber) or an > =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would fu= rther say what > exactly the encoding of the string would be. That means that when you rea= d > the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusi= on on what the value was > or how it was represented, regardless of the input format. Seeing a numbe= r > there means exactly one interpretation and seeing a string means exactly > one (different) interpretation =E2=80=94 but importantly, both of them ar= e a > =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determines= the type. An > implementation would likely use an internal BigInteger type of object to > represent the field value after parsing, so the question is how to go fro= m > the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just > apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you apply= it to all > sub-fields of that object. > > > > So let=E2=80=99s dig into the specific bug you bring up in the strawman, = because > it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings,= and not > numbers, is not compliant with the JSON definitions of the field in > question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not > equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t = be treated > the same by a parser implementation when mapping to a concrete object. It= =E2=80=99s > in this kind of automated guessing that this class of bugs occur, and > that=E2=80=99s going to be the case whether or not you take advantage of= JSON=E2=80=99s > polymorphic nature. I=E2=80=99ve run into cases where a parser library wa= s trying > to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but= ended up > introducing errors in more strict components downstream. This is somethin= g > that protocol designers need to be aware of and guard against in the desi= gn > of the protocol to reduce possible ambiguities. Within GNAP today, we > generally have things that branch whether they=E2=80=99re an object (for = a rich > description of something) or some non-structured special value (for a > reference or other item). > > > > The design team created some simple JSON Schemas for parts of the protoco= l > during our discussion, but we didn=E2=80=99t include them in the design d= ocument > due to both lack of time to keep it updated with the rapid changes to the > protocol during the design team discussion, and not knowing if there woul= d > be interest in such material. I personally think it would be helpful to > include as an informative reference in the final document, but that=E2=80= =99s > something for the working group to take up eventually. > > > > =E2=80=94 Justin > > > > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < > mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: > > > > Hello, everyone. > > > > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and > when I made note about certain concerns, I was requested to send my > comments to this working group. > > > > In short, I believe that the use of polymorphic JSON in the protocol > invites subtle and confusing implementation problems. I also searched > through the WG archives, and noticed that similar concerns were noted, > briefly, in a thread in July. > > > > The problem with polymorphic values, as I see it, is that implementations > will need to branch on the (inferred) type of a given field. This isn't > quite as bad if the types are strictly different, but allows for subtle > bugs when the value in question is a dictionary. What makes this > unappealing is that "subtle bugs" in security protocols have a habit of > turning into vulnerabilities. > > > > Let's say we have these imaginary payloads, both possible and valid in th= e > same protocol step: > > > > # payload 1 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": > > } > > } > > > > # payload 2 > > { > > ..., > > "public_key": { > > "alg": "rsa", > > "modulus": "" > > } > > } > > > > In both cases, the type of "public_key" field is a dictionary. In both > cases, they even have the same keys. However, the values in the > dictionaries are entirely different, and an implementation will have to > branch to at least two possible decoding mechanisms. To make things worse= , > some JSON implementations may choose to encode non-dictionary values as > strings, so it is possible for an originator to transmit what they expect > and believe to be payload 1 format, but which the receiver will interpret > to be in payload 2 format. And if the encoded string contains only digits= , > it will even parse correctly as a bignum. > > > > While the above is clearly a manufactured scenario, it nonetheless > demonstrates the potential for logic bugs with polymorphic JSON. With > richer types and more complex dictionaries, there will surely be more roo= m > for errors. > > > > Ambiguity in protocols is always a source of implementation complexity an= d > interoperability snags, but in an AuthN/AuthZ protocol it is worse: it's > terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it > be in everyone's interest to keep implementation complexity and mistake > potential to a minimum? > > > > Best regards, > > Mika > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > *Error! Filename not specified.*=E1=90=A7 > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > > Mika Bostr=C3=B6m > > Smarkets > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --00000000000026b1f305b2e4d750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    --
    TXAuth mailing list
    = TXAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth

    --00000000000026b1f305b2e4d750-- From nobody Fri Oct 30 08:21:25 2020 Return-Path: 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 A71073A0B9C for ; Fri, 30 Oct 2020 08:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 nTWwfLLOh1z2 for ; Fri, 30 Oct 2020 08:21:17 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 951D23A0B8A for ; Fri, 30 Oct 2020 08:21:16 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 2so7254356ljj.13 for ; Fri, 30 Oct 2020 08:21:16 -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=Tr7ZAe4LnyQjiUpS3c2SyEvj83uSaWHBkrzHVmOUwXA=; b=CQDEGAX/3MF7jyQH9HK18uNmmjmMeThLhEVqLSito2j6aGK7en2fHDhlu3DailOmDA 18S0+6lxpsoFcWJ7AN6pH5RBXRcUYsCo6fCcog7kEwznxdorWJXh8/LyEQPDCgvhxuDb ije7+acuPFILbkBZkocIjZo1cPf5R9Spnh2r2IH0mDed5xlKA27dXPzzc0eemyo/O2pP qIi6cGY0YczffWvsglxXGrZLFDFUQEcbNeeQSySb0Zh6EnhoHomSjwlki7dGVTY3xqvO N0NzO92dtzGDInBP7VrcKzI95VAkqWY2wjrKOF/8Wdnu30ekEqLfnbJujxD/KrtPWWY1 Qe4w== 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=Tr7ZAe4LnyQjiUpS3c2SyEvj83uSaWHBkrzHVmOUwXA=; b=tyVKz+7nc9uMlSxOd3Z1L/ldgwlXh1KNExsXH+yG0zD4xErMfHvs61Yf08BvlxEtqq lpSjVsACVn7Vw7Gpww0t7aM4OSBM3ayWOljLPmp+LvQdIu/HNyEroJrw9ElBNj9fJDQ3 jVBBAZai5Rd4YIUSYAA1tdn1zPoxGjSmkRks9FosqaCzuSh//RMY6p7NOWub954zNkRD kejRlJABvg6umwJj4OaPQjBM36GltEToxW1QXOIifK96qCtxkXlMv8Lry96qq5+fYZI/ MekPBT9MYUnlGGl/zcj3epMmCneU4BQOBA+mxdNTsV8BI+Lc6sKLSfLXaCctKLxdQZdu 4qtA== X-Gm-Message-State: AOAM531ww8cAI+5/CDo44Ujc5kiykcz1+PARMV4CKONhUhaoWk/thXAe UHSOBpPMoDw5F/6kQZ3ert988UXVeHou4O3ZIZc= X-Google-Smtp-Source: ABdhPJz6qWv711RvltG5g4Ea7jNjccGeN7NNRl17LMX6oIhdQ3tZb+1AFS2VnAT5MQ+Q/eFtzM2ipQFUg/pCneYAy5o= X-Received: by 2002:a2e:8056:: with SMTP id p22mr1226400ljg.437.1604071274376; Fri, 30 Oct 2020 08:21:14 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> In-Reply-To: From: Dick Hardt Date: Fri, 30 Oct 2020 08:20:37 -0700 Message-ID: To: Fabien Imbault Cc: Yaron Sheffer , Andrii Deinega , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000080f40d05b2e4f29b" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 15:21:24 -0000 --00000000000080f40d05b2e4f29b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I exchanged some emails with the JSON Schema team last summer. They are actively working on a revision to better server OpenAPI. They felt stonewalled at the IETF and now question the value of spending time in a standards body. Another schema option is JSON Type Definition [1], which is built on CDDL (RFC 8610) [2], the CBOR type language. [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition [2] https://tools.ietf.org/html/rfc8610 =E1=90=A7 On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault wrote: > Hi Yaron, > > Thanks a lot for the feedback, I fixed the issue related to the > standardisation status (I guess there's some historic background that I > don't know ;-)). > > Is JSON the only real possible format? Probably, at least for > compatibility with pretty much everything that exists. Only TJSON could > maybe be used as an alternative (and kind of removes the need for a > schema), with the downsides that you don't have so many existing librarie= s > and that the community seems much smaller: 2k stars for JSON schema spec = vs > 65 for TJSON spec (and the expired website SSL certificate doesn't help). > > The main problem I see is that for constrained cases, CBOR won't have a > schema in a foreseeable future (at least I'm not aware of any work on > that). I know it's not our main focus right now and might not even be > covered by the current WG, but still it might become an issue at some > point. > > Best, > Fabien > > On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer > wrote: > >> Hi Fabien, >> >> >> >> One correction, JSON Schema (which I am personally advocating for, but >> still) does not have an IETF spec. They claim on their web site that the= y >> want it standardized, but in practice are not (yet?) moving in this >> direction. Their Internet Draft is unmaintained. >> >> >> >> At a higher level, I think your discussion conflates two things: the >> representation of data on the wire (JSON or various mostly binary >> encodings) and the data modeling language, a.k.a. schema. Personally I >> think JSON is almost a must in our case, and if this is true, the playin= g >> field is **much** more narrow. >> >> >> >> A major strength of JSON which you don=E2=80=99t mention in your compari= son is >> the cryptographic ecosystem (JOSE): standard formats for encryption, >> signature etc. >> >> >> >> I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a good= fit for us, still a very >> interesting direction. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Fabien Imbault >> *Date: *Friday, October 30, 2020 at 14:53 >> *To: *Andrii Deinega >> *Cc: *Mika Bostr=C3=B6m , Justin Richer < >> jricher@mit.edu>, Yaron Sheffer , GNAP Mailing >> List , Dick Hardt >> *Subject: *Re: [GNAP] Feedback on polymorphism >> >> >> >> Hi Justin, >> >> >> >> > Regarding your question, what else could we propose? >> >> >> >> I've started a review of possibilities at >> https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md >> to be followed by actual code testing. >> >> >> >> Cheers, >> >> Fabien >> >> >> >> On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega >> wrote: >> >> Hi Mika, Justin, and WG, >> >> >> >> The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) >> has a JSON object as its value. This claim could be a part of AT JWT or = a >> token introspection response and has the same semantics in both cases. T= he >> JSON object as its value may look like this >> >> "act": >> { >> "sub":"admin@example.com" >> } >> >> or even be nested like in >> >> "act": >> { >> "sub":"https://service16.example.com", >> "act": >> { >> "sub":"https://service77.example.com" >> } >> } >> >> Personally, I find it to be a very expressive approach. Also, as far I a= s >> know, several (oAuth2) client libraries have good support of things like >> >> "aud":"https://service1.example.com" and "aud":[" >> https://service1.example.com","https://service2.example.com"] >> >> in AT JWTs for a quite long time. >> >> >> >> Regards, >> >> Andrii >> >> >> >> On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault >> wrote: >> >> Hi Yaron, >> >> >> >> We'll indeed have to check how make it as idiomatic as possible with >> experts of each language (help welcome). >> >> >> >> Regarding the client, the variations are more limited but they do exist. >> Here I believe it's much more problematic than on the server side and th= ere >> are at least a few actions we should take: >> >> >> >> A) check in sec 7 if we really have a compelling reason for key and proo= f >> variants. This is derived from larger discussions on key binding as per = the >> related note. There are quite a few open questions related to this theme= . >> >> >> >> B) there is also the choice between value/reference that may generate >> complexity. >> >> >> >> C) More generally, as many feedbacks already have noticed, we need to >> have a systematic review and reduce the set of available options in the >> protocol. >> >> >> >> Unless we have a clear idea why runtime behavior requires mutability, it >> might be useful to have a way to define the chosen variant before hand, = so >> that the expected behavior becomes deterministic on the client side. The= re >> are various ways it could be done in practice. >> >> >> >> For sure several independant implementations would help, especially if w= e >> make sure they can work together. >> >> >> >> Anyway all this open to improvement. >> >> >> >> Cheers >> >> Fabien >> >> >> >> Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = a >> =C3=A9crit : >> >> Hi Fabien, >> >> >> >> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is fa= r worse than the >> problem. The code in the article you cite is very specific to the use ca= se >> and IMHO quite ugly. So my preferred Go implementation would be a >> combination of untyped structures (Go interface{}) and run-time enforcem= ent >> of JSON Schema. >> >> >> >> Also, going back to our earlier discussion on this topic, I just read >> Sec. 7 of gnap-00 and realized that the RC also needs to deal with >> polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Date: *Wednesday, October 28, 2020 at 18:56 >> *To: *Mika Bostr=C3=B6m >> *Cc: *GNAP Mailing List , Justin Richer , >> Dick Hardt >> *Subject: *Re: [GNAP] Feedback on polymorphism >> >> >> >> Thanks for the great feedback. Your concern is very valid. >> >> >> >> My implementation is in rust, which makes life easier in that specific >> case. >> >> >> >> So I'm not a golang specialist but I guess the transcription of json >> strings/arrays into go structs would work around the lines described by >> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 >> >> When we have a more formalized json schema, I suggest we make a library >> of json examples and some related code samples in mainstream languages, = to >> check it is feasible for everyone. >> >> >> >> Cheers, >> >> Fabien >> >> >> >> >> >> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m >> wrote: >> >> Hi everyone, >> >> >> >> Looks like I stuck my finger in a hornets' nest. First off, apologies fo= r >> not chipping in earlier, but there was a lot of material to digest. Also= , >> warning: lots to read ahead. >> >> >> >> I'm one of those people who end up making use of AuthN/AuthZ >> functionality through a library. On top of that I can see myself being >> roped in as a server (AS) implementation help. So I'm approaching this f= rom >> an outsider's perspective. Someone who expects to be exposed to the >> eventual RFC and all the nitty-gritty details. My relatively terse comme= nt >> ended up at the top of the aforementioned HN thread, which didn't >> necessarily help. Sorry about that. >> >> >> >> Now, having read Justin's initial reply - and the rest of the thread - I >> believe I can see where the desire for polymorphism comes from. To be >> clear: I am all for strict types inside an implementation, as it will ad= d >> helpful guard-rails to the state management code paths. However, I see t= his >> as a case of leaky abstraction. If we take the existing oauth.xyj-java c= ode >> to be the reference implementation, the choice makes logical sense: JSON= is >> not expressive enough to serialise arbitrary objects, so in order to avo= id >> writing complex payload parser(s) the internal implementation details no= w >> leak to the protocol itself. From a purely technical perspective, it's a >> cool trick. From a distance it even looks a bit like the result of proto= buf >> decoding, but without the generated code parts. >> >> >> >> But then the downside. I don't personally expect to be able to use the >> reference implementation, being mostly a Python user myself. A fair numb= er >> of AS implementations will be written with languages such as Go, Python, >> C#, Ruby, and JavaScript (thanks to node.js), and all of them will have = to >> deal with the polymorphism. From what I've read over the past couple of >> days, I understand that at least Go supports custom unmarshalers from JS= ON >> to typed structs, at the cost of an indirection. Normally when a Go code >> processes JSON to a typed struct, the process is helped by field >> annotations in the type definition itself. For example, if the payload f= or >> a person in JSON was >> >> >> >> { >> >> "name": "", >> >> "age": , >> >> "country": "", >> >> "city": "" >> >> } >> >> >> >> .. then the type definition would look like: >> >> >> >> type Person struct { >> >> Name string `json:"name" >> >> Age int `json:"age"` >> >> Country string `json:"country"` >> >> City string `json:"city"` >> >> } >> >> >> >> When the (possibly complex) type of a given field is fixed, unmarshaling >> should still be straightforward. I haven't verified, but since the >> annotation only gives which field to look at for a given typed value, th= ere >> should be nothing special about that. But when the field can instead be = a >> union of more than one distinct types, things start to get messy. There = is >> no union type in the language at all, so the following construct is not >> even possible: >> >> >> >> type Entity struct { >> >> Resources []string `json:"resources"` >> >> Client union(Client, string) `json:"client"` >> >> } >> >> >> >> As I understand, the implicit expectation is that in the above case, the >> unmarshaler detects that "client" is a string, and so expands it from an >> opaque handle to the expected, populated type. Even after thinking about >> the ramifications over the past few days I remain confused, because I do= n't >> see how the commonly used annotations could work. If the expectation is >> that protocol implementations should use strong types, then the use of >> polymorphic JSON is very likely to make things _more_ complicated for >> non-reference implementations. >> >> >> >> Hence my concern. I'm afraid that the leaky abstraction, while making th= e >> reference implementation more robust and straightforward, contributes to >> making other implementations less robust. And this being a security >> protocol, the potential for brittle and/or confused implementations is >> terrifying. >> >> >> >> I am a fan of reducing complexity, and from what I can see, for the >> reference implementation the polymorphic approach actually does that. Bu= t >> I'm afraid it does so at others' expense. Languages have their individua= l >> constraints, idioms and best practices. If parsing a protocol payload >> introduces low-level complexities and encourages to go against common >> practices, that is an invitation for problems. I am aware that my choice= of >> words in the HN thread was likely to put people on defense, and for that= I >> apologise. But I do believe that the choice of polymorphic JSON is going= to >> make the life and use of other implementations notably less boring than >> people in general would prefer. >> >> >> >> Cheers, >> >> Mika >> >> >> >> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault >> wrote: >> >> Hi Dick, >> >> >> >> Well technically yes. Obviously the client can present any interface it >> seems fit. >> >> >> >> Still there's the question of the common model we want to present to the >> outside world and supported by the protocol itself (which client librari= es >> all build upon). >> >> >> >> But beneath the polyphormism question, the HN debate seems on the surfac= e >> a lot like the original xyz (polyphormism goes along with the reduced >> endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where th= e >> client design has more latitude). Just explained differently, by outside >> people with different agendas. >> >> >> >> Which is a bit weird because many of the critics on HN (who criticize >> polyphormism) also seem to really dislike OAuth in the first place (the >> inconsistencies are partially due to a bunch of different people >> commenting). >> >> >> >> Really to me there's no fundamental truth behind that question. It's a >> matter of preference and priorities in the design. Whatever choices we >> make, we'll have to be prepared to explain and justify them in the open, >> even to some people that will dislike pretty much whatever we do (becaus= e >> it's fun to look smart and critize without proposing alternatives). And = we >> owe these answers to people like Mika, who genuinely try to make the bes= t >> of it. >> >> >> >> Fabien >> >> >> >> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a = =C3=A9crit : >> >> Hi Fabien >> >> >> >> A library developer can provide whatever abstraction layer makes sense >> for the library's target audience and language. >> >> >> >> If the client library developer wants to use polymorphism in the >> interface presented to the user's of the library, the library developer = can >> do that independent of polymorphism in the protocol, and vice versa >> >> >> >> =3D> polymorphism in the protocol has no impact on client library develo= pers >> >> >> >> >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >> wrote: >> >> I'm just realizing your "least to most important" might actually say the >> same as what I was trying to say. So I'm not even sure what we're arguin= g >> against :-) >> >> >> >> In brief my point if it wasn't clear is that we should be crystal clear >> on where we put the cursor of simplicity, because this can mean differen= t >> things for different people and different roles. >> >> And as we see on HN we need to better explain our design choices. >> >> >> >> >> >> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >> a =C3=A9crit : >> >> Hi Dick, >> >> >> >> Independantly from the debate on polyphormism, I beg to differ on your >> order preference. >> >> >> >> Your assumption is that AS devs matter the most, because they're doing >> the important security implementation. But eating our own dogfood might >> help a lot to change that view. Most security issues occur because users= of >> the spec are unable to deal with the complexity that is passed onto them= . >> >> >> >> 99% of the people that will actually use the output of the work are >> application developers (client or RS) and their own users. >> >> >> >> Our intent as well as the protocol drive the usage. Client libraries may >> help, but they're not a silver bullet, especially because GNAP ultimatel= y >> has no control about what people do there (for better or worse). And >> everything we do here will help get to the better part. >> >> >> >> I'm not saying we don't intend to also care about AS developers >> (beginning with ourselves) but it's a second order optimisation. And sin= ce >> it's a tendancy we're leaning towards by default, I'm pretty sure we won= 't >> forget that anyway. >> >> >> >> Fabien >> >> >> >> >> >> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a = =C3=A9crit : >> >> I'm confused by your logic Fabien. >> >> >> >> If a client library developer wants to expose polymorphism, they can do >> that independent of what is in the protocol. >> >> >> >> I differ on who our stakeholders are. >> >> >> >> I think our stakeholders are in least to most important: >> >> >> >> - AS developer >> - RS developer >> - client developer >> - user >> >> >> >> A client library developer can expose whatever interface they want to >> simplify implementation. >> >> >> >> I list the user so that we don't lose site of a critical role. >> >> >> >> /Dick >> >> >> >> >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >> wrote: >> >> Hi there, >> >> >> >> Let me try to approach the issue under a different light. More like a >> product manager would deal with feature selection to make it intuitive f= or >> its users. >> >> >> >> For most people, riding a bike is far easier than using a unicycle. Feel= s >> more stable. And yet it's way easier to design for a single wheel than t= o >> build with 2. Because then you'll need a lot more accessories (chain, ch= ain >> ring, etc.). Even so producing a bike doesn't have to be a brittle proce= ss, >> it can be industrialized. >> >> >> >> Back to the GNAP topic. >> >> Ultimately we should strive to make the spec as simple as can be. But we >> need to ask: simple for whom? For the bike owner or for the bike vendor? >> >> (short answer: the priority should be simplicity for spec users, not spe= c >> implementers and even less spec designers). >> >> >> >> The initial question that is asked is very interesting: isn't the design >> flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the >> state of the request? Or if we must handle token revocation? Or if we ar= e >> looking for a global unique identifier? The argument stems of the fact t= hat >> is still arguably harder and more error prone to implement. Fair enough. >> >> >> >> From a spec implementer's perspective, it may well be more complex. It >> mostly impacts the json library you'll end up using, plus a bit of >> input/output decoration around it. Even golang provides utilities for th= is, >> despite not exactly being made for this kind of purpose. >> >> My practical experience implementing it is that it's not that big a deal= . >> I mean, I wished it could be simpler, but it's manageable and there are >> other ways to reach levels of insurance that it does work as intended (j= son >> schema, test cases to validate the implementation, etc.). Arguably it is >> still easier from an implementation perspective than say, json-ld, which= is >> massively used in the SSI community. >> >> >> >> But ultimately who are we designing for? Are we striving to go easy on >> the spec implementer? Or are we trying to make sure end-developers using >> the client libraries won't shoot themselves in the foot? >> >> >> >> The job to be done (JTBD), from the end-developer's perspective, is to >> efficiently ship an application. And provide authN/authZ capabilities fo= r >> end-users by relying on some well known implementation. >> >> In turn, this spec implementer will rely on cryptographic utility >> libraries that deals internally with the complexity of their own domain,= so >> that we don't have to. And here we could launch another HN flame war tha= t >> starts with the title "JWT sucks because". Which does have its set of ve= ry >> real issues but that's beyond the point. >> >> Note that any decent flamewar will be efficiently fueled by people hatin= g >> medium. Is it outrageous for blog posts to be behind a paywall? Maybe bu= t >> it's even more outrageous to lack consistency, either by not knowing how= to >> get around a paywall if you're into a hacker punk movement, or on the >> contrary by to not paying a subscription if you believe that surveillanc= e >> capitalism, to reuse Zuboff's terms, should be eradicated. >> >> What likely seems an unnecessary sidenote tries to illustrate the point: >> for Justin it was easier to publish on medium, because as a blog publish= er, >> you might not want to deal with hosting your own blog. But maybe as a >> reader you'll find that annoying. Different audiences, different JTBD, >> different tradeoffs. >> >> >> >> Polyphormism is a tool that enables the end-developer to have minimal >> knowledge of what it means to deal with a GNAP client library. You prepa= re >> the request, send to the endpoint and you're good to go. Massively simpl= er >> than OAuth2 or any similar protocol by the way (as anyone with teaching >> experience on the subject might acknowledge). And there's a lot more to= be >> done to make sure we indeed reduce the complexity for the end-developer = and >> the end-user. >> >> >> >> If we find a better way to deal with that simplicity balance, I'm all in= . >> But the arguments need to be way more convincing than just saying that i= t >> may be difficult to implement or validate. >> >> >> >> Cheers. >> >> Fabien >> >> >> >> >> >> >> >> >> >> >> >> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a =C3= =A9crit : >> >> >> >> >> >> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >> >> >> >> Justin >> >> >> >> I did note that I was the one that argued for instance_id being in the >> object. Since it is in the object in the current draft, not including a >> pass by reference option would be preferable. >> >> >> >> As for concrete examples: >> >> - version of client >> >> - version of OS >> >> - security attestation of OS / device >> >> - location of client device >> >> - network client is operating on >> >> >> >> These are all attributes of the client that an AS may require on the >> initial grant request, and in future grant requests (which is when an >> instance_id) would be used. >> >> >> >> >> >> This is where our interpretations differ: I don=E2=80=99t see these as >> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key,= display >> information, class identifiers, and other items currently represented by= an >> instance_id are attributes of the client instance. The attestation >> components don=E2=80=99t modify the instance so much as present addition= al >> information on top of the client instance itself. This is why I argue th= at >> they ought to be handled in a separate object, so you=E2=80=99d have som= ething like >> this strawman: >> >> >> >> { >> >> >> >> posture: { >> >> software_version: 1.2.3, >> >> os_version: 14.3.2 >> >> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >> >> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >> >> }, >> >> >> >> client: =E2=80=9Cclient-541-ab" >> >> >> >> } >> >> >> >> This is a more fundamental question about GNAP than whether the syntax >> uses polymorphism: this is about GNAP being very explicit about the data >> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mode= l of what >> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply pr= oblematic in >> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with havi= ng to >> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn= =E2=80=99t fully capture >> the different aspects that are out there. I think we=E2=80=99re getting = closer here >> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, b= ut we still need to >> be more precise about what exactly a client instance includes, and what = it >> does not. >> >> >> >> =E2=80=94 Justin >> >> >> >> >> >> /Dick >> >> >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >> >> Dick, >> >> >> >> As you=E2=80=99ll recall, I argued against including the client instance >> identifier inside of the object as a mutually-exclusive field precisely >> because of the principle violation that you are pointing out here, and s= o >> it=E2=80=99s important to point out that the current text is a compromis= e that >> needs to be examined in the wider experience of the working group. I am = on >> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >> object, but this needs to be explored. >> >> >> >> The crux of my argument is that is exactly a case of pass-by-reference v= s >> pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient >> instance=E2=80=9D value itself but rather belong outside of that object = in a >> another part of the request. As stated in the editorial notes in this >> section, we need to look carefully at how these concepts fit within the >> model and where we would want to put them. Without concrete examples of >> what these extensions look like and how they=E2=80=99re generated, that = is nearly >> impossible to do at this stage. I look forward to seeing examples of thi= s >> kind of data and how it can fit into the protocol. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >> >> >> >> Hey Justin, >> >> >> >> As the draft has evolved, I question the continued use of polymorphism. >> Note that I appreciate the elegance of using a string for >> pass-by-reference, and an object for pass-by-value. >> >> >> >> In the current draft, the >> >> >> >> Every time you create or process a field it will mean only one thing, an= d >> there=E2=80=99s only one field to look at to answer a question. >> >> >> >> is violated in 2.3.1. Identifying the RC Instance >> >> >> >> >> >> >> instance_id An identifier string that the AS can use to identify the >> >> particular instance of this RC. The content and structure of this >> >> identifier is opaque to the RC. >> >> >> >> "client": { >> >> "instance_id": "client-541-ab" >> >> } >> >> >> >> If there are no additional fields to send, the RC MAY send the >> >> instance identifier as a direct reference value in lieu of the >> >> object. >> >> >> >> "client": "client-541-ab" >> >> >> >> The instance identifier can be sent two ways. Polymorphism is a >> convenience for the client, but requires the server to have two code pat= hs >> for "instance_id". We discussed this in the design team, and I argued f= or >> having "instance_id" in the "client" object so that any updates, such as >> new devices assertions, could be in the "client" object. As noted above, >> while I appreciate the elegance of using a string (handle) to reference = a >> previously provided object, it complicates how to update an existing obj= ect >> while providing the reference. >> >> >> >> In your example of the "key" object below, setting "proof" to bearer >> would avoid the issue you describe: >> >> >> >> { >> "key": { >> "proof": "bearer" >> } >> } >> >> >> >> In your example, when processing the "key" object, code is having to >> check both the JSON type of the property, as well as check the value of = the >> "proof" property. In the example I provided, only the value of "proof" >> needs to be checked. The "proof" property is acting as a type for the "k= ey" >> object. >> >> >> >> Not being a Java programmer, I don't know how this would work in a Java >> implementation, but node.js, the processing would need to be done as abo= ve. >> >> >> >> On a related note, there was significant negative feedback on handles an= d >> polymorphism in the Hacker News article >> https://news.ycombinator.com/item?id=3D24855750 >> >> >> >> /Dick >> >> >> >> >> >> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >> >> Hi Mika, >> >> >> >> Thanks for bringing this topic here =E2=80=94 I was able to see the foru= m >> discussion that brought you here, and hopefully I can help clear up what= I >> mean with how polymorphism is used in the proposal. The short version is >> that the goal is to *avoid* the kinds of ambiguity that make insecure >> protocols, and so in that goal we=E2=80=99re fully aligned. I think that= using >> polymorphism in very specific ways can help that goal =E2=80=94 just as = I agree >> that misusing it or applying it sloppily can lead to ambiguous and insec= ure >> systems. >> >> >> >> Some background: I built out the XYZ protocol (one of the predecessors t= o >> the initial GNAP Draft) in Java using strongly typed parsers and Java >> objects specifically to prove to myself that it could be done in a way t= hat >> made any sense in the code. (My own open source implementation is at >> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not y= et up to >> date with the GNAP spec). It was important to me that I be able to use t= he >> system-wide configured parsers to implement this and not have to resort = to >> stepping through elements completely by hand. Java doesn=E2=80=99t make = it simple >> to get the hooks into the right places (especially with the Jackson pars= er >> that I used), but it is definitely possible to create a deterministic an= d >> strongly-typed parser and serializer for this kind of data structure. So= me >> of the rationale for using polymorphism is covered in the trailing appen= dix >> of the draft document ( >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#na= me-json-structures-and-polymor), >> but it=E2=80=99s still good to discuss this here as the working group de= cides which >> approaches to take. >> >> >> >> The driving reason for using polymorphism at the protocol level was to >> simplify the protocol and make it :more: deterministic to create and >> process, not less. Every time you create or process a field it will mean >> only one thing, and there=E2=80=99s only one field to look at to answer = a question. >> Without polymorphic field values, you usually need to rely on mutual >> exclusivity of fields, which is prone to failure and requires additional >> error checking. Take for example the key binding of access tokens. An >> access token could be bound to the RC=E2=80=99s key used during the requ= est, to a >> different key chosen by the AS, or it could be a bearer token with no ke= y >> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can de= fine it in terms of >> boolean values and objects and express this set of mutually-exclusive >> options in a non-ambiguous way. Without that, you=E2=80=99d need to have= different >> fields for the options and include additional checks in your parser to m= ake >> sure they weren=E2=80=99t sent simultaneously, otherwise you could get h= it with >> this potential security vulnerability in an object: >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> }, >> >> bearer_token: true, >> >> bind_to_rc_key: true >> >> } >> >> >> >> This would be an illegal object as per this alternate proposal, but then >> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t p= ut next to others >> in the same object. I=E2=80=99ve done this exercise with many other prot= ocols and >> it=E2=80=99s both error prone and easy to ignore since all the =E2=80=9C= good=E2=80=9D examples >> would pass code that doesn=E2=80=99t check this. With the polymorphic ap= proach to >> this same field, each of these three mutually-exclusive states is writte= n >> in a way that they cannot be sent together. It=E2=80=99s not just illega= l, it=E2=80=99s >> impossible and enforced by the syntax of JSON itself. >> >> >> >> { >> >> key: { >> >> proof: httpsig, >> >> jwk: { =E2=80=A6 key value =E2=80=A6 } >> >> } >> >> } >> >> >> >> // bearer token >> >> >> >> { >> >> key: false >> >> } >> >> >> >> // bound to the RC=E2=80=99s presented key >> >> >> >> { >> >> key: true >> >> } >> >> >> >> If someone sends a different type for this field, like an array or numbe= r >> or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and >> would be a protocol level error. >> >> >> >> While it might sound like polymorphism means that any field could have >> any type or value, the opposite is true: each possible value is explicit= ly >> typed, it=E2=80=99s just that there are potentially different types that= express >> meaning for the field. This applies to all members of all objects >> (dictionaries) as well as all members of an array (list). Every time you >> process a field value or other element, you look at the type and then th= e >> value to determine what to do with that typed value. >> >> >> >> In your example below, each field within the dictionary would also need >> to be typed, and each type would need to have a clear indication of its >> meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could >> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON = number) or an >> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would f= urther say what >> exactly the encoding of the string would be. That means that when you re= ad >> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confus= ion on what the value was >> or how it was represented, regardless of the input format. Seeing a numb= er >> there means exactly one interpretation and seeing a string means exactly >> one (different) interpretation =E2=80=94 but importantly, both of them a= re a >> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An >> implementation would likely use an internal BigInteger type of object to >> represent the field value after parsing, so the question is how to go fr= om >> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you appl= y it to all >> sub-fields of that object. >> >> >> >> So let=E2=80=99s dig into the specific bug you bring up in the strawman,= because >> it=E2=80=99s interesting: A JSON encoder that encodes numbers as strings= , and not >> numbers, is not compliant with the JSON definitions of the field in >> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99t= be treated >> the same by a parser implementation when mapping to a concrete object. I= t=E2=80=99s >> in this kind of automated guessing that this class of bugs occur, and >> that=E2=80=99s going to be the case whether or not you take advantage o= f JSON=E2=80=99s >> polymorphic nature. I=E2=80=99ve run into cases where a parser library w= as trying >> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up >> introducing errors in more strict components downstream. This is somethi= ng >> that protocol designers need to be aware of and guard against in the des= ign >> of the protocol to reduce possible ambiguities. Within GNAP today, we >> generally have things that branch whether they=E2=80=99re an object (for= a rich >> description of something) or some non-structured special value (for a >> reference or other item). >> >> >> >> The design team created some simple JSON Schemas for parts of the >> protocol during our discussion, but we didn=E2=80=99t include them in th= e design >> document due to both lack of time to keep it updated with the rapid chan= ges >> to the protocol during the design team discussion, and not knowing if th= ere >> would be interest in such material. I personally think it would be helpf= ul >> to include as an informative reference in the final document, but that= =E2=80=99s >> something for the working group to take up eventually. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >> >> >> >> Hello, everyone. >> >> >> >> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and >> when I made note about certain concerns, I was requested to send my >> comments to this working group. >> >> >> >> In short, I believe that the use of polymorphic JSON in the protocol >> invites subtle and confusing implementation problems. I also searched >> through the WG archives, and noticed that similar concerns were noted, >> briefly, in a thread in July. >> >> >> >> The problem with polymorphic values, as I see it, is that implementation= s >> will need to branch on the (inferred) type of a given field. This isn't >> quite as bad if the types are strictly different, but allows for subtle >> bugs when the value in question is a dictionary. What makes this >> unappealing is that "subtle bugs" in security protocols have a habit of >> turning into vulnerabilities. >> >> >> >> Let's say we have these imaginary payloads, both possible and valid in >> the same protocol step: >> >> >> >> # payload 1 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": >> >> } >> >> } >> >> >> >> # payload 2 >> >> { >> >> ..., >> >> "public_key": { >> >> "alg": "rsa", >> >> "modulus": "" >> >> } >> >> } >> >> >> >> In both cases, the type of "public_key" field is a dictionary. In both >> cases, they even have the same keys. However, the values in the >> dictionaries are entirely different, and an implementation will have to >> branch to at least two possible decoding mechanisms. To make things wors= e, >> some JSON implementations may choose to encode non-dictionary values as >> strings, so it is possible for an originator to transmit what they expec= t >> and believe to be payload 1 format, but which the receiver will interpre= t >> to be in payload 2 format. And if the encoded string contains only digit= s, >> it will even parse correctly as a bignum. >> >> >> >> While the above is clearly a manufactured scenario, it nonetheless >> demonstrates the potential for logic bugs with polymorphic JSON. With >> richer types and more complex dictionaries, there will surely be more ro= om >> for errors. >> >> >> >> Ambiguity in protocols is always a source of implementation complexity >> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, would= n't >> it be in everyone's interest to keep implementation complexity and mista= ke >> potential to a minimum? >> >> >> >> Best regards, >> >> Mika >> >> >> >> -- >> >> Mika Bostr=C3=B6m >> >> Smarkets >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> *Error! Filename not specified.*=E1=90=A7 >> >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> >> Mika Bostr=C3=B6m >> >> Smarkets >> >> -- TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> --00000000000080f40d05b2e4f29b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I exchanged some emails with the JSON Schema team last sum= mer. They are actively working on a revision to better server OpenAPI.
    =
    They felt stonewalled at the IETF and now question the value= of spending time in a standards body.=C2=A0

    =
    Another schema option is JSON Type Definition [1], which is built on C= DDL (RFC 8610) [2], the CBOR type language.


    =

    3D""=E1=90=A7

    On Fri, Oct 30, 202= 0 at 8:13 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron,=C2=A0
    Thanks a lot for the feedback, I fixed the issue related to th= e standardisation status (I guess there's some historic background that= I don't know ;-)).

    Is JSON the only real poss= ible format? Probably, at least for compatibility with pretty much everythi= ng that exists. Only TJSON could maybe be used as an alternative (and kind = of removes the need for a schema), with the downsides that you don't ha= ve so many existing libraries and that the community seems much smaller: 2k= stars for JSON schema spec vs 65 for TJSON spec (and the expired website S= SL certificate doesn't help).=C2=A0 =C2=A0

    The= main problem I see is that for constrained cases, CBOR won't have a sc= hema in a foreseeable future (at least I'm not aware of any work on tha= t). I know it's not our main focus right now and might not even be cove= red by the current WG, but still it might become an issue at some point.=C2= =A0

    Best,
    Fabien=C2=A0 =C2=A0

    <= div class=3D"gmail_quote">
    On Fri, Oct= 30, 2020 at 3:19 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

    = =C2=A0

    One correction, JSON Schema (which = I am personally advocating for, but still) does not have an IETF spec. They= claim on their web site that they want it standardized, but in practice ar= e not (yet?) moving in this direction. Their Internet Draft is unmaintained= .

    =C2=A0

    At a higher level, I think your discussion conflates two thi= ngs: the representation of data on the wire (JSON or various mostly binary = encodings) and the data modeling language, a.k.a. schema. Personally I thin= k JSON is almost a must in our case, and if this is true, the playing field= is *much* more narrow.

    <= /u>=C2=A0

    A major strength of JSON which y= ou don=E2=80=99t mention in your comparison is the cryptographic ecosystem = (JOSE): standard formats for encryption, signature etc.

    =C2=A0

    I wasn= =E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a good fit for = us, still a very interesting direction.

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    =C2=A0

    From: Fabie= n Imbault <fabien.imbault@gmail.com>
    Date: Friday, October 30, 2020 = at 14:53
    To: Andrii Deinega <andrii.deinega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>, Justin Richer <jricher@mit.edu>, Yaron S= heffer <yaron= f.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com= >
    Subject: Re: [GNAP] Feedback on polymorphism

    =C2=A0

    Hi Justin,=C2=A0

    =C2=A0

    &g= t; Regarding your question, what else could we propose?=C2=A0=

    =C2=A0

    I've started a review of possibilities at=C2=A0https://github.com/fimbault/reasonably-polymorphic/b= lob/main/README.md to be followed by actual code testing.=C2=A0<= u>

    =C2=A0

    <= div>

    Cheers,

    Fabien

    =C2=A0

    On Thu, Oct 29, 2020 at= 8:23 PM Andrii Deinega <andrii.deinega@gmail.com> wrote:

    Hi=C2=A0Mika, Ju= stin, and WG,

    =C2= =A0

    The act (actor) claim introduced= in RFC 8693 (OAuth 2.0 Token Exchange) has a JSON object as its value. Thi= s claim could be a part of AT JWT or a token introspection response and has= the same semantics in both cases. The JSON object as its value may look li= ke this

    "act":
    {
    =C2=A0 "sub":"admin@example.com"= ;
    }

    or even be nested like in

    "act":
    {
    =C2= =A0"sub":"https://service16.example.com",
    =C2=A0 =C2=A0"= act":
    =C2=A0 =C2=A0{
    =C2=A0 =C2=A0 =C2=A0"sub":"<= a href=3D"https://service77.example.com" target=3D"_blank">https://service7= 7.example.com"
    =C2=A0 =C2=A0}
    }

    Personally, I find it= to be a very expressive approach. Also, as far I as know, several (oAuth2)= client libraries have good support of things like

    "aud":&= quot;https://ser= vice1.example.com" and "aud":["https://service1.example.com&quo= t;,"https:/= /service2.example.com"]

    in AT JWTs for a quite long time.

    =C2=A0

    <= div>

    Regards,

    Andrii

    <= /u>=C2=A0

    On Wed, Oct 28, 2020 a= t 12:58 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    <= /div>

    Hi Yaron,=

    =C2=A0

    We'll indeed have to check how make it as idiomatic = as possible with experts of each language (help welcome).=C2=A0

    =C2=A0

    =

    Regarding the client, the variations are more limite= d but they do exist. Here I believe it's much more problematic than on = the server side and there are at least a few actions we should take:=

    =C2=A0

    =

    A) check in sec 7 if we really have a compellin= g reason for key and proof variants. This is derived from larger discussion= s on key binding as per the related note. There are quite a few open questi= ons related to this theme.=C2=A0

    =C2=A0

    B) there= is also the choice between value/reference that may generate complexity.= =C2=A0

    =C2=A0<= /u>

    C) More generally, as many feedbac= ks already have noticed, we need to have a systematic review and reduce the= set of available options in the protocol.=C2=A0

    =C2=A0

    Unless we have a clear= idea why runtime behavior requires mutability, it might be useful to have = a way to define the chosen variant before hand, so that the expected behavi= or becomes deterministic on the client side. There are various ways it coul= d be done in practice.=C2=A0

    =C2=A0

    For s= ure several independant implementations would help, especially if we make s= ure they can work together.=C2=A0

    =C2=A0

    Anyway = all this open to improvement.=C2=A0

    =C2=A0

    Cheer= s=C2=A0

    Fabien=C2=A0<= /u>

    = =C2=A0

    Le mer. 28 oct. 2020 = =C3=A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:=

    Hi Fa= bien,

    =C2=A0

    At least in the case of Go, I think the =E2=80=9Csolution= =E2=80=9D is far worse than the problem. The code in the article you cite i= s very specific to the use case and IMHO quite ugly. So my preferred Go imp= lementation would be a combination of untyped structures (Go interface{}) a= nd run-time enforcement of JSON Schema.

    =C2=A0

    Also, going back to our= earlier discussion on this topic, I just read Sec. 7 of gnap-00 and realiz= ed that the RC also needs to deal with polymorphism (the =E2=80=9Ckey=E2=80= =9D value), not only the AS.

    =C2=A0=

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    =C2=A0

    Fro= m: TXAuth <txauth-bounces@ietf.o= rg> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: = Wednesday, October 28, 2020 at 18:56
    To: Mika Bostr=C3=B6m &l= t;mika.bostr= om@smarkets.com>
    Cc: GNAP Mailing List <txauth@ietf.org>, Justin Riche= r <jricher@mit.edu<= /a>>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback = on polymorphism

    = =C2=A0

    Thanks for the gr= eat feedback. Your concern is very valid.=C2=A0

    =

    =C2=A0

    My implementation is in rust, which makes life easier in that specifi= c case.=C2=A0

    =C2= =A0

    So I'm not a gol= ang specialist but I guess the transcription of json strings/arrays into go= structs would work around the lines described by=C2=A0https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1=

    When we have a more formal= ized json schema, I suggest we make a library of json examples and some rel= ated code samples in mainstream languages, to check it is feasible for ever= yone.=C2=A0

    =C2=A0

    Cheers,

    Fabien

    =C2=A0

    = =C2=A0

    On Wed, Oct 28, 20= 20 at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote:<= /u>

    Hi everyone,<= /u>

    =C2=A0

    Looks like I stuck my finger in a hornets= 9; nest. First off, apologies for not chipping in earlier, but there was a = lot of material to digest. Also, warning: lots to read ahead.=

    =C2=A0

    I'm one of those people who end up making use of A= uthN/AuthZ functionality through a library. On top of that I can see myself= being roped in as a server (AS) implementation help. So I'm approachin= g this from an outsider's perspective. Someone who expects to be expose= d to the eventual RFC and all the nitty-gritty details. My relatively terse= comment ended up at the top of the aforementioned HN thread, which didn= 9;t necessarily help. Sorry about that.

    =C2=A0

    N= ow, having read Justin's initial reply - and the rest of the thread - I= believe I can see where the desire for polymorphism comes from. To be clea= r: I am all for strict types inside an implementation, as it will add helpf= ul guard-rails to the state management code paths. However, I see this as a= case of leaky abstraction. If we take the existing oauth.xyj-java code to = be the reference implementation, the choice makes logical sense: JSON is no= t expressive enough to serialise arbitrary objects, so in order to avoid wr= iting complex payload parser(s) the internal implementation details now lea= k to the protocol itself. From a purely technical perspective, it's a c= ool trick. From a distance it even looks a bit like the result of protobuf = decoding, but without the generated code parts.

    =C2=A0

    But then the downside. I don't personally expect to be able to u= se the reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, Pyt= hon, C#, Ruby, and JavaScript (thanks to node.js), and all of them will hav= e to deal with the polymorphism. From what I've read over the past coup= le of days, I understand that at least Go supports custom unmarshalers from= JSON to typed structs, at the cost of an indirection. Normally when a Go c= ode processes JSON to a typed struct, the process is helped by field annota= tions in the type definition itself. For example, if the payload for a pers= on in JSON was

    =C2=A0=

    {

    <= div>

    =C2=A0 "name": "<string>&qu= ot;,

    =C2=A0 "age&qu= ot;: <int>,

    =C2=A0= "country": "<string>",

    =C2=A0 "city": "<string>&quo= t;

    }

    =C2=A0

    .. then the type definition would look like:

    =C2=A0

    type Person struct {

    =C2=A0 Name string `json:"name"

    =

    =C2=A0 Age int `json:"age"`<= /u>

    =C2=A0 Country string `json= :"country"`

    = =C2=A0 City string `json:"city"`

    }

    =C2= =A0

    When the (possibly c= omplex) type of a given field is fixed, unmarshaling should still be straig= htforward. I haven't verified, but since the annotation only gives whic= h field to look at for a given typed value, there should be nothing special= about that. But when the field can instead be a union of more than one dis= tinct types, things start to get messy. There is no union type in the langu= age at all, so the following construct is not even possible:<= /p>

    =C2=A0

    type Entity struct {

    =C2=A0 Resources []string `json:"resources"`<= /u>

    =C2=A0 Client union(Client,= string) `json:"client"`

    }

    =C2=A0

    As I understand, the implici= t expectation is that in the above case, the unmarshaler detects that "= ;client" is a string, and so expands it from an opaque handle to the e= xpected, populated type. Even after thinking about the ramifications over t= he past few days I remain confused, because I don't see how the commonl= y used annotations could work. If the expectation is that protocol implemen= tations should use strong types, then the use of polymorphic JSON is very l= ikely to make things _more_ complicated for non-reference implementations. =

    =C2=A0

    Hence my concern. I'm afraid that the lea= ky abstraction, while making the reference implementation more robust and s= traightforward, contributes to making other implementations less robust. An= d this being a security protocol, the potential for brittle and/or confused= implementations is terrifying.

    =C2=A0

    I am a fan of = reducing complexity, and from what I can see, for the reference implementat= ion the polymorphic approach actually does that. But I'm afraid it does= so at others' expense. Languages have their individual constraints, id= ioms and best practices. If parsing a protocol payload introduces low-level= complexities and encourages to go against common practices, that is an inv= itation for problems. I am aware that my choice of words in the HN thread w= as likely to put people on defense, and for that I apologise. But I do beli= eve that the choice of polymorphic JSON is going to make the life and use o= f other implementations notably less boring than people in general would pr= efer.

    =C2=A0

    Cheers,

    Mika

    =C2=A0

    On Mon, 26 O= ct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Dick,=

    =C2=A0

    Well technically yes. Obviously the client can present any i= nterface it seems fit.=C2=A0

    =C2=A0

    Still there&= #39;s the question of the common model we want to present to the outside wo= rld and supported by the protocol itself (which client libraries all build = upon).=C2=A0

    =C2=A0

    But beneath the polyphormism= question, the HN debate seems on the surface a lot like the original xyz (= polyphormism goes along with the reduced endpoint model) vs xauth (a bit cl= oser to OAuth2 in spirit, and where the client design has more latitude). J= ust explained differently, by outside people with different agendas.=C2=A0<= u>

    =C2=A0

    =

    Which is a bit weird because many of the = critics on HN (who criticize polyphormism) also seem to really dislike OAut= h in the first place (the inconsistencies are partially due to a bunch of d= ifferent people commenting).=C2=A0

    =C2=A0

    Really= to me there's no fundamental truth behind that question. It's a ma= tter of preference and priorities in the design. Whatever choices we make, = we'll have to be prepared to explain and justify them in the open, even= to some people that will dislike pretty much whatever we do (because it= 9;s fun to look smart and critize without proposing alternatives). And we o= we these answers to people like Mika, who genuinely try to make the best of= it.=C2=A0

    =C2=A0=

    Fabien=C2=A0

    =

    =C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:

    Hi Fabien

    =C2= =A0

    A library developer = can provide whatever abstraction layer makes sense for the library's ta= rget=C2=A0audience and language.

    =C2=A0

    If the c= lient library=C2=A0developer wants to use polymorphism=C2=A0in the interfac= e presented to the user's of the library, the library developer can do = that independent of polymorphism in the protocol, and vice versa=C2=A0

    =C2=A0

    =3D> polymorphism in the protocol has no i= mpact on client library developers

    =C2=A0

    =C2=A0=

    Error! Filename not specified.=E1=90=A7

    =C2= =A0

    On Sat, Oct 24, 2020 = at 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    <= /div>

    I'm just realizing your &= quot;least to most important" might actually say the same as what I wa= s trying to say. So I'm not even sure what we're arguing against :-= )=C2=A0

    =C2=A0

    In brief my point if it wasn't clea= r is that we should be crystal clear on where we put the cursor of simplici= ty, because this can mean different things for different people and differe= nt roles.=C2=A0

    And as w= e see on HN we need to better explain our design choices.=C2=A0

    =C2=A0

    =C2=A0

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@gmail.com= > a =C3=A9crit=C2=A0:

    Hi Dick,

    =C2=A0=

    Independantly from the = debate on polyphormism, I beg to differ on your order preference.=C2=A0<= /u>

    =C2=A0

    Your assumption is that AS devs matter the m= ost,=C2=A0because they're = doing the important security implementation. But eating our own dogfood mig= ht help a lot to change that view. Most security issues occur because users= of the spec are unable to deal with the complexity that is passed onto the= m.=C2=A0

    =C2=A0

    99% of the people that wi= ll actually use the output of the work are application developers (client o= r RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the protocol dri= ve the usage. Client libraries may help, but they're not a silver bulle= t, especially because GNAP ultimately has no control about what people do t= here (for better or worse). And everything we do here will help get to the = better part.=C2=A0

    =C2=A0

    I'm not say= ing we don't intend to also care about AS developers (beginning with ou= rselves) but it's a second order optimisation. And since it's a ten= dancy we're leaning towards by default, I'm pretty sure we won'= t forget that anyway.=C2=A0

    =C2=A0

    Fabien= =C2=A0

    =C2=A0<= /u>

    =C2= =A0

    Le sam. 24 oct. 2020 = =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:<= /p>

    I'm confused by your = logic Fabien.

    =C2=A0=

    If a client library developer wan= ts to expose polymorphism, they can do that independent of what is in the p= rotocol.=C2=A0

    =C2=A0=

    I differ on who our stakeh= olders are.=C2=A0

    =C2=A0=

    I think our stakeholder= s are in least to most important:

    =C2=A0

    • AS developer
    • RS devel= oper
    • client developer
    • user

    =C2=A0

    A client library developer can expose whatever interface they want to simp= lify implementation.

    =C2= =A0

    I list the user so t= hat we don't lose site of a critical role.

    =

    =C2=A0

    /Dick

    =C2=A0

    =C2=A0

    Error! Filename not specified.=E1=90=A7=

    =C2=A0

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault= <fabien.i= mbault@gmail.com> wrote:

    Hi there,=C2=A0

    =C2=A0

    Let = me try to approach the issue under a different light. More like a product m= anager would deal with feature selection to make it intuitive for its users= .=C2=A0

    =C2=A0

    For most people, riding a bike is = far easier than using a unicycle. Feels more stable. And yet it's way e= asier to design for a single wheel than to build with 2. Because then you&#= 39;ll need a lot more accessories (chain, chain ring, etc.). Even so produc= ing a bike doesn't have to be a brittle process, it can be industrializ= ed.=C2=A0

    =C2=A0<= u>

    Back to the GNAP topic.=C2=A0

    Ultimately we should strive to make the spec as simple as can= be. But we need to ask: simple for whom? For the bike owner or for the bik= e vendor?=C2=A0

    <= span style=3D"font-family:Arial,sans-serif">(short answer: the priority sho= uld be simplicity for spec users, not spec implementers and even less spec = designers).=C2=A0

    =C2=A0

    The initial ques= tion that is asked is very interesting: isn't the design flawed if GNAP= is using json polyphormism? Or if the AS needs to handle the state of the = request? Or if we must handle token revocation? Or if we are looking for a = global unique identifier? The argument stems of the fact that is still argu= ably harder and more error prone to implement. Fair enough.=C2=A0=

    =C2=A0

    From a spec implementer's perspective, it may = well be more complex. It mostly impacts the json library you'll end up = using, plus a bit of input/output decoration around it. Even golang provide= s utilities for this, despite not exactly being made for this kind of purpo= se.

    My practical experie= nce implementing it is that it's not that big a deal. I mean, I wished = it could be simpler, but it's manageable and there are other ways to re= ach levels of insurance that it does work as intended (json schema, test ca= ses to validate the implementation, etc.). Arguably it is still easier from= an implementation perspective than say, json-ld, which is massively used i= n the SSI community.=C2=A0

    =C2=A0

    But ultimately= who are we designing for? Are we striving to go easy on the spec implement= er? Or are we trying to make sure end-developers using the client libraries= won't shoot themselves in the foot?

    =C2=A0

    = The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities for e= nd-users by relying on some well known implementation.=C2=A0<= /p>

    In turn, this spec implementer will re= ly on cryptographic utility libraries that deals internally with the comple= xity of their own domain, so that we don't have to. And here we could l= aunch another HN flame war that starts with the title "JWT sucks becau= se". Which does have its set of very real issues but that's beyond= the point.=C2=A0

    Note t= hat any decent flamewar will be efficiently fueled by people hating medium.= Is it outrageous for blog posts to be behind a paywall? Maybe but it's= even more outrageous to lack consistency, either by not knowing how to get= around a paywall if you're into a hacker punk movement, or on the cont= rary by to not paying a subscription if you believe that surveillance capit= alism, to reuse Zuboff's terms, should be eradicated.=C2=A0

    What likely seems an unnecessary si= denote tries to illustrate the point: for Justin it was easier to publish o= n medium, because as a blog publisher, you might not want to deal with host= ing your own blog. But maybe as a reader you'll find that annoying. Dif= ferent audiences, different JTBD, different tradeoffs.=C2=A0<= /p>

    =C2=A0

    Polyphormism is a tool that enables the end-developer t= o have minimal knowledge of what it means to deal with a GNAP client librar= y. You prepare the request, send to the endpoint and you're good to go.= Massively simpler than OAuth2 or any similar protocol by the way (as anyon= e with teaching experience on the subject might acknowledge). And=C2=A0 the= re's a lot more to be done to make sure we indeed reduce the complexity= for the end-developer and the end-user.=C2=A0

    =

    =C2=A0

    If we find a better way to deal with that simplicity balance, I'm= all in. But the arguments need to be way more convincing than just saying = that it may be difficult to implement or validate.=C2=A0

    <= /div>

    =C2=A0

    Cheers.

    = Fabien

    =C2=A0<= /u>

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct.= 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0

    =C2=A0=

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= u>

    =C2=A0

    =

    Justin

    =C2=A0

    I did note t= hat I was the one that argued for instance_id being in the object. Since it= is in the object in the current draft, not including a pass by reference o= ption would be preferable.=C2=A0

    =C2=A0

    As for c= oncrete examples:

    - vers= ion of client

    - version = of OS

    - security attesta= tion of OS / device

    - lo= cation of client device

    = - network client is operating on

    =C2=A0

    These ar= e all attributes of the client that an AS may require=C2=A0on the initial g= rant request, and in future grant requests (which is when an instance_id) w= ould be used.

    =C2=A0<= /u>

    = =C2=A0

    This is where our= interpretations differ: I don=E2=80=99t see these as =E2=80=9Cattributes o= f the client=E2=80=9D in the same way that the key, display information, cl= ass identifiers, and other items currently represented by an instance_id ar= e attributes of the client instance. The attestation components don=E2=80= =99t modify the instance so much as present additional information on top o= f the client instance itself. This is why I argue that they ought to be han= dled in a separate object, so you=E2=80=99d have something like this strawm= an:

    =C2=A0=

    {

    =C2=A0

    = =C2=A0 posture: {

    =C2=A0= =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2

    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some struct= ure or signed blob? =E2=80=A6 }

    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2= =80=A6 }

    =C2=A0 },

    =C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"=

    =C2=A0

    }

    =C2=A0

    This is= a more fundamental question about GNAP than whether the syntax uses polymo= rphism: this is about GNAP being very explicit about the data model of its = elements. OAuth 2=E2=80=99s incredibly loose and broad model of what the te= rm =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply problematic= in practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with hav= ing to define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that d= oesn=E2=80=99t fully capture the different aspects that are out there. I th= ink we=E2=80=99re getting closer here in GNAP with explicit definition of = =E2=80=9Cclient instance=E2=80=9D, but we still need to be more precise abo= ut what exactly a client instance includes, and what it does not.=

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    =C2=A0

    /D= ick

    =C2=A0=

    Error! Filename not specified.=E1=90= =A7

    =C2=A0

    On Fri, Oct 23, 2020 at 12:42 PM Jus= tin Richer <jricher= @mit.edu> wrote:

    Dick,

    =C2=A0=

    As you=E2=80=99ll recall, = I argued against including the client instance identifier inside of the obj= ect as a mutually-exclusive field precisely because of the principle violat= ion that you are pointing out here, and so it=E2=80=99s important to point = out that the current text is a compromise that needs to be examined in the = wider experience of the working group. I am on the side of removing the mut= ually-exclusive =E2=80=9Cinstance_id=E2=80=9D option within an object, but = this needs to be explored.

    =C2=A0

    The crux of my= argument is that is exactly a case of pass-by-reference vs pass-by-value, = and that runtime attestations are not part of the =E2=80=9Cclient instance= =E2=80=9D value itself but rather belong outside of that object in a anothe= r part of the request. As stated in the editorial notes in this section, we= need to look carefully at how these concepts fit within the model and wher= e we would want to put them. Without concrete examples of what these extens= ions look like and how they=E2=80=99re generated, that is nearly impossible= to do at this stage. I look forward to seeing examples of this kind of dat= a and how it can fit into the protocol.

    =C2=A0

    = =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct 23= , 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    Hey Justin,

    =C2=A0=

    As the draft has evolve= d, I question the continued use of polymorphism. Note that I appreciate the= elegance=C2=A0of using a string for pass-by-reference, and an object for p= ass-by-value.

    =C2=A0<= /u>

    In the current draft, the= =C2=A0

    =C2=A0<= /u>

    Every time you create or process a field it will mean only one = thing, and there=E2=80=99s only one field to look at to answer a question.= =C2=A0

    =C2= =A0

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0inst= ance_id =C2=A0An identifier string that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 particu= lar instance of this RC.=C2=A0 The content and structure of this<= /u>

    =C2=A0 =C2=A0 =C2=A0 identifier is= opaque to the RC.

    =C2= =A0

    =C2=A0 =C2=A0"c= lient": {

    =C2=A0 = =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541-ab"

    =C2=A0 =C2=A0}=

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fields to send= , the RC MAY send the

    = =C2=A0 =C2=A0instance identifier as a direct reference value in lieu of the=

    =C2=A0 =C2=A0object.=

    =C2=A0

    =C2=A0 =C2=A0"client": "clie= nt-541-ab"

    =C2=A0

    The instance= identifier can be sent two ways. Polymorphism is a convenience for the cli= ent, but requires the server=C2=A0to have two code=C2=A0paths for "ins= tance_id".=C2=A0 We discussed this in the design team, and I argued fo= r having "instance_id" in the "client" object=C2=A0so t= hat any updates, such as new devices assertions, could be in the "clie= nt" object. As noted above, while I appreciate the elegance of using a= string (handle) to reference a previously provided object, it complicates = how to update an existing object while providing the reference.

    =C2=A0

    =

    In your example of the "key" object below,= setting "proof" to bearer would avoid the issue you describe:=

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0=C2=A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 =C2= =A0 }
    }

    =C2=A0

    In your example, when process= ing the "key" object, code is having to check both the JSON type = of the property, as well as check the value of the "proof" proper= ty. In the example I provided, only the value of "proof" needs to= be checked. The "proof" property is acting as a type for the &qu= ot;key" object.

    =C2= =A0

    Not being a Java pro= grammer, I don't know how this would work in a Java implementation, but= node.js, the processing would need to be done as above.

    <= /div>

    =C2=A0

    On a related note, there was significant negative feedback = on handles and polymorphism in the Hacker News article=C2=A0https://news= .ycombinator.com/item?id=3D24855750=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    /Dick

    =C2=A0=

    =C2=A0

    =

    On Fri, Oct 23, 2020 at 10:20 AM Jus= tin Richer <jricher= @mit.edu> wrote:

    Hi Mika,

    =C2=A0=

    Thanks for bringing thi= s topic here =E2=80=94 I was able to see the forum discussion that brought = you here, and hopefully I can help clear up what I mean with how polymorphi= sm is used in the proposal. The short version is that the goal is to=C2=A0<= b>avoid=C2=A0the kinds of ambiguity that make insecure protocols, and s= o in that goal we=E2=80=99re fully aligned. I think that using polymorphism= in very specific ways can help that goal =E2=80=94 just as I agree that mi= susing it or applying it sloppily can lead to ambiguous and insecure system= s.

    =C2=A0<= /p>

    Some background: I built out the XYZ p= rotocol (one of the predecessors to the initial GNAP Draft) in Java using s= trongly typed parsers and Java objects specifically to prove to myself that= it could be done in a way that made any sense in the code. (My own open so= urce implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java, but no= te that it=E2=80=99s not yet up to date with the GNAP spec). It was importa= nt to me that I be able to use the system-wide configured parsers to implem= ent this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the right p= laces (especially with the Jackson parser that I used), but it is definitel= y possible to create a deterministic and strongly-typed parser and serializ= er for this kind of data structure. Some of the rationale for using polymor= phism is covered in the trailing appendix of the draft document (https://www.ietf.org/archiv= e/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-and-polymor= ), but it=E2=80=99s still good to discuss this here as the working grou= p decides which approaches to take.=C2=A0

    =C2=A0

    The driving reason for using polymorphism at the protocol level was to sim= plify the protocol and make it :more: deterministic to create and process, = not less. Every time you create or process a field it will mean only one th= ing, and there=E2=80=99s only one field to look at to answer a question. Wi= thout polymorphic field values, you usually need to rely on mutual exclusiv= ity of fields, which is prone to failure and requires additional error chec= king. Take for example the key binding of access tokens. An access token co= uld be bound to the RC=E2=80=99s key used during the request, to a differen= t key chosen by the AS, or it could be a bearer token with no key at all. B= y making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in t= erms of boolean values and objects and express this set of mutually-exclusi= ve options in a non-ambiguous way. Without that, you=E2=80=99d need to have= different fields for the options and include additional checks in your par= ser to make sure they weren=E2=80=99t sent simultaneously, otherwise you co= uld get hit with this potential security vulnerability in an object:=

    =C2=A0

    =

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2= =80=A6 }

    =C2=A0 =C2=A0 }= ,

    =C2=A0 =C2=A0 bearer_t= oken: true,

    =C2=A0 =C2= =A0 bind_to_rc_key: true

    }

    =C2=A0<= /p>

    This would be an illegal object as per= this alternate proposal, but then you=E2=80=99d have to check each field a= nd make sure it wasn=E2=80=99t put next to others in the same object. I=E2= =80=99ve done this exercise with many other protocols and it=E2=80=99s both= error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D exampl= es would pass code that doesn=E2=80=99t check this. With the polymorphic ap= proach to this same field, each of these three mutually-exclusive states is= written in a way that they cannot be sent together. It=E2=80=99s not just = illegal, it=E2=80=99s impossible and enforced by the syntax of JSON itself.=

    =C2=A0

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    =

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key= value =E2=80=A6 }

    =C2= =A0 =C2=A0 }

    }=

    =C2=A0

    // bearer token

    =C2=A0

    = {

    =C2=A0 =C2=A0 key: fal= se

    }

    =C2=A0

    // bound to the RC=E2=80=99s presented key

    =C2=A0

    =

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0<= /p>

    If someone sends a different type for = this field, like an array or number or a null, this doesn=E2=80=99t have a = defined interpretation in the protocol and would be a protocol level error.=

    =C2=A0

    While it might sound like polymorphism m= eans that any field could have any type or value, the opposite is true: eac= h possible value is explicitly typed, it=E2=80=99s just that there are pote= ntially different types that express meaning for the field. This applies to= all members of all objects (dictionaries) as well as all members of an arr= ay (list). Every time you process a field value or other element, you look = at the type and then the value to determine what to do with that typed valu= e.

    =C2=A0<= /p>

    In your example below, each field with= in the dictionary would also need to be typed, and each type would need to = have a clear indication of its meaning. To take your strawman key format be= low, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphically a= s either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded = string=E2=80=9D (a JSON string). The definition would further say what exac= tly the encoding of the string would be. That means that when you read the = =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusion on = what the value was or how it was represented, regardless of the input forma= t. Seeing a number there means exactly one interpretation and seeing a stri= ng means exactly one (different) interpretation =E2=80=94 but importantly, = both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the fiel= d that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so th= e question is how to go from the JSON value (which is typed) into the BigIn= teger value.You don=E2=80=99t just apply the type rules on the =E2=80=9Cpub= lic_key=E2=80=9D field, you apply it to all sub-fields of that object.=C2= =A0

    =C2=A0=

    So let=E2=80=99s dig into the specifi= c bug you bring up in the strawman, because it=E2=80=99s interesting: A JSO= N encoder that encodes numbers as strings, and not numbers, is not complian= t with the JSON definitions of the field in question. For another example, = the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the = boolean value true in JSON, and they shouldn=E2=80=99t be treated the same = by a parser implementation when mapping to a concrete object. It=E2=80=99s = in this kind of automated guessing that this class of bugs occur, and that= =E2=80=99s going to be the case whether or not you take =C2=A0advantage of = JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a pars= er library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing this = kind of mapping, but ended up introducing errors in more strict components = downstream. This is something that protocol designers need to be aware of a= nd guard against in the design of the protocol to reduce possible ambiguiti= es. Within GNAP today, we generally have things that branch whether they=E2= =80=99re an object (for a rich description of something) or some non-struct= ured special value (for a reference or other item).=C2=A0

    =

    =C2=A0

    The design team created some simple JSON Schemas for parts= of the protocol during our discussion, but we didn=E2=80=99t include them = in the design document due to both lack of time to keep it updated with the= rapid changes to the protocol during the design team discussion, and not k= nowing if there would be interest in such material. I personally think it w= ould be helpful to include as an informative reference in the final documen= t, but that=E2=80=99s something for the working group to take up eventually= .

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2= =A0

    <= p class=3D"MsoNormal">On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m <<= a href=3D"mailto:mika.bostrom=3D40smarkets.com@dmarc.ietf.org" target=3D"_b= lank">mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:=

    =C2=A0

    Hello, everyone.

    =C2=A0

    = For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and wh= en I made note about certain concerns, I was requested to send my comments = to this working group.

    = =C2=A0

    In short, I belie= ve that the use of polymorphic JSON in the protocol invites subtle and conf= using implementation problems. I also searched through the WG archives, and= noticed that similar concerns were noted, briefly, in a thread in July.

    =C2=A0

    <= /div>

    The problem with polymorphic values, as I = see it, is that implementations will need to branch on the (inferred) type = of a given field. This isn't quite as bad if the types are strictly dif= ferent, but allows for subtle bugs when the value in question is a dictiona= ry. What makes this unappealing is that "subtle bugs" in security= protocols have a habit of turning into vulnerabilities.

    <= /div>

    =C2=A0

    Let's say we have these imaginary payloads, both possib= le and valid in the same protocol step:

    =C2=A0

    #= payload 1

    {

    =C2=A0 ...,

    =

    =C2=A0 "public_key": {<= /p>

    =C2=A0=C2=A0=C2=A0 "alg": &q= uot;rsa",

    =C2=A0=C2= =A0=C2=A0 "modulus": <BIGINT>

    <= p class=3D"MsoNormal">=C2=A0 }

    }

    =C2=A0

    # payload 2

    {

    =C2=A0 ...,

    =C2= =A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": = "<encoded string>"

    =C2=A0 }

    }=

    =C2=A0

    In both cases, the type of "public_key= " field is a dictionary. In both cases, they even have the same keys. = However, the values in the dictionaries are entirely different, and an impl= ementation will have to branch to at least two possible decoding mechanisms= . To make things worse, some JSON implementations may choose to encode non-= dictionary values as strings, so it is possible for an originator to transm= it what they expect and believe to be payload 1 format, but which the recei= ver will interpret to be in payload 2 format. And if the encoded string con= tains only digits, it will even parse correctly as a bignum.<= /p>

    =C2=A0

    While the above is clearly a manufactured scenario, it = nonetheless demonstrates the potential for logic bugs with polymorphic JSON= . With richer types and more complex dictionaries, there will surely be mor= e room for errors.

    =C2= =A0

    Ambiguity in protoco= ls is always a source of implementation complexity and interoperability sna= gs, but in an AuthN/AuthZ protocol it is worse: it's terrifying. If GNA= P/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in everyone&= #39;s interest to keep implementation complexity and mistake potential to a= minimum?

    =C2=A0<= u>

    Best regards,

    =

    Mika

    =C2=A0

    -- <= /u>

    Mik= a Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth

    = =C2=A0

    --
    TXAuth mailing = list
    TXAuth@ietf.or= g
    https://www.ietf.org/mailman/listinfo/txauth

    =

    Error! Filename not specified.=E1=90=A7

    =C2=A0

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth

    =


    --

    Mika= Bostr=C3=B6m

    Smarkets=

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

    = --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    --00000000000080f40d05b2e4f29b-- From nobody Fri Oct 30 08:42:04 2020 Return-Path: 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 AF8F13A08AB for ; Fri, 30 Oct 2020 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 6-tYmFFpJVfG for ; Fri, 30 Oct 2020 08:41:56 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D9AA33A0808 for ; Fri, 30 Oct 2020 08:41:55 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h21so7933397iob.10 for ; Fri, 30 Oct 2020 08:41:55 -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=PTdcWRlu1DQMvTa49dzTXuycXqZn8XdWNl3h009+J8Y=; b=FdGuJd/Fbo6jdZWW5jfj/Tm/ArWHzswHNGpFstPwmVBkATuI0r5SrPEtHL7ODOk9eM pJQgLlOeRjcNDFo9AdcMVsrdzgjvzV+fT8i9tTl8nUo49u5a0XsjoVbgc5b1w8PrkUtk ql9rAo7RoCSMlsU92+QI4qO7C1m4bbUjwp+5z5Z5pUB78BENRIkFHGD1SH6ckdZhIOpX wvqISpcNJYksURAJDyhKb/Wbpv062DkbWuZbz+ltv/4IRt2gA6m4da64a40WV8wwjfmv 6ExKfMOy37LBqRZTFnjo9Bzg4Yjq/WILafzB33GQxAt/jW0zB2EwOtX15RK+/Vc+5dVg UQ0A== 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=PTdcWRlu1DQMvTa49dzTXuycXqZn8XdWNl3h009+J8Y=; b=N31lI5/TnkGdqhwB166+AIKEU9T30dkicEymx6hE5EbPL1Lel2KpjlDHGDMbnFZEDf l08qjD5pNg9rD4wIQDfjTmPclWVs4KMNx4cDxv3LfWg3tfacToNOppMl4Y3Y7sGdLZ77 xSRO2T8pRMZUDPGy9uBVFXuaVCawE5Mz964I87GgxvLk2F0vdavbEOWlgeTZDcW0sWwW x3FxeG1tyrxWAfHU42nv8zqRA7+C5nzC8sl1AkttB4x4omuAlKw0JYtWpO3rYNzMYKaA ebXRIlQqGN2fS6vof3Xs2eO/75W9PogYZcuSXB03lkIRurgLOyRQh8WE85uotWtdLDHP OH8w== X-Gm-Message-State: AOAM531TRQKZnX0pbrpAnUWuo6OUmSV8CaCxu247KAfsFItO5fcyyepe X73YFv3So53RowXNJX8yMZb2Dz3f0Brwhx6et0g= X-Google-Smtp-Source: ABdhPJw2DV/qYjuUtRcaoXCyPyVe9Zc/Gs9uRiszNWYVZv6bTiebZzqT1ak6RekzR/S/D0m3DDyV3LI4gvy2i5tN98M= X-Received: by 2002:a02:48:: with SMTP id 69mr2373685jaa.108.1604072514945; Fri, 30 Oct 2020 08:41:54 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> In-Reply-To: From: Fabien Imbault Date: Fri, 30 Oct 2020 16:41:41 +0100 Message-ID: To: Dick Hardt Cc: Yaron Sheffer , Andrii Deinega , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , Justin Richer , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000072877e05b2e53cfe" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 15:42:03 -0000 --00000000000072877e05b2e53cfe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Dick, interesting ! I'll add that to my list. Maybe we could liaise with the JSON schema team if it helps. In the meantime, I'll focus on how to implement my json polymorphism ;-) On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt wrote: > I exchanged some emails with the JSON Schema team last summer. They are > actively working on a revision to better server OpenAPI. > > They felt stonewalled at the IETF and now question the value of spending > time in a standards body. > > Another schema option is JSON Type Definition [1], which is built on CDDL > (RFC 8610) [2], the CBOR type language. > > > [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition > [2] https://tools.ietf.org/html/rfc8610 > > > =E1=90=A7 > > On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault > wrote: > >> Hi Yaron, >> >> Thanks a lot for the feedback, I fixed the issue related to the >> standardisation status (I guess there's some historic background that I >> don't know ;-)). >> >> Is JSON the only real possible format? Probably, at least for >> compatibility with pretty much everything that exists. Only TJSON could >> maybe be used as an alternative (and kind of removes the need for a >> schema), with the downsides that you don't have so many existing librari= es >> and that the community seems much smaller: 2k stars for JSON schema spec= vs >> 65 for TJSON spec (and the expired website SSL certificate doesn't help)= . >> >> The main problem I see is that for constrained cases, CBOR won't have a >> schema in a foreseeable future (at least I'm not aware of any work on >> that). I know it's not our main focus right now and might not even be >> covered by the current WG, but still it might become an issue at some >> point. >> >> Best, >> Fabien >> >> On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer >> wrote: >> >>> Hi Fabien, >>> >>> >>> >>> One correction, JSON Schema (which I am personally advocating for, but >>> still) does not have an IETF spec. They claim on their web site that th= ey >>> want it standardized, but in practice are not (yet?) moving in this >>> direction. Their Internet Draft is unmaintained. >>> >>> >>> >>> At a higher level, I think your discussion conflates two things: the >>> representation of data on the wire (JSON or various mostly binary >>> encodings) and the data modeling language, a.k.a. schema. Personally I >>> think JSON is almost a must in our case, and if this is true, the playi= ng >>> field is **much** more narrow. >>> >>> >>> >>> A major strength of JSON which you don=E2=80=99t mention in your compar= ison is >>> the cryptographic ecosystem (JOSE): standard formats for encryption, >>> signature etc. >>> >>> >>> >>> I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a goo= d fit for us, still a >>> very interesting direction. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *Fabien Imbault >>> *Date: *Friday, October 30, 2020 at 14:53 >>> *To: *Andrii Deinega >>> *Cc: *Mika Bostr=C3=B6m , Justin Richer < >>> jricher@mit.edu>, Yaron Sheffer , GNAP Mailing >>> List , Dick Hardt >>> *Subject: *Re: [GNAP] Feedback on polymorphism >>> >>> >>> >>> Hi Justin, >>> >>> >>> >>> > Regarding your question, what else could we propose? >>> >>> >>> >>> I've started a review of possibilities at >>> https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md >>> to be followed by actual code testing. >>> >>> >>> >>> Cheers, >>> >>> Fabien >>> >>> >>> >>> On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega >>> wrote: >>> >>> Hi Mika, Justin, and WG, >>> >>> >>> >>> The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) >>> has a JSON object as its value. This claim could be a part of AT JWT or= a >>> token introspection response and has the same semantics in both cases. = The >>> JSON object as its value may look like this >>> >>> "act": >>> { >>> "sub":"admin@example.com" >>> } >>> >>> or even be nested like in >>> >>> "act": >>> { >>> "sub":"https://service16.example.com", >>> "act": >>> { >>> "sub":"https://service77.example.com" >>> } >>> } >>> >>> Personally, I find it to be a very expressive approach. Also, as far I >>> as know, several (oAuth2) client libraries have good support of things = like >>> >>> "aud":"https://service1.example.com" and "aud":[" >>> https://service1.example.com","https://service2.example.com"] >>> >>> in AT JWTs for a quite long time. >>> >>> >>> >>> Regards, >>> >>> Andrii >>> >>> >>> >>> On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>> Hi Yaron, >>> >>> >>> >>> We'll indeed have to check how make it as idiomatic as possible with >>> experts of each language (help welcome). >>> >>> >>> >>> Regarding the client, the variations are more limited but they do exist= . >>> Here I believe it's much more problematic than on the server side and t= here >>> are at least a few actions we should take: >>> >>> >>> >>> A) check in sec 7 if we really have a compelling reason for key and >>> proof variants. This is derived from larger discussions on key binding = as >>> per the related note. There are quite a few open questions related to t= his >>> theme. >>> >>> >>> >>> B) there is also the choice between value/reference that may generate >>> complexity. >>> >>> >>> >>> C) More generally, as many feedbacks already have noticed, we need to >>> have a systematic review and reduce the set of available options in the >>> protocol. >>> >>> >>> >>> Unless we have a clear idea why runtime behavior requires mutability, i= t >>> might be useful to have a way to define the chosen variant before hand,= so >>> that the expected behavior becomes deterministic on the client side. Th= ere >>> are various ways it could be done in practice. >>> >>> >>> >>> For sure several independant implementations would help, especially if >>> we make sure they can work together. >>> >>> >>> >>> Anyway all this open to improvement. >>> >>> >>> >>> Cheers >>> >>> Fabien >>> >>> >>> >>> Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer a >>> =C3=A9crit : >>> >>> Hi Fabien, >>> >>> >>> >>> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is f= ar worse than the >>> problem. The code in the article you cite is very specific to the use c= ase >>> and IMHO quite ugly. So my preferred Go implementation would be a >>> combination of untyped structures (Go interface{}) and run-time enforce= ment >>> of JSON Schema. >>> >>> >>> >>> Also, going back to our earlier discussion on this topic, I just read >>> Sec. 7 of gnap-00 and realized that the RC also needs to deal with >>> polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *TXAuth on behalf of Fabien Imbault < >>> fabien.imbault@gmail.com> >>> *Date: *Wednesday, October 28, 2020 at 18:56 >>> *To: *Mika Bostr=C3=B6m >>> *Cc: *GNAP Mailing List , Justin Richer < >>> jricher@mit.edu>, Dick Hardt >>> *Subject: *Re: [GNAP] Feedback on polymorphism >>> >>> >>> >>> Thanks for the great feedback. Your concern is very valid. >>> >>> >>> >>> My implementation is in rust, which makes life easier in that specific >>> case. >>> >>> >>> >>> So I'm not a golang specialist but I guess the transcription of json >>> strings/arrays into go structs would work around the lines described by >>> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 >>> >>> When we have a more formalized json schema, I suggest we make a library >>> of json examples and some related code samples in mainstream languages,= to >>> check it is feasible for everyone. >>> >>> >>> >>> Cheers, >>> >>> Fabien >>> >>> >>> >>> >>> >>> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m >>> wrote: >>> >>> Hi everyone, >>> >>> >>> >>> Looks like I stuck my finger in a hornets' nest. First off, apologies >>> for not chipping in earlier, but there was a lot of material to digest. >>> Also, warning: lots to read ahead. >>> >>> >>> >>> I'm one of those people who end up making use of AuthN/AuthZ >>> functionality through a library. On top of that I can see myself being >>> roped in as a server (AS) implementation help. So I'm approaching this = from >>> an outsider's perspective. Someone who expects to be exposed to the >>> eventual RFC and all the nitty-gritty details. My relatively terse comm= ent >>> ended up at the top of the aforementioned HN thread, which didn't >>> necessarily help. Sorry about that. >>> >>> >>> >>> Now, having read Justin's initial reply - and the rest of the thread - = I >>> believe I can see where the desire for polymorphism comes from. To be >>> clear: I am all for strict types inside an implementation, as it will a= dd >>> helpful guard-rails to the state management code paths. However, I see = this >>> as a case of leaky abstraction. If we take the existing oauth.xyj-java = code >>> to be the reference implementation, the choice makes logical sense: JSO= N is >>> not expressive enough to serialise arbitrary objects, so in order to av= oid >>> writing complex payload parser(s) the internal implementation details n= ow >>> leak to the protocol itself. From a purely technical perspective, it's = a >>> cool trick. From a distance it even looks a bit like the result of prot= obuf >>> decoding, but without the generated code parts. >>> >>> >>> >>> But then the downside. I don't personally expect to be able to use the >>> reference implementation, being mostly a Python user myself. A fair num= ber >>> of AS implementations will be written with languages such as Go, Python= , >>> C#, Ruby, and JavaScript (thanks to node.js), and all of them will have= to >>> deal with the polymorphism. From what I've read over the past couple of >>> days, I understand that at least Go supports custom unmarshalers from J= SON >>> to typed structs, at the cost of an indirection. Normally when a Go cod= e >>> processes JSON to a typed struct, the process is helped by field >>> annotations in the type definition itself. For example, if the payload = for >>> a person in JSON was >>> >>> >>> >>> { >>> >>> "name": "", >>> >>> "age": , >>> >>> "country": "", >>> >>> "city": "" >>> >>> } >>> >>> >>> >>> .. then the type definition would look like: >>> >>> >>> >>> type Person struct { >>> >>> Name string `json:"name" >>> >>> Age int `json:"age"` >>> >>> Country string `json:"country"` >>> >>> City string `json:"city"` >>> >>> } >>> >>> >>> >>> When the (possibly complex) type of a given field is fixed, unmarshalin= g >>> should still be straightforward. I haven't verified, but since the >>> annotation only gives which field to look at for a given typed value, t= here >>> should be nothing special about that. But when the field can instead be= a >>> union of more than one distinct types, things start to get messy. There= is >>> no union type in the language at all, so the following construct is not >>> even possible: >>> >>> >>> >>> type Entity struct { >>> >>> Resources []string `json:"resources"` >>> >>> Client union(Client, string) `json:"client"` >>> >>> } >>> >>> >>> >>> As I understand, the implicit expectation is that in the above case, th= e >>> unmarshaler detects that "client" is a string, and so expands it from a= n >>> opaque handle to the expected, populated type. Even after thinking abou= t >>> the ramifications over the past few days I remain confused, because I d= on't >>> see how the commonly used annotations could work. If the expectation is >>> that protocol implementations should use strong types, then the use of >>> polymorphic JSON is very likely to make things _more_ complicated for >>> non-reference implementations. >>> >>> >>> >>> Hence my concern. I'm afraid that the leaky abstraction, while making >>> the reference implementation more robust and straightforward, contribut= es >>> to making other implementations less robust. And this being a security >>> protocol, the potential for brittle and/or confused implementations is >>> terrifying. >>> >>> >>> >>> I am a fan of reducing complexity, and from what I can see, for the >>> reference implementation the polymorphic approach actually does that. B= ut >>> I'm afraid it does so at others' expense. Languages have their individu= al >>> constraints, idioms and best practices. If parsing a protocol payload >>> introduces low-level complexities and encourages to go against common >>> practices, that is an invitation for problems. I am aware that my choic= e of >>> words in the HN thread was likely to put people on defense, and for tha= t I >>> apologise. But I do believe that the choice of polymorphic JSON is goin= g to >>> make the life and use of other implementations notably less boring than >>> people in general would prefer. >>> >>> >>> >>> Cheers, >>> >>> Mika >>> >>> >>> >>> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault >>> wrote: >>> >>> Hi Dick, >>> >>> >>> >>> Well technically yes. Obviously the client can present any interface it >>> seems fit. >>> >>> >>> >>> Still there's the question of the common model we want to present to th= e >>> outside world and supported by the protocol itself (which client librar= ies >>> all build upon). >>> >>> >>> >>> But beneath the polyphormism question, the HN debate seems on the >>> surface a lot like the original xyz (polyphormism goes along with the >>> reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and >>> where the client design has more latitude). Just explained differently,= by >>> outside people with different agendas. >>> >>> >>> >>> Which is a bit weird because many of the critics on HN (who criticize >>> polyphormism) also seem to really dislike OAuth in the first place (the >>> inconsistencies are partially due to a bunch of different people >>> commenting). >>> >>> >>> >>> Really to me there's no fundamental truth behind that question. It's a >>> matter of preference and priorities in the design. Whatever choices we >>> make, we'll have to be prepared to explain and justify them in the open= , >>> even to some people that will dislike pretty much whatever we do (becau= se >>> it's fun to look smart and critize without proposing alternatives). And= we >>> owe these answers to people like Mika, who genuinely try to make the be= st >>> of it. >>> >>> >>> >>> Fabien >>> >>> >>> >>> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a >>> =C3=A9crit : >>> >>> Hi Fabien >>> >>> >>> >>> A library developer can provide whatever abstraction layer makes sense >>> for the library's target audience and language. >>> >>> >>> >>> If the client library developer wants to use polymorphism in the >>> interface presented to the user's of the library, the library developer= can >>> do that independent of polymorphism in the protocol, and vice versa >>> >>> >>> >>> =3D> polymorphism in the protocol has no impact on client library >>> developers >>> >>> >>> >>> >>> >>> *Error! Filename not specified.*=E1=90=A7 >>> >>> >>> >>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault >>> wrote: >>> >>> I'm just realizing your "least to most important" might actually say th= e >>> same as what I was trying to say. So I'm not even sure what we're argui= ng >>> against :-) >>> >>> >>> >>> In brief my point if it wasn't clear is that we should be crystal clear >>> on where we put the cursor of simplicity, because this can mean differe= nt >>> things for different people and different roles. >>> >>> And as we see on HN we need to better explain our design choices. >>> >>> >>> >>> >>> >>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >>> a =C3=A9crit : >>> >>> Hi Dick, >>> >>> >>> >>> Independantly from the debate on polyphormism, I beg to differ on your >>> order preference. >>> >>> >>> >>> Your assumption is that AS devs matter the most, because they're doing >>> the important security implementation. But eating our own dogfood might >>> help a lot to change that view. Most security issues occur because user= s of >>> the spec are unable to deal with the complexity that is passed onto the= m. >>> >>> >>> >>> 99% of the people that will actually use the output of the work are >>> application developers (client or RS) and their own users. >>> >>> >>> >>> Our intent as well as the protocol drive the usage. Client libraries ma= y >>> help, but they're not a silver bullet, especially because GNAP ultimate= ly >>> has no control about what people do there (for better or worse). And >>> everything we do here will help get to the better part. >>> >>> >>> >>> I'm not saying we don't intend to also care about AS developers >>> (beginning with ourselves) but it's a second order optimisation. And si= nce >>> it's a tendancy we're leaning towards by default, I'm pretty sure we wo= n't >>> forget that anyway. >>> >>> >>> >>> Fabien >>> >>> >>> >>> >>> >>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a >>> =C3=A9crit : >>> >>> I'm confused by your logic Fabien. >>> >>> >>> >>> If a client library developer wants to expose polymorphism, they can do >>> that independent of what is in the protocol. >>> >>> >>> >>> I differ on who our stakeholders are. >>> >>> >>> >>> I think our stakeholders are in least to most important: >>> >>> >>> >>> - AS developer >>> - RS developer >>> - client developer >>> - user >>> >>> >>> >>> A client library developer can expose whatever interface they want to >>> simplify implementation. >>> >>> >>> >>> I list the user so that we don't lose site of a critical role. >>> >>> >>> >>> /Dick >>> >>> >>> >>> >>> >>> *Error! Filename not specified.*=E1=90=A7 >>> >>> >>> >>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault >>> wrote: >>> >>> Hi there, >>> >>> >>> >>> Let me try to approach the issue under a different light. More like a >>> product manager would deal with feature selection to make it intuitive = for >>> its users. >>> >>> >>> >>> For most people, riding a bike is far easier than using a unicycle. >>> Feels more stable. And yet it's way easier to design for a single wheel >>> than to build with 2. Because then you'll need a lot more accessories >>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be = a >>> brittle process, it can be industrialized. >>> >>> >>> >>> Back to the GNAP topic. >>> >>> Ultimately we should strive to make the spec as simple as can be. But w= e >>> need to ask: simple for whom? For the bike owner or for the bike vendor= ? >>> >>> (short answer: the priority should be simplicity for spec users, not >>> spec implementers and even less spec designers). >>> >>> >>> >>> The initial question that is asked is very interesting: isn't the desig= n >>> flawed if GNAP is using json polyphormism? Or if the AS needs to handle= the >>> state of the request? Or if we must handle token revocation? Or if we a= re >>> looking for a global unique identifier? The argument stems of the fact = that >>> is still arguably harder and more error prone to implement. Fair enough= . >>> >>> >>> >>> From a spec implementer's perspective, it may well be more complex. It >>> mostly impacts the json library you'll end up using, plus a bit of >>> input/output decoration around it. Even golang provides utilities for t= his, >>> despite not exactly being made for this kind of purpose. >>> >>> My practical experience implementing it is that it's not that big a >>> deal. I mean, I wished it could be simpler, but it's manageable and the= re >>> are other ways to reach levels of insurance that it does work as intend= ed >>> (json schema, test cases to validate the implementation, etc.). Arguabl= y it >>> is still easier from an implementation perspective than say, json-ld, w= hich >>> is massively used in the SSI community. >>> >>> >>> >>> But ultimately who are we designing for? Are we striving to go easy on >>> the spec implementer? Or are we trying to make sure end-developers usin= g >>> the client libraries won't shoot themselves in the foot? >>> >>> >>> >>> The job to be done (JTBD), from the end-developer's perspective, is to >>> efficiently ship an application. And provide authN/authZ capabilities f= or >>> end-users by relying on some well known implementation. >>> >>> In turn, this spec implementer will rely on cryptographic utility >>> libraries that deals internally with the complexity of their own domain= , so >>> that we don't have to. And here we could launch another HN flame war th= at >>> starts with the title "JWT sucks because". Which does have its set of v= ery >>> real issues but that's beyond the point. >>> >>> Note that any decent flamewar will be efficiently fueled by people >>> hating medium. Is it outrageous for blog posts to be behind a paywall? >>> Maybe but it's even more outrageous to lack consistency, either by not >>> knowing how to get around a paywall if you're into a hacker punk moveme= nt, >>> or on the contrary by to not paying a subscription if you believe that >>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated. >>> >>> What likely seems an unnecessary sidenote tries to illustrate the point= : >>> for Justin it was easier to publish on medium, because as a blog publis= her, >>> you might not want to deal with hosting your own blog. But maybe as a >>> reader you'll find that annoying. Different audiences, different JTBD, >>> different tradeoffs. >>> >>> >>> >>> Polyphormism is a tool that enables the end-developer to have minimal >>> knowledge of what it means to deal with a GNAP client library. You prep= are >>> the request, send to the endpoint and you're good to go. Massively simp= ler >>> than OAuth2 or any similar protocol by the way (as anyone with teaching >>> experience on the subject might acknowledge). And there's a lot more t= o be >>> done to make sure we indeed reduce the complexity for the end-developer= and >>> the end-user. >>> >>> >>> >>> If we find a better way to deal with that simplicity balance, I'm all >>> in. But the arguments need to be way more convincing than just saying t= hat >>> it may be difficult to implement or validate. >>> >>> >>> >>> Cheers. >>> >>> Fabien >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a = =C3=A9crit : >>> >>> >>> >>> >>> >>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>> >>> >>> >>> Justin >>> >>> >>> >>> I did note that I was the one that argued for instance_id being in the >>> object. Since it is in the object in the current draft, not including a >>> pass by reference option would be preferable. >>> >>> >>> >>> As for concrete examples: >>> >>> - version of client >>> >>> - version of OS >>> >>> - security attestation of OS / device >>> >>> - location of client device >>> >>> - network client is operating on >>> >>> >>> >>> These are all attributes of the client that an AS may require on the >>> initial grant request, and in future grant requests (which is when an >>> instance_id) would be used. >>> >>> >>> >>> >>> >>> This is where our interpretations differ: I don=E2=80=99t see these as >>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key= , display >>> information, class identifiers, and other items currently represented b= y an >>> instance_id are attributes of the client instance. The attestation >>> components don=E2=80=99t modify the instance so much as present additio= nal >>> information on top of the client instance itself. This is why I argue t= hat >>> they ought to be handled in a separate object, so you=E2=80=99d have so= mething like >>> this strawman: >>> >>> >>> >>> { >>> >>> >>> >>> posture: { >>> >>> software_version: 1.2.3, >>> >>> os_version: 14.3.2 >>> >>> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >>> >>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>> >>> }, >>> >>> >>> >>> client: =E2=80=9Cclient-541-ab" >>> >>> >>> >>> } >>> >>> >>> >>> This is a more fundamental question about GNAP than whether the syntax >>> uses polymorphism: this is about GNAP being very explicit about the dat= a >>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mod= el of what >>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply p= roblematic in >>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with hav= ing to >>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that does= n=E2=80=99t fully capture >>> the different aspects that are out there. I think we=E2=80=99re getting= closer here >>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D, = but we still need to >>> be more precise about what exactly a client instance includes, and what= it >>> does not. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> >>> >>> /Dick >>> >>> >>> >>> *Error! Filename not specified.*=E1=90=A7 >>> >>> >>> >>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote: >>> >>> Dick, >>> >>> >>> >>> As you=E2=80=99ll recall, I argued against including the client instanc= e >>> identifier inside of the object as a mutually-exclusive field precisely >>> because of the principle violation that you are pointing out here, and = so >>> it=E2=80=99s important to point out that the current text is a compromi= se that >>> needs to be examined in the wider experience of the working group. I am= on >>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >>> object, but this needs to be explored. >>> >>> >>> >>> The crux of my argument is that is exactly a case of pass-by-reference >>> vs pass-by-value, and that runtime attestations are not part of the =E2= =80=9Cclient >>> instance=E2=80=9D value itself but rather belong outside of that object= in a >>> another part of the request. As stated in the editorial notes in this >>> section, we need to look carefully at how these concepts fit within the >>> model and where we would want to put them. Without concrete examples of >>> what these extensions look like and how they=E2=80=99re generated, that= is nearly >>> impossible to do at this stage. I look forward to seeing examples of th= is >>> kind of data and how it can fit into the protocol. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>> >>> >>> >>> Hey Justin, >>> >>> >>> >>> As the draft has evolved, I question the continued use of polymorphism. >>> Note that I appreciate the elegance of using a string for >>> pass-by-reference, and an object for pass-by-value. >>> >>> >>> >>> In the current draft, the >>> >>> >>> >>> Every time you create or process a field it will mean only one thing, >>> and there=E2=80=99s only one field to look at to answer a question. >>> >>> >>> >>> is violated in 2.3.1. Identifying the RC Instance >>> >>> >>> >>> >>> >>> >>> instance_id An identifier string that the AS can use to identify th= e >>> >>> particular instance of this RC. The content and structure of thi= s >>> >>> identifier is opaque to the RC. >>> >>> >>> >>> "client": { >>> >>> "instance_id": "client-541-ab" >>> >>> } >>> >>> >>> >>> If there are no additional fields to send, the RC MAY send the >>> >>> instance identifier as a direct reference value in lieu of the >>> >>> object. >>> >>> >>> >>> "client": "client-541-ab" >>> >>> >>> >>> The instance identifier can be sent two ways. Polymorphism is a >>> convenience for the client, but requires the server to have two code pa= ths >>> for "instance_id". We discussed this in the design team, and I argued = for >>> having "instance_id" in the "client" object so that any updates, such a= s >>> new devices assertions, could be in the "client" object. As noted above= , >>> while I appreciate the elegance of using a string (handle) to reference= a >>> previously provided object, it complicates how to update an existing ob= ject >>> while providing the reference. >>> >>> >>> >>> In your example of the "key" object below, setting "proof" to bearer >>> would avoid the issue you describe: >>> >>> >>> >>> { >>> "key": { >>> "proof": "bearer" >>> } >>> } >>> >>> >>> >>> In your example, when processing the "key" object, code is having to >>> check both the JSON type of the property, as well as check the value of= the >>> "proof" property. In the example I provided, only the value of "proof" >>> needs to be checked. The "proof" property is acting as a type for the "= key" >>> object. >>> >>> >>> >>> Not being a Java programmer, I don't know how this would work in a Java >>> implementation, but node.js, the processing would need to be done as ab= ove. >>> >>> >>> >>> On a related note, there was significant negative feedback on handles >>> and polymorphism in the Hacker News article >>> https://news.ycombinator.com/item?id=3D24855750 >>> >>> >>> >>> /Dick >>> >>> >>> >>> >>> >>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote: >>> >>> Hi Mika, >>> >>> >>> >>> Thanks for bringing this topic here =E2=80=94 I was able to see the for= um >>> discussion that brought you here, and hopefully I can help clear up wha= t I >>> mean with how polymorphism is used in the proposal. The short version i= s >>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>> protocols, and so in that goal we=E2=80=99re fully aligned. I think tha= t using >>> polymorphism in very specific ways can help that goal =E2=80=94 just as= I agree >>> that misusing it or applying it sloppily can lead to ambiguous and inse= cure >>> systems. >>> >>> >>> >>> Some background: I built out the XYZ protocol (one of the predecessors >>> to the initial GNAP Draft) in Java using strongly typed parsers and Jav= a >>> objects specifically to prove to myself that it could be done in a way = that >>> made any sense in the code. (My own open source implementation is at >>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not = yet up >>> to date with the GNAP spec). It was important to me that I be able to u= se >>> the system-wide configured parsers to implement this and not have to re= sort >>> to stepping through elements completely by hand. Java doesn=E2=80=99t m= ake it >>> simple to get the hooks into the right places (especially with the Jack= son >>> parser that I used), but it is definitely possible to create a >>> deterministic and strongly-typed parser and serializer for this kind of >>> data structure. Some of the rationale for using polymorphism is covered= in >>> the trailing appendix of the draft document ( >>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#n= ame-json-structures-and-polymor), >>> but it=E2=80=99s still good to discuss this here as the working group d= ecides which >>> approaches to take. >>> >>> >>> >>> The driving reason for using polymorphism at the protocol level was to >>> simplify the protocol and make it :more: deterministic to create and >>> process, not less. Every time you create or process a field it will mea= n >>> only one thing, and there=E2=80=99s only one field to look at to answer= a question. >>> Without polymorphic field values, you usually need to rely on mutual >>> exclusivity of fields, which is prone to failure and requires additiona= l >>> error checking. Take for example the key binding of access tokens. An >>> access token could be bound to the RC=E2=80=99s key used during the req= uest, to a >>> different key chosen by the AS, or it could be a bearer token with no k= ey >>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can d= efine it in terms of >>> boolean values and objects and express this set of mutually-exclusive >>> options in a non-ambiguous way. Without that, you=E2=80=99d need to hav= e different >>> fields for the options and include additional checks in your parser to = make >>> sure they weren=E2=80=99t sent simultaneously, otherwise you could get = hit with >>> this potential security vulnerability in an object: >>> >>> >>> >>> { >>> >>> key: { >>> >>> proof: httpsig, >>> >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> >>> }, >>> >>> bearer_token: true, >>> >>> bind_to_rc_key: true >>> >>> } >>> >>> >>> >>> This would be an illegal object as per this alternate proposal, but the= n >>> you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others >>> in the same object. I=E2=80=99ve done this exercise with many other pro= tocols and >>> it=E2=80=99s both error prone and easy to ignore since all the =E2=80= =9Cgood=E2=80=9D examples >>> would pass code that doesn=E2=80=99t check this. With the polymorphic a= pproach to >>> this same field, each of these three mutually-exclusive states is writt= en >>> in a way that they cannot be sent together. It=E2=80=99s not just illeg= al, it=E2=80=99s >>> impossible and enforced by the syntax of JSON itself. >>> >>> >>> >>> { >>> >>> key: { >>> >>> proof: httpsig, >>> >>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>> >>> } >>> >>> } >>> >>> >>> >>> // bearer token >>> >>> >>> >>> { >>> >>> key: false >>> >>> } >>> >>> >>> >>> // bound to the RC=E2=80=99s presented key >>> >>> >>> >>> { >>> >>> key: true >>> >>> } >>> >>> >>> >>> If someone sends a different type for this field, like an array or >>> number or a null, this doesn=E2=80=99t have a defined interpretation in= the >>> protocol and would be a protocol level error. >>> >>> >>> >>> While it might sound like polymorphism means that any field could have >>> any type or value, the opposite is true: each possible value is explici= tly >>> typed, it=E2=80=99s just that there are potentially different types tha= t express >>> meaning for the field. This applies to all members of all objects >>> (dictionaries) as well as all members of an array (list). Every time yo= u >>> process a field value or other element, you look at the type and then t= he >>> value to determine what to do with that typed value. >>> >>> >>> >>> In your example below, each field within the dictionary would also need >>> to be typed, and each type would need to have a clear indication of its >>> meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could >>> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON= number) or an >>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would = further say what >>> exactly the encoding of the string would be. That means that when you r= ead >>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confu= sion on what the value was >>> or how it was represented, regardless of the input format. Seeing a num= ber >>> there means exactly one interpretation and seeing a string means exactl= y >>> one (different) interpretation =E2=80=94 but importantly, both of them = are a >>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determin= es the type. An >>> implementation would likely use an internal BigInteger type of object t= o >>> represent the field value after parsing, so the question is how to go f= rom >>> the JSON value (which is typed) into the BigInteger value.You don=E2=80= =99t just >>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you app= ly it to all >>> sub-fields of that object. >>> >>> >>> >>> So let=E2=80=99s dig into the specific bug you bring up in the strawman= , because >>> it=E2=80=99s interesting: A JSON encoder that encodes numbers as string= s, and not >>> numbers, is not compliant with the JSON definitions of the field in >>> question. For another example, the quoted string value of =E2=80=9Ctrue= =E2=80=9D is not >>> equivalent to the boolean value true in JSON, and they shouldn=E2=80=99= t be treated >>> the same by a parser implementation when mapping to a concrete object. = It=E2=80=99s >>> in this kind of automated guessing that this class of bugs occur, and >>> that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s >>> polymorphic nature. I=E2=80=99ve run into cases where a parser library = was trying >>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, b= ut ended up >>> introducing errors in more strict components downstream. This is someth= ing >>> that protocol designers need to be aware of and guard against in the de= sign >>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>> generally have things that branch whether they=E2=80=99re an object (fo= r a rich >>> description of something) or some non-structured special value (for a >>> reference or other item). >>> >>> >>> >>> The design team created some simple JSON Schemas for parts of the >>> protocol during our discussion, but we didn=E2=80=99t include them in t= he design >>> document due to both lack of time to keep it updated with the rapid cha= nges >>> to the protocol during the design team discussion, and not knowing if t= here >>> would be interest in such material. I personally think it would be help= ful >>> to include as an informative reference in the final document, but that= =E2=80=99s >>> something for the working group to take up eventually. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>> >>> >>> >>> Hello, everyone. >>> >>> >>> >>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum an= d >>> when I made note about certain concerns, I was requested to send my >>> comments to this working group. >>> >>> >>> >>> In short, I believe that the use of polymorphic JSON in the protocol >>> invites subtle and confusing implementation problems. I also searched >>> through the WG archives, and noticed that similar concerns were noted, >>> briefly, in a thread in July. >>> >>> >>> >>> The problem with polymorphic values, as I see it, is that >>> implementations will need to branch on the (inferred) type of a given >>> field. This isn't quite as bad if the types are strictly different, but >>> allows for subtle bugs when the value in question is a dictionary. What >>> makes this unappealing is that "subtle bugs" in security protocols have= a >>> habit of turning into vulnerabilities. >>> >>> >>> >>> Let's say we have these imaginary payloads, both possible and valid in >>> the same protocol step: >>> >>> >>> >>> # payload 1 >>> >>> { >>> >>> ..., >>> >>> "public_key": { >>> >>> "alg": "rsa", >>> >>> "modulus": >>> >>> } >>> >>> } >>> >>> >>> >>> # payload 2 >>> >>> { >>> >>> ..., >>> >>> "public_key": { >>> >>> "alg": "rsa", >>> >>> "modulus": "" >>> >>> } >>> >>> } >>> >>> >>> >>> In both cases, the type of "public_key" field is a dictionary. In both >>> cases, they even have the same keys. However, the values in the >>> dictionaries are entirely different, and an implementation will have to >>> branch to at least two possible decoding mechanisms. To make things wor= se, >>> some JSON implementations may choose to encode non-dictionary values as >>> strings, so it is possible for an originator to transmit what they expe= ct >>> and believe to be payload 1 format, but which the receiver will interpr= et >>> to be in payload 2 format. And if the encoded string contains only digi= ts, >>> it will even parse correctly as a bignum. >>> >>> >>> >>> While the above is clearly a manufactured scenario, it nonetheless >>> demonstrates the potential for logic bugs with polymorphic JSON. With >>> richer types and more complex dictionaries, there will surely be more r= oom >>> for errors. >>> >>> >>> >>> Ambiguity in protocols is always a source of implementation complexity >>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse: >>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, woul= dn't >>> it be in everyone's interest to keep implementation complexity and mist= ake >>> potential to a minimum? >>> >>> >>> >>> Best regards, >>> >>> Mika >>> >>> >>> >>> -- >>> >>> Mika Bostr=C3=B6m >>> >>> Smarkets >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> *Error! Filename not specified.*=E1=90=A7 >>> >>> >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> >>> Mika Bostr=C3=B6m >>> >>> Smarkets >>> >>> -- TXAuth mailing list TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> --00000000000072877e05b2e53cfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Dick, interesting ! I'll add that to my list.Maybe we could liaise with the JSON schema team if it helps.
    In the meantime, I'll focus on how to implement my json pol= ymorphism=C2=A0;-)

    On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt &l= t;dick.hardt@gmail.com> wrot= e:
    I exchanged some emails with the JSON Schema team last summer. They are= actively working on a revision to better server OpenAPI.

    They felt stonewalled at the IETF and now question the value of spending = time in a standards body.=C2=A0

    Another = schema option is JSON Type Definition [1], which is built on CDDL (RFC 8610= ) [2], the CBOR type language.

    <= div>


    3D""=E1=90= =A7

    On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron,=C2=A0

    Thanks a lot fo= r the feedback, I fixed the issue related to the standardisation status (I = guess there's some historic background that I don't know ;-)).

    Is JSON the only real possible format? Probably, at le= ast for compatibility with pretty much everything that exists. Only TJSON c= ould maybe be used as an alternative (and kind of removes the need for a sc= hema), with the downsides that you don't have so many existing librarie= s and that the community seems much smaller: 2k stars for JSON schema spec = vs 65 for TJSON spec (and the expired website SSL certificate doesn't h= elp).=C2=A0 =C2=A0

    The main problem I see is that = for constrained cases, CBOR won't have a schema in a foreseeable future= (at least I'm not aware of any work on that). I know it's not our = main focus right now and might not even be covered by the current WG, but s= till it might become an issue at some point.=C2=A0

    Best,
    Fabien=C2=A0 =C2=A0

    On Fri, Oct 30, 2020 at 3:19 PM Yaron S= heffer <yaron= f.ietf@gmail.com> wrote:

    Hi Fabien,<= u>

    =C2=A0

    One correction, JSON Schema (which I am personally advocating f= or, but still) does not have an IETF spec. They claim on their web site tha= t they want it standardized, but in practice are not (yet?) moving in this = direction. Their Internet Draft is unmaintained.

    =C2=A0

    At a higher l= evel, I think your discussion conflates two things: the representation of d= ata on the wire (JSON or various mostly binary encodings) and the data mode= ling language, a.k.a. schema. Personally I think JSON is almost a must in o= ur case, and if this is true, the playing field is *much* more narro= w.

    =C2=A0

    A major strength of JSON which you don=E2=80=99t mention in = your comparison is the cryptographic ecosystem (JOSE): standard formats for= encryption, signature etc.

    = =C2=A0

    I wasn=E2=80=99t aware of Ion. I do= n=E2=80=99t think it=E2=80=99s a good fit for us, still a very interesting = direction.

    =C2=A0

    =

    Thanks,

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Yaron

    =C2=A0=

    From: Fabien Imbault <fabien.imbault@gmail.com&g= t;
    Date: Friday, October 30, 2020 at 14:53
    To: Andrii D= einega <an= drii.deinega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarke= ts.com>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, GNAP = Mailing List <txaut= h@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP= ] Feedback on polymorphism

    =C2=A0

    Hi Just= in,=C2=A0

    =C2=A0=

    > Regarding your question, what el= se could we propose?=C2=A0

    =C2=A0

    I've start= ed a review of possibilities at=C2=A0https://gith= ub.com/fimbault/reasonably-polymorphic/blob/main/README.md to be follow= ed by actual code testing.=C2=A0

    =C2=A0

    Cheers,<= u>

    Fabien

    =

    =C2=A0

    On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega <andrii.deinega@gmail= .com> wrote:

    Hi=C2=A0Mika, Justin, and WG,

    =C2=A0

    The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Excha= nge) has a JSON object as its value. This claim could be a part of AT JWT o= r a token introspection response and has the same semantics in both cases. = The JSON object as its value may look like this

    "act":
    = {
    =C2=A0 "sub":"admin@example.com"
    }

    or even be nested lik= e in

    "act":
    {
    =C2=A0"sub":"https://service16.example= .com",
    =C2=A0 =C2=A0"act":
    =C2=A0 =C2=A0{
    =C2= =A0 =C2=A0 =C2=A0"sub":"https://service77.example.com"
    =C2=A0 = =C2=A0}
    }

    Personally, I find it to be a very expressive approach.= Also, as far I as know, several (oAuth2) client libraries have good suppor= t of things like

    "aud":"https://service1.example.com" and &q= uot;aud":["https://service1.example.com","https://service2.example.com"]
    in AT JWTs for a quite long time.

    =C2=A0

    Regards= ,

    Andrii

    =C2=A0

    On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:

    <= p class=3D"MsoNormal">Hi Yaron,

    =C2=A0

    We'll indee= d have to check how make it as idiomatic as possible with experts of each l= anguage (help welcome).=C2=A0

    =C2=A0

    Regarding t= he client, the variations are more limited but they do exist. Here I believ= e it's much more problematic than on the server side and there are at l= east a few actions we should take:

    =C2=A0

    A) che= ck in sec 7 if we really have a compelling reason for key and proof variant= s. This is derived from larger discussions on key binding as per the relate= d note. There are quite a few open questions related to this theme.=C2=A0

    =C2=A0

    <= /div>

    B) there is also the choice between value/= reference that may generate complexity.=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    C) More generally, as many feedbacks already have noticed, we need to = have a systematic review and reduce the set of available options in the pro= tocol.=C2=A0

    =C2= =A0

    Unless we have a clear idea why runtime behavior requires= mutability, it might be useful to have a way to define the chosen variant = before hand, so that the expected behavior becomes deterministic on the cli= ent side. There are various ways it could be done in practice.=C2=A0=

    =C2=A0

    For sure several independant implementat= ions would help, especially if we make sure they can work together.=C2=A0

    =C2=A0

    <= /div>

    Anyway all this open to improvement.=C2=A0=

    =C2=A0

    Cheers=C2=A0

    Fabien=C2=A0

    =C2=A0

    Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.c= om> a =C3=A9crit=C2=A0:

    Hi Fabien,

    =C2=A0

    At least in the c= ase of Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than the pro= blem. The code in the article you cite is very specific to the use case and= IMHO quite ugly. So my preferred Go implementation would be a combination = of untyped structures (Go interface{}) and run-time enforcement of JSON Sch= ema.

    =C2=A0

    Also, going back to our earlier discussion on this topic, = I just read Sec. 7 of gnap-00 and realized that the RC also needs to deal w= ith polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS.=

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbau= lt <fabien= .imbault@gmail.com>
    Date: Wednesday, October 28, 2020 at 1= 8:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com><= br>Subject: Re: [GNAP] Feedback on polymorphism    =

    =C2=A0

    Thanks for the great feedback. Your concern is very va= lid.=C2=A0

    =C2=A0<= u>

    My implementation is in rust, w= hich makes life easier in that specific case.=C2=A0

    =

    =C2=A0

    So I'm not a golang specialist but I guess the transcr= iption of json strings/arrays into go structs would work around the lines d= escribed by=C2=A0https://medium.com/@alexkappa/json-p= olymorphism-in-go-4cade1e58ed1

    When we have a more formalized json schema, I suggest we make a = library of json examples and some related code samples in mainstream langua= ges, to check it is feasible for everyone.=C2=A0

    =C2=A0

    Cheers,

    Fabien

    =C2=A0

    <= /div>

    =C2=A0

    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smar= kets.com> wrote:

    Hi everyone,

    =C2=A0

    Looks like= I stuck my finger in a hornets' nest. First off, apologies for not chi= pping in earlier, but there was a lot of material to digest. Also, warning:= lots to read ahead.

    =C2= =A0

    I'm one of those= people who end up making use of AuthN/AuthZ functionality through a librar= y. On top of that I can see myself being roped in as a server (AS) implemen= tation help. So I'm approaching this from an outsider's perspective= . Someone who expects to be exposed to the eventual RFC and all the nitty-g= ritty details. My relatively terse comment ended up at the top of the afore= mentioned HN thread, which didn't necessarily help. Sorry about that.

    =C2=A0

    <= /div>

    Now, having read Justin's initial repl= y - and the rest of the thread - I believe I can see where the desire for p= olymorphism comes from. To be clear: I am all for strict types inside an im= plementation, as it will add helpful guard-rails to the state management co= de paths. However, I see this as a case of leaky abstraction. If we take th= e existing oauth.xyj-java code to be the reference implementation, the choi= ce makes logical sense: JSON is not expressive enough to serialise arbitrar= y objects, so in order to avoid writing complex payload parser(s) the inter= nal implementation details now leak to the protocol itself. From a purely t= echnical perspective, it's a cool trick. From a distance it even looks = a bit like the result of protobuf decoding, but without the generated code = parts.

    =C2=A0<= /u>

    But then the downside. I don't= personally expect to be able to use the reference implementation, being mo= stly a Python user myself. A fair number of AS implementations will be writ= ten with languages such as Go, Python, C#, Ruby, and JavaScript (thanks to = node.js), and all of them will have to deal with the polymorphism. From wha= t I've read over the past couple of days, I understand that at least Go= supports custom unmarshalers from JSON to typed structs, at the cost of an= indirection. Normally when a Go code processes JSON to a typed struct, the= process is helped by field annotations in the type definition itself. For = example, if the payload for a person in JSON was

    =C2=A0

    {

    =C2=A0 "n= ame": "<string>",

    =C2=A0 "age": <int>,

    =

    =C2=A0 "country": "<string>= ;",

    =C2=A0 "ci= ty": "<string>"

    }

    =C2=A0<= u>

    .. then the type definit= ion would look like:

    =C2= =A0

    type Person struct {=

    =C2=A0 Name string `jso= n:"name"

    =C2= =A0 Age int `json:"age"`

    =C2=A0 Country string `json:"country"`

    =C2=A0 City string `json:"city&quo= t;`

    }

    <= /div>

    =C2=A0

    When the (possibly complex) type of a given field is fixed,= unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed va= lue, there should be nothing special about that. But when the field can ins= tead be a union of more than one distinct types, things start to get messy.= There is no union type in the language at all, so the following construct = is not even possible:

    = =C2=A0

    type Entity struc= t {

    =C2=A0 Resources []s= tring `json:"resources"`

    =C2=A0 Client union(Client, string) `json:"client"`=

    }

    <= div>

    =C2=A0

    As I understand, the implicit expectation is that in the above ca= se, the unmarshaler detects that "client" is a string, and so exp= ands it from an opaque handle to the expected, populated type. Even after t= hinking about the ramifications over the past few days I remain confused, b= ecause I don't see how the commonly used annotations could work. If the= expectation is that protocol implementations should use strong types, then= the use of polymorphic JSON is very likely to make things _more_ complicat= ed for non-reference implementations.

    =C2=A0

    Hence m= y concern. I'm afraid that the leaky abstraction, while making the refe= rence implementation more robust and straightforward, contributes to making= other implementations less robust. And this being a security protocol, the= potential for brittle and/or confused implementations is terrifying.

    =C2=A0

    I am a fan of reducing complexity, and from what I = can see, for the reference implementation the polymorphic approach actually= does that. But I'm afraid it does so at others' expense. Languages= have their individual constraints, idioms and best practices. If parsing a= protocol payload introduces low-level complexities and encourages to go ag= ainst common practices, that is an invitation for problems. I am aware that= my choice of words in the HN thread was likely to put people on defense, a= nd for that I apologise. But I do believe that the choice of polymorphic JS= ON is going to make the life and use of other implementations notably less = boring than people in general would prefer.

    =C2=A0

    Cheers,

    Mika

    =C2=A0

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <= fabien.imbaul= t@gmail.com> wrote:

    Hi Dick,

    =C2= =A0

    Well technically yes= . Obviously the client can present any interface it seems fit.=C2=A0=

    =C2=A0

    =

    Still there's the question of the common mo= del we want to present to the outside world and supported by the protocol i= tself (which client libraries all build upon).=C2=A0

    =C2=A0

    But beneath the polyphormism question, the HN debate seems on t= he surface a lot like the original xyz (polyphormism goes along with the re= duced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where= the client design has more latitude). Just explained differently, by outsi= de people with different agendas.=C2=A0

    =C2=A0

    W= hich is a bit weird because many of the critics on HN (who criticize polyph= ormism) also seem to really dislike OAuth in the first place (the inconsist= encies are partially due to a bunch of different people commenting).=C2=A0<= u>

    =C2=A0

    =

    Really to me there's no fundamental t= ruth behind that question. It's a matter of preference and priorities i= n the design. Whatever choices we make, we'll have to be prepared to ex= plain and justify them in the open, even to some people that will dislike p= retty much whatever we do (because it's fun to look smart and critize w= ithout proposing alternatives). And we owe these answers to people like Mik= a, who genuinely try to make the best of it.=C2=A0

    <= div>

    =C2=A0

    Fabien=C2=A0

    = =C2=A0

    Le lun. 26 oct. 20= 20 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

    Hi Fabien

    =C2=A0

    A library developer can provide whatever abstraction layer = makes sense for the library's target=C2=A0audience and language.=

    =C2=A0

    =

    If the client library=C2=A0developer wants to u= se polymorphism=C2=A0in the interface presented to the user's of the li= brary, the library developer can do that independent of polymorphism in the= protocol, and vice versa=C2=A0

    =C2=A0

    =3D> p= olymorphism in the protocol has no impact on client library developers

    =C2=A0

    =C2=A0

    = Error! Filename not specified.=E1=90=A7

    =C2=A0

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:

    I'm just realizing your "least to most important" mi= ght actually say the same as what I was trying to say. So I'm not even = sure what we're arguing against :-)=C2=A0

    =C2=A0

    I= n brief my point if it wasn't clear is that we should be crystal clear = on where we put the cursor of simplicity, because this can mean different t= hings for different people and different roles.=C2=A0

    And as we see on HN we need to better explain= our design choices.=C2=A0

    =C2=A0

    =C2=A0=

    Le dim. 25 oct. 2020 =C3=A0 00:= 25, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:<= /u>

    Hi Dick,

    =C2=A0

    Independantly from the debate on polyphormism, I beg to dif= fer on your order preference.=C2=A0

    =C2=A0

    Your = assumption is that AS devs matter the most,=C2=A0because they're doing the important security impleme= ntation. But eating our own dogfood might help a lot to change that view. M= ost security issues occur because users of the spec are unable to deal with= the complexity that is passed onto them.=C2=A0

    =C2=A0

    99% of the people that will actually use the output of the w= ork are application developers (client or RS) and their own users.=C2=A0=

    =C2=A0

    Our intent as well as the protocol drive the usage. Client libraries may = help, but they're not a silver bullet, especially because GNAP ultimate= ly has no control about what people do there (for better or worse). And eve= rything we do here will help get to the better part.=C2=A0=

    =C2=A0

    I'm not saying we don't intend to also car= e about AS developers (beginning with ourselves) but it's a second orde= r optimisation. And since it's a tendancy we're leaning towards by = default, I'm pretty sure we won't forget that anyway.=C2=A0<= u>

    =C2=A0

    <= div>

    Fabien=C2=A0

    =C2=A0

    =C2=A0

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:

    I'm confused by your logic Fabien.

    =C2=A0

    If a client library developer wants to expose polymorphism, they can= do that independent of what is in the protocol.=C2=A0

    =C2=A0

    I differ on who our stakeholders are.=C2=A0

    =C2=A0

    I think our stakeholders are in least to most important:<= u>

    =C2=A0

    =
    • AS developer=
    • RS developer
    • client developer
    • u= ser

    =C2=A0<= u>

    A client library developer can = expose whatever interface they want to simplify implementation.

    =C2=A0

    =

    I list the user so that we don't lose site of a = critical role.

    =C2=A0=

    /Dick

    =C2=A0

    =C2=A0

    Error! Filen= ame not specified.=E1=90=A7

    =C2=A0

    On= Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    Hi th= ere,=C2=A0

    =C2=A0=

    Let me try to approach the issue un= der a different light. More like a product manager would deal with feature = selection to make it intuitive for its users.=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    For most people, riding a bike is far easier than using a unicycl= e. Feels more stable. And yet it's way easier to design for a single wh= eel than to build with 2. Because then you'll need a lot more accessori= es (chain, chain ring, etc.). Even so producing a bike doesn't have to = be a brittle process, it can be industrialized.=C2=A0

    =C2=A0

    Back to the GNAP topic.=C2=A0

    Ultimately we s= hould strive to make the spec as simple as can be. But we need to ask: simp= le for whom? For the bike owner or for the bike vendor?=C2=A0=

    (short answer: the priority should be simplicity for spec us= ers, not spec implementers and even less spec designers).=C2=A0

    =C2=A0

    The initial question that is asked is very in= teresting: isn't the design flawed if GNAP is using json polyphormism? = Or if the AS needs to handle the state of the request? Or if we must handle= token revocation? Or if we are looking for a global unique identifier? The= argument stems of the fact that is still arguably harder and more error pr= one to implement. Fair enough.=C2=A0

    =C2=A0

    Fr= om a spec implementer's perspective, it may well be more complex. It mo= stly impacts the json library you'll end up using, plus a bit of input/= output decoration around it. Even golang provides utilities for this, despi= te not exactly being made for this kind of purpose.

    =

    My practical experience implementing it is that= it's not that big a deal. I mean, I wished it could be simpler, but it= 's manageable and there are other ways to reach levels of insurance tha= t it does work as intended (json schema, test cases to validate the impleme= ntation, etc.). Arguably it is still easier from an implementation perspect= ive than say, json-ld, which is massively used in the SSI community.=C2=A0<= u>

    =C2=A0

    =

    But ultimately who are we designing for? = Are we striving to go easy on the spec implementer? Or are we trying to mak= e sure end-developers using the client libraries won't shoot themselves= in the foot?

    =C2=A0<= /u>

    The job to be done (JTBD), = from the end-developer's perspective, is to efficiently ship an applica= tion. And provide authN/authZ capabilities for end-users by relying on some= well known implementation.=C2=A0

    In turn, this spec implementer will rely on cryptographic utility= libraries that deals internally with the complexity of their own domain, s= o that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have i= ts set of very real issues but that's beyond the point.=C2=A0=

    Note that any decent flamewar wil= l be efficiently fueled by people hating medium. Is it outrageous for blog = posts to be behind a paywall? Maybe but it's even more outrageous to la= ck consistency, either by not knowing how to get around a paywall if you= 9;re into a hacker punk movement, or on the contrary by to not paying a sub= scription if you believe that surveillance capitalism, to reuse Zuboff'= s terms, should be eradicated.=C2=A0

    What likely seems an unnecessary sidenote tries to illustrat= e the point: for Justin it was easier to publish on medium, because as a bl= og publisher, you might not want to deal with hosting your own blog. But ma= ybe as a reader you'll find that annoying. Different audiences, differe= nt JTBD, different tradeoffs.=C2=A0

    =C2=A0

    Polyp= hormism is a tool that enables the end-developer to have minimal knowledge = of what it means to deal with a GNAP client library. You prepare the reques= t, send to the endpoint and you're good to go. Massively simpler than O= Auth2 or any similar protocol by the way (as anyone with teaching experienc= e on the subject might acknowledge). And=C2=A0 there's a lot more to be= done to make sure we indeed reduce the complexity for the end-developer an= d the end-user.=C2=A0

    = =C2=A0

    If we find a bett= er way to deal with that simplicity balance, I'm all in. But the argume= nts need to be way more convincing than just saying that it may be difficul= t to implement or validate.=C2=A0

    =C2=A0

    Cheers.=

    Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0=

    =C2=A0=

    Le ven. 23 oct. 2020 =C3=A0 22:35, Jus= tin Richer <jricher= @mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0

    =C2=A0

    On Oct 23= , 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    Justin

    =C2=A0=

    I did note that I was the one tha= t argued for instance_id being in the object. Since it is in the object in = the current draft, not including a pass by reference option would be prefer= able.=C2=A0

    =C2=A0

    As for concrete examples:<= /u>

    - version of client<= u>

    - version of OS

    - security attestation of OS / device

    - location of client devi= ce

    - network client is o= perating on

    =C2=A0

    These are all attributes of t= he client that an AS may require=C2=A0on the initial grant request, and in = future grant requests (which is when an instance_id) would be used.<= u>

    =C2=A0

    <= /div>

    =C2=A0

    This is where our interpretations differ= : I don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D i= n the same way that the key, display information, class identifiers, and ot= her items currently represented by an instance_id are attributes of the cli= ent instance. The attestation components don=E2=80=99t modify the instance = so much as present additional information on top of the client instance its= elf. This is why I argue that they ought to be handled in a separate object= , so you=E2=80=99d have something like this strawman:

    =C2=A0

    {

    =C2=A0<= u>

    =C2=A0 posture: {=

    =C2=A0 =C2=A0 software_version= : 1.2.3,

    =C2=A0 =C2=A0 o= s_version: 14.3.2

    =C2=A0= =C2=A0 device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 }

    =C2=A0 =C2=A0 l= ocation: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"

    =C2=A0

    }

    =C2=A0<= u>

    This is a more fundamental ques= tion about GNAP than whether the syntax uses polymorphism: this is about GN= AP being very explicit about the data model of its elements. OAuth 2=E2=80= =99s incredibly loose and broad model of what the term =E2=80=9Cclient=E2= =80=9D is referring to, exactly, is deeply problematic in practice. We=E2= =80=99re even seeing that in the OAuth 2.1 work with having to define a =E2= =80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t full= y capture the different aspects that are out there. I think we=E2=80=99re g= etting closer here in GNAP with explicit definition of =E2=80=9Cclient inst= ance=E2=80=9D, but we still need to be more precise about what exactly a cl= ient instance includes, and what it does not.

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    =C2=A0

    /Dick

    =C2=A0

    Error! Filename not specified.=E1=90=A7<= /u>

    =C2=A0

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrot= e:

    Dick,=

    =C2=A0

    As you=E2=80=99ll recall, I argued against includ= ing the client instance identifier inside of the object as a mutually-exclu= sive field precisely because of the principle violation that you are pointi= ng out here, and so it=E2=80=99s important to point out that the current te= xt is a compromise that needs to be examined in the wider experience of the= working group. I am on the side of removing the mutually-exclusive =E2=80= =9Cinstance_id=E2=80=9D option within an object, but this needs to be explo= red.

    =C2=A0

    The crux of my argument is that is e= xactly a case of pass-by-reference vs pass-by-value, and that runtime attes= tations are not part of the =E2=80=9Cclient instance=E2=80=9D value itself = but rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look carefully= at how these concepts fit within the model and where we would want to put = them. Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this stage. I= look forward to seeing examples of this kind of data and how it can fit in= to the protocol.

    =C2=A0<= u>

    =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct 23, 2020, at 3:07 PM, Dick = Hardt <dick.ha= rdt@gmail.com> wrote:

    = =C2=A0

    Hey Justin,

    =C2=A0

    <= div>

    As the draft has evolved, I question the continu= ed use of polymorphism. Note that I appreciate the elegance=C2=A0of using a= string for pass-by-reference, and an object for pass-by-value.

    =C2=A0

    =

    In the current draft, the=C2=A0

    =C2=A0

    Every time you = create or process a field it will mean only one thing, and there=E2=80=99s = only one field to look at to answer a question.=C2=A0

    =C2=A0

    is violated in 2.3.= 1.=C2=A0 Identifying the RC Instance

    =C2=A0

    = =C2=A0

    =C2=A0 =C2=A0instance_id =C2=A0An identifier s= tring that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2= =A0 The content and structure of this

    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.<= u>

    =C2=A0

    <= div>

    =C2=A0 =C2=A0"client": {=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0"inst= ance_id": "client-541-ab"

    =C2=A0 =C2=A0}

    =C2=A0

    =C2=A0 = =C2=A0If there are no additional fields to send, the RC MAY send the=

    =C2=A0 =C2=A0instance identifi= er as a direct reference value in lieu of the

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0object.

    =C2=A0

    =C2=A0 =C2=A0"client": "client-541-ab"<= /p>

    =C2=A0

    <= /div>

    The instance identifier can be sent two wa= ys. Polymorphism is a convenience for the client, but requires the server= =C2=A0to have two code=C2=A0paths for "instance_id".=C2=A0 We dis= cussed this in the design team, and I argued for having "instance_id&q= uot; in the "client" object=C2=A0so that any updates, such as new= devices assertions, could be in the "client" object. As noted ab= ove, while I appreciate the elegance of using a string (handle) to referenc= e a previously provided object, it complicates how to update an existing ob= ject while providing the reference.

    =C2=A0

    In yo= ur example of the "key" object below, setting "proof" t= o bearer would avoid the issue you describe:

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"= proof": "bearer"
    =C2=A0 =C2=A0 }
    }

    =

    =C2=A0

    In your example, when processing the "key" objec= t, code is having to check both the JSON type of the property, as well as c= heck the value of the "proof" property. In the example I provided= , only the value of "proof" needs to be checked. The "proof&= quot; property is acting as a type for the "key" object.

    =C2=A0

    Not being a Java programmer, I don't know how= this would work in a Java implementation, but node.js, the processing woul= d need to be done as above.

    =C2=A0

    On a related = note, there was significant negative feedback on handles and polymorphism i= n the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24= 855750=C2=A0

    =C2=A0<= u>

    /Dick

    <= /div>

    =C2=A0

    =C2=A0

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,<= u>

    =C2=A0

    Thanks for bringing this topic here =E2=80=94 I was ab= le to see the forum discussion that brought you here, and hopefully I can h= elp clear up what I mean with how polymorphism is used in the proposal. The= short version is that the goal is to=C2=A0avoid=C2=A0the kinds of a= mbiguity that make insecure protocols, and so in that goal we=E2=80=99re fu= lly aligned. I think that using polymorphism in very specific ways can help= that goal =E2=80=94 just as I agree that misusing it or applying it sloppi= ly can lead to ambiguous and insecure systems.

    =

    =C2=A0

    Some background: I built out the XYZ protocol (one of the predecessor= s to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way that= made any sense in the code. (My own open source implementation is at=C2=A0= https:= //github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up= to date with the GNAP spec). It was important to me that I be able to use = the system-wide configured parsers to implement this and not have to resort= to stepping through elements completely by hand. Java doesn=E2=80=99t make= it simple to get the hooks into the right places (especially with the Jack= son parser that I used), but it is definitely possible to create a determin= istic and strongly-typed parser and serializer for this kind of data struct= ure. Some of the rationale for using polymorphism is covered in the trailin= g appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-proto= col-00.html#name-json-structures-and-polymor), but it=E2=80=99s still g= ood to discuss this here as the working group decides which approaches to t= ake.=C2=A0

    =C2=A0=

    The driving reason for using p= olymorphism at the protocol level was to simplify the protocol and make it = :more: deterministic to create and process, not less. Every time you create= or process a field it will mean only one thing, and there=E2=80=99s only o= ne field to look at to answer a question. Without polymorphic field values,= you usually need to rely on mutual exclusivity of fields, which is prone t= o failure and requires additional error checking. Take for example the key = binding of access tokens. An access token could be bound to the RC=E2=80=99= s key used during the request, to a different key chosen by the AS, or it c= ould be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and obje= cts and express this set of mutually-exclusive options in a non-ambiguous w= ay. Without that, you=E2=80=99d need to have different fields for the optio= ns and include additional checks in your parser to make sure they weren=E2= =80=99t sent simultaneously, otherwise you could get hit with this potentia= l security vulnerability in an object:

    =C2=A0

    {= =C2=A0

    =C2=A0 =C2=A0 key= : {

    =C2=A0 =C2=A0 =C2=A0= proof: httpsig,

    =C2=A0 = =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0

    This would be an illegal object as per this alternate proposal, but the= n you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others in the same object. I=E2=80=99ve done this exercise with m= any other protocols and it=E2=80=99s both error prone and easy to ignore si= nce all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2= =80=99t check this. With the polymorphic approach to this same field, each = of these three mutually-exclusive states is written in a way that they cann= ot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible= and enforced by the syntax of JSON itself.

    =C2=A0

    {=C2=A0

    =C2=A0 = =C2=A0 key: {

    =C2=A0 =C2= =A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // beare= r token

    =C2=A0=

    {

    =C2=A0 =C2=A0 key: false

    }

    =C2=A0

    // bound to = the RC=E2=80=99s presented key

    =C2=A0

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0

    If someone sends a different type for this field, like an array or numb= er or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and would be a protocol level error.

    =C2=A0

    While it might sound like polymorphism means that any field could have an= y type or value, the opposite is true: each possible value is explicitly ty= ped, it=E2=80=99s just that there are potentially different types that expr= ess meaning for the field. This applies to all members of all objects (dict= ionaries) as well as all members of an array (list). Every time you process= a field value or other element, you look at the type and then the value to= determine what to do with that typed value.

    =C2=A0

    In your example below, each field within the dictionary would also need= to be typed, and each type would need to have a clear indication of its me= aning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON strin= g). The definition would further say what exactly the encoding of the strin= g would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D fie= ld there wouldn=E2=80=99t be any confusion on what the value was or how it = was represented, regardless of the input format. Seeing a number there mean= s exactly one interpretation and seeing a string means exactly one (differe= nt) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cm= odulus=E2=80=9D, since that=E2=80=99s the field that determines the type. A= n implementation would likely use an internal BigInteger type of object to = represent the field value after parsing, so the question is how to go from = the JSON value (which is typed) into the BigInteger value.You don=E2=80=99t= just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you a= pply it to all sub-fields of that object.=C2=A0

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up in the straw= man, because it=E2=80=99s interesting: A JSON encoder that encodes numbers = as strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of =E2= =80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON, an= d they shouldn=E2=80=99t be treated the same by a parser implementation whe= n mapping to a concrete object. It=E2=80=99s in this kind of automated gues= sing that this class of bugs occur, and that=E2=80=99s going to be the case= whether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic natu= re. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up i= ntroducing errors in more strict components downstream. This is something t= hat protocol designers need to be aware of and guard against in the design = of the protocol to reduce possible ambiguities. Within GNAP today, we gener= ally have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a refer= ence or other item).=C2=A0

    =C2=A0

    The design tea= m created some simple JSON Schemas for parts of the protocol during our dis= cussion, but we didn=E2=80=99t include them in the design document due to b= oth lack of time to keep it updated with the rapid changes to the protocol = during the design team discussion, and not knowing if there would be intere= st in such material. I personally think it would be helpful to include as a= n informative reference in the final document, but that=E2=80=99s something= for the working group to take up eventually.

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct 23= , 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarke= ts.com@dmarc.ietf.org> wrote:

    =C2=A0

    Hello= , everyone.

    =C2=A0

    For background: GNAP/TxAuth/X= YZ/Oauth3 came up on a discussion forum and when I made note about certain = concerns, I was requested to send my comments to this working group.=

    =C2=A0

    =

    In short, I believe that the use of polymorphic= JSON in the protocol invites subtle and confusing implementation problems.= I also searched through the WG archives, and noticed that similar concerns= were noted, briefly, in a thread in July.

    =C2=A0

    The problem with polymorphic values, as I see it, is that implementation= s will need to branch on the (inferred) type of a given field. This isn'= ;t quite as bad if the types are strictly different, but allows for subtle = bugs when the value in question is a dictionary. What makes this unappealin= g is that "subtle bugs" in security protocols have a habit of tur= ning into vulnerabilities.

    =C2=A0

    Let's say = we have these imaginary payloads, both possible and valid in the same proto= col step:

    =C2=A0<= u>

    # payload 1

    {

    =C2=A0 ...,

    = =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",=

    =C2=A0=C2=A0=C2=A0 "modulus"= ;: <BIGINT>

    =C2=A0= }

    }

    =C2=A0

    # payload 2

    {

    =C2=A0 ...,<= u>

    =C2=A0 "public_key": = {

    =C2=A0=C2=A0=C2=A0 &qu= ot;alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<encoded string>= "

    =C2=A0 }

    }

    =C2=A0

    In both cases, the type of "public_key" field is a dictionary= . In both cases, they even have the same keys. However, the values in the d= ictionaries are entirely different, and an implementation will have to bran= ch to at least two possible decoding mechanisms. To make things worse, some= JSON implementations may choose to encode non-dictionary values as strings= , so it is possible for an originator to transmit what they expect and beli= eve to be payload 1 format, but which the receiver will interpret to be in = payload 2 format. And if the encoded string contains only digits, it will e= ven parse correctly as a bignum.

    =C2=A0

    While th= e above is clearly a manufactured scenario, it nonetheless demonstrates the= potential for logic bugs with polymorphic JSON. With richer types and more= complex dictionaries, there will surely be more room for errors.=

    =C2=A0

    Ambiguity in protocols is always a source of imple= mentation complexity and interoperability snags, but in an AuthN/AuthZ prot= ocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supers= ede Oauth1/2, wouldn't it be in everyone's interest to keep impleme= ntation complexity and mistake potential to a minimum?

    =C2=A0

    Best regards,

    Mika

    =C2=A0<= u>

    --

    =

    Mika Bostr=C3=B6m<= /p>

    Smarkets

    --
    TXAuth mailing list<= br>TXAuth@ietf.org=
    https://www.ietf.org/mailman/listinfo/txauth

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth

    =E1=90=A7=

    =C2=A0<= /u>

    =C2=A0

    --
    TXAu= th mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    <= /blockquote>
    =



    --

    Mika Bostr=C3=B6m

    <= /div>

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https:/= /www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    = TXAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/txauth

    --00000000000072877e05b2e53cfe-- From nobody Fri Oct 30 09:42:33 2020 Return-Path: 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 25A2B3A101F for ; Fri, 30 Oct 2020 09:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 l8lpVdGv688g for ; Fri, 30 Oct 2020 09:42:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7AE3A0992 for ; Fri, 30 Oct 2020 09:42:22 -0700 (PDT) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09UGgJFN013042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Oct 2020 12:42:19 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9461F523-35D1-4E15-BC96-86CD9DF6BDA6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 30 Oct 2020 12:42:19 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , Andrii Deinega , =?utf-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List To: Fabien Imbault References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:42:31 -0000 --Apple-Mail=_9461F523-35D1-4E15-BC96-86CD9DF6BDA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for putting this list together, Fabien! And thanks Dick, I was = also going to point out CDDL as a potential option for a schema = description language. =E2=80=94 Justin > On Oct 30, 2020, at 11:41 AM, Fabien Imbault = wrote: >=20 > Thanks Dick, interesting ! I'll add that to my list. > Maybe we could liaise with the JSON schema team if it helps. >=20 > In the meantime, I'll focus on how to implement my json polymorphism = ;-) >=20 > On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt > wrote: > I exchanged some emails with the JSON Schema team last summer. They = are actively working on a revision to better server OpenAPI. >=20 > They felt stonewalled at the IETF and now question the value of = spending time in a standards body.=20 >=20 > Another schema option is JSON Type Definition [1], which is built on = CDDL (RFC 8610) [2], the CBOR type language. >=20 >=20 > [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition = > [2] https://tools.ietf.org/html/rfc8610 = >=20 >=20 > =E1=90=A7 >=20 > On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault = > wrote: > Hi Yaron,=20 >=20 > Thanks a lot for the feedback, I fixed the issue related to the = standardisation status (I guess there's some historic background that I = don't know ;-)). >=20 > Is JSON the only real possible format? Probably, at least for = compatibility with pretty much everything that exists. Only TJSON could = maybe be used as an alternative (and kind of removes the need for a = schema), with the downsides that you don't have so many existing = libraries and that the community seems much smaller: 2k stars for JSON = schema spec vs 65 for TJSON spec (and the expired website SSL = certificate doesn't help). =20 >=20 > The main problem I see is that for constrained cases, CBOR won't have = a schema in a foreseeable future (at least I'm not aware of any work on = that). I know it's not our main focus right now and might not even be = covered by the current WG, but still it might become an issue at some = point.=20 >=20 > Best, > Fabien =20 >=20 > On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer > wrote: > Hi Fabien, >=20 > =20 >=20 > One correction, JSON Schema (which I am personally advocating for, but = still) does not have an IETF spec. They claim on their web site that = they want it standardized, but in practice are not (yet?) moving in this = direction. Their Internet Draft is unmaintained. >=20 > =20 >=20 > At a higher level, I think your discussion conflates two things: the = representation of data on the wire (JSON or various mostly binary = encodings) and the data modeling language, a.k.a. schema. Personally I = think JSON is almost a must in our case, and if this is true, the = playing field is *much* more narrow. >=20 > =20 >=20 > A major strength of JSON which you don=E2=80=99t mention in your = comparison is the cryptographic ecosystem (JOSE): standard formats for = encryption, signature etc. >=20 > =20 >=20 > I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a = good fit for us, still a very interesting direction. >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > From: Fabien Imbault > > Date: Friday, October 30, 2020 at 14:53 > To: Andrii Deinega > > Cc: Mika Bostr=C3=B6m >, Justin Richer >, Yaron Sheffer >, GNAP Mailing List >, Dick Hardt > > Subject: Re: [GNAP] Feedback on polymorphism >=20 > =20 >=20 > Hi Justin,=20 >=20 > =20 >=20 > > Regarding your question, what else could we propose?=20 >=20 > =20 >=20 > I've started a review of possibilities at = https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md = = to be followed by actual code testing.=20 >=20 > =20 >=20 > Cheers, >=20 > Fabien >=20 > =20 >=20 > On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega = > wrote: >=20 > Hi Mika, Justin, and WG, >=20 > =20 >=20 > The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token = Exchange) has a JSON object as its value. This claim could be a part of = AT JWT or a token introspection response and has the same semantics in = both cases. The JSON object as its value may look like this >=20 > "act": > { > "sub":"admin@example.com " > } >=20 > or even be nested like in >=20 > "act": > { > "sub":"https://service16.example.com = ", > "act": > { > "sub":"https://service77.example.com = " > } > } >=20 > Personally, I find it to be a very expressive approach. Also, as far I = as know, several (oAuth2) client libraries have good support of things = like >=20 > "aud":"https://service1.example.com " = and "aud":["https://service1.example.com = ","https://service2.example.com = "] >=20 > in AT JWTs for a quite long time. >=20 > =20 >=20 > Regards, >=20 > Andrii >=20 > =20 >=20 > On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault = > wrote: >=20 > Hi Yaron, >=20 > =20 >=20 > We'll indeed have to check how make it as idiomatic as possible with = experts of each language (help welcome).=20 >=20 > =20 >=20 > Regarding the client, the variations are more limited but they do = exist. Here I believe it's much more problematic than on the server side = and there are at least a few actions we should take: >=20 > =20 >=20 > A) check in sec 7 if we really have a compelling reason for key and = proof variants. This is derived from larger discussions on key binding = as per the related note. There are quite a few open questions related to = this theme.=20 >=20 > =20 >=20 > B) there is also the choice between value/reference that may generate = complexity.=20 >=20 > =20 >=20 > C) More generally, as many feedbacks already have noticed, we need to = have a systematic review and reduce the set of available options in the = protocol.=20 >=20 > =20 >=20 > Unless we have a clear idea why runtime behavior requires mutability, = it might be useful to have a way to define the chosen variant before = hand, so that the expected behavior becomes deterministic on the client = side. There are various ways it could be done in practice.=20 >=20 > =20 >=20 > For sure several independant implementations would help, especially if = we make sure they can work together.=20 >=20 > =20 >=20 > Anyway all this open to improvement.=20 >=20 > =20 >=20 > Cheers=20 >=20 > Fabien=20 >=20 > =20 >=20 > Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = > a =C3=A9crit : >=20 > Hi Fabien, >=20 > =20 >=20 > At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is = far worse than the problem. The code in the article you cite is very = specific to the use case and IMHO quite ugly. So my preferred Go = implementation would be a combination of untyped structures (Go = interface{}) and run-time enforcement of JSON Schema. >=20 > =20 >=20 > Also, going back to our earlier discussion on this topic, I just read = Sec. 7 of gnap-00 and realized that the RC also needs to deal with = polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > From: TXAuth > on behalf of Fabien Imbault = > > Date: Wednesday, October 28, 2020 at 18:56 > To: Mika Bostr=C3=B6m > > Cc: GNAP Mailing List >, = Justin Richer >, Dick Hardt = > > Subject: Re: [GNAP] Feedback on polymorphism >=20 > =20 >=20 > Thanks for the great feedback. Your concern is very valid.=20 >=20 > =20 >=20 > My implementation is in rust, which makes life easier in that specific = case.=20 >=20 > =20 >=20 > So I'm not a golang specialist but I guess the transcription of json = strings/arrays into go structs would work around the lines described by = https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 = > When we have a more formalized json schema, I suggest we make a = library of json examples and some related code samples in mainstream = languages, to check it is feasible for everyone.=20 >=20 > =20 >=20 > Cheers, >=20 > Fabien >=20 > =20 >=20 > =20 >=20 > On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m = > wrote: >=20 > Hi everyone, >=20 > =20 >=20 > Looks like I stuck my finger in a hornets' nest. First off, apologies = for not chipping in earlier, but there was a lot of material to digest. = Also, warning: lots to read ahead. >=20 > =20 >=20 > I'm one of those people who end up making use of AuthN/AuthZ = functionality through a library. On top of that I can see myself being = roped in as a server (AS) implementation help. So I'm approaching this = from an outsider's perspective. Someone who expects to be exposed to the = eventual RFC and all the nitty-gritty details. My relatively terse = comment ended up at the top of the aforementioned HN thread, which = didn't necessarily help. Sorry about that. >=20 > =20 >=20 > Now, having read Justin's initial reply - and the rest of the thread - = I believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts. >=20 > =20 >=20 > But then the downside. I don't personally expect to be able to use the = reference implementation, being mostly a Python user myself. A fair = number of AS implementations will be written with languages such as Go, = Python, C#, Ruby, and JavaScript (thanks to node.js), and all of them = will have to deal with the polymorphism. =46rom what I've read over the = past couple of days, I understand that at least Go supports custom = unmarshalers from JSON to typed structs, at the cost of an indirection. = Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, = if the payload for a person in JSON was >=20 > =20 >=20 > { >=20 > "name": "", >=20 > "age": , >=20 > "country": "", >=20 > "city": "" >=20 > } >=20 > =20 >=20 > .. then the type definition would look like: >=20 > =20 >=20 > type Person struct { >=20 > Name string `json:"name" >=20 > Age int `json:"age"` >=20 > Country string `json:"country"` >=20 > City string `json:"city"` >=20 > } >=20 > =20 >=20 > When the (possibly complex) type of a given field is fixed, = unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed = value, there should be nothing special about that. But when the field = can instead be a union of more than one distinct types, things start to = get messy. There is no union type in the language at all, so the = following construct is not even possible: >=20 > =20 >=20 > type Entity struct { >=20 > Resources []string `json:"resources"` >=20 > Client union(Client, string) `json:"client"` >=20 > } >=20 > =20 >=20 > As I understand, the implicit expectation is that in the above case, = the unmarshaler detects that "client" is a string, and so expands it = from an opaque handle to the expected, populated type. Even after = thinking about the ramifications over the past few days I remain = confused, because I don't see how the commonly used annotations could = work. If the expectation is that protocol implementations should use = strong types, then the use of polymorphic JSON is very likely to make = things _more_ complicated for non-reference implementations. >=20 > =20 >=20 > Hence my concern. I'm afraid that the leaky abstraction, while making = the reference implementation more robust and straightforward, = contributes to making other implementations less robust. And this being = a security protocol, the potential for brittle and/or confused = implementations is terrifying. >=20 > =20 >=20 > I am a fan of reducing complexity, and from what I can see, for the = reference implementation the polymorphic approach actually does that. = But I'm afraid it does so at others' expense. Languages have their = individual constraints, idioms and best practices. If parsing a protocol = payload introduces low-level complexities and encourages to go against = common practices, that is an invitation for problems. I am aware that my = choice of words in the HN thread was likely to put people on defense, = and for that I apologise. But I do believe that the choice of = polymorphic JSON is going to make the life and use of other = implementations notably less boring than people in general would prefer. >=20 > =20 >=20 > Cheers, >=20 > Mika >=20 > =20 >=20 > On Mon, 26 Oct 2020 at 02:04, Fabien Imbault > wrote: >=20 > Hi Dick, >=20 > =20 >=20 > Well technically yes. Obviously the client can present any interface = it seems fit.=20 >=20 > =20 >=20 > Still there's the question of the common model we want to present to = the outside world and supported by the protocol itself (which client = libraries all build upon).=20 >=20 > =20 >=20 > But beneath the polyphormism question, the HN debate seems on the = surface a lot like the original xyz (polyphormism goes along with the = reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and = where the client design has more latitude). Just explained differently, = by outside people with different agendas.=20 >=20 > =20 >=20 > Which is a bit weird because many of the critics on HN (who criticize = polyphormism) also seem to really dislike OAuth in the first place (the = inconsistencies are partially due to a bunch of different people = commenting).=20 >=20 > =20 >=20 > Really to me there's no fundamental truth behind that question. It's a = matter of preference and priorities in the design. Whatever choices we = make, we'll have to be prepared to explain and justify them in the open, = even to some people that will dislike pretty much whatever we do = (because it's fun to look smart and critize without proposing = alternatives). And we owe these answers to people like Mika, who = genuinely try to make the best of it.=20 >=20 > =20 >=20 > Fabien=20 >=20 > =20 >=20 > Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt > a =C3=A9crit : >=20 > Hi Fabien >=20 > =20 >=20 > A library developer can provide whatever abstraction layer makes sense = for the library's target audience and language. >=20 > =20 >=20 > If the client library developer wants to use polymorphism in the = interface presented to the user's of the library, the library developer = can do that independent of polymorphism in the protocol, and vice versa=20= >=20 > =20 >=20 > =3D> polymorphism in the protocol has no impact on client library = developers >=20 > =20 >=20 > =20 >=20 > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = > wrote: >=20 > I'm just realizing your "least to most important" might actually say = the same as what I was trying to say. So I'm not even sure what we're = arguing against :-)=20 >=20 > =20 >=20 > In brief my point if it wasn't clear is that we should be crystal = clear on where we put the cursor of simplicity, because this can mean = different things for different people and different roles.=20 >=20 > And as we see on HN we need to better explain our design choices.=20 >=20 > =20 >=20 > =20 >=20 > Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault = > a =C3=A9crit = : >=20 > Hi Dick, >=20 > =20 >=20 > Independantly from the debate on polyphormism, I beg to differ on your = order preference.=20 >=20 > =20 >=20 > Your assumption is that AS devs matter the most, because they're doing = the important security implementation. But eating our own dogfood might = help a lot to change that view. Most security issues occur because users = of the spec are unable to deal with the complexity that is passed onto = them.=20 >=20 > =20 >=20 > 99% of the people that will actually use the output of the work are = application developers (client or RS) and their own users.=20 >=20 > =20 >=20 > Our intent as well as the protocol drive the usage. Client libraries = may help, but they're not a silver bullet, especially because GNAP = ultimately has no control about what people do there (for better or = worse). And everything we do here will help get to the better part.=20 >=20 > =20 >=20 > I'm not saying we don't intend to also care about AS developers = (beginning with ourselves) but it's a second order optimisation. And = since it's a tendancy we're leaning towards by default, I'm pretty sure = we won't forget that anyway.=20 >=20 > =20 >=20 > Fabien=20 >=20 > =20 >=20 > =20 >=20 > Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt > a =C3=A9crit : >=20 > I'm confused by your logic Fabien. >=20 > =20 >=20 > If a client library developer wants to expose polymorphism, they can = do that independent of what is in the protocol.=20 >=20 > =20 >=20 > I differ on who our stakeholders are.=20 >=20 > =20 >=20 > I think our stakeholders are in least to most important: >=20 > =20 >=20 > AS developer > RS developer > client developer > user > =20 >=20 > A client library developer can expose whatever interface they want to = simplify implementation. >=20 > =20 >=20 > I list the user so that we don't lose site of a critical role. >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > =20 >=20 > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = > wrote: >=20 > Hi there,=20 >=20 > =20 >=20 > Let me try to approach the issue under a different light. More like a = product manager would deal with feature selection to make it intuitive = for its users.=20 >=20 > =20 >=20 > For most people, riding a bike is far easier than using a unicycle. = Feels more stable. And yet it's way easier to design for a single wheel = than to build with 2. Because then you'll need a lot more accessories = (chain, chain ring, etc.). Even so producing a bike doesn't have to be a = brittle process, it can be industrialized.=20 >=20 > =20 >=20 > Back to the GNAP topic.=20 >=20 > Ultimately we should strive to make the spec as simple as can be. But = we need to ask: simple for whom? For the bike owner or for the bike = vendor?=20 >=20 > (short answer: the priority should be simplicity for spec users, not = spec implementers and even less spec designers).=20 >=20 > =20 >=20 > The initial question that is asked is very interesting: isn't the = design flawed if GNAP is using json polyphormism? Or if the AS needs to = handle the state of the request? Or if we must handle token revocation? = Or if we are looking for a global unique identifier? The argument stems = of the fact that is still arguably harder and more error prone to = implement. Fair enough.=20 >=20 > =20 >=20 > =46rom a spec implementer's perspective, it may well be more complex. = It mostly impacts the json library you'll end up using, plus a bit of = input/output decoration around it. Even golang provides utilities for = this, despite not exactly being made for this kind of purpose. >=20 > My practical experience implementing it is that it's not that big a = deal. I mean, I wished it could be simpler, but it's manageable and = there are other ways to reach levels of insurance that it does work as = intended (json schema, test cases to validate the implementation, etc.). = Arguably it is still easier from an implementation perspective than say, = json-ld, which is massively used in the SSI community.=20 >=20 > =20 >=20 > But ultimately who are we designing for? Are we striving to go easy on = the spec implementer? Or are we trying to make sure end-developers using = the client libraries won't shoot themselves in the foot? >=20 > =20 >=20 > The job to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation.=20 >=20 > In turn, this spec implementer will rely on cryptographic utility = libraries that deals internally with the complexity of their own domain, = so that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have its set = of very real issues but that's beyond the point.=20 >=20 > Note that any decent flamewar will be efficiently fueled by people = hating medium. Is it outrageous for blog posts to be behind a paywall? = Maybe but it's even more outrageous to lack consistency, either by not = knowing how to get around a paywall if you're into a hacker punk = movement, or on the contrary by to not paying a subscription if you = believe that surveillance capitalism, to reuse Zuboff's terms, should be = eradicated.=20 >=20 > What likely seems an unnecessary sidenote tries to illustrate the = point: for Justin it was easier to publish on medium, because as a blog = publisher, you might not want to deal with hosting your own blog. But = maybe as a reader you'll find that annoying. Different audiences, = different JTBD, different tradeoffs.=20 >=20 > =20 >=20 > Polyphormism is a tool that enables the end-developer to have minimal = knowledge of what it means to deal with a GNAP client library. You = prepare the request, send to the endpoint and you're good to go. = Massively simpler than OAuth2 or any similar protocol by the way (as = anyone with teaching experience on the subject might acknowledge). And = there's a lot more to be done to make sure we indeed reduce the = complexity for the end-developer and the end-user.=20 >=20 > =20 >=20 > If we find a better way to deal with that simplicity balance, I'm all = in. But the arguments need to be way more convincing than just saying = that it may be difficult to implement or validate.=20 >=20 > =20 >=20 > Cheers. >=20 > Fabien >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer > a =C3=A9crit : >=20 > =20 >=20 > =20 >=20 > On Oct 23, 2020, at 3:52 PM, Dick Hardt > wrote: >=20 > =20 >=20 > Justin >=20 > =20 >=20 > I did note that I was the one that argued for instance_id being in the = object. Since it is in the object in the current draft, not including a = pass by reference option would be preferable.=20 >=20 > =20 >=20 > As for concrete examples: >=20 > - version of client >=20 > - version of OS >=20 > - security attestation of OS / device >=20 > - location of client device >=20 > - network client is operating on >=20 > =20 >=20 > These are all attributes of the client that an AS may require on the = initial grant request, and in future grant requests (which is when an = instance_id) would be used. >=20 > =20 >=20 > =20 >=20 > This is where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman: >=20 > =20 >=20 > { >=20 > =20 >=20 > posture: { >=20 > software_version: 1.2.3, >=20 > os_version: 14.3.2 >=20 > device_attestation: { =E2=80=A6 some structure or signed blob? =E2=80= =A6 } >=20 > location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >=20 > }, >=20 > =20 >=20 > client: =E2=80=9Cclient-541-ab" >=20 > =20 >=20 > } >=20 > =20 >=20 > This is a more fundamental question about GNAP than whether the syntax = uses polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 12:42 PM Justin Richer > wrote: >=20 > Dick, >=20 > =20 >=20 > As you=E2=80=99ll recall, I argued against including the client = instance identifier inside of the object as a mutually-exclusive field = precisely because of the principle violation that you are pointing out = here, and so it=E2=80=99s important to point out that the current text = is a compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored. >=20 > =20 >=20 > The crux of my argument is that is exactly a case of pass-by-reference = vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Oct 23, 2020, at 3:07 PM, Dick Hardt > wrote: >=20 > =20 >=20 > Hey Justin, >=20 > =20 >=20 > As the draft has evolved, I question the continued use of = polymorphism. Note that I appreciate the elegance of using a string for = pass-by-reference, and an object for pass-by-value. >=20 > =20 >=20 > In the current draft, the=20 >=20 > =20 >=20 > Every time you create or process a field it will mean only one thing, = and there=E2=80=99s only one field to look at to answer a question.=20 >=20 > =20 >=20 > is violated in 2.3.1.=C2=A0 Identifying the RC Instance = > =20 >=20 > =20 >=20 > instance_id An identifier string that the AS can use to identify = the >=20 > particular instance of this RC. The content and structure of = this >=20 > identifier is opaque to the RC. >=20 > =20 >=20 > "client": { >=20 > "instance_id": "client-541-ab" >=20 > } >=20 > =20 >=20 > If there are no additional fields to send, the RC MAY send the >=20 > instance identifier as a direct reference value in lieu of the >=20 > object. >=20 > =20 >=20 > "client": "client-541-ab" >=20 > =20 >=20 > The instance identifier can be sent two ways. Polymorphism is a = convenience for the client, but requires the server to have two code = paths for "instance_id". We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference. >=20 > =20 >=20 > In your example of the "key" object below, setting "proof" to bearer = would avoid the issue you describe: >=20 > =20 >=20 > {=20 > "key": {=20 > "proof": "bearer"=20 > }=20 > } >=20 > =20 >=20 > In your example, when processing the "key" object, code is having to = check both the JSON type of the property, as well as check the value of = the "proof" property. In the example I provided, only the value of = "proof" needs to be checked. The "proof" property is acting as a type = for the "key" object. >=20 > =20 >=20 > Not being a Java programmer, I don't know how this would work in a = Java implementation, but node.js, the processing would need to be done = as above. >=20 > =20 >=20 > On a related note, there was significant negative feedback on handles = and polymorphism in the Hacker News article = https://news.ycombinator.com/item?id=3D24855750 = =20 >=20 > =20 >=20 > /Dick >=20 > =20 >=20 > =20 >=20 > On Fri, Oct 23, 2020 at 10:20 AM Justin Richer > wrote: >=20 > Hi Mika, >=20 > =20 >=20 > Thanks for bringing this topic here =E2=80=94 I was able to see the = forum discussion that brought you here, and hopefully I can help clear = up what I mean with how polymorphism is used in the proposal. The short = version is that the goal is to avoid the kinds of ambiguity that make = insecure protocols, and so in that goal we=E2=80=99re fully aligned. I = think that using polymorphism in very specific ways can help that goal = =E2=80=94 just as I agree that misusing it or applying it sloppily can = lead to ambiguous and insecure systems. >=20 > =20 >=20 > Some background: I built out the XYZ protocol (one of the predecessors = to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way = that made any sense in the code. (My own open source implementation is = at https://github.com/bspk/oauth.xyz-java = , but note that it=E2=80=99s not = yet up to date with the GNAP spec). It was important to me that I be = able to use the system-wide configured parsers to implement this and not = have to resort to stepping through elements completely by hand. Java = doesn=E2=80=99t make it simple to get the hooks into the right places = (especially with the Jackson parser that I used), but it is definitely = possible to create a deterministic and strongly-typed parser and = serializer for this kind of data structure. Some of the rationale for = using polymorphism is covered in the trailing appendix of the draft = document = (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#nam= e-json-structures-and-polymor = ), but it=E2=80=99s still good to discuss = this here as the working group decides which approaches to take.=20 >=20 > =20 >=20 > The driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object: >=20 > =20 >=20 > {=20 >=20 > key: { >=20 > proof: httpsig, >=20 > jwk: { =E2=80=A6 key value =E2=80=A6 } >=20 > }, >=20 > bearer_token: true, >=20 > bind_to_rc_key: true >=20 > } >=20 > =20 >=20 > This would be an illegal object as per this alternate proposal, but = then you=E2=80=99d have to check each field and make sure it wasn=E2=80=99= t put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself. >=20 > =20 >=20 > {=20 >=20 > key: { >=20 > proof: httpsig, >=20 > jwk: { =E2=80=A6 key value =E2=80=A6 } >=20 > } >=20 > } >=20 > =20 >=20 > // bearer token >=20 > =20 >=20 > { >=20 > key: false >=20 > } >=20 > =20 >=20 > // bound to the RC=E2=80=99s presented key >=20 > =20 >=20 > { >=20 > key: true >=20 > } >=20 > =20 >=20 > If someone sends a different type for this field, like an array or = number or a null, this doesn=E2=80=99t have a defined interpretation in = the protocol and would be a protocol level error. >=20 > =20 >=20 > While it might sound like polymorphism means that any field could have = any type or value, the opposite is true: each possible value is = explicitly typed, it=E2=80=99s just that there are potentially different = types that express meaning for the field. This applies to all members of = all objects (dictionaries) as well as all members of an array (list). = Every time you process a field value or other element, you look at the = type and then the value to determine what to do with that typed value. >=20 > =20 >=20 > In your example below, each field within the dictionary would also = need to be typed, and each type would need to have a clear indication of = its meaning. To take your strawman key format below, the =E2=80=9Cmodulus=E2= =80=9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON = string). The definition would further say what exactly the encoding of = the string would be. That means that when you read the =E2=80=9Cmodulus=E2= =80=9D field there wouldn=E2=80=99t be any confusion on what the value = was or how it was represented, regardless of the input format. Seeing a = number there means exactly one interpretation and seeing a string means = exactly one (different) interpretation =E2=80=94 but importantly, both = of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field = that determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object.=20 >=20 > =20 >=20 > So let=E2=80=99s dig into the specific bug you bring up in the = strawman, because it=E2=80=99s interesting: A JSON encoder that encodes = numbers as strings, and not numbers, is not compliant with the JSON = definitions of the field in question. For another example, the quoted = string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean = value true in JSON, and they shouldn=E2=80=99t be treated the same by a = parser implementation when mapping to a concrete object. It=E2=80=99s in = this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take advantage = of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where = a parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item).=20 >=20 > =20 >=20 > The design team created some simple JSON Schemas for parts of the = protocol during our discussion, but we didn=E2=80=99t include them in = the design document due to both lack of time to keep it updated with the = rapid changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = > wrote: >=20 > =20 >=20 > Hello, everyone. >=20 > =20 >=20 > For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum = and when I made note about certain concerns, I was requested to send my = comments to this working group. >=20 > =20 >=20 > In short, I believe that the use of polymorphic JSON in the protocol = invites subtle and confusing implementation problems. I also searched = through the WG archives, and noticed that similar concerns were noted, = briefly, in a thread in July. >=20 > =20 >=20 > The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given = field. This isn't quite as bad if the types are strictly different, but = allows for subtle bugs when the value in question is a dictionary. What = makes this unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities. >=20 > =20 >=20 > Let's say we have these imaginary payloads, both possible and valid in = the same protocol step: >=20 > =20 >=20 > # payload 1 >=20 > { >=20 > ..., >=20 > "public_key": { >=20 > "alg": "rsa", >=20 > "modulus": >=20 > } >=20 > } >=20 > =20 >=20 > # payload 2 >=20 > { >=20 > ..., >=20 > "public_key": { >=20 > "alg": "rsa", >=20 > "modulus": "" >=20 > } >=20 > } >=20 > =20 >=20 > In both cases, the type of "public_key" field is a dictionary. In both = cases, they even have the same keys. However, the values in the = dictionaries are entirely different, and an implementation will have to = branch to at least two possible decoding mechanisms. To make things = worse, some JSON implementations may choose to encode non-dictionary = values as strings, so it is possible for an originator to transmit what = they expect and believe to be payload 1 format, but which the receiver = will interpret to be in payload 2 format. And if the encoded string = contains only digits, it will even parse correctly as a bignum. >=20 > =20 >=20 > While the above is clearly a manufactured scenario, it nonetheless = demonstrates the potential for logic bugs with polymorphic JSON. With = richer types and more complex dictionaries, there will surely be more = room for errors. >=20 > =20 >=20 > Ambiguity in protocols is always a source of implementation complexity = and interoperability snags, but in an AuthN/AuthZ protocol it is worse: = it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, = wouldn't it be in everyone's interest to keep implementation complexity = and mistake potential to a minimum? >=20 > =20 >=20 > Best regards, >=20 > Mika >=20 > =20 >=20 > -- >=20 > Mika Bostr=C3=B6m >=20 > Smarkets >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > Error! Filename not specified.=E1=90=A7 >=20 > =20 >=20 > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > -- >=20 > Mika Bostr=C3=B6m >=20 > Smarkets >=20 > -- TXAuth mailing list TXAuth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_9461F523-35D1-4E15-BC96-86CD9DF6BDA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for putting this list together, Fabien! And thanks = Dick, I was also going to point out CDDL as a potential option for a = schema description language.

     =E2=80=94 Justin

    On Oct 30, 2020, at 11:41 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Thanks Dick, interesting ! I'll = add that to my list.
    Maybe we could liaise with the JSON = schema team if it helps.

    In the meantime, I'll focus on how to = implement my json polymorphism ;-)

    On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    I = exchanged some emails with the JSON Schema team last summer. They are = actively working on a revision to better server OpenAPI.

    They felt stonewalled at = the IETF and now question the value of spending time in a standards = body. 

    Another schema option is JSON Type = Definition [1], which is built on CDDL (RFC 8610) [2], the CBOR type = language.


    [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition<= /a>
    [2] https://tools.ietf.org/html/rfc8610


    3D""=E1=90=A7

    On Fri, Oct = 30, 2020 at 8:13 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron, 

    Thanks a lot for the feedback, I fixed the issue related to = the standardisation status (I guess there's some historic background = that I don't know ;-)).

    Is JSON the only real possible format? Probably, at least for = compatibility with pretty much everything that exists. Only TJSON could = maybe be used as an alternative (and kind of removes the need for a = schema), with the downsides that you don't have so many existing = libraries and that the community seems much smaller: 2k stars for JSON = schema spec vs 65 for TJSON spec (and the expired website SSL = certificate doesn't help).   

    The main problem I see is that for = constrained cases, CBOR won't have a schema in a foreseeable future (at = least I'm not aware of any work on that). I know it's not our main focus = right now and might not even be covered by the current WG, but still it = might become an issue at some point. 

    Best,
    Fabien  =  

    On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

     

    One correction, JSON Schema = (which I am personally advocating for, but still) does not have an IETF = spec. They claim on their web site that they want it standardized, but = in practice are not (yet?) moving in this direction. Their Internet = Draft is unmaintained.

     

    At a higher level, I think your discussion conflates = two things: the representation of data on the wire (JSON or various = mostly binary encodings) and the data modeling language, a.k.a. schema. = Personally I think JSON is almost a must in our case, and if this is = true, the playing field is *much* more narrow.

     

    A = major strength of JSON which you don=E2=80=99t mention in your = comparison is the cryptographic ecosystem (JOSE): standard formats for = encryption, signature etc.

     

    I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think = it=E2=80=99s a good fit for us, still a very interesting direction.

     

    Thanks,

             =        Yaron

     

    From: Fabien Imbault <fabien.imbault@gmail.com>
    Date: Friday, October 30, 2020 at 14:53
    To: Andrii Deinega <andrii.deinega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback on polymorphism

     

    Hi = Justin, 

     

    > = Regarding your question, what else could we propose? 

     

    I've = started a review of possibilities at https://github.com/fimbault/reasonably-polymorphic/blob/main/RE= ADME.md to be followed by actual code testing. 

     

    Cheers,

    Fabien

     

    On Thu, Oct 29, 2020 at 8:23 PM Andrii = Deinega <andrii.deinega@gmail.com> wrote:

    Hi Mika, Justin, and WG,

     

    The act (actor) claim introduced in RFC 8693 (OAuth = 2.0 Token Exchange) has a JSON object as its value. This claim could be = a part of AT JWT or a token introspection response and has the same = semantics in both cases. The JSON object as its value may look like = this

    "act":
    {
      "sub":"admin@example.com"
    }

    or even be nested like in

    "act":
    {
     "sub":"https://service16.example.com",
      =  "act":
       {
        =  "sub":"https://service77.example.com"
      =  }
    }

    Personally, I find = it to be a very expressive approach. Also, as far I as know, several = (oAuth2) client libraries have good support of things like

    "aud":"https://service1.example.com" and = "aud":["https://service1.example.com","https://service2.example.com"]

    in AT JWTs for a quite long time.

     

    Regards,

    Andrii

     

    On Wed, Oct 28, 2020 at 12:58 PM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Yaron,

     

    We'll = indeed have to check how make it as idiomatic as possible with experts = of each language (help welcome). 

     

    Regarding the client, the variations are more = limited but they do exist. Here I believe it's much more problematic = than on the server side and there are at least a few actions we should = take:

     

    A) check = in sec 7 if we really have a compelling reason for key and proof = variants. This is derived from larger discussions on key binding as per = the related note. There are quite a few open questions related to this = theme. 

     

    B) there = is also the choice between value/reference that may generate = complexity. 

     

    C) More = generally, as many feedbacks already have noticed, we need to have a = systematic review and reduce the set of available options in the = protocol. 

     

    Unless we have a clear = idea why runtime behavior requires mutability, it might be useful to = have a way to define the chosen variant before hand, so that the = expected behavior becomes deterministic on the client side. There are = various ways it could be done in practice. 

     

    For sure = several independant implementations would help, especially if we make = sure they can work together. 

     

    Anyway all this open to improvement. 

     

    Cheers 

    Fabien 

     

    Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer = <yaronf.ietf@gmail.com> a =C3=A9crit :

    Hi Fabien,

     

    At least in the case of Go, I = think the =E2=80=9Csolution=E2=80=9D is far worse than the problem. The = code in the article you cite is very specific to the use case and IMHO = quite ugly. So my preferred Go implementation would be a combination of = untyped structures (Go interface{}) and run-time enforcement of JSON = Schema.

     

    Also, going back to our earlier discussion on this = topic, I just read Sec. 7 of gnap-00 and realized that the RC also needs = to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only = the AS.

     

    Thanks,

             =        Yaron

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf = of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, October 28, 2020 at = 18:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback on polymorphism

     

    Thanks = for the great feedback. Your concern is very valid. 

     

    My = implementation is in rust, which makes life easier in that specific = case. 

     

    So I'm = not a golang specialist but I guess the transcription of json = strings/arrays into go structs would work around the lines described = by https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58= ed1

    When we have a more formalized json schema, I = suggest we make a library of json examples and some related code samples = in mainstream languages, to check it is feasible for everyone. 

     

    Cheers,

    Fabien

     

     

    On Wed, Oct 28, 2020 = at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote:

    Hi everyone,

     

    Looks like I stuck my finger in a hornets' nest. = First off, apologies for not chipping in earlier, but there was a lot of = material to digest. Also, warning: lots to read ahead.

     

    I'm one of those people who end up making use of = AuthN/AuthZ functionality through a library. On top of that I can see = myself being roped in as a server (AS) implementation help. So I'm = approaching this from an outsider's perspective. Someone who expects to = be exposed to the eventual RFC and all the nitty-gritty details. My = relatively terse comment ended up at the top of the aforementioned HN = thread, which didn't necessarily help. Sorry about that.

     

    Now, = having read Justin's initial reply - and the rest of the thread - I = believe I can see where the desire for polymorphism comes from. To be = clear: I am all for strict types inside an implementation, as it will = add helpful guard-rails to the state management code paths. However, I = see this as a case of leaky abstraction. If we take the existing = oauth.xyj-java code to be the reference implementation, the choice makes = logical sense: JSON is not expressive enough to serialise arbitrary = objects, so in order to avoid writing complex payload parser(s) the = internal implementation details now leak to the protocol itself. =46rom = a purely technical perspective, it's a cool trick. =46rom a distance it = even looks a bit like the result of protobuf decoding, but without the = generated code parts.

     

    But then = the downside. I don't personally expect to be able to use the reference = implementation, being mostly a Python user myself. A fair number of AS = implementations will be written with languages such as Go, Python, C#, = Ruby, and JavaScript (thanks to node.js), and all of them will have to = deal with the polymorphism. =46rom what I've read over the past couple = of days, I understand that at least Go supports custom unmarshalers from = JSON to typed structs, at the cost of an indirection. Normally when a Go = code processes JSON to a typed struct, the process is helped by field = annotations in the type definition itself. For example, if the payload = for a person in JSON was

     

    {

      "name": "<string>",

      = "age": <int>,

      "country": "<string>",

      "city": "<string>"

    }

     

    .. then = the type definition would look like:

     

    type Person struct {

      = Name string `json:"name"

      Age int `json:"age"`

      Country string `json:"country"`

      City string `json:"city"`

    }

     

    When the = (possibly complex) type of a given field is fixed, unmarshaling should = still be straightforward. I haven't verified, but since the annotation = only gives which field to look at for a given typed value, there should = be nothing special about that. But when the field can instead be a union = of more than one distinct types, things start to get messy. There is no = union type in the language at all, so the following construct is not = even possible:

     

    type = Entity struct {

      Resources []string = `json:"resources"`

      Client union(Client, string) = `json:"client"`

    }

     

    As I understand, the implicit expectation is that in = the above case, the unmarshaler detects that "client" is a string, and = so expands it from an opaque handle to the expected, populated type. = Even after thinking about the ramifications over the past few days I = remain confused, because I don't see how the commonly used annotations = could work. If the expectation is that protocol implementations should = use strong types, then the use of polymorphic JSON is very likely to = make things _more_ complicated for non-reference implementations.

     

    Hence my concern. I'm afraid that the leaky = abstraction, while making the reference implementation more robust and = straightforward, contributes to making other implementations less = robust. And this being a security protocol, the potential for brittle = and/or confused implementations is terrifying.

     

    I am a fan of reducing complexity, and from what I = can see, for the reference implementation the polymorphic approach = actually does that. But I'm afraid it does so at others' expense. = Languages have their individual constraints, idioms and best practices. = If parsing a protocol payload introduces low-level complexities and = encourages to go against common practices, that is an invitation for = problems. I am aware that my choice of words in the HN thread was likely = to put people on defense, and for that I apologise. But I do believe = that the choice of polymorphic JSON is going to make the life and use of = other implementations notably less boring than people in general would = prefer.

     

    Cheers,

    Mika

     

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Dick,

     

    Well = technically yes. Obviously the client can present any interface it seems = fit. 

     

    Still = there's the question of the common model we want to present to the = outside world and supported by the protocol itself (which client = libraries all build upon). 

     

    But beneath the polyphormism question, the HN debate = seems on the surface a lot like the original xyz (polyphormism goes = along with the reduced endpoint model) vs xauth (a bit closer to OAuth2 = in spirit, and where the client design has more latitude). Just = explained differently, by outside people with different agendas. 

     

    Which is = a bit weird because many of the critics on HN (who criticize = polyphormism) also seem to really dislike OAuth in the first place (the = inconsistencies are partially due to a bunch of different people = commenting). 

     

    Really = to me there's no fundamental truth behind that question. It's a matter = of preference and priorities in the design. Whatever choices we make, = we'll have to be prepared to explain and justify them in the open, even = to some people that will dislike pretty much whatever we do (because = it's fun to look smart and critize without proposing alternatives). And = we owe these answers to people like Mika, who genuinely try to make the = best of it. 

     

    Fabien 

     

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    Hi Fabien

     

    A = library developer can provide whatever abstraction layer makes sense for = the library's target audience and language.

     

    If the client library developer wants to use = polymorphism in the interface presented to the user's of the = library, the library developer can do that independent of polymorphism = in the protocol, and vice versa 

     

    =3D> polymorphism in the protocol has no impact = on client library developers

     

     

    Error! Filename not = specified.=E1=90=A7

     

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:

    I'm just = realizing your "least to most important" might actually say the same as = what I was trying to say. So I'm not even sure what we're arguing = against :-) 

     

    In brief = my point if it wasn't clear is that we should be crystal clear on where = we put the cursor of simplicity, because this can mean different things = for different people and different roles. 

    And as = we see on HN we need to better explain our design choices. 

     

     

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault = <fabien.imbault@gmail.com> a =C3=A9crit :

    Hi Dick,

     

    Independantly from the debate on polyphormism, I beg = to differ on your order preference. 

     

    Your assumption is that AS devs matter the = most, because= they're doing the important security implementation. But eating our own = dogfood might help a lot to change that view. Most security issues occur = because users of the spec are unable to deal with the complexity that is = passed onto them. 

     

    99% of the people that will actually use the output = of the work are application developers (client or RS) and their own = users. 

     

    Our intent as well as = the protocol drive the usage. Client libraries may help, but they're not = a silver bullet, especially because GNAP ultimately has no control about = what people do there (for better or worse). And everything we do here = will help get to the better part. 

     

    I'm not saying we don't intend to also care about AS = developers (beginning with ourselves) but it's a second order = optimisation. And since it's a tendancy we're leaning towards by = default, I'm pretty sure we won't forget that anyway. 

     

    Fabien 

     

     

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :

    I'm confused by = your logic Fabien.

     

    If a = client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol. 

     

    I differ on who our stakeholders are. 

     

    I think = our stakeholders are in least to most important:

     

    • AS developer
    • RS = developer
    • client developer
    • user

     

    A client = library developer can expose whatever interface they want to simplify = implementation.

     

    I list = the user so that we don't lose site of a critical role.

     

    /Dick

     

     

    Error! Filename not = specified.=E1=90=A7

     

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:

    Hi there, 

     

    Let me = try to approach the issue under a different light. More like a product = manager would deal with feature selection to make it intuitive for its = users. 

     

    For most people, riding a bike is far easier than = using a unicycle. Feels more stable. And yet it's way easier to design = for a single wheel than to build with 2. Because then you'll need a lot = more accessories (chain, chain ring, etc.). Even so producing a bike = doesn't have to be a brittle process, it can be industrialized. 

     

    Back to = the GNAP topic. 

    Ultimately we should = strive to make the spec as simple as can be. But we need to ask: simple = for whom? For the bike owner or for the bike vendor? 

    (short answer: the priority should be simplicity for spec = users, not spec implementers and even less spec = designers). 

     

    The = initial question that is asked is very interesting: isn't the design = flawed if GNAP is using json polyphormism? Or if the AS needs to handle = the state of the request? Or if we must handle token revocation? Or if = we are looking for a global unique identifier? The argument stems of the = fact that is still arguably harder and more error prone to implement. = Fair enough. 

     

    =46rom a = spec implementer's perspective, it may well be more complex. It mostly = impacts the json library you'll end up using, plus a bit of input/output = decoration around it. Even golang provides utilities for this, despite = not exactly being made for this kind of purpose.

    My = practical experience implementing it is that it's not that big a deal. I = mean, I wished it could be simpler, but it's manageable and there are = other ways to reach levels of insurance that it does work as intended = (json schema, test cases to validate the implementation, etc.). Arguably = it is still easier from an implementation perspective than say, json-ld, = which is massively used in the SSI community. 

     

    But ultimately who are we designing for? Are we = striving to go easy on the spec implementer? Or are we trying to make = sure end-developers using the client libraries won't shoot themselves in = the foot?

     

    The job = to be done (JTBD), from the end-developer's perspective, is to = efficiently ship an application. And provide authN/authZ capabilities = for end-users by relying on some well known implementation. 

    In turn, this spec implementer will rely on = cryptographic utility libraries that deals internally with the = complexity of their own domain, so that we don't have to. And here we = could launch another HN flame war that starts with the title "JWT sucks = because". Which does have its set of very real issues but that's beyond = the point. 

    Note that any decent flamewar will be = efficiently fueled by people hating medium. Is it outrageous for blog = posts to be behind a paywall? Maybe but it's even more outrageous to = lack consistency, either by not knowing how to get around a paywall if = you're into a hacker punk movement, or on the contrary by to not paying = a subscription if you believe that surveillance capitalism, to reuse = Zuboff's terms, should be eradicated. 

    What = likely seems an unnecessary sidenote tries to illustrate the point: for = Justin it was easier to publish on medium, because as a blog publisher, = you might not want to deal with hosting your own blog. But maybe as a = reader you'll find that annoying. Different audiences, different JTBD, = different tradeoffs. 

     

    Polyphormism is a tool that enables the = end-developer to have minimal knowledge of what it means to deal with a = GNAP client library. You prepare the request, send to the endpoint and = you're good to go. Massively simpler than OAuth2 or any similar protocol = by the way (as anyone with teaching experience on the subject might = acknowledge). And  there's a lot more to be done to make sure we = indeed reduce the complexity for the end-developer and the = end-user. 

     

    If we = find a better way to deal with that simplicity balance, I'm all in. But = the arguments need to be way more convincing than just saying that it = may be difficult to implement or validate. 

     

    Cheers.

    Fabien

     

     

     

     

     

    Le ven. 23 oct. 2020 = =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit :

     

     

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

     

    Justin

     

    I did = note that I was the one that argued for instance_id being in the object. = Since it is in the object in the current draft, not including a pass by = reference option would be preferable. 

     

    As for concrete examples:

    - = version of client

    - version of OS

    - = security attestation of OS / device

    - = location of client device

    - = network client is operating on

     

    These are all attributes of the client that an AS = may require on the initial grant request, and in future grant = requests (which is when an instance_id) would be used.

     

     

    This is = where our interpretations differ: I don=E2=80=99t see these as = =E2=80=9Cattributes of the client=E2=80=9D in the same way that the key, = display information, class identifiers, and other items currently = represented by an instance_id are attributes of the client instance. The = attestation components don=E2=80=99t modify the instance so much as = present additional information on top of the client instance itself. = This is why I argue that they ought to be handled in a separate object, = so you=E2=80=99d have something like this strawman:

     

    {

     

      = posture: {

        software_version: 1.2.3,

        os_version: 14.3.2

      =   device_attestation: { =E2=80=A6 some structure or signed blob? = =E2=80=A6 }

        location: { lat: =E2=80=A6= , lon: =E2=80=A6, alt: =E2=80=A6 }

      = },

     

      = client: =E2=80=9Cclient-541-ab"

     

    }

     

    This is = a more fundamental question about GNAP than whether the syntax uses = polymorphism: this is about GNAP being very explicit about the data = model of its elements. OAuth 2=E2=80=99s incredibly loose and broad = model of what the term =E2=80=9Cclient=E2=80=9D is referring to, = exactly, is deeply problematic in practice. We=E2=80=99re even seeing = that in the OAuth 2.1 work with having to define a =E2=80=9Ccredentialed = client=E2=80=9D, and even then that doesn=E2=80=99t fully capture the = different aspects that are out there. I think we=E2=80=99re getting = closer here in GNAP with explicit definition of =E2=80=9Cclient = instance=E2=80=9D, but we still need to be more precise about what = exactly a client instance includes, and what it does not.

     

     =E2=80= =94 Justin

     

     

    /Dick

     

    Error! Filename not = specified.=E1=90=A7

     

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer = <jricher@mit.edu> wrote:

    Dick,

     

    As = you=E2=80=99ll recall, I argued against including the client instance = identifier inside of the object as a mutually-exclusive field precisely = because of the principle violation that you are pointing out here, and = so it=E2=80=99s important to point out that the current text is a = compromise that needs to be examined in the wider experience of the = working group. I am on the side of removing the mutually-exclusive = =E2=80=9Cinstance_id=E2=80=9D option within an object, but this needs to = be explored.

     

    The crux = of my argument is that is exactly a case of pass-by-reference vs = pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient instance=E2=80=9D value itself but rather belong outside = of that object in a another part of the request. As stated in the = editorial notes in this section, we need to look carefully at how these = concepts fit within the model and where we would want to put them. = Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this = stage. I look forward to seeing examples of this kind of data and how it = can fit into the protocol.

     

     =E2=80=94 Justin

     

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

     

    Hey Justin,

     

    As the draft has evolved, I question the continued = use of polymorphism. Note that I appreciate the elegance of using a = string for pass-by-reference, and an object for pass-by-value.

     

    In the = current draft, the 

     

    Every time you create = or process a field it will mean only one thing, and there=E2=80=99s only = one field to look at to answer a question. 

     

    is = violated in 2.3.1.  Identifying the RC = Instance

     

     

      =  instance_id  An identifier string that the AS can use to = identify the

          particular = instance of this RC.  The content and structure of this

          identifier is opaque to the = RC.

     

      =  "client": {

          =  "instance_id": "client-541-ab"

      =  }

     

      =  If there are no additional fields to send, the RC MAY send the

       instance identifier as a direct = reference value in lieu of the

      =  object.

     

      =  "client": "client-541-ab"

     

    The = instance identifier can be sent two ways. Polymorphism is a convenience = for the client, but requires the server to have two code paths = for "instance_id".  We discussed this in the design team, and I = argued for having "instance_id" in the "client" object so that any = updates, such as new devices assertions, could be in the "client" = object. As noted above, while I appreciate the elegance of using a = string (handle) to reference a previously provided object, it = complicates how to update an existing object while providing the = reference.

     

    In your = example of the "key" object below, setting "proof" to bearer would avoid = the issue you describe:

     

    {  "key": { 
        =  "proof": "bearer"
        }
    }

     

    In your = example, when processing the "key" object, code is having to check both = the JSON type of the property, as well as check the value of the "proof" = property. In the example I provided, only the value of "proof" needs to = be checked. The "proof" property is acting as a type for the "key" = object.

     

    Not = being a Java programmer, I don't know how this would work in a Java = implementation, but node.js, the processing would need to be done as = above.

     

    On a = related note, there was significant negative feedback on handles and = polymorphism in the Hacker News article https://news.ycombinator.com/item?id=3D24855750 

     

    /Dick

     

     

    On Fri, Oct 23, 2020 at 10:20 AM = Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

     

    Thanks = for bringing this topic here =E2=80=94 I was able to see the forum = discussion that brought you here, and hopefully I can help clear up what = I mean with how polymorphism is used in the proposal. The short version = is that the goal is to avoid the kinds of = ambiguity that make insecure protocols, and so in that goal we=E2=80=99re = fully aligned. I think that using polymorphism in very specific ways can = help that goal =E2=80=94 just as I agree that misusing it or applying it = sloppily can lead to ambiguous and insecure systems.

     

    Some background: I built out the XYZ protocol (one = of the predecessors to the initial GNAP Draft) in Java using strongly = typed parsers and Java objects specifically to prove to myself that it = could be done in a way that made any sense in the code. (My own open = source implementation is at https://github.com/bspk/oauth.xyz-java, but note that = it=E2=80=99s not yet up to date with the GNAP spec). It was important to = me that I be able to use the system-wide configured parsers to implement = this and not have to resort to stepping through elements completely by = hand. Java doesn=E2=80=99t make it simple to get the hooks into the = right places (especially with the Jackson parser that I used), but it is = definitely possible to create a deterministic and strongly-typed parser = and serializer for this kind of data structure. Some of the rationale = for using polymorphism is covered in the trailing appendix of the draft = document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 0.html#name-json-structures-and-polymor), but it=E2=80=99s still = good to discuss this here as the working group decides which approaches = to take. 

     

    The = driving reason for using polymorphism at the protocol level was to = simplify the protocol and make it :more: deterministic to create and = process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer = a question. Without polymorphic field values, you usually need to rely = on mutual exclusivity of fields, which is prone to failure and requires = additional error checking. Take for example the key binding of access = tokens. An access token could be bound to the RC=E2=80=99s key used = during the request, to a different key chosen by the AS, or it could be = a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80=9D = field polymorphic, we can define it in terms of boolean values and = objects and express this set of mutually-exclusive options in a = non-ambiguous way. Without that, you=E2=80=99d need to have different = fields for the options and include additional checks in your parser to = make sure they weren=E2=80=99t sent simultaneously, otherwise you could = get hit with this potential security vulnerability in an object:

     

    { 

        key: {

      =     proof: httpsig,

      =     jwk: { =E2=80=A6 key value =E2=80=A6 }

      =   },

        bearer_token: true,

      =   bind_to_rc_key: true

    }

     

    This = would be an illegal object as per this alternate proposal, but then = you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t = put next to others in the same object. I=E2=80=99ve done this exercise = with many other protocols and it=E2=80=99s both error prone and easy to = ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass code = that doesn=E2=80=99t check this. With the polymorphic approach to this = same field, each of these three mutually-exclusive states is written in = a way that they cannot be sent together. It=E2=80=99s not just illegal, = it=E2=80=99s impossible and enforced by the syntax of JSON itself.

     

    { 

      =   key: {

          proof: httpsig,

          jwk: { =E2=80=A6 key value =E2=80= =A6 }

        }

    }

     

    // = bearer token

     

    {

        key: false

    }

     

    // bound = to the RC=E2=80=99s presented key

     

    {

        key: true

    }

     

    If = someone sends a different type for this field, like an array or number = or a null, this doesn=E2=80=99t have a defined interpretation in the = protocol and would be a protocol level error.

     

    While it might sound like polymorphism means that = any field could have any type or value, the opposite is true: each = possible value is explicitly typed, it=E2=80=99s just that there are = potentially different types that express meaning for the field. This = applies to all members of all objects (dictionaries) as well as all = members of an array (list). Every time you process a field value or = other element, you look at the type and then the value to determine what = to do with that typed value.

     

    In your example below, each field within the = dictionary would also need to be typed, and each type would need to have = a clear indication of its meaning. To take your strawman key format = below, the =E2=80=9Cmodulus=E2=80=9D field could be defined = polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or = an =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition = would further say what exactly the encoding of the string would be. That = means that when you read the =E2=80=9Cmodulus=E2=80=9D field there = wouldn=E2=80=99t be any confusion on what the value was or how it was = represented, regardless of the input format. Seeing a number there means = exactly one interpretation and seeing a string means exactly one = (different) interpretation =E2=80=94 but importantly, both of them are a = =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that = determines the type. An implementation would likely use an internal = BigInteger type of object to represent the field value after parsing, so = the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the = =E2=80=9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of = that object. 

     

    So = let=E2=80=99s dig into the specific bug you bring up in the strawman, = because it=E2=80=99s interesting: A JSON encoder that encodes numbers as = strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of = =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in = JSON, and they shouldn=E2=80=99t be treated the same by a parser = implementation when mapping to a concrete object. It=E2=80=99s in this = kind of automated guessing that this class of bugs occur, and that=E2=80=99= s going to be the case whether or not you take  advantage of = JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a = parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in = doing this kind of mapping, but ended up introducing errors in more = strict components downstream. This is something that protocol designers = need to be aware of and guard against in the design of the protocol to = reduce possible ambiguities. Within GNAP today, we generally have things = that branch whether they=E2=80=99re an object (for a rich description of = something) or some non-structured special value (for a reference or = other item). 

     

    The = design team created some simple JSON Schemas for parts of the protocol = during our discussion, but we didn=E2=80=99t include them in the design = document due to both lack of time to keep it updated with the rapid = changes to the protocol during the design team discussion, and not = knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final = document, but that=E2=80=99s something for the working group to take up = eventually.

     

     =E2=80= =94 Justin

     

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m = <mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:

     

    Hello, everyone.

     

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a = discussion forum and when I made note about certain concerns, I was = requested to send my comments to this working group.

     

    In short, I believe that the use of polymorphic JSON = in the protocol invites subtle and confusing implementation problems. I = also searched through the WG archives, and noticed that similar concerns = were noted, briefly, in a thread in July.

     

    The problem with polymorphic values, as I see it, is = that implementations will need to branch on the (inferred) type of a = given field. This isn't quite as bad if the types are strictly = different, but allows for subtle bugs when the value in question is a = dictionary. What makes this unappealing is that "subtle bugs" in = security protocols have a habit of turning into vulnerabilities.

     

    Let's = say we have these imaginary payloads, both possible and valid in the = same protocol step:

     

    # = payload 1

    {

      ...,

      = "public_key": {

        "alg": "rsa",

        "modulus": <BIGINT>

      }

    }

     

    # = payload 2

    {

      ...,

      = "public_key": {

        "alg": "rsa",

        "modulus": "<encoded = string>"

      }

    }

     

    In both = cases, the type of "public_key" field is a dictionary. In both cases, = they even have the same keys. However, the values in the dictionaries = are entirely different, and an implementation will have to branch to at = least two possible decoding mechanisms. To make things worse, some JSON = implementations may choose to encode non-dictionary values as strings, = so it is possible for an originator to transmit what they expect and = believe to be payload 1 format, but which the receiver will interpret to = be in payload 2 format. And if the encoded string contains only digits, = it will even parse correctly as a bignum.

     

    While the above is clearly a manufactured scenario, = it nonetheless demonstrates the potential for logic bugs with = polymorphic JSON. With richer types and more complex dictionaries, there = will surely be more room for errors.

     

    Ambiguity in protocols is always a source of = implementation complexity and interoperability snags, but in an = AuthN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is = intended to supersede Oauth1/2, wouldn't it be in everyone's interest to = keep implementation complexity and mistake potential to a minimum?

     

    Best = regards,

    Mika

     

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

     

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    Error! Filename not = specified.=E1=90=A7

     

     

    --
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth



    --

    Mika Bostr=C3=B6m

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth


    = --Apple-Mail=_9461F523-35D1-4E15-BC96-86CD9DF6BDA6-- From nobody Fri Oct 30 09:50:33 2020 Return-Path: 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 E2CF33A102D for ; Fri, 30 Oct 2020 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: 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 RpqLb6k9ih4t for ; Fri, 30 Oct 2020 09:50:25 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 0EE143A1031 for ; Fri, 30 Oct 2020 09:50:25 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id k1so7040495ilc.10 for ; Fri, 30 Oct 2020 09:50:25 -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=yRdYjaYrRMivm+z+rhNlvTKzRB7bqztq4f9gkU7t3iE=; b=SD8ecr6/KgLThDMqoS07ZugxzT13yuJvqU9pndTJy/IZotFY1VOPZDnGEA2m+WimvZ 7t55bkdMZ0fKbFpG8fI+nwyhbED7Nz54pVa+zpN6J8JoOXk3Ab6bcWnSMui0pJFCZZJG jzU+8JztTOTpMGKrsKu6Wdk4UwzCoVWzdlaK1fii8DvuSsQBtNPunpRu3TzR/27DKGHS OXlRaDj1qSoDuqKFk5Nj82ba7BLx92R44Ra+w6t8ZXLE78j5B0kldU8b/v6WmJEEKMF/ 64Xh7S0Y4urmsim1QUtHVlPHTza5Ud8i3BmsK2YVEyC2CWTWExWKpPmiXOz+4/7swo3z OYmg== 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=yRdYjaYrRMivm+z+rhNlvTKzRB7bqztq4f9gkU7t3iE=; b=KTr5PwfmKR/GTXTiLCLkVHU+nrKJFlh8NOzyd6yqtjRh1xL+4RhbUSrQbVZ6vG3oJP hMnGlL6EUn43cePc9XRdSM59/WO96gba4yMBKbMzOR9KWEhNsJS288fyA1mlxy+px+mf cnRaUUE+xus6l+EaYUCW1caOj82d6P948iRJmiRAx1TmGGM/PhIyK+u7P/1eWSmNseyW HjokINHx/LSJ+gPTG+2CFSanokN7Kwi6mZZGh5WrNEiaOcvYJ7tgIgUFDkP1mJ+vz81a 9sT5xb/mz9st/5h64Ncu8IbvNzP61HDqlpDO8YhnSaKeLUkF23eR5cb0nl9ZDWR0S4cX w3rQ== X-Gm-Message-State: AOAM533UJbm6yTC9pT3DUpiBnnyNXyp9mhdxPTQ5FMHAPUDwFcqZ56mI tTuT4FYY9ljC61I0S8gxQyWSFj3AtpT6fqlVxE4= X-Google-Smtp-Source: ABdhPJztPgaUs1w/ZDwKLruPvLX/eGZ+uxJnmfZlQRh3toCvr/fjex5w/e21XZl7vmIjScw+p0ybD/WDXIStsZmyKg8= X-Received: by 2002:a92:9106:: with SMTP id t6mr2605163ild.178.1604076624100; Fri, 30 Oct 2020 09:50:24 -0700 (PDT) MIME-Version: 1.0 References: <30AE73A0-6A18-454A-AA20-0ECE5AEBD49A@mit.edu> <14F2A48D-F6CC-4DF4-9F5F-D3A01776907A@mit.edu> <7EDAE04E-7747-48BC-9318-68911C3291C1@gmail.com> In-Reply-To: From: Fabien Imbault Date: Fri, 30 Oct 2020 17:50:09 +0100 Message-ID: To: Justin Richer Cc: Dick Hardt , Yaron Sheffer , Andrii Deinega , =?UTF-8?Q?Mika_Bostr=C3=B6m?= , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005f40b705b2e631b5" Archived-At: Subject: Re: [GNAP] Feedback on polymorphism X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:50:32 -0000 --0000000000005f40b705b2e631b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I didn't know about CDDL before Dick mentioned it and just made a first test with existing libraries, that's awesome. Appendix E in the spec highlights a few caveats between json/cbor support but no big deal. Fabien On Fri, Oct 30, 2020 at 5:42 PM Justin Richer wrote: > Thanks for putting this list together, Fabien! And thanks Dick, I was als= o > going to point out CDDL as a potential option for a schema description > language. > > =E2=80=94 Justin > > On Oct 30, 2020, at 11:41 AM, Fabien Imbault > wrote: > > Thanks Dick, interesting ! I'll add that to my list. > Maybe we could liaise with the JSON schema team if it helps. > > In the meantime, I'll focus on how to implement my json polymorphism ;-) > > On Fri, Oct 30, 2020 at 4:21 PM Dick Hardt wrote: > >> I exchanged some emails with the JSON Schema team last summer. They are >> actively working on a revision to better server OpenAPI. >> >> They felt stonewalled at the IETF and now question the value of spending >> time in a standards body. >> >> Another schema option is JSON Type Definition [1], which is built on CDD= L >> (RFC 8610) [2], the CBOR type language. >> >> >> [1] https://tools.ietf.org/html/draft-ucarion-json-type-definition >> [2] https://tools.ietf.org/html/rfc8610 >> >> >> =E1=90=A7 >> >> On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault >> wrote: >> >>> Hi Yaron, >>> >>> Thanks a lot for the feedback, I fixed the issue related to the >>> standardisation status (I guess there's some historic background that I >>> don't know ;-)). >>> >>> Is JSON the only real possible format? Probably, at least for >>> compatibility with pretty much everything that exists. Only TJSON could >>> maybe be used as an alternative (and kind of removes the need for a >>> schema), with the downsides that you don't have so many existing librar= ies >>> and that the community seems much smaller: 2k stars for JSON schema spe= c vs >>> 65 for TJSON spec (and the expired website SSL certificate doesn't help= ). >>> >>> The main problem I see is that for constrained cases, CBOR won't have a >>> schema in a foreseeable future (at least I'm not aware of any work on >>> that). I know it's not our main focus right now and might not even be >>> covered by the current WG, but still it might become an issue at some >>> point. >>> >>> Best, >>> Fabien >>> >>> On Fri, Oct 30, 2020 at 3:19 PM Yaron Sheffer >>> wrote: >>> >>>> Hi Fabien, >>>> >>>> >>>> >>>> One correction, JSON Schema (which I am personally advocating for, but >>>> still) does not have an IETF spec. They claim on their web site that t= hey >>>> want it standardized, but in practice are not (yet?) moving in this >>>> direction. Their Internet Draft is unmaintained. >>>> >>>> >>>> >>>> At a higher level, I think your discussion conflates two things: the >>>> representation of data on the wire (JSON or various mostly binary >>>> encodings) and the data modeling language, a.k.a. schema. Personally I >>>> think JSON is almost a must in our case, and if this is true, the play= ing >>>> field is **much** more narrow. >>>> >>>> >>>> >>>> A major strength of JSON which you don=E2=80=99t mention in your compa= rison is >>>> the cryptographic ecosystem (JOSE): standard formats for encryption, >>>> signature etc. >>>> >>>> >>>> >>>> I wasn=E2=80=99t aware of Ion. I don=E2=80=99t think it=E2=80=99s a go= od fit for us, still a >>>> very interesting direction. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> >>>> >>>> *From: *Fabien Imbault >>>> *Date: *Friday, October 30, 2020 at 14:53 >>>> *To: *Andrii Deinega >>>> *Cc: *Mika Bostr=C3=B6m , Justin Richer < >>>> jricher@mit.edu>, Yaron Sheffer , GNAP Mailing >>>> List , Dick Hardt >>>> *Subject: *Re: [GNAP] Feedback on polymorphism >>>> >>>> >>>> >>>> Hi Justin, >>>> >>>> >>>> >>>> > Regarding your question, what else could we propose? >>>> >>>> >>>> >>>> I've started a review of possibilities at >>>> https://github.com/fimbault/reasonably-polymorphic/blob/main/README.md >>>> to be followed by actual code testing. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Fabien >>>> >>>> >>>> >>>> On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega < >>>> andrii.deinega@gmail.com> wrote: >>>> >>>> Hi Mika, Justin, and WG, >>>> >>>> >>>> >>>> The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange= ) >>>> has a JSON object as its value. This claim could be a part of AT JWT o= r a >>>> token introspection response and has the same semantics in both cases.= The >>>> JSON object as its value may look like this >>>> >>>> "act": >>>> { >>>> "sub":"admin@example.com" >>>> } >>>> >>>> or even be nested like in >>>> >>>> "act": >>>> { >>>> "sub":"https://service16.example.com", >>>> "act": >>>> { >>>> "sub":"https://service77.example.com" >>>> } >>>> } >>>> >>>> Personally, I find it to be a very expressive approach. Also, as far I >>>> as know, several (oAuth2) client libraries have good support of things= like >>>> >>>> "aud":"https://service1.example.com" and "aud":[" >>>> https://service1.example.com","https://service2.example.com"] >>>> >>>> in AT JWTs for a quite long time. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Andrii >>>> >>>> >>>> >>>> On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>> Hi Yaron, >>>> >>>> >>>> >>>> We'll indeed have to check how make it as idiomatic as possible with >>>> experts of each language (help welcome). >>>> >>>> >>>> >>>> Regarding the client, the variations are more limited but they do >>>> exist. Here I believe it's much more problematic than on the server si= de >>>> and there are at least a few actions we should take: >>>> >>>> >>>> >>>> A) check in sec 7 if we really have a compelling reason for key and >>>> proof variants. This is derived from larger discussions on key binding= as >>>> per the related note. There are quite a few open questions related to = this >>>> theme. >>>> >>>> >>>> >>>> B) there is also the choice between value/reference that may generate >>>> complexity. >>>> >>>> >>>> >>>> C) More generally, as many feedbacks already have noticed, we need to >>>> have a systematic review and reduce the set of available options in th= e >>>> protocol. >>>> >>>> >>>> >>>> Unless we have a clear idea why runtime behavior requires mutability, >>>> it might be useful to have a way to define the chosen variant before h= and, >>>> so that the expected behavior becomes deterministic on the client side= . >>>> There are various ways it could be done in practice. >>>> >>>> >>>> >>>> For sure several independant implementations would help, especially if >>>> we make sure they can work together. >>>> >>>> >>>> >>>> Anyway all this open to improvement. >>>> >>>> >>>> >>>> Cheers >>>> >>>> Fabien >>>> >>>> >>>> >>>> Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer a >>>> =C3=A9crit : >>>> >>>> Hi Fabien, >>>> >>>> >>>> >>>> At least in the case of Go, I think the =E2=80=9Csolution=E2=80=9D is = far worse than >>>> the problem. The code in the article you cite is very specific to the = use >>>> case and IMHO quite ugly. So my preferred Go implementation would be a >>>> combination of untyped structures (Go interface{}) and run-time enforc= ement >>>> of JSON Schema. >>>> >>>> >>>> >>>> Also, going back to our earlier discussion on this topic, I just read >>>> Sec. 7 of gnap-00 and realized that the RC also needs to deal with >>>> polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> >>>> >>>> *From: *TXAuth on behalf of Fabien Imbault < >>>> fabien.imbault@gmail.com> >>>> *Date: *Wednesday, October 28, 2020 at 18:56 >>>> *To: *Mika Bostr=C3=B6m >>>> *Cc: *GNAP Mailing List , Justin Richer < >>>> jricher@mit.edu>, Dick Hardt >>>> *Subject: *Re: [GNAP] Feedback on polymorphism >>>> >>>> >>>> >>>> Thanks for the great feedback. Your concern is very valid. >>>> >>>> >>>> >>>> My implementation is in rust, which makes life easier in that specific >>>> case. >>>> >>>> >>>> >>>> So I'm not a golang specialist but I guess the transcription of json >>>> strings/arrays into go structs would work around the lines described b= y >>>> https://medium.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1 >>>> >>>> When we have a more formalized json schema, I suggest we make a librar= y >>>> of json examples and some related code samples in mainstream languages= , to >>>> check it is feasible for everyone. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Fabien >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m >>>> wrote: >>>> >>>> Hi everyone, >>>> >>>> >>>> >>>> Looks like I stuck my finger in a hornets' nest. First off, apologies >>>> for not chipping in earlier, but there was a lot of material to digest= . >>>> Also, warning: lots to read ahead. >>>> >>>> >>>> >>>> I'm one of those people who end up making use of AuthN/AuthZ >>>> functionality through a library. On top of that I can see myself being >>>> roped in as a server (AS) implementation help. So I'm approaching this= from >>>> an outsider's perspective. Someone who expects to be exposed to the >>>> eventual RFC and all the nitty-gritty details. My relatively terse com= ment >>>> ended up at the top of the aforementioned HN thread, which didn't >>>> necessarily help. Sorry about that. >>>> >>>> >>>> >>>> Now, having read Justin's initial reply - and the rest of the thread - >>>> I believe I can see where the desire for polymorphism comes from. To b= e >>>> clear: I am all for strict types inside an implementation, as it will = add >>>> helpful guard-rails to the state management code paths. However, I see= this >>>> as a case of leaky abstraction. If we take the existing oauth.xyj-java= code >>>> to be the reference implementation, the choice makes logical sense: JS= ON is >>>> not expressive enough to serialise arbitrary objects, so in order to a= void >>>> writing complex payload parser(s) the internal implementation details = now >>>> leak to the protocol itself. From a purely technical perspective, it's= a >>>> cool trick. From a distance it even looks a bit like the result of pro= tobuf >>>> decoding, but without the generated code parts. >>>> >>>> >>>> >>>> But then the downside. I don't personally expect to be able to use the >>>> reference implementation, being mostly a Python user myself. A fair nu= mber >>>> of AS implementations will be written with languages such as Go, Pytho= n, >>>> C#, Ruby, and JavaScript (thanks to node.js), and all of them will hav= e to >>>> deal with the polymorphism. From what I've read over the past couple o= f >>>> days, I understand that at least Go supports custom unmarshalers from = JSON >>>> to typed structs, at the cost of an indirection. Normally when a Go co= de >>>> processes JSON to a typed struct, the process is helped by field >>>> annotations in the type definition itself. For example, if the payload= for >>>> a person in JSON was >>>> >>>> >>>> >>>> { >>>> >>>> "name": "", >>>> >>>> "age": , >>>> >>>> "country": "", >>>> >>>> "city": "" >>>> >>>> } >>>> >>>> >>>> >>>> .. then the type definition would look like: >>>> >>>> >>>> >>>> type Person struct { >>>> >>>> Name string `json:"name" >>>> >>>> Age int `json:"age"` >>>> >>>> Country string `json:"country"` >>>> >>>> City string `json:"city"` >>>> >>>> } >>>> >>>> >>>> >>>> When the (possibly complex) type of a given field is fixed, >>>> unmarshaling should still be straightforward. I haven't verified, but = since >>>> the annotation only gives which field to look at for a given typed val= ue, >>>> there should be nothing special about that. But when the field can ins= tead >>>> be a union of more than one distinct types, things start to get messy. >>>> There is no union type in the language at all, so the following constr= uct >>>> is not even possible: >>>> >>>> >>>> >>>> type Entity struct { >>>> >>>> Resources []string `json:"resources"` >>>> >>>> Client union(Client, string) `json:"client"` >>>> >>>> } >>>> >>>> >>>> >>>> As I understand, the implicit expectation is that in the above case, >>>> the unmarshaler detects that "client" is a string, and so expands it f= rom >>>> an opaque handle to the expected, populated type. Even after thinking = about >>>> the ramifications over the past few days I remain confused, because I = don't >>>> see how the commonly used annotations could work. If the expectation i= s >>>> that protocol implementations should use strong types, then the use of >>>> polymorphic JSON is very likely to make things _more_ complicated for >>>> non-reference implementations. >>>> >>>> >>>> >>>> Hence my concern. I'm afraid that the leaky abstraction, while making >>>> the reference implementation more robust and straightforward, contribu= tes >>>> to making other implementations less robust. And this being a security >>>> protocol, the potential for brittle and/or confused implementations is >>>> terrifying. >>>> >>>> >>>> >>>> I am a fan of reducing complexity, and from what I can see, for the >>>> reference implementation the polymorphic approach actually does that. = But >>>> I'm afraid it does so at others' expense. Languages have their individ= ual >>>> constraints, idioms and best practices. If parsing a protocol payload >>>> introduces low-level complexities and encourages to go against common >>>> practices, that is an invitation for problems. I am aware that my choi= ce of >>>> words in the HN thread was likely to put people on defense, and for th= at I >>>> apologise. But I do believe that the choice of polymorphic JSON is goi= ng to >>>> make the life and use of other implementations notably less boring tha= n >>>> people in general would prefer. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Mika >>>> >>>> >>>> >>>> On Mon, 26 Oct 2020 at 02:04, Fabien Imbault >>>> wrote: >>>> >>>> Hi Dick, >>>> >>>> >>>> >>>> Well technically yes. Obviously the client can present any interface i= t >>>> seems fit. >>>> >>>> >>>> >>>> Still there's the question of the common model we want to present to >>>> the outside world and supported by the protocol itself (which client >>>> libraries all build upon). >>>> >>>> >>>> >>>> But beneath the polyphormism question, the HN debate seems on the >>>> surface a lot like the original xyz (polyphormism goes along with the >>>> reduced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, an= d >>>> where the client design has more latitude). Just explained differently= , by >>>> outside people with different agendas. >>>> >>>> >>>> >>>> Which is a bit weird because many of the critics on HN (who criticize >>>> polyphormism) also seem to really dislike OAuth in the first place (th= e >>>> inconsistencies are partially due to a bunch of different people >>>> commenting). >>>> >>>> >>>> >>>> Really to me there's no fundamental truth behind that question. It's a >>>> matter of preference and priorities in the design. Whatever choices we >>>> make, we'll have to be prepared to explain and justify them in the ope= n, >>>> even to some people that will dislike pretty much whatever we do (beca= use >>>> it's fun to look smart and critize without proposing alternatives). An= d we >>>> owe these answers to people like Mika, who genuinely try to make the b= est >>>> of it. >>>> >>>> >>>> >>>> Fabien >>>> >>>> >>>> >>>> Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt a >>>> =C3=A9crit : >>>> >>>> Hi Fabien >>>> >>>> >>>> >>>> A library developer can provide whatever abstraction layer makes sense >>>> for the library's target audience and language. >>>> >>>> >>>> >>>> If the client library developer wants to use polymorphism in the >>>> interface presented to the user's of the library, the library develope= r can >>>> do that independent of polymorphism in the protocol, and vice versa >>>> >>>> >>>> >>>> =3D> polymorphism in the protocol has no impact on client library >>>> developers >>>> >>>> >>>> >>>> >>>> >>>> *Error! Filename not specified.*=E1=90=A7 >>>> >>>> >>>> >>>> On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>> I'm just realizing your "least to most important" might actually say >>>> the same as what I was trying to say. So I'm not even sure what we're >>>> arguing against :-) >>>> >>>> >>>> >>>> In brief my point if it wasn't clear is that we should be crystal clea= r >>>> on where we put the cursor of simplicity, because this can mean differ= ent >>>> things for different people and different roles. >>>> >>>> And as we see on HN we need to better explain our design choices. >>>> >>>> >>>> >>>> >>>> >>>> Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault >>>> a =C3=A9crit : >>>> >>>> Hi Dick, >>>> >>>> >>>> >>>> Independantly from the debate on polyphormism, I beg to differ on your >>>> order preference. >>>> >>>> >>>> >>>> Your assumption is that AS devs matter the most, because they're doing >>>> the important security implementation. But eating our own dogfood migh= t >>>> help a lot to change that view. Most security issues occur because use= rs of >>>> the spec are unable to deal with the complexity that is passed onto th= em. >>>> >>>> >>>> >>>> 99% of the people that will actually use the output of the work are >>>> application developers (client or RS) and their own users. >>>> >>>> >>>> >>>> Our intent as well as the protocol drive the usage. Client libraries >>>> may help, but they're not a silver bullet, especially because GNAP >>>> ultimately has no control about what people do there (for better or wo= rse). >>>> And everything we do here will help get to the better part. >>>> >>>> >>>> >>>> I'm not saying we don't intend to also care about AS developers >>>> (beginning with ourselves) but it's a second order optimisation. And s= ince >>>> it's a tendancy we're leaning towards by default, I'm pretty sure we w= on't >>>> forget that anyway. >>>> >>>> >>>> >>>> Fabien >>>> >>>> >>>> >>>> >>>> >>>> Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt a >>>> =C3=A9crit : >>>> >>>> I'm confused by your logic Fabien. >>>> >>>> >>>> >>>> If a client library developer wants to expose polymorphism, they can d= o >>>> that independent of what is in the protocol. >>>> >>>> >>>> >>>> I differ on who our stakeholders are. >>>> >>>> >>>> >>>> I think our stakeholders are in least to most important: >>>> >>>> >>>> >>>> - AS developer >>>> - RS developer >>>> - client developer >>>> - user >>>> >>>> >>>> >>>> A client library developer can expose whatever interface they want to >>>> simplify implementation. >>>> >>>> >>>> >>>> I list the user so that we don't lose site of a critical role. >>>> >>>> >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> >>>> *Error! Filename not specified.*=E1=90=A7 >>>> >>>> >>>> >>>> On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>> Hi there, >>>> >>>> >>>> >>>> Let me try to approach the issue under a different light. More like a >>>> product manager would deal with feature selection to make it intuitive= for >>>> its users. >>>> >>>> >>>> >>>> For most people, riding a bike is far easier than using a unicycle. >>>> Feels more stable. And yet it's way easier to design for a single whee= l >>>> than to build with 2. Because then you'll need a lot more accessories >>>> (chain, chain ring, etc.). Even so producing a bike doesn't have to be= a >>>> brittle process, it can be industrialized. >>>> >>>> >>>> >>>> Back to the GNAP topic. >>>> >>>> Ultimately we should strive to make the spec as simple as can be. But >>>> we need to ask: simple for whom? For the bike owner or for the bike ve= ndor? >>>> >>>> (short answer: the priority should be simplicity for spec users, not >>>> spec implementers and even less spec designers). >>>> >>>> >>>> >>>> The initial question that is asked is very interesting: isn't the >>>> design flawed if GNAP is using json polyphormism? Or if the AS needs t= o >>>> handle the state of the request? Or if we must handle token revocation= ? Or >>>> if we are looking for a global unique identifier? The argument stems o= f the >>>> fact that is still arguably harder and more error prone to implement. = Fair >>>> enough. >>>> >>>> >>>> >>>> From a spec implementer's perspective, it may well be more complex. It >>>> mostly impacts the json library you'll end up using, plus a bit of >>>> input/output decoration around it. Even golang provides utilities for = this, >>>> despite not exactly being made for this kind of purpose. >>>> >>>> My practical experience implementing it is that it's not that big a >>>> deal. I mean, I wished it could be simpler, but it's manageable and th= ere >>>> are other ways to reach levels of insurance that it does work as inten= ded >>>> (json schema, test cases to validate the implementation, etc.). Arguab= ly it >>>> is still easier from an implementation perspective than say, json-ld, = which >>>> is massively used in the SSI community. >>>> >>>> >>>> >>>> But ultimately who are we designing for? Are we striving to go easy on >>>> the spec implementer? Or are we trying to make sure end-developers usi= ng >>>> the client libraries won't shoot themselves in the foot? >>>> >>>> >>>> >>>> The job to be done (JTBD), from the end-developer's perspective, is to >>>> efficiently ship an application. And provide authN/authZ capabilities = for >>>> end-users by relying on some well known implementation. >>>> >>>> In turn, this spec implementer will rely on cryptographic utility >>>> libraries that deals internally with the complexity of their own domai= n, so >>>> that we don't have to. And here we could launch another HN flame war t= hat >>>> starts with the title "JWT sucks because". Which does have its set of = very >>>> real issues but that's beyond the point. >>>> >>>> Note that any decent flamewar will be efficiently fueled by people >>>> hating medium. Is it outrageous for blog posts to be behind a paywall? >>>> Maybe but it's even more outrageous to lack consistency, either by not >>>> knowing how to get around a paywall if you're into a hacker punk movem= ent, >>>> or on the contrary by to not paying a subscription if you believe that >>>> surveillance capitalism, to reuse Zuboff's terms, should be eradicated= . >>>> >>>> What likely seems an unnecessary sidenote tries to illustrate the >>>> point: for Justin it was easier to publish on medium, because as a blo= g >>>> publisher, you might not want to deal with hosting your own blog. But = maybe >>>> as a reader you'll find that annoying. Different audiences, different = JTBD, >>>> different tradeoffs. >>>> >>>> >>>> >>>> Polyphormism is a tool that enables the end-developer to have minimal >>>> knowledge of what it means to deal with a GNAP client library. You pre= pare >>>> the request, send to the endpoint and you're good to go. Massively sim= pler >>>> than OAuth2 or any similar protocol by the way (as anyone with teachin= g >>>> experience on the subject might acknowledge). And there's a lot more = to be >>>> done to make sure we indeed reduce the complexity for the end-develope= r and >>>> the end-user. >>>> >>>> >>>> >>>> If we find a better way to deal with that simplicity balance, I'm all >>>> in. But the arguments need to be way more convincing than just saying = that >>>> it may be difficult to implement or validate. >>>> >>>> >>>> >>>> Cheers. >>>> >>>> Fabien >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer a = =C3=A9crit : >>>> >>>> >>>> >>>> >>>> >>>> On Oct 23, 2020, at 3:52 PM, Dick Hardt wrote: >>>> >>>> >>>> >>>> Justin >>>> >>>> >>>> >>>> I did note that I was the one that argued for instance_id being in the >>>> object. Since it is in the object in the current draft, not including = a >>>> pass by reference option would be preferable. >>>> >>>> >>>> >>>> As for concrete examples: >>>> >>>> - version of client >>>> >>>> - version of OS >>>> >>>> - security attestation of OS / device >>>> >>>> - location of client device >>>> >>>> - network client is operating on >>>> >>>> >>>> >>>> These are all attributes of the client that an AS may require on the >>>> initial grant request, and in future grant requests (which is when an >>>> instance_id) would be used. >>>> >>>> >>>> >>>> >>>> >>>> This is where our interpretations differ: I don=E2=80=99t see these as >>>> =E2=80=9Cattributes of the client=E2=80=9D in the same way that the ke= y, display >>>> information, class identifiers, and other items currently represented = by an >>>> instance_id are attributes of the client instance. The attestation >>>> components don=E2=80=99t modify the instance so much as present additi= onal >>>> information on top of the client instance itself. This is why I argue = that >>>> they ought to be handled in a separate object, so you=E2=80=99d have s= omething like >>>> this strawman: >>>> >>>> >>>> >>>> { >>>> >>>> >>>> >>>> posture: { >>>> >>>> software_version: 1.2.3, >>>> >>>> os_version: 14.3.2 >>>> >>>> device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 } >>>> >>>> location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 } >>>> >>>> }, >>>> >>>> >>>> >>>> client: =E2=80=9Cclient-541-ab" >>>> >>>> >>>> >>>> } >>>> >>>> >>>> >>>> This is a more fundamental question about GNAP than whether the syntax >>>> uses polymorphism: this is about GNAP being very explicit about the da= ta >>>> model of its elements. OAuth 2=E2=80=99s incredibly loose and broad mo= del of what >>>> the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is deeply = problematic in >>>> practice. We=E2=80=99re even seeing that in the OAuth 2.1 work with ha= ving to >>>> define a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doe= sn=E2=80=99t fully capture >>>> the different aspects that are out there. I think we=E2=80=99re gettin= g closer here >>>> in GNAP with explicit definition of =E2=80=9Cclient instance=E2=80=9D,= but we still need to >>>> be more precise about what exactly a client instance includes, and wha= t it >>>> does not. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> >>>> >>>> /Dick >>>> >>>> >>>> >>>> *Error! Filename not specified.*=E1=90=A7 >>>> >>>> >>>> >>>> On Fri, Oct 23, 2020 at 12:42 PM Justin Richer wrote= : >>>> >>>> Dick, >>>> >>>> >>>> >>>> As you=E2=80=99ll recall, I argued against including the client instan= ce >>>> identifier inside of the object as a mutually-exclusive field precisel= y >>>> because of the principle violation that you are pointing out here, and= so >>>> it=E2=80=99s important to point out that the current text is a comprom= ise that >>>> needs to be examined in the wider experience of the working group. I a= m on >>>> the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an >>>> object, but this needs to be explored. >>>> >>>> >>>> >>>> The crux of my argument is that is exactly a case of pass-by-reference >>>> vs pass-by-value, and that runtime attestations are not part of the = =E2=80=9Cclient >>>> instance=E2=80=9D value itself but rather belong outside of that objec= t in a >>>> another part of the request. As stated in the editorial notes in this >>>> section, we need to look carefully at how these concepts fit within th= e >>>> model and where we would want to put them. Without concrete examples o= f >>>> what these extensions look like and how they=E2=80=99re generated, tha= t is nearly >>>> impossible to do at this stage. I look forward to seeing examples of t= his >>>> kind of data and how it can fit into the protocol. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Oct 23, 2020, at 3:07 PM, Dick Hardt wrote: >>>> >>>> >>>> >>>> Hey Justin, >>>> >>>> >>>> >>>> As the draft has evolved, I question the continued use of polymorphism= . >>>> Note that I appreciate the elegance of using a string for >>>> pass-by-reference, and an object for pass-by-value. >>>> >>>> >>>> >>>> In the current draft, the >>>> >>>> >>>> >>>> Every time you create or process a field it will mean only one thing, >>>> and there=E2=80=99s only one field to look at to answer a question. >>>> >>>> >>>> >>>> is violated in 2.3.1. Identifying the RC Instance >>>> >>>> >>>> >>>> >>>> >>>> >>>> instance_id An identifier string that the AS can use to identify t= he >>>> >>>> particular instance of this RC. The content and structure of th= is >>>> >>>> identifier is opaque to the RC. >>>> >>>> >>>> >>>> "client": { >>>> >>>> "instance_id": "client-541-ab" >>>> >>>> } >>>> >>>> >>>> >>>> If there are no additional fields to send, the RC MAY send the >>>> >>>> instance identifier as a direct reference value in lieu of the >>>> >>>> object. >>>> >>>> >>>> >>>> "client": "client-541-ab" >>>> >>>> >>>> >>>> The instance identifier can be sent two ways. Polymorphism is a >>>> convenience for the client, but requires the server to have two code p= aths >>>> for "instance_id". We discussed this in the design team, and I argued= for >>>> having "instance_id" in the "client" object so that any updates, such = as >>>> new devices assertions, could be in the "client" object. As noted abov= e, >>>> while I appreciate the elegance of using a string (handle) to referenc= e a >>>> previously provided object, it complicates how to update an existing o= bject >>>> while providing the reference. >>>> >>>> >>>> >>>> In your example of the "key" object below, setting "proof" to bearer >>>> would avoid the issue you describe: >>>> >>>> >>>> >>>> { >>>> "key": { >>>> "proof": "bearer" >>>> } >>>> } >>>> >>>> >>>> >>>> In your example, when processing the "key" object, code is having to >>>> check both the JSON type of the property, as well as check the value o= f the >>>> "proof" property. In the example I provided, only the value of "proof" >>>> needs to be checked. The "proof" property is acting as a type for the = "key" >>>> object. >>>> >>>> >>>> >>>> Not being a Java programmer, I don't know how this would work in a Jav= a >>>> implementation, but node.js, the processing would need to be done as a= bove. >>>> >>>> >>>> >>>> On a related note, there was significant negative feedback on handles >>>> and polymorphism in the Hacker News article >>>> https://news.ycombinator.com/item?id=3D24855750 >>>> >>>> >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Oct 23, 2020 at 10:20 AM Justin Richer wrote= : >>>> >>>> Hi Mika, >>>> >>>> >>>> >>>> Thanks for bringing this topic here =E2=80=94 I was able to see the fo= rum >>>> discussion that brought you here, and hopefully I can help clear up wh= at I >>>> mean with how polymorphism is used in the proposal. The short version = is >>>> that the goal is to *avoid* the kinds of ambiguity that make insecure >>>> protocols, and so in that goal we=E2=80=99re fully aligned. I think th= at using >>>> polymorphism in very specific ways can help that goal =E2=80=94 just a= s I agree >>>> that misusing it or applying it sloppily can lead to ambiguous and ins= ecure >>>> systems. >>>> >>>> >>>> >>>> Some background: I built out the XYZ protocol (one of the predecessors >>>> to the initial GNAP Draft) in Java using strongly typed parsers and Ja= va >>>> objects specifically to prove to myself that it could be done in a way= that >>>> made any sense in the code. (My own open source implementation is at >>>> https://github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not= yet up >>>> to date with the GNAP spec). It was important to me that I be able to = use >>>> the system-wide configured parsers to implement this and not have to r= esort >>>> to stepping through elements completely by hand. Java doesn=E2=80=99t = make it >>>> simple to get the hooks into the right places (especially with the Jac= kson >>>> parser that I used), but it is definitely possible to create a >>>> deterministic and strongly-typed parser and serializer for this kind o= f >>>> data structure. Some of the rationale for using polymorphism is covere= d in >>>> the trailing appendix of the draft document ( >>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-00.html#= name-json-structures-and-polymor), >>>> but it=E2=80=99s still good to discuss this here as the working group = decides which >>>> approaches to take. >>>> >>>> >>>> >>>> The driving reason for using polymorphism at the protocol level was to >>>> simplify the protocol and make it :more: deterministic to create and >>>> process, not less. Every time you create or process a field it will me= an >>>> only one thing, and there=E2=80=99s only one field to look at to answe= r a question. >>>> Without polymorphic field values, you usually need to rely on mutual >>>> exclusivity of fields, which is prone to failure and requires addition= al >>>> error checking. Take for example the key binding of access tokens. An >>>> access token could be bound to the RC=E2=80=99s key used during the re= quest, to a >>>> different key chosen by the AS, or it could be a bearer token with no = key >>>> at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can = define it in terms of >>>> boolean values and objects and express this set of mutually-exclusive >>>> options in a non-ambiguous way. Without that, you=E2=80=99d need to ha= ve different >>>> fields for the options and include additional checks in your parser to= make >>>> sure they weren=E2=80=99t sent simultaneously, otherwise you could get= hit with >>>> this potential security vulnerability in an object: >>>> >>>> >>>> >>>> { >>>> >>>> key: { >>>> >>>> proof: httpsig, >>>> >>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>> >>>> }, >>>> >>>> bearer_token: true, >>>> >>>> bind_to_rc_key: true >>>> >>>> } >>>> >>>> >>>> >>>> This would be an illegal object as per this alternate proposal, but >>>> then you=E2=80=99d have to check each field and make sure it wasn=E2= =80=99t put next to >>>> others in the same object. I=E2=80=99ve done this exercise with many o= ther >>>> protocols and it=E2=80=99s both error prone and easy to ignore since a= ll the =E2=80=9Cgood=E2=80=9D >>>> examples would pass code that doesn=E2=80=99t check this. With the pol= ymorphic >>>> approach to this same field, each of these three mutually-exclusive st= ates >>>> is written in a way that they cannot be sent together. It=E2=80=99s no= t just >>>> illegal, it=E2=80=99s impossible and enforced by the syntax of JSON it= self. >>>> >>>> >>>> >>>> { >>>> >>>> key: { >>>> >>>> proof: httpsig, >>>> >>>> jwk: { =E2=80=A6 key value =E2=80=A6 } >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> // bearer token >>>> >>>> >>>> >>>> { >>>> >>>> key: false >>>> >>>> } >>>> >>>> >>>> >>>> // bound to the RC=E2=80=99s presented key >>>> >>>> >>>> >>>> { >>>> >>>> key: true >>>> >>>> } >>>> >>>> >>>> >>>> If someone sends a different type for this field, like an array or >>>> number or a null, this doesn=E2=80=99t have a defined interpretation i= n the >>>> protocol and would be a protocol level error. >>>> >>>> >>>> >>>> While it might sound like polymorphism means that any field could have >>>> any type or value, the opposite is true: each possible value is explic= itly >>>> typed, it=E2=80=99s just that there are potentially different types th= at express >>>> meaning for the field. This applies to all members of all objects >>>> (dictionaries) as well as all members of an array (list). Every time y= ou >>>> process a field value or other element, you look at the type and then = the >>>> value to determine what to do with that typed value. >>>> >>>> >>>> >>>> In your example below, each field within the dictionary would also nee= d >>>> to be typed, and each type would need to have a clear indication of it= s >>>> meaning. To take your strawman key format below, the =E2=80=9Cmodulus= =E2=80=9D field could >>>> be defined polymorphically as either a =E2=80=9Cbigint=E2=80=9D (a JSO= N number) or an >>>> =E2=80=9Cencoded string=E2=80=9D (a JSON string). The definition would= further say what >>>> exactly the encoding of the string would be. That means that when you = read >>>> the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any conf= usion on what the value was >>>> or how it was represented, regardless of the input format. Seeing a nu= mber >>>> there means exactly one interpretation and seeing a string means exact= ly >>>> one (different) interpretation =E2=80=94 but importantly, both of them= are a >>>> =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determi= nes the type. An >>>> implementation would likely use an internal BigInteger type of object = to >>>> represent the field value after parsing, so the question is how to go = from >>>> the JSON value (which is typed) into the BigInteger value.You don=E2= =80=99t just >>>> apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you ap= ply it to all >>>> sub-fields of that object. >>>> >>>> >>>> >>>> So let=E2=80=99s dig into the specific bug you bring up in the strawma= n, >>>> because it=E2=80=99s interesting: A JSON encoder that encodes numbers = as strings, >>>> and not numbers, is not compliant with the JSON definitions of the fie= ld in >>>> question. For another example, the quoted string value of =E2=80=9Ctru= e=E2=80=9D is not >>>> equivalent to the boolean value true in JSON, and they shouldn=E2=80= =99t be treated >>>> the same by a parser implementation when mapping to a concrete object.= It=E2=80=99s >>>> in this kind of automated guessing that this class of bugs occur, and >>>> that=E2=80=99s going to be the case whether or not you take advantage= of JSON=E2=80=99s >>>> polymorphic nature. I=E2=80=99ve run into cases where a parser library= was trying >>>> to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, = but ended up >>>> introducing errors in more strict components downstream. This is somet= hing >>>> that protocol designers need to be aware of and guard against in the d= esign >>>> of the protocol to reduce possible ambiguities. Within GNAP today, we >>>> generally have things that branch whether they=E2=80=99re an object (f= or a rich >>>> description of something) or some non-structured special value (for a >>>> reference or other item). >>>> >>>> >>>> >>>> The design team created some simple JSON Schemas for parts of the >>>> protocol during our discussion, but we didn=E2=80=99t include them in = the design >>>> document due to both lack of time to keep it updated with the rapid ch= anges >>>> to the protocol during the design team discussion, and not knowing if = there >>>> would be interest in such material. I personally think it would be hel= pful >>>> to include as an informative reference in the final document, but that= =E2=80=99s >>>> something for the working group to take up eventually. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m < >>>> mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote: >>>> >>>> >>>> >>>> Hello, everyone. >>>> >>>> >>>> >>>> For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum >>>> and when I made note about certain concerns, I was requested to send m= y >>>> comments to this working group. >>>> >>>> >>>> >>>> In short, I believe that the use of polymorphic JSON in the protocol >>>> invites subtle and confusing implementation problems. I also searched >>>> through the WG archives, and noticed that similar concerns were noted, >>>> briefly, in a thread in July. >>>> >>>> >>>> >>>> The problem with polymorphic values, as I see it, is that >>>> implementations will need to branch on the (inferred) type of a given >>>> field. This isn't quite as bad if the types are strictly different, bu= t >>>> allows for subtle bugs when the value in question is a dictionary. Wha= t >>>> makes this unappealing is that "subtle bugs" in security protocols hav= e a >>>> habit of turning into vulnerabilities. >>>> >>>> >>>> >>>> Let's say we have these imaginary payloads, both possible and valid in >>>> the same protocol step: >>>> >>>> >>>> >>>> # payload 1 >>>> >>>> { >>>> >>>> ..., >>>> >>>> "public_key": { >>>> >>>> "alg": "rsa", >>>> >>>> "modulus": >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> # payload 2 >>>> >>>> { >>>> >>>> ..., >>>> >>>> "public_key": { >>>> >>>> "alg": "rsa", >>>> >>>> "modulus": "" >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> In both cases, the type of "public_key" field is a dictionary. In both >>>> cases, they even have the same keys. However, the values in the >>>> dictionaries are entirely different, and an implementation will have t= o >>>> branch to at least two possible decoding mechanisms. To make things wo= rse, >>>> some JSON implementations may choose to encode non-dictionary values a= s >>>> strings, so it is possible for an originator to transmit what they exp= ect >>>> and believe to be payload 1 format, but which the receiver will interp= ret >>>> to be in payload 2 format. And if the encoded string contains only dig= its, >>>> it will even parse correctly as a bignum. >>>> >>>> >>>> >>>> While the above is clearly a manufactured scenario, it nonetheless >>>> demonstrates the potential for logic bugs with polymorphic JSON. With >>>> richer types and more complex dictionaries, there will surely be more = room >>>> for errors. >>>> >>>> >>>> >>>> Ambiguity in protocols is always a source of implementation complexity >>>> and interoperability snags, but in an AuthN/AuthZ protocol it is worse= : >>>> it's terrifying. If GNAP/Oauth3 is intended to supersede Oauth1/2, wou= ldn't >>>> it be in everyone's interest to keep implementation complexity and mis= take >>>> potential to a minimum? >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Mika >>>> >>>> >>>> >>>> -- >>>> >>>> Mika Bostr=C3=B6m >>>> >>>> Smarkets >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> *Error! Filename not specified.*=E1=90=A7 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> -- >>>> >>>> Mika Bostr=C3=B6m >>>> >>>> Smarkets >>>> >>>> -- TXAuth mailing list TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> > --0000000000005f40b705b2e631b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, I didn't know about CDDL before Dick mentioned it= and just made a=C2=A0first test with existing libraries, that's awesom= e. Appendix E in the spec highlights a few caveats between json/cbor suppor= t but no big deal.=C2=A0
    Fabien

    On Fri, Oct 30, 2020 at 5:42 PM Ju= stin Richer <jricher@mit.edu> = wrote:
    Thanks for putting this list together, Fab= ien! And thanks Dick, I was also going to point out CDDL as a potential opt= ion for a schema description language.

    =C2=A0=E2=80= =94 Justin

    On Oct 30, 2020, at 1= 1:41 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    3D""=E1=90=A7

    On Fri, Oct 30, 2020 at 8:13 AM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:
    Hi Yaron,=C2=A0

    T= hanks a lot for the feedback, I fixed the issue related to the standardisat= ion status (I guess there's some historic background that I don't k= now ;-)).

    Is JSON the only real possible format? P= robably, at least for compatibility with pretty much everything that exists= . Only TJSON could maybe be used as an alternative (and kind of removes the= need for a schema), with the downsides that you don't have so many exi= sting libraries and that the community seems much smaller: 2k stars for JSO= N schema spec vs 65 for TJSON spec (and the expired website SSL certificate= doesn't help).=C2=A0 =C2=A0

    The main problem = I see is that for constrained cases, CBOR won't have a schema in a fore= seeable future (at least I'm not aware of any work on that). I know it&= #39;s not our main focus right now and might not even be covered by the cur= rent WG, but still it might become an issue at some point.=C2=A0
    =
    Best,
    Fabien=C2=A0 =C2=A0

    On Fri, Oct 30, 2020 at 3= :19 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

    =C2=A0<= /p>

    One correction, JSON Schema (which I am personall= y advocating for, but still) does not have an IETF spec. They claim on thei= r web site that they want it standardized, but in practice are not (yet?) m= oving in this direction. Their Internet Draft is unmaintained.

    =C2=A0

    = At a higher level, I think your discussion conflates two things: the repres= entation of data on the wire (JSON or various mostly binary encodings) and = the data modeling language, a.k.a. schema. Personally I think JSON is almos= t a must in our case, and if this is true, the playing field is *much* more narrow.

    =C2=A0

    A major strength of JSON which you don=E2=80=99= t mention in your comparison is the cryptographic ecosystem (JOSE): standar= d formats for encryption, signature etc.

    =C2=A0

    I wasn=E2=80=99t aware= of Ion. I don=E2=80=99t think it=E2=80=99s a good fit for us, still a very= interesting direction.

    =C2= =A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    <= u>=C2=A0

    =

    From: <= span style=3D"font-size:12pt">Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Friday, October 30, 2020 at 14:53
    To: Andrii Deinega &l= t;andrii.dein= ega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com= >, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, GNAP Mailing Li= st <txauth@ietf.org= >, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Feedback= on polymorphism

    = =C2=A0

    Hi Justin,=C2=A0<= u>

    =C2=A0

    =

    > Regarding your question, what else could w= e propose?=C2=A0

    = =C2=A0

    I've started a revie= w of possibilities at=C2=A0https://github.com/fim= bault/reasonably-polymorphic/blob/main/README.md to be followed by actu= al code testing.=C2=A0

    <= u>=C2=A0

    Cheers,<= /u>

    Fabien

    =C2=A0

    On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega <andrii.deinega@gmail.com&g= t; wrote:

    Hi=C2=A0Mika, Justin, and WG,

    =C2=A0

    T= he act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Exchange) has = a JSON object as its value. This claim could be a part of AT JWT or a token= introspection response and has the same semantics in both cases. The JSON = object as its value may look like this

    "act":
    {
    =C2= =A0 "sub":"admin@example.com"
    }

    or even be nested like in
    =
    "act":
    {
    =C2=A0"sub":"https://service16.example.com",
    =C2=A0 =C2=A0"act":
    =C2=A0 =C2=A0{
    =C2=A0 =C2= =A0 =C2=A0"sub":"    https://service77.example.com"
    =C2=A0 =C2=A0}=
    }

    Personally, I find it to be a very expressive approach. Also, = as far I as know, several (oAuth2) client libraries have good support of th= ings like

    "aud":"https://service1.example.com" and "au= d":["= https://service1.example.com","https://service2.example.com"]
    in AT JWTs for a quite long time.

    =C2=A0

    Regards,=

    Andrii

    =C2=A0

    On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:

    Hi Yaron,

    <= u>=C2=A0

    We'll indeed h= ave to check how make it as idiomatic as possible with experts of each lang= uage (help welcome).=C2=A0

    =C2=A0

    Regarding the = client, the variations are more limited but they do exist. Here I believe i= t's much more problematic than on the server side and there are at leas= t a few actions we should take:

    =C2=A0

    A) check = in sec 7 if we really have a compelling reason for key and proof variants. = This is derived from larger discussions on key binding as per the related n= ote. There are quite a few open questions related to this theme.=C2=A0

    =C2=A0

    B) there is also the choice between value/ref= erence that may generate complexity.=C2=A0

    =C2=A0

    C) More generally, as many feedbacks already have noticed, we need to hav= e a systematic review and reduce the set of available options in the protoc= ol.=C2=A0

    =C2=A0<= u>

    Unless we have a clear idea why runtime behavior requires mut= ability, it might be useful to have a way to define the chosen variant befo= re hand, so that the expected behavior becomes deterministic on the client = side. There are various ways it could be done in practice.=C2=A0<= /u>

    =C2=A0

    For sure several independant implementations= would help, especially if we make sure they can work together.=C2=A0

    =C2=A0

    Anyway all this open to improvement.=C2=A0<= /u>

    =C2=A0

    Cheers=C2=A0

    Fabien=C2=A0

    =C2=A0

    Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:

    Hi Fabien,

    =C2=A0

    At least in the case = of Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than the problem= . The code in the article you cite is very specific to the use case and IMH= O quite ugly. So my preferred Go implementation would be a combination of u= ntyped structures (Go interface{}) and run-time enforcement of JSON Schema.=

    =C2=A0

    Also, going back to our earlier discussion on this topic, I = just read Sec. 7 of gnap-00 and realized that the RC also needs to deal wit= h polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS.

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

    =C2=A0

    From: TXA= uth <txauth= -bounces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com&g= t;
    Date: Wednesday, October 28, 2020 at 18:56
    To: Mika = Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: GNAP Mailing List <= txauth@ietf.org>= ;, Justin Richer <j= richer@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [= GNAP] Feedback on polymorphism

    =C2=A0

    Th= anks for the great feedback. Your concern is very valid.=C2=A0

    =C2=A0

    My implementation is in rust, which makes life easier = in that specific case.=C2=A0

    =C2=A0

    So I&#= 39;m not a golang specialist but I guess the transcription of json strings/= arrays into go structs would work around the lines described by=C2=A0https://medium.com/@alexkappa/json-polymorphism-in-go-4cade= 1e58ed1

    When we have= a more formalized json schema, I suggest we make a library of json example= s and some related code samples in mainstream languages, to check it is fea= sible for everyone.=C2=A0

    =C2=A0

    Cheers,<= u>

    Fabien

    <= div>

    =C2=A0

    =C2=A0

    On Wed,= Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote:=

    Hi ev= eryone,

    =C2=A0=

    Looks like I stuck my finger in a= hornets' nest. First off, apologies for not chipping in earlier, but t= here was a lot of material to digest. Also, warning: lots to read ahead.=

    =C2=A0

    I'm one of those people who end up maki= ng use of AuthN/AuthZ functionality through a library. On top of that I can= see myself being roped in as a server (AS) implementation help. So I'm= approaching this from an outsider's perspective. Someone who expects t= o be exposed to the eventual RFC and all the nitty-gritty details. My relat= ively terse comment ended up at the top of the aforementioned HN thread, wh= ich didn't necessarily help. Sorry about that.

    <= div>

    =C2=A0

    Now, having read Justin's initial reply - and the rest of the= thread - I believe I can see where the desire for polymorphism comes from.= To be clear: I am all for strict types inside an implementation, as it wil= l add helpful guard-rails to the state management code paths. However, I se= e this as a case of leaky abstraction. If we take the existing oauth.xyj-ja= va code to be the reference implementation, the choice makes logical sense:= JSON is not expressive enough to serialise arbitrary objects, so in order = to avoid writing complex payload parser(s) the internal implementation deta= ils now leak to the protocol itself. From a purely technical perspective, i= t's a cool trick. From a distance it even looks a bit like the result o= f protobuf decoding, but without the generated code parts.

    =C2=A0

    But then the downside. I don't personally expect to b= e able to use the reference implementation, being mostly a Python user myse= lf. A fair number of AS implementations will be written with languages such= as Go, Python, C#, Ruby, and JavaScript (thanks to node.js), and all of th= em will have to deal with the polymorphism. From what I've read over th= e past couple of days, I understand that at least Go supports custom unmars= halers from JSON to typed structs, at the cost of an indirection. Normally = when a Go code processes JSON to a typed struct, the process is helped by f= ield annotations in the type definition itself. For example, if the payload= for a person in JSON was

    =C2=A0

    {=

    =C2=A0 "name": "<st= ring>",

    =C2=A0 &= quot;age": <int>,

    =C2=A0 "country": "<string>",<= /p>

    =C2=A0 "city": "<str= ing>"

    }

    =C2=A0

    .. then the type definition would look like:

    =C2=A0

    type Person struct {

    <= div>

    =C2=A0 Name string `json:"name"=

    =C2=A0 Age int `json:"age= "`

    =C2=A0 Country s= tring `json:"country"`

    =C2=A0 City string `json:"city"`

    =

    }

    =C2=A0

    When the (p= ossibly complex) type of a given field is fixed, unmarshaling should still = be straightforward. I haven't verified, but since the annotation only g= ives which field to look at for a given typed value, there should be nothin= g special about that. But when the field can instead be a union of more tha= n one distinct types, things start to get messy. There is no union type in = the language at all, so the following construct is not even possible:

    =C2=A0

    type Entity struct {

    =C2=A0 Resources []string `json:"resources&q= uot;`

    =C2=A0 Client unio= n(Client, string) `json:"client"`

    }

    = =C2=A0

    As I understand, = the implicit expectation is that in the above case, the unmarshaler detects= that "client" is a string, and so expands it from an opaque hand= le to the expected, populated type. Even after thinking about the ramificat= ions over the past few days I remain confused, because I don't see how = the commonly used annotations could work. If the expectation is that protoc= ol implementations should use strong types, then the use of polymorphic JSO= N is very likely to make things _more_ complicated for non-reference implem= entations.

    =C2=A0

    Hence my concern. I'm afraid t= hat the leaky abstraction, while making the reference implementation more r= obust and straightforward, contributes to making other implementations less= robust. And this being a security protocol, the potential for brittle and/= or confused implementations is terrifying.

    =C2=A0

    I = am a fan of reducing complexity, and from what I can see, for the reference= implementation the polymorphic approach actually does that. But I'm af= raid it does so at others' expense. Languages have their individual con= straints, idioms and best practices. If parsing a protocol payload introduc= es low-level complexities and encourages to go against common practices, th= at is an invitation for problems. I am aware that my choice of words in the= HN thread was likely to put people on defense, and for that I apologise. B= ut I do believe that the choice of polymorphic JSON is going to make the li= fe and use of other implementations notably less boring than people in gene= ral would prefer.

    =C2=A0=

    Cheers,

    Mika

    =C2=A0

    = On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    Hi Dick,

    =C2=A0

    <= div>

    Well technically yes. Obviously the client can p= resent any interface it seems fit.=C2=A0

    =C2=A0

    = Still there's the question of the common model we want to present to th= e outside world and supported by the protocol itself (which client librarie= s all build upon).=C2=A0

    =C2=A0

    But beneath the = polyphormism question, the HN debate seems on the surface a lot like the or= iginal xyz (polyphormism goes along with the reduced endpoint model) vs xau= th (a bit closer to OAuth2 in spirit, and where the client design has more = latitude). Just explained differently, by outside people with different age= ndas.=C2=A0

    =C2=A0

    Which is a bit weird because = many of the critics on HN (who criticize polyphormism) also seem to really = dislike OAuth in the first place (the inconsistencies are partially due to = a bunch of different people commenting).=C2=A0

    =

    =C2=A0

    Really to me there's no fundamental truth behind that question. I= t's a matter of preference and priorities in the design. Whatever choic= es we make, we'll have to be prepared to explain and justify them in th= e open, even to some people that will dislike pretty much whatever we do (b= ecause it's fun to look smart and critize without proposing alternative= s). And we owe these answers to people like Mika, who genuinely try to make= the best of it.=C2=A0

    = =C2=A0

    Fabien=C2=A0

    =C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt= <dick.hardt@g= mail.com> a =C3=A9crit=C2=A0:

    Hi Fabien

    =C2=A0

    A library d= eveloper can provide whatever abstraction layer makes sense for the library= 's target=C2=A0audience and language.

    =C2=A0

    If the client library=C2=A0developer wants to use polymorphism=C2=A0in the= interface presented to the user's of the library, the library develope= r can do that independent of polymorphism in the protocol, and vice versa= =C2=A0

    =C2=A0<= /u>

    =3D> polymorphism in the protoc= ol has no impact on client library developers

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0

    Error! Filename not sp= ecified.=E1=90=A7

    =C2=A0

    On Sat, Oct = 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    I'm just realizi= ng your "least to most important" might actually say the same as = what I was trying to say. So I'm not even sure what we're arguing a= gainst :-)=C2=A0

    =C2=A0=

    In brief my point if it wasn&#= 39;t clear is that we should be crystal clear on where we put the cursor of= simplicity, because this can mean different things for different people an= d different roles.=C2=A0

    And as we see on HN we need to better explain our design choices.=C2=A0=

    =C2=A0

    =C2=A0

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Imbault <fabien.imbault@gmai= l.com> a =C3=A9crit=C2=A0:

    Hi Dick,

    =C2=A0

    Independantly = from the debate on polyphormism, I beg to differ on your order preference.= =C2=A0

    =C2=A0<= /u>

    Your assumption is that AS devs ma= tter the most,=C2=A0because th= ey're doing the important security implementation. But eating our own d= ogfood might help a lot to change that view. Most security issues occur bec= ause users of the spec are unable to deal with the complexity that is passe= d onto them.=C2=A0

    =C2=A0

    99% of the peop= le that will actually use the output of the work are application developers= (client or RS) and their own users.=C2=A0

    =C2=A0

    Our intent as well as the pr= otocol drive the usage. Client libraries may help, but they're not a si= lver bullet, especially because GNAP ultimately has no control about what p= eople do there (for better or worse). And everything we do here will help g= et to the better part.=C2=A0

    =C2=A0

    I'= ;m not saying we don't intend to also care about AS developers (beginni= ng with ourselves) but it's a second order optimisation. And since it&#= 39;s a tendancy we're leaning towards by default, I'm pretty sure w= e won't forget that anyway.=C2=A0

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    =C2=A0

    Le sam. 24 oc= t. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:=

    I'm confused = by your logic Fabien.

    =C2=A0

    If a client library devel= oper wants to expose polymorphism, they can do that independent of what is = in the protocol.=C2=A0

    = =C2=A0

    I differ on who o= ur stakeholders are.=C2=A0

    =C2=A0

    I think our st= akeholders are in least to most important:

    =C2=A0

      AS developer
    • RS developer
    • client developer=
    • user
    <= div>

    =C2=A0

    A client library developer can expose whatever interface they wan= t to simplify implementation.

    =C2=A0

    I list the = user so that we don't lose site of a critical role.

    =C2=A0

    /Dick

    =C2= =A0

    =C2=A0=

    Error! Filename not specified.=E1=90= =A7

    =C2=A0

    On Fri, Oct 23, 2020 at 6:27 PM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:

    Hi there,=C2=A0

    =

    =C2=A0

    Let me try to approach the issue under a different light. More like a= product manager would deal with feature selection to make it intuitive for= its users.=C2=A0

    =C2=A0

    For most people, riding = a bike is far easier than using a unicycle. Feels more stable. And yet it&#= 39;s way easier to design for a single wheel than to build with 2. Because = then you'll need a lot more accessories (chain, chain ring, etc.). Even= so producing a bike doesn't have to be a brittle process, it can be in= dustrialized.=C2=A0

    =C2= =A0

    Back to the GNAP top= ic.=C2=A0

    Ultimately we should strive to make the spec as si= mple as can be. But we need to ask: simple for whom? For the bike owner or = for the bike vendor?=C2=A0

    (short answer: the p= riority should be simplicity for spec users, not spec implementers and even= less spec designers).=C2=A0

    =C2=A0

    The i= nitial question that is asked is very interesting: isn't the design fla= wed if GNAP is using json polyphormism? Or if the AS needs to handle the st= ate of the request? Or if we must handle token revocation? Or if we are loo= king for a global unique identifier? The argument stems of the fact that is= still arguably harder and more error prone to implement. Fair enough.=C2= =A0

    =C2=A0=

    From a spec implementer's perspec= tive, it may well be more complex. It mostly impacts the json library you&#= 39;ll end up using, plus a bit of input/output decoration around it. Even g= olang provides utilities for this, despite not exactly being made for this = kind of purpose.

    My prac= tical experience implementing it is that it's not that big a deal. I me= an, I wished it could be simpler, but it's manageable and there are oth= er ways to reach levels of insurance that it does work as intended (json sc= hema, test cases to validate the implementation, etc.). Arguably it is stil= l easier from an implementation perspective than say, json-ld, which is mas= sively used in the SSI community.=C2=A0

    =C2=A0

    B= ut ultimately who are we designing for? Are we striving to go easy on the s= pec implementer? Or are we trying to make sure end-developers using the cli= ent libraries won't shoot themselves in the foot?

    =C2=A0

    The job to be done (JTBD), from the end-developer's pers= pective, is to efficiently ship an application. And provide authN/authZ cap= abilities for end-users by relying on some well known implementation.=C2=A0=

    In turn, this spec impl= ementer will rely on cryptographic utility libraries that deals internally = with the complexity of their own domain, so that we don't have to. And = here we could launch another HN flame war that starts with the title "= JWT sucks because". Which does have its set of very real issues but th= at's beyond the point.=C2=A0

    Note that any decent flamewar will be efficiently fueled by people= hating medium. Is it outrageous for blog posts to be behind a paywall? May= be but it's even more outrageous to lack consistency, either by not kno= wing how to get around a paywall if you're into a hacker punk movement,= or on the contrary by to not paying a subscription if you believe that sur= veillance capitalism, to reuse Zuboff's terms, should be eradicated.=C2= =A0

    What likely seems an= unnecessary sidenote tries to illustrate the point: for Justin it was easi= er to publish on medium, because as a blog publisher, you might not want to= deal with hosting your own blog. But maybe as a reader you'll find tha= t annoying. Different audiences, different JTBD, different tradeoffs.=C2=A0=

    =C2=A0

    Polyphormism is a tool that enables the = end-developer to have minimal knowledge of what it means to deal with a GNA= P client library. You prepare the request, send to the endpoint and you'= ;re good to go. Massively simpler than OAuth2 or any similar protocol by th= e way (as anyone with teaching experience on the subject might acknowledge)= . And=C2=A0 there's a lot more to be done to make sure we indeed reduce= the complexity for the end-developer and the end-user.=C2=A0=

    =C2=A0

    If we find a better way to deal with that simplicity b= alance, I'm all in. But the arguments need to be way more convincing th= an just saying that it may be difficult to implement or validate.=C2=A0<= /u>

    =C2=A0

    Cheers.

    Fabien

    = =C2=A0

    =C2=A0<= /u>

    =C2=A0

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0= :

    =C2=A0=

    = =C2=A0

    On Oct 23, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:

    =C2=A0

    Justin

    <= p class=3D"MsoNormal">=C2=A0

    I did note that I was the one that argued for instance_id being in the= object. Since it is in the object in the current draft, not including a pa= ss by reference option would be preferable.=C2=A0

    =C2=A0

    As for concrete examples:

    - version of client

    - version of OS

    -= security attestation of OS / device

    - location of client device

    - network client is operating on

    =

    =C2=A0

    These are all attributes of the client that an AS may require=C2= =A0on the initial grant request, and in future grant requests (which is whe= n an instance_id) would be used.

    =C2=A0

    =C2=A0

    = This is where our interpretations differ: I don=E2=80=99t see these as =E2= =80=9Cattributes of the client=E2=80=9D in the same way that the key, displ= ay information, class identifiers, and other items currently represented by= an instance_id are attributes of the client instance. The attestation comp= onents don=E2=80=99t modify the instance so much as present additional info= rmation on top of the client instance itself. This is why I argue that they= ought to be handled in a separate object, so you=E2=80=99d have something = like this strawman:

    =C2= =A0

    {

    <= /div>

    =C2=A0

    =C2=A0 posture: {

    =C2=A0 =C2=A0 software_version: 1.2.3,

    =C2=A0 =C2=A0 os_version: 14.3.2

    =

    =C2=A0 =C2=A0 device_attestation: { =E2= =80=A6 some structure or signed blob? =E2=80=A6 }

    =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: = =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    =C2=A0<= /u>

    =C2=A0 client: =E2=80=9Ccli= ent-541-ab"

    =C2=A0<= u>

    }

    =C2=A0

    This is a more fundamental question about GNAP than whether the= syntax uses polymorphism: this is about GNAP being very explicit about the= data model of its elements. OAuth 2=E2=80=99s incredibly loose and broad m= odel of what the term =E2=80=9Cclient=E2=80=9D is referring to, exactly, is= deeply problematic in practice. We=E2=80=99re even seeing that in the OAut= h 2.1 work with having to define a =E2=80=9Ccredentialed client=E2=80=9D, a= nd even then that doesn=E2=80=99t fully capture the different aspects that = are out there. I think we=E2=80=99re getting closer here in GNAP with expli= cit definition of =E2=80=9Cclient instance=E2=80=9D, but we still need to b= e more precise about what exactly a client instance includes, and what it d= oes not.

    =C2=A0

    =C2=A0=E2=80=94 Justin=

    =C2=A0

    =C2=A0

    /Dick

    = =C2=A0

    Error! Filename not specifi= ed.=E1=90=A7

    =C2=A0

    On Fri, Oct 23, 2= 020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:

    Dick,

    =C2=A0

    As you=E2= =80=99ll recall, I argued against including the client instance identifier = inside of the object as a mutually-exclusive field precisely because of the= principle violation that you are pointing out here, and so it=E2=80=99s im= portant to point out that the current text is a compromise that needs to be= examined in the wider experience of the working group. I am on the side of= removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80=9D option withi= n an object, but this needs to be explored.

    =C2=A0

    The crux of my argument is that is exactly a case of pass-by-reference v= s pass-by-value, and that runtime attestations are not part of the =E2=80= =9Cclient instance=E2=80=9D value itself but rather belong outside of that = object in a another part of the request. As stated in the editorial notes i= n this section, we need to look carefully at how these concepts fit within = the model and where we would want to put them. Without concrete examples of= what these extensions look like and how they=E2=80=99re generated, that is= nearly impossible to do at this stage. I look forward to seeing examples o= f this kind of data and how it can fit into the protocol.

    =

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    <= blockquote style=3D"margin-top:5pt;margin-bottom:5pt">

    On Oct 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    =

    Hey Justin,

    =C2=A0

    As the = draft has evolved, I question the continued use of polymorphism. Note that = I appreciate the elegance=C2=A0of using a string for pass-by-reference, and= an object for pass-by-value.

    =C2=A0

    In the curr= ent draft, the=C2=A0

    =C2= =A0

    Every time you create or process a field it will = mean only one thing, and there=E2=80=99s only one field to look at to answe= r a question.=C2=A0

    =C2=A0

    =C2=A0<= /u>

    =C2=A0

    =C2= =A0 =C2=A0instance_id =C2=A0An identifier string that the AS can use to ide= ntify the

    =C2=A0 =C2=A0 = =C2=A0 particular instance of this RC.=C2=A0 The content and structure of t= his

    =C2=A0 =C2=A0 =C2=A0= identifier is opaque to the RC.

    =C2=A0

    =C2=A0 = =C2=A0"client": {

    =C2=A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541-ab= "

    =C2=A0 =C2=A0}=

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fie= lds to send, the RC MAY send the

    =C2=A0 =C2=A0instance identifier as a direct reference value in li= eu of the

    =C2=A0 =C2=A0o= bject.

    =C2=A0<= /u>

    =C2=A0 =C2=A0"client": &= quot;client-541-ab"

    =C2=A0

    Th= e instance identifier can be sent two ways. Polymorphism is a convenience f= or the client, but requires the server=C2=A0to have two code=C2=A0paths for= "instance_id".=C2=A0 We discussed this in the design team, and I= argued for having "instance_id" in the "client" object= =C2=A0so that any updates, such as new devices assertions, could be in the = "client" object. As noted above, while I appreciate the elegance = of using a string (handle) to reference a previously provided object, it co= mplicates how to update an existing object while providing the reference.

    =C2=A0

    <= /div>

    In your example of the "key" obj= ect below, setting "proof" to bearer would avoid the issue you de= scribe:

    =C2=A0=

    {=C2=A0
    =C2=A0"key":= {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"proof": "bearer"
    = =C2=A0 =C2=A0 }
    }

    = =C2=A0

    In your example, = when processing the "key" object, code is having to check both th= e JSON type of the property, as well as check the value of the "proof&= quot; property. In the example I provided, only the value of "proof&qu= ot; needs to be checked. The "proof" property is acting as a type= for the "key" object.

    =C2=A0

    Not bein= g a Java programmer, I don't know how this would work in a Java impleme= ntation, but node.js, the processing would need to be done as above.=

    =C2=A0

    =

    On a related note, there was significant negati= ve feedback on handles and polymorphism in the Hacker News article=C2=A0= https://news.ycombinator.com/item?id=3D24855750=C2=A0

    =

    =C2=A0

    /Dick

    = =C2=A0

    =C2=A0<= /u>

    On Fri, Oct 23, 2020 at= 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,

    =C2=A0

    Thanks for b= ringing this topic here =E2=80=94 I was able to see the forum discussion th= at brought you here, and hopefully I can help clear up what I mean with how= polymorphism is used in the proposal. The short version is that the goal i= s to=C2=A0avoid=C2=A0the kinds of ambiguity that make insecure proto= cols, and so in that goal we=E2=80=99re fully aligned. I think that using p= olymorphism in very specific ways can help that goal =E2=80=94 just as I ag= ree that misusing it or applying it sloppily can lead to ambiguous and inse= cure systems.

    =C2=A0<= /u>

    Some background: I built ou= t the XYZ protocol (one of the predecessors to the initial GNAP Draft) in J= ava using strongly typed parsers and Java objects specifically to prove to = myself that it could be done in a way that made any sense in the code. (My = own open source implementation is at=C2=A0https://github.com/bspk/oauth.xyz-java<= /a>, but note that it=E2=80=99s not yet up to date with the GNAP spec). It = was important to me that I be able to use the system-wide configured parser= s to implement this and not have to resort to stepping through elements com= pletely by hand. Java doesn=E2=80=99t make it simple to get the hooks into = the right places (especially with the Jackson parser that I used), but it i= s definitely possible to create a deterministic and strongly-typed parser a= nd serializer for this kind of data structure. Some of the rationale for us= ing polymorphism is covered in the trailing appendix of the draft document = (https://www.ietf= .org/archive/id/draft-ietf-gnap-core-protocol-00.html#name-json-structures-= and-polymor), but it=E2=80=99s still good to discuss this here as the w= orking group decides which approaches to take.=C2=A0

    =C2=A0

    The driving reason for using polymorphism at the protocol level= was to simplify the protocol and make it :more: deterministic to create an= d process, not less. Every time you create or process a field it will mean = only one thing, and there=E2=80=99s only one field to look at to answer a q= uestion. Without polymorphic field values, you usually need to rely on mutu= al exclusivity of fields, which is prone to failure and requires additional= error checking. Take for example the key binding of access tokens. An acce= ss token could be bound to the RC=E2=80=99s key used during the request, to= a different key chosen by the AS, or it could be a bearer token with no ke= y at all. By making the =E2=80=9Ckey=E2=80=9D field polymorphic, we can def= ine it in terms of boolean values and objects and express this set of mutua= lly-exclusive options in a non-ambiguous way. Without that, you=E2=80=99d n= eed to have different fields for the options and include additional checks = in your parser to make sure they weren=E2=80=99t sent simultaneously, other= wise you could get hit with this potential security vulnerability in an obj= ect:

    =C2=A0

    {=C2=A0

    =

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    <= /div>

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key = value =E2=80=A6 }

    =C2=A0= =C2=A0 },

    =C2=A0 =C2=A0= bearer_token: true,

    =C2= =A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0<= u>

    This would be an illegal object= as per this alternate proposal, but then you=E2=80=99d have to check each = field and make sure it wasn=E2=80=99t put next to others in the same object= . I=E2=80=99ve done this exercise with many other protocols and it=E2=80=99= s both error prone and easy to ignore since all the =E2=80=9Cgood=E2=80=9D = examples would pass code that doesn=E2=80=99t check this. With the polymorp= hic approach to this same field, each of these three mutually-exclusive sta= tes is written in a way that they cannot be sent together. It=E2=80=99s not= just illegal, it=E2=80=99s impossible and enforced by the syntax of JSON i= tself.

    =C2=A0<= /u>

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    <= div>

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80= =A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // bearer token

    <= p class=3D"MsoNormal">=C2=A0

    {

    =C2=A0 =C2=A0 key= : false

    }<= /p>

    =C2=A0

    // bound to the RC=E2=80=99s presented key=

    =C2=A0

    =

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0=

    If someone sends a different type= for this field, like an array or number or a null, this doesn=E2=80=99t ha= ve a defined interpretation in the protocol and would be a protocol level e= rror.

    =C2=A0

    While it might sound like polymorph= ism means that any field could have any type or value, the opposite is true= : each possible value is explicitly typed, it=E2=80=99s just that there are= potentially different types that express meaning for the field. This appli= es to all members of all objects (dictionaries) as well as all members of a= n array (list). Every time you process a field value or other element, you = look at the type and then the value to determine what to do with that typed= value.

    =C2=A0=

    In your example below, each field= within the dictionary would also need to be typed, and each type would nee= d to have a clear indication of its meaning. To take your strawman key form= at below, the =E2=80=9Cmodulus=E2=80=9D field could be defined polymorphica= lly as either a =E2=80=9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cenc= oded string=E2=80=9D (a JSON string). The definition would further say what= exactly the encoding of the string would be. That means that when you read= the =E2=80=9Cmodulus=E2=80=9D field there wouldn=E2=80=99t be any confusio= n on what the value was or how it was represented, regardless of the input = format. Seeing a number there means exactly one interpretation and seeing a= string means exactly one (different) interpretation =E2=80=94 but importan= tly, both of them are a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the= field that determines the type. An implementation would likely use an inte= rnal BigInteger type of object to represent the field value after parsing, = so the question is how to go from the JSON value (which is typed) into the = BigInteger value.You don=E2=80=99t just apply the type rules on the =E2=80= =9Cpublic_key=E2=80=9D field, you apply it to all sub-fields of that object= .=C2=A0

    =C2=A0=

    So let=E2=80=99s dig into the spe= cific bug you bring up in the strawman, because it=E2=80=99s interesting: A= JSON encoder that encodes numbers as strings, and not numbers, is not comp= liant with the JSON definitions of the field in question. For another examp= le, the quoted string value of =E2=80=9Ctrue=E2=80=9D is not equivalent to = the boolean value true in JSON, and they shouldn=E2=80=99t be treated the s= ame by a parser implementation when mapping to a concrete object. It=E2=80= =99s in this kind of automated guessing that this class of bugs occur, and = that=E2=80=99s going to be the case whether or not you take =C2=A0advantage= of JSON=E2=80=99s polymorphic nature. I=E2=80=99ve run into cases where a = parser library was trying to be overly =E2=80=9Chelpful=E2=80=9D in doing t= his kind of mapping, but ended up introducing errors in more strict compone= nts downstream. This is something that protocol designers need to be aware = of and guard against in the design of the protocol to reduce possible ambig= uities. Within GNAP today, we generally have things that branch whether the= y=E2=80=99re an object (for a rich description of something) or some non-st= ructured special value (for a reference or other item).=C2=A0=

    =C2=A0

    The design team created some simple JSON Schemas for p= arts of the protocol during our discussion, but we didn=E2=80=99t include t= hem in the design document due to both lack of time to keep it updated with= the rapid changes to the protocol during the design team discussion, and n= ot knowing if there would be interest in such material. I personally think = it would be helpful to include as an informative reference in the final doc= ument, but that=E2=80=99s something for the working group to take up eventu= ally.

    =C2=A0

    =C2=A0=E2=80=94 Justin

    = =C2=A0

    On Oct 23, 2020, at 10:18 AM, Mika Bostr=C3=B6m &l= t;mika.bostrom=3D40smarkets.com@dmarc.ietf.org> wrote:=

    =C2=A0

    <= div>

    Hello, everyone.

    =C2=A0

    For background: GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and= when I made note about certain concerns, I was requested to send my commen= ts to this working group.

    =C2=A0

    In short, I bel= ieve that the use of polymorphic JSON in the protocol invites subtle and co= nfusing implementation problems. I also searched through the WG archives, a= nd noticed that similar concerns were noted, briefly, in a thread in July. =

    =C2=A0

    The problem with polymorphic values, as = I see it, is that implementations will need to branch on the (inferred) typ= e of a given field. This isn't quite as bad if the types are strictly d= ifferent, but allows for subtle bugs when the value in question is a dictio= nary. What makes this unappealing is that "subtle bugs" in securi= ty protocols have a habit of turning into vulnerabilities.

    =C2=A0

    Let's say we have these imaginary payloads, both poss= ible and valid in the same protocol step:

    =C2=A0

    # payload 1

    {=

    =C2=A0 ...,

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": = "rsa",

    =C2=A0= =C2=A0=C2=A0 "modulus": <BIGINT>

    =C2=A0 }

    }

    =C2=A0

    # payload 2

    =

    {

    =C2=A0 ...,

    = =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",=

    =C2=A0=C2=A0=C2=A0 "modulus"= ;: "<encoded string>"

    =C2=A0 }

    = }

    =C2=A0

    In both cases, the type of "public= _key" field is a dictionary. In both cases, they even have the same ke= ys. However, the values in the dictionaries are entirely different, and an = implementation will have to branch to at least two possible decoding mechan= isms. To make things worse, some JSON implementations may choose to encode = non-dictionary values as strings, so it is possible for an originator to tr= ansmit what they expect and believe to be payload 1 format, but which the r= eceiver will interpret to be in payload 2 format. And if the encoded string= contains only digits, it will even parse correctly as a bignum.<= /u>

    =C2=A0

    While the above is clearly a manufactured scenario,= it nonetheless demonstrates the potential for logic bugs with polymorphic = JSON. With richer types and more complex dictionaries, there will surely be= more room for errors.

    = =C2=A0

    Ambiguity in prot= ocols is always a source of implementation complexity and interoperability = snags, but in an AuthN/AuthZ protocol it is worse: it's terrifying. If = GNAP/Oauth3 is intended to supersede Oauth1/2, wouldn't it be in everyo= ne's interest to keep implementation complexity and mistake potential t= o a minimum?

    =C2=A0

    Best regards,<= /p>

    Mika

    =C2=A0

    -- <= u>

    = Mika Bostr=C3=B6m

    Smarkets=

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/t= xauth

    = =C2=A0

    --
    TXAuth mailing = list
    TXAuth@ietf.or= g
    https://www.ietf.org/mailman/listinfo/txauth

    =

    Error! Filename not specified.=E1=90=A7

    =C2=A0

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth

    =


    --

    Mika= Bostr=C3=B6m

    Smarkets=

    -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

    = --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=


    --0000000000005f40b705b2e631b5--
    Hi Yaron,=C2=A0

    Thanks a lot= for the feedback, I fixed the issue related to the standardisation status = (I guess there's some historic background that I don't know ;-)).

    Is JSON the only real possible format? Probably, at= least for compatibility with pretty much everything that exists. Only TJSO= N could maybe be used as an alternative (and kind of removes the need for a= schema), with the downsides that you don't have so many existing libra= ries and that the community seems much smaller: 2k stars for JSON schema sp= ec vs 65 for TJSON spec (and the expired website SSL certificate doesn'= t help).=C2=A0 =C2=A0

    The main problem I see is th= at for constrained cases, CBOR won't have a schema in a foreseeable fut= ure (at least I'm not aware of any work on that). I know it's not o= ur main focus right now and might not even be covered by the current WG, bu= t still it might become an issue at some point.=C2=A0

    <= div>Best,
    Fabien=C2=A0 =C2=A0

    On Fri, Oct 30, 2020 at 3:19 PM Yaro= n Sheffer <yaronf.ietf@gmail.co= m> wrote:

    Hi Fabien,<= /u>

    =C2=A0

    One correction, JSON Schema (which I am personally advocating for,= but still) does not have an IETF spec. They claim on their web site that t= hey want it standardized, but in practice are not (yet?) moving in this dir= ection. Their Internet Draft is unmaintained.

    =C2=A0

    At a higher level= , I think your discussion conflates two things: the representation of data = on the wire (JSON or various mostly binary encodings) and the data modeling= language, a.k.a. schema. Personally I think JSON is almost a must in our c= ase, and if this is true, the playing field is *much* more narrow.

    =C2=A0

    A major strength of JSON which you don=E2=80=99t mention in your= comparison is the cryptographic ecosystem (JOSE): standard formats for enc= ryption, signature etc.

    =C2= =A0

    I wasn=E2=80=99t aware of Ion. I don= =E2=80=99t think it=E2=80=99s a good fit for us, still a very interesting d= irection.

    =C2=A0

    <= p class=3D"MsoNormal">Thanks,

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Yaron

    =C2=A0=

    From: Fabien Imbault <fabien.imbault@gmail.com&g= t;
    Date: Friday, October 30, 2020 at 14:53
    To: Andrii D= einega <an= drii.deinega@gmail.com>
    Cc: Mika Bostr=C3=B6m <mika.bostrom@smarke= ts.com>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, GNAP = Mailing List <txaut= h@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP= ] Feedback on polymorphism

    =C2=A0

    Hi Just= in,=C2=A0

    =C2=A0=

    > Regarding your question, what el= se could we propose?=C2=A0

    =C2=A0

    I've start= ed a review of possibilities at=C2=A0https://gith= ub.com/fimbault/reasonably-polymorphic/blob/main/README.md to be follow= ed by actual code testing.=C2=A0

    =C2=A0

    Cheers,<= u>

    Fabien

    =

    =C2=A0

    On Thu, Oct 29, 2020 at 8:23 PM Andrii Deinega <andrii.deinega@gmail= .com> wrote:

    Hi=C2=A0Mika, Justin, and WG,

    =C2=A0

    The act (actor) claim introduced in RFC 8693 (OAuth 2.0 Token Excha= nge) has a JSON object as its value. This claim could be a part of AT JWT o= r a token introspection response and has the same semantics in both cases. = The JSON object as its value may look like this

    "act":
    = {
    =C2=A0 "sub":"admin@example.com"
    }

    or even be nested lik= e in

    "act":
    {
    =C2=A0"sub":"https://service16.example= .com",
    =C2=A0 =C2=A0"act":
    =C2=A0 =C2=A0{
    =C2= =A0 =C2=A0 =C2=A0"sub":"https://service77.example.com"
    =C2=A0 = =C2=A0}
    }

    Personally, I find it to be a very expressive approach.= Also, as far I as know, several (oAuth2) client libraries have good suppor= t of things like

    "aud":"https://service1.example.com" and &q= uot;aud":["https://service1.example.com","https://service2.example.com"]
    in AT JWTs for a quite long time.

    =C2=A0

    Regards= ,

    Andrii

    =C2=A0

    On Wed, Oct 28, 2020 at 12:58 PM Fabien Imbault <fabien.imbault@gm= ail.com> wrote:

    <= p class=3D"MsoNormal">Hi Yaron,

    =C2=A0

    We'll indee= d have to check how make it as idiomatic as possible with experts of each l= anguage (help welcome).=C2=A0

    =C2=A0

    Regarding t= he client, the variations are more limited but they do exist. Here I believ= e it's much more problematic than on the server side and there are at l= east a few actions we should take:

    =C2=A0

    A) che= ck in sec 7 if we really have a compelling reason for key and proof variant= s. This is derived from larger discussions on key binding as per the relate= d note. There are quite a few open questions related to this theme.=C2=A0

    =C2=A0

    <= /div>

    B) there is also the choice between value/= reference that may generate complexity.=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    C) More generally, as many feedbacks already have noticed, we need to = have a systematic review and reduce the set of available options in the pro= tocol.=C2=A0

    =C2= =A0

    Unless we have a clear idea why runtime behavior requires= mutability, it might be useful to have a way to define the chosen variant = before hand, so that the expected behavior becomes deterministic on the cli= ent side. There are various ways it could be done in practice.=C2=A0=

    =C2=A0

    For sure several independant implementat= ions would help, especially if we make sure they can work together.=C2=A0

    =C2=A0

    <= /div>

    Anyway all this open to improvement.=C2=A0=

    =C2=A0

    Cheers=C2=A0

    Fabien=C2=A0

    =C2=A0

    Le mer. 28 oct. 2020 =C3=A0 19:47, Yaron Sheffer <yaronf.ietf@gmail.c= om> a =C3=A9crit=C2=A0:

    Hi Fabien,

    =C2=A0

    At least in the c= ase of Go, I think the =E2=80=9Csolution=E2=80=9D is far worse than the pro= blem. The code in the article you cite is very specific to the use case and= IMHO quite ugly. So my preferred Go implementation would be a combination = of untyped structures (Go interface{}) and run-time enforcement of JSON Sch= ema.

    =C2=A0

    Also, going back to our earlier discussion on this topic, = I just read Sec. 7 of gnap-00 and realized that the RC also needs to deal w= ith polymorphism (the =E2=80=9Ckey=E2=80=9D value), not only the AS.=

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbau= lt <fabien= .imbault@gmail.com>
    Date: Wednesday, October 28, 2020 at 1= 8:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Dick Hardt <dick.hardt@gmail.com><= br>Subject: Re: [GNAP] Feedback on polymorphism    =

    =C2=A0

    Thanks for the great feedback. Your concern is very va= lid.=C2=A0

    =C2=A0<= u>

    My implementation is in rust, w= hich makes life easier in that specific case.=C2=A0

    =

    =C2=A0

    So I'm not a golang specialist but I guess the transcr= iption of json strings/arrays into go structs would work around the lines d= escribed by=C2=A0https://medium.com/@alexkappa/json-p= olymorphism-in-go-4cade1e58ed1

    When we have a more formalized json schema, I suggest we make a = library of json examples and some related code samples in mainstream langua= ges, to check it is feasible for everyone.=C2=A0

    =C2=A0

    Cheers,

    Fabien

    =C2=A0

    <= /div>

    =C2=A0

    On Wed, Oct 28, 2020 at 5:28 PM Mika Bostr=C3=B6m <mika.bostrom@smar= kets.com> wrote:

    Hi everyone,

    =C2=A0

    Looks like= I stuck my finger in a hornets' nest. First off, apologies for not chi= pping in earlier, but there was a lot of material to digest. Also, warning:= lots to read ahead.

    =C2= =A0

    I'm one of those= people who end up making use of AuthN/AuthZ functionality through a librar= y. On top of that I can see myself being roped in as a server (AS) implemen= tation help. So I'm approaching this from an outsider's perspective= . Someone who expects to be exposed to the eventual RFC and all the nitty-g= ritty details. My relatively terse comment ended up at the top of the afore= mentioned HN thread, which didn't necessarily help. Sorry about that.

    =C2=A0

    <= /div>

    Now, having read Justin's initial repl= y - and the rest of the thread - I believe I can see where the desire for p= olymorphism comes from. To be clear: I am all for strict types inside an im= plementation, as it will add helpful guard-rails to the state management co= de paths. However, I see this as a case of leaky abstraction. If we take th= e existing oauth.xyj-java code to be the reference implementation, the choi= ce makes logical sense: JSON is not expressive enough to serialise arbitrar= y objects, so in order to avoid writing complex payload parser(s) the inter= nal implementation details now leak to the protocol itself. From a purely t= echnical perspective, it's a cool trick. From a distance it even looks = a bit like the result of protobuf decoding, but without the generated code = parts.

    =C2=A0<= /u>

    But then the downside. I don't= personally expect to be able to use the reference implementation, being mo= stly a Python user myself. A fair number of AS implementations will be writ= ten with languages such as Go, Python, C#, Ruby, and JavaScript (thanks to = node.js), and all of them will have to deal with the polymorphism. From wha= t I've read over the past couple of days, I understand that at least Go= supports custom unmarshalers from JSON to typed structs, at the cost of an= indirection. Normally when a Go code processes JSON to a typed struct, the= process is helped by field annotations in the type definition itself. For = example, if the payload for a person in JSON was

    =C2=A0

    {

    =C2=A0 "n= ame": "<string>",

    =C2=A0 "age": <int>,

    =

    =C2=A0 "country": "<string>= ;",

    =C2=A0 "ci= ty": "<string>"

    }

    =C2=A0<= u>

    .. then the type definit= ion would look like:

    =C2= =A0

    type Person struct {=

    =C2=A0 Name string `jso= n:"name"

    =C2= =A0 Age int `json:"age"`

    =C2=A0 Country string `json:"country"`

    =C2=A0 City string `json:"city&quo= t;`

    }

    <= /div>

    =C2=A0

    When the (possibly complex) type of a given field is fixed,= unmarshaling should still be straightforward. I haven't verified, but = since the annotation only gives which field to look at for a given typed va= lue, there should be nothing special about that. But when the field can ins= tead be a union of more than one distinct types, things start to get messy.= There is no union type in the language at all, so the following construct = is not even possible:

    = =C2=A0

    type Entity struc= t {

    =C2=A0 Resources []s= tring `json:"resources"`

    =C2=A0 Client union(Client, string) `json:"client"`=

    }

    <= div>

    =C2=A0

    As I understand, the implicit expectation is that in the above ca= se, the unmarshaler detects that "client" is a string, and so exp= ands it from an opaque handle to the expected, populated type. Even after t= hinking about the ramifications over the past few days I remain confused, b= ecause I don't see how the commonly used annotations could work. If the= expectation is that protocol implementations should use strong types, then= the use of polymorphic JSON is very likely to make things _more_ complicat= ed for non-reference implementations.

    =C2=A0

    Hence m= y concern. I'm afraid that the leaky abstraction, while making the refe= rence implementation more robust and straightforward, contributes to making= other implementations less robust. And this being a security protocol, the= potential for brittle and/or confused implementations is terrifying.

    =C2=A0

    I am a fan of reducing complexity, and from what I = can see, for the reference implementation the polymorphic approach actually= does that. But I'm afraid it does so at others' expense. Languages= have their individual constraints, idioms and best practices. If parsing a= protocol payload introduces low-level complexities and encourages to go ag= ainst common practices, that is an invitation for problems. I am aware that= my choice of words in the HN thread was likely to put people on defense, a= nd for that I apologise. But I do believe that the choice of polymorphic JS= ON is going to make the life and use of other implementations notably less = boring than people in general would prefer.

    =C2=A0

    Cheers,

    Mika

    =C2=A0

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <= fabien.imbaul= t@gmail.com> wrote:

    Hi Dick,

    =C2= =A0

    Well technically yes= . Obviously the client can present any interface it seems fit.=C2=A0=

    =C2=A0

    =

    Still there's the question of the common mo= del we want to present to the outside world and supported by the protocol i= tself (which client libraries all build upon).=C2=A0

    =C2=A0

    But beneath the polyphormism question, the HN debate seems on t= he surface a lot like the original xyz (polyphormism goes along with the re= duced endpoint model) vs xauth (a bit closer to OAuth2 in spirit, and where= the client design has more latitude). Just explained differently, by outsi= de people with different agendas.=C2=A0

    =C2=A0

    W= hich is a bit weird because many of the critics on HN (who criticize polyph= ormism) also seem to really dislike OAuth in the first place (the inconsist= encies are partially due to a bunch of different people commenting).=C2=A0<= u>

    =C2=A0

    =

    Really to me there's no fundamental t= ruth behind that question. It's a matter of preference and priorities i= n the design. Whatever choices we make, we'll have to be prepared to ex= plain and justify them in the open, even to some people that will dislike p= retty much whatever we do (because it's fun to look smart and critize w= ithout proposing alternatives). And we owe these answers to people like Mik= a, who genuinely try to make the best of it.=C2=A0

    <= div>

    =C2=A0

    Fabien=C2=A0

    = =C2=A0

    Le lun. 26 oct. 20= 20 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

    Hi Fabien

    =C2=A0

    A library developer can provide whatever abstraction layer = makes sense for the library's target=C2=A0audience and language.=

    =C2=A0

    =

    If the client library=C2=A0developer wants to u= se polymorphism=C2=A0in the interface presented to the user's of the li= brary, the library developer can do that independent of polymorphism in the= protocol, and vice versa=C2=A0

    =C2=A0

    =3D> p= olymorphism in the protocol has no impact on client library developers

    =C2=A0

    =C2=A0

    = Error! Filename not specified.=E1=90=A7

    =C2=A0

    On Sat, Oct 24, 2020 at 3:40 PM Fabien Imbault <fabien.imbault@gmail= .com> wrote:

    I'm just realizing your "least to most important" mi= ght actually say the same as what I was trying to say. So I'm not even = sure what we're arguing against :-)=C2=A0

    =C2=A0

    I= n brief my point if it wasn't clear is that we should be crystal clear = on where we put the cursor of simplicity, because this can mean different t= hings for different people and different roles.=C2=A0

    And as we see on HN we need to better explain= our design choices.=C2=A0

    =C2=A0

    =C2=A0=

    Le dim. 25 oct. 2020 =C3=A0 00:= 25, Fabien Imbault <fabien.imbault@gmail.com> a =C3=A9crit=C2=A0:<= /u>

    Hi Dick,

    =C2=A0

    Independantly from the debate on polyphormism, I beg to dif= fer on your order preference.=C2=A0

    =C2=A0

    Your = assumption is that AS devs matter the most,=C2=A0because they're doing the important security impleme= ntation. But eating our own dogfood might help a lot to change that view. M= ost security issues occur because users of the spec are unable to deal with= the complexity that is passed onto them.=C2=A0

    =C2=A0

    99% of the people that will actually use the output of the w= ork are application developers (client or RS) and their own users.=C2=A0=

    =C2=A0

    Our intent as well as the protocol drive the usage. Client libraries may = help, but they're not a silver bullet, especially because GNAP ultimate= ly has no control about what people do there (for better or worse). And eve= rything we do here will help get to the better part.=C2=A0=

    =C2=A0

    I'm not saying we don't intend to also car= e about AS developers (beginning with ourselves) but it's a second orde= r optimisation. And since it's a tendancy we're leaning towards by = default, I'm pretty sure we won't forget that anyway.=C2=A0<= u>

    =C2=A0

    <= div>

    Fabien=C2=A0

    =C2=A0

    =C2=A0

    Le sam. 24 oct. 2020 =C3=A0 23:50, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:

    I'm confused by your logic Fabien.

    =C2=A0

    If a client library developer wants to expose polymorphism, they can= do that independent of what is in the protocol.=C2=A0

    =C2=A0

    I differ on who our stakeholders are.=C2=A0

    =C2=A0

    I think our stakeholders are in least to most important:<= u>

    =C2=A0

    =
    • AS developer=
    • RS developer
    • client developer
    • u= ser

    =C2=A0<= u>

    A client library developer can = expose whatever interface they want to simplify implementation.

    =C2=A0

    =

    I list the user so that we don't lose site of a = critical role.

    =C2=A0=

    /Dick

    =C2=A0

    =C2=A0

    Error! Filen= ame not specified.=E1=90=A7

    =C2=A0

    On= Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    Hi th= ere,=C2=A0

    =C2=A0=

    Let me try to approach the issue un= der a different light. More like a product manager would deal with feature = selection to make it intuitive for its users.=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    For most people, riding a bike is far easier than using a unicycl= e. Feels more stable. And yet it's way easier to design for a single wh= eel than to build with 2. Because then you'll need a lot more accessori= es (chain, chain ring, etc.). Even so producing a bike doesn't have to = be a brittle process, it can be industrialized.=C2=A0

    =C2=A0

    Back to the GNAP topic.=C2=A0

    Ultimately we s= hould strive to make the spec as simple as can be. But we need to ask: simp= le for whom? For the bike owner or for the bike vendor?=C2=A0=

    (short answer: the priority should be simplicity for spec us= ers, not spec implementers and even less spec designers).=C2=A0

    =C2=A0

    The initial question that is asked is very in= teresting: isn't the design flawed if GNAP is using json polyphormism? = Or if the AS needs to handle the state of the request? Or if we must handle= token revocation? Or if we are looking for a global unique identifier? The= argument stems of the fact that is still arguably harder and more error pr= one to implement. Fair enough.=C2=A0

    =C2=A0

    Fr= om a spec implementer's perspective, it may well be more complex. It mo= stly impacts the json library you'll end up using, plus a bit of input/= output decoration around it. Even golang provides utilities for this, despi= te not exactly being made for this kind of purpose.

    =

    My practical experience implementing it is that= it's not that big a deal. I mean, I wished it could be simpler, but it= 's manageable and there are other ways to reach levels of insurance tha= t it does work as intended (json schema, test cases to validate the impleme= ntation, etc.). Arguably it is still easier from an implementation perspect= ive than say, json-ld, which is massively used in the SSI community.=C2=A0<= u>

    =C2=A0

    =

    But ultimately who are we designing for? = Are we striving to go easy on the spec implementer? Or are we trying to mak= e sure end-developers using the client libraries won't shoot themselves= in the foot?

    =C2=A0<= /u>

    The job to be done (JTBD), = from the end-developer's perspective, is to efficiently ship an applica= tion. And provide authN/authZ capabilities for end-users by relying on some= well known implementation.=C2=A0

    In turn, this spec implementer will rely on cryptographic utility= libraries that deals internally with the complexity of their own domain, s= o that we don't have to. And here we could launch another HN flame war = that starts with the title "JWT sucks because". Which does have i= ts set of very real issues but that's beyond the point.=C2=A0=

    Note that any decent flamewar wil= l be efficiently fueled by people hating medium. Is it outrageous for blog = posts to be behind a paywall? Maybe but it's even more outrageous to la= ck consistency, either by not knowing how to get around a paywall if you= 9;re into a hacker punk movement, or on the contrary by to not paying a sub= scription if you believe that surveillance capitalism, to reuse Zuboff'= s terms, should be eradicated.=C2=A0

    What likely seems an unnecessary sidenote tries to illustrat= e the point: for Justin it was easier to publish on medium, because as a bl= og publisher, you might not want to deal with hosting your own blog. But ma= ybe as a reader you'll find that annoying. Different audiences, differe= nt JTBD, different tradeoffs.=C2=A0

    =C2=A0

    Polyp= hormism is a tool that enables the end-developer to have minimal knowledge = of what it means to deal with a GNAP client library. You prepare the reques= t, send to the endpoint and you're good to go. Massively simpler than O= Auth2 or any similar protocol by the way (as anyone with teaching experienc= e on the subject might acknowledge). And=C2=A0 there's a lot more to be= done to make sure we indeed reduce the complexity for the end-developer an= d the end-user.=C2=A0

    = =C2=A0

    If we find a bett= er way to deal with that simplicity balance, I'm all in. But the argume= nts need to be way more convincing than just saying that it may be difficul= t to implement or validate.=C2=A0

    =C2=A0

    Cheers.=

    Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0=

    =C2=A0=

    Le ven. 23 oct. 2020 =C3=A0 22:35, Jus= tin Richer <jricher= @mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0

    =C2=A0

    On Oct 23= , 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    Justin

    =C2=A0=

    I did note that I was the one tha= t argued for instance_id being in the object. Since it is in the object in = the current draft, not including a pass by reference option would be prefer= able.=C2=A0

    =C2=A0

    As for concrete examples:<= /u>

    - version of client<= u>

    - version of OS

    - security attestation of OS / device

    - location of client devi= ce

    - network client is o= perating on

    =C2=A0

    These are all attributes of t= he client that an AS may require=C2=A0on the initial grant request, and in = future grant requests (which is when an instance_id) would be used.<= u>

    =C2=A0

    <= /div>

    =C2=A0

    This is where our interpretations differ= : I don=E2=80=99t see these as =E2=80=9Cattributes of the client=E2=80=9D i= n the same way that the key, display information, class identifiers, and ot= her items currently represented by an instance_id are attributes of the cli= ent instance. The attestation components don=E2=80=99t modify the instance = so much as present additional information on top of the client instance its= elf. This is why I argue that they ought to be handled in a separate object= , so you=E2=80=99d have something like this strawman:

    =C2=A0

    {

    =C2=A0<= u>

    =C2=A0 posture: {=

    =C2=A0 =C2=A0 software_version= : 1.2.3,

    =C2=A0 =C2=A0 o= s_version: 14.3.2

    =C2=A0= =C2=A0 device_attestation: { =E2=80=A6 some structure or signed blob? =E2= =80=A6 }

    =C2=A0 =C2=A0 l= ocation: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }

    =C2=A0 },

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"

    =C2=A0

    }

    =C2=A0<= u>

    This is a more fundamental ques= tion about GNAP than whether the syntax uses polymorphism: this is about GN= AP being very explicit about the data model of its elements. OAuth 2=E2=80= =99s incredibly loose and broad model of what the term =E2=80=9Cclient=E2= =80=9D is referring to, exactly, is deeply problematic in practice. We=E2= =80=99re even seeing that in the OAuth 2.1 work with having to define a =E2= =80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2=80=99t full= y capture the different aspects that are out there. I think we=E2=80=99re g= etting closer here in GNAP with explicit definition of =E2=80=9Cclient inst= ance=E2=80=9D, but we still need to be more precise about what exactly a cl= ient instance includes, and what it does not.

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    =C2=A0

    /Dick

    =C2=A0

    Error! Filename not specified.=E1=90=A7<= /u>

    =C2=A0

    On Fri, Oct 23, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrot= e:

    Dick,=

    =C2=A0

    As you=E2=80=99ll recall, I argued against includ= ing the client instance identifier inside of the object as a mutually-exclu= sive field precisely because of the principle violation that you are pointi= ng out here, and so it=E2=80=99s important to point out that the current te= xt is a compromise that needs to be examined in the wider experience of the= working group. I am on the side of removing the mutually-exclusive =E2=80= =9Cinstance_id=E2=80=9D option within an object, but this needs to be explo= red.

    =C2=A0

    The crux of my argument is that is e= xactly a case of pass-by-reference vs pass-by-value, and that runtime attes= tations are not part of the =E2=80=9Cclient instance=E2=80=9D value itself = but rather belong outside of that object in a another part of the request. = As stated in the editorial notes in this section, we need to look carefully= at how these concepts fit within the model and where we would want to put = them. Without concrete examples of what these extensions look like and how = they=E2=80=99re generated, that is nearly impossible to do at this stage. I= look forward to seeing examples of this kind of data and how it can fit in= to the protocol.

    =C2=A0<= u>

    =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct 23, 2020, at 3:07 PM, Dick = Hardt <dick.ha= rdt@gmail.com> wrote:

    = =C2=A0

    Hey Justin,

    =C2=A0

    <= div>

    As the draft has evolved, I question the continu= ed use of polymorphism. Note that I appreciate the elegance=C2=A0of using a= string for pass-by-reference, and an object for pass-by-value.

    =C2=A0

    =

    In the current draft, the=C2=A0

    =C2=A0

    Every time you = create or process a field it will mean only one thing, and there=E2=80=99s = only one field to look at to answer a question.=C2=A0

    =C2=A0

    is violated in 2.3.= 1.=C2=A0 Identifying the RC Instance

    =C2=A0

    = =C2=A0

    =C2=A0 =C2=A0instance_id =C2=A0An identifier s= tring that the AS can use to identify the

    =C2=A0 =C2=A0 =C2=A0 particular instance of this RC.=C2= =A0 The content and structure of this

    =C2=A0 =C2=A0 =C2=A0 identifier is opaque to the RC.<= u>

    =C2=A0

    <= div>

    =C2=A0 =C2=A0"client": {=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0"inst= ance_id": "client-541-ab"

    =C2=A0 =C2=A0}

    =C2=A0

    =C2=A0 = =C2=A0If there are no additional fields to send, the RC MAY send the=

    =C2=A0 =C2=A0instance identifi= er as a direct reference value in lieu of the

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0object.

    =C2=A0

    =C2=A0 =C2=A0"client": "client-541-ab"<= /p>

    =C2=A0

    <= /div>

    The instance identifier can be sent two wa= ys. Polymorphism is a convenience for the client, but requires the server= =C2=A0to have two code=C2=A0paths for "instance_id".=C2=A0 We dis= cussed this in the design team, and I argued for having "instance_id&q= uot; in the "client" object=C2=A0so that any updates, such as new= devices assertions, could be in the "client" object. As noted ab= ove, while I appreciate the elegance of using a string (handle) to referenc= e a previously provided object, it complicates how to update an existing ob= ject while providing the reference.

    =C2=A0

    In yo= ur example of the "key" object below, setting "proof" t= o bearer would avoid the issue you describe:

    =C2=A0

    {=C2=A0
    =C2=A0"key": {=C2=A0
    =C2=A0 =C2=A0 =C2=A0"= proof": "bearer"
    =C2=A0 =C2=A0 }
    }

    =

    =C2=A0

    In your example, when processing the "key" objec= t, code is having to check both the JSON type of the property, as well as c= heck the value of the "proof" property. In the example I provided= , only the value of "proof" needs to be checked. The "proof&= quot; property is acting as a type for the "key" object.

    =C2=A0

    Not being a Java programmer, I don't know how= this would work in a Java implementation, but node.js, the processing woul= d need to be done as above.

    =C2=A0

    On a related = note, there was significant negative feedback on handles and polymorphism i= n the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24= 855750=C2=A0

    =C2=A0<= u>

    /Dick

    <= /div>

    =C2=A0

    =C2=A0

    On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu> wrote:

    Hi Mika,<= u>

    =C2=A0

    Thanks for bringing this topic here =E2=80=94 I was ab= le to see the forum discussion that brought you here, and hopefully I can h= elp clear up what I mean with how polymorphism is used in the proposal. The= short version is that the goal is to=C2=A0avoid=C2=A0the kinds of a= mbiguity that make insecure protocols, and so in that goal we=E2=80=99re fu= lly aligned. I think that using polymorphism in very specific ways can help= that goal =E2=80=94 just as I agree that misusing it or applying it sloppi= ly can lead to ambiguous and insecure systems.

    =

    =C2=A0

    Some background: I built out the XYZ protocol (one of the predecessor= s to the initial GNAP Draft) in Java using strongly typed parsers and Java = objects specifically to prove to myself that it could be done in a way that= made any sense in the code. (My own open source implementation is at=C2=A0= https:= //github.com/bspk/oauth.xyz-java, but note that it=E2=80=99s not yet up= to date with the GNAP spec). It was important to me that I be able to use = the system-wide configured parsers to implement this and not have to resort= to stepping through elements completely by hand. Java doesn=E2=80=99t make= it simple to get the hooks into the right places (especially with the Jack= son parser that I used), but it is definitely possible to create a determin= istic and strongly-typed parser and serializer for this kind of data struct= ure. Some of the rationale for using polymorphism is covered in the trailin= g appendix of the draft document (https://www.ietf.org/archive/id/draft-ietf-gnap-core-proto= col-00.html#name-json-structures-and-polymor), but it=E2=80=99s still g= ood to discuss this here as the working group decides which approaches to t= ake.=C2=A0

    =C2=A0=

    The driving reason for using p= olymorphism at the protocol level was to simplify the protocol and make it = :more: deterministic to create and process, not less. Every time you create= or process a field it will mean only one thing, and there=E2=80=99s only o= ne field to look at to answer a question. Without polymorphic field values,= you usually need to rely on mutual exclusivity of fields, which is prone t= o failure and requires additional error checking. Take for example the key = binding of access tokens. An access token could be bound to the RC=E2=80=99= s key used during the request, to a different key chosen by the AS, or it c= ould be a bearer token with no key at all. By making the =E2=80=9Ckey=E2=80= =9D field polymorphic, we can define it in terms of boolean values and obje= cts and express this set of mutually-exclusive options in a non-ambiguous w= ay. Without that, you=E2=80=99d need to have different fields for the optio= ns and include additional checks in your parser to make sure they weren=E2= =80=99t sent simultaneously, otherwise you could get hit with this potentia= l security vulnerability in an object:

    =C2=A0

    {= =C2=A0

    =C2=A0 =C2=A0 key= : {

    =C2=A0 =C2=A0 =C2=A0= proof: httpsig,

    =C2=A0 = =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    <= p class=3D"MsoNormal">=C2=A0 =C2=A0 bearer_token: true,

    =C2=A0 =C2=A0 bind_to_rc_key: true

    }

    =C2=A0

    This would be an illegal object as per this alternate proposal, but the= n you=E2=80=99d have to check each field and make sure it wasn=E2=80=99t pu= t next to others in the same object. I=E2=80=99ve done this exercise with m= any other protocols and it=E2=80=99s both error prone and easy to ignore si= nce all the =E2=80=9Cgood=E2=80=9D examples would pass code that doesn=E2= =80=99t check this. With the polymorphic approach to this same field, each = of these three mutually-exclusive states is written in a way that they cann= ot be sent together. It=E2=80=99s not just illegal, it=E2=80=99s impossible= and enforced by the syntax of JSON itself.

    =C2=A0

    {=C2=A0

    =C2=A0 = =C2=A0 key: {

    =C2=A0 =C2= =A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 }

    }

    =C2=A0

    // beare= r token

    =C2=A0=

    {

    =C2=A0 =C2=A0 key: false

    }

    =C2=A0

    // bound to = the RC=E2=80=99s presented key

    =C2=A0

    {

    =C2=A0 =C2=A0 key: true

    }

    =C2=A0

    If someone sends a different type for this field, like an array or numb= er or a null, this doesn=E2=80=99t have a defined interpretation in the pro= tocol and would be a protocol level error.

    =C2=A0

    While it might sound like polymorphism means that any field could have an= y type or value, the opposite is true: each possible value is explicitly ty= ped, it=E2=80=99s just that there are potentially different types that expr= ess meaning for the field. This applies to all members of all objects (dict= ionaries) as well as all members of an array (list). Every time you process= a field value or other element, you look at the type and then the value to= determine what to do with that typed value.

    =C2=A0

    In your example below, each field within the dictionary would also need= to be typed, and each type would need to have a clear indication of its me= aning. To take your strawman key format below, the =E2=80=9Cmodulus=E2=80= =9D field could be defined polymorphically as either a =E2=80=9Cbigint=E2= =80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (a JSON strin= g). The definition would further say what exactly the encoding of the strin= g would be. That means that when you read the =E2=80=9Cmodulus=E2=80=9D fie= ld there wouldn=E2=80=99t be any confusion on what the value was or how it = was represented, regardless of the input format. Seeing a number there mean= s exactly one interpretation and seeing a string means exactly one (differe= nt) interpretation =E2=80=94 but importantly, both of them are a =E2=80=9Cm= odulus=E2=80=9D, since that=E2=80=99s the field that determines the type. A= n implementation would likely use an internal BigInteger type of object to = represent the field value after parsing, so the question is how to go from = the JSON value (which is typed) into the BigInteger value.You don=E2=80=99t= just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D field, you a= pply it to all sub-fields of that object.=C2=A0

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up in the straw= man, because it=E2=80=99s interesting: A JSON encoder that encodes numbers = as strings, and not numbers, is not compliant with the JSON definitions of = the field in question. For another example, the quoted string value of =E2= =80=9Ctrue=E2=80=9D is not equivalent to the boolean value true in JSON, an= d they shouldn=E2=80=99t be treated the same by a parser implementation whe= n mapping to a concrete object. It=E2=80=99s in this kind of automated gues= sing that this class of bugs occur, and that=E2=80=99s going to be the case= whether or not you take =C2=A0advantage of JSON=E2=80=99s polymorphic natu= re. I=E2=80=99ve run into cases where a parser library was trying to be ove= rly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, but ended up i= ntroducing errors in more strict components downstream. This is something t= hat protocol designers need to be aware of and guard against in the design = of the protocol to reduce possible ambiguities. Within GNAP today, we gener= ally have things that branch whether they=E2=80=99re an object (for a rich = description of something) or some non-structured special value (for a refer= ence or other item).=C2=A0

    =C2=A0

    The design tea= m created some simple JSON Schemas for parts of the protocol during our dis= cussion, but we didn=E2=80=99t include them in the design document due to b= oth lack of time to keep it updated with the rapid changes to the protocol = during the design team discussion, and not knowing if there would be intere= st in such material. I personally think it would be helpful to include as a= n informative reference in the final document, but that=E2=80=99s something= for the working group to take up eventually.

    <= p class=3D"MsoNormal">=C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0

    On Oct 23= , 2020, at 10:18 AM, Mika Bostr=C3=B6m <mika.bostrom=3D40smarke= ts.com@dmarc.ietf.org> wrote:

    =C2=A0

    Hello= , everyone.

    =C2=A0

    For background: GNAP/TxAuth/X= YZ/Oauth3 came up on a discussion forum and when I made note about certain = concerns, I was requested to send my comments to this working group.=

    =C2=A0

    =

    In short, I believe that the use of polymorphic= JSON in the protocol invites subtle and confusing implementation problems.= I also searched through the WG archives, and noticed that similar concerns= were noted, briefly, in a thread in July.

    =C2=A0

    The problem with polymorphic values, as I see it, is that implementation= s will need to branch on the (inferred) type of a given field. This isn'= ;t quite as bad if the types are strictly different, but allows for subtle = bugs when the value in question is a dictionary. What makes this unappealin= g is that "subtle bugs" in security protocols have a habit of tur= ning into vulnerabilities.

    =C2=A0

    Let's say = we have these imaginary payloads, both possible and valid in the same proto= col step:

    =C2=A0<= u>

    # payload 1

    {

    =C2=A0 ...,

    = =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",=

    =C2=A0=C2=A0=C2=A0 "modulus"= ;: <BIGINT>

    =C2=A0= }

    }

    =C2=A0

    # payload 2

    {

    =C2=A0 ...,<= u>

    =C2=A0 "public_key": = {

    =C2=A0=C2=A0=C2=A0 &qu= ot;alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<encoded string>= "

    =C2=A0 }

    }

    =C2=A0

    In both cases, the type of "public_key" field is a dictionary= . In both cases, they even have the same keys. However, the values in the d= ictionaries are entirely different, and an implementation will have to bran= ch to at least two possible decoding mechanisms. To make things worse, some= JSON implementations may choose to encode non-dictionary values as strings= , so it is possible for an originator to transmit what they expect and beli= eve to be payload 1 format, but which the receiver will interpret to be in = payload 2 format. And if the encoded string contains only digits, it will e= ven parse correctly as a bignum.

    =C2=A0

    While th= e above is clearly a manufactured scenario, it nonetheless demonstrates the= potential for logic bugs with polymorphic JSON. With richer types and more= complex dictionaries, there will surely be more room for errors.=

    =C2=A0

    Ambiguity in protocols is always a source of imple= mentation complexity and interoperability snags, but in an AuthN/AuthZ prot= ocol it is worse: it's terrifying. If GNAP/Oauth3 is intended to supers= ede Oauth1/2, wouldn't it be in everyone's interest to keep impleme= ntation complexity and mistake potential to a minimum?

    =C2=A0

    Best regards,

    Mika

    =C2=A0<= u>

    --

    =

    Mika Bostr=C3=B6m<= /p>

    Smarkets

    --
    TXAuth mailing list<= br>TXAuth@ietf.org=
    https://www.ietf.org/mailman/listinfo/txauth

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/txauth

    =E1=90=A7=

    =C2=A0<= /u>

    =C2=A0

    --
    TXAu= th mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth=

    <= /blockquote>
    =



    --

    Mika Bostr=C3=B6m

    <= /div>

    Smarkets

    -- TXAuth mailing list TXAuth@ietf.org https:/= /www.ietf.org/mailman/listinfo/txauth

    Anyway all this open to improvement.=C2=A0

    Cheers=C2=A0
    Fabien=C2=A0


    Le mer. 28 oct. 2020 =C3=A0 19:47, = Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:
    <= /div>

    Hi Fabien,=

    =C2=A0

    At least in the case of Go, I think the =E2=80=9Csolution=E2= =80=9D is far worse than the problem. The code in the article you cite is v= ery specific to the use case and IMHO quite ugly. So my preferred Go implem= entation would be a combination of untyped structures (Go interface{}) and = run-time enforcement of JSON Schema.

    =C2=A0

    Also, going back to our ea= rlier discussion on this topic, I just read Sec. 7 of gnap-00 and realized = that the RC also needs to deal with polymorphism (the =E2=80=9Ckey=E2=80=9D= value), not only the AS.

    = =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    =C2=A0

    Fro= m: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Wednesday, = October 28, 2020 at 18:56
    To: Mika Bostr=C3=B6m <mika.bostrom@smarkets.com>
    Cc: GNAP Mailing List <= txauth@ietf.org>, Justin Richer <jricher@mit.edu<= /a>>, Dick Hardt <dick.hardt@gmail.com>
    Sub= ject: Re: [GNAP] Feedback on polymorphism

    =C2=A0

    Thanks for the great feedback. Your concern is very valid.=C2= =A0

    =C2=A0<= /p>

    My implementation is in rust, which ma= kes life easier in that specific case.=C2=A0

    <= div>

    =C2=A0

    So I'm not a golang specialist but I guess the transcription = of json strings/arrays into go structs would work around the lines describe= d by=C2=A0https://mediu= m.com/@alexkappa/json-polymorphism-in-go-4cade1e58ed1

    =

    When we have a more formalized json schem= a, I suggest we make a library of json examples and some related code sampl= es in mainstream languages, to check it is feasible for everyone.=C2=A0<= /u>

    =C2=A0

    Cheers,

    Fabien

    =C2=A0

    =C2=A0

    On Wed, Oct 28, 2020 at 5:28 PM Mika= Bostr=C3=B6m <mika.bostrom@smarkets.com> wrote= :

    Hi everyone,

    =C2=A0

    Looks like I stuck my = finger in a hornets' nest. First off, apologies for not chipping in ear= lier, but there was a lot of material to digest. Also, warning: lots to rea= d ahead.

    =C2=A0

    I'm one of those people who = end up making use of AuthN/AuthZ functionality through a library. On top of= that I can see myself being roped in as a server (AS) implementation help.= So I'm approaching this from an outsider's perspective. Someone wh= o expects to be exposed to the eventual RFC and all the nitty-gritty detail= s. My relatively terse comment ended up at the top of the aforementioned HN= thread, which didn't necessarily help. Sorry about that.=

    =C2=A0

    Now, having read Justin's initial reply - and the = rest of the thread - I believe I can see where the desire for polymorphism = comes from. To be clear: I am all for strict types inside an implementation= , as it will add helpful guard-rails to the state management code paths. Ho= wever, I see this as a case of leaky abstraction. If we take the existing o= auth.xyj-java code to be the reference implementation, the choice makes log= ical sense: JSON is not expressive enough to serialise arbitrary objects, s= o in order to avoid writing complex payload parser(s) the internal implemen= tation details now leak to the protocol itself. From a purely technical per= spective, it's a cool trick. From a distance it even looks a bit like t= he result of protobuf decoding, but without the generated code parts.

    =C2=A0

    But then the downside. I don't personally = expect to be able to use the reference implementation, being mostly a Pytho= n user myself. A fair number of AS implementations will be written with lan= guages such as Go, Python, C#, Ruby, and JavaScript (thanks to node.js), an= d all of them will have to deal with the polymorphism. From what I've r= ead over the past couple of days, I understand that at least Go supports cu= stom unmarshalers from JSON to typed structs, at the cost of an indirection= . Normally when a Go code processes JSON to a typed struct, the process is = helped by field annotations in the type definition itself. For example, if = the payload for a person in JSON was

    =C2=A0

    {<= u>

    =C2=A0 "name":= "<string>",

    =C2=A0 "age": <int>,

    =C2=A0 "country": "<string>",

    =C2=A0 "city": = "<string>"

    }

    =C2=A0

    .. then the type definition would lo= ok like:

    =C2=A0

    type Person struct {

    =C2=A0 Name string `json:"name= "

    =C2=A0 Age int `j= son:"age"`

    =C2= =A0 Country string `json:"country"`

    <= p class=3D"MsoNormal">=C2=A0 City string `json:"city"`<= /u>

    }

    =C2=A0

    When the (possibly complex) type of a given field is fixed, unmarshaling = should still be straightforward. I haven't verified, but since the anno= tation only gives which field to look at for a given typed value, there sho= uld be nothing special about that. But when the field can instead be a unio= n of more than one distinct types, things start to get messy. There is no u= nion type in the language at all, so the following construct is not even po= ssible:

    =C2=A0=

    type Entity struct {

    =C2=A0 Resources []string `json:&quo= t;resources"`

    =C2= =A0 Client union(Client, string) `json:"client"`

    }

    =C2=A0

    As= I understand, the implicit expectation is that in the above case, the unma= rshaler detects that "client" is a string, and so expands it from= an opaque handle to the expected, populated type. Even after thinking abou= t the ramifications over the past few days I remain confused, because I don= 't see how the commonly used annotations could work. If the expectation= is that protocol implementations should use strong types, then the use of = polymorphic JSON is very likely to make things _more_ complicated for non-r= eference implementations.

    =C2=A0

    Hence my concern. I= 'm afraid that the leaky abstraction, while making the reference implem= entation more robust and straightforward, contributes to making other imple= mentations less robust. And this being a security protocol, the potential f= or brittle and/or confused implementations is terrifying.

    =C2=A0

    I am a fan of reducing complexity, and from what I can see, for= the reference implementation the polymorphic approach actually does that. = But I'm afraid it does so at others' expense. Languages have their = individual constraints, idioms and best practices. If parsing a protocol pa= yload introduces low-level complexities and encourages to go against common= practices, that is an invitation for problems. I am aware that my choice o= f words in the HN thread was likely to put people on defense, and for that = I apologise. But I do believe that the choice of polymorphic JSON is going = to make the life and use of other implementations notably less boring than = people in general would prefer.

    =C2=A0

    Cheers,

    Mika

    =C2=A0

    On Mon, 26 Oct 2020 at 02:04, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Dick,

    =C2=A0

    Well technically yes. Obviously the client can present any interface= it seems fit.=C2=A0

    = =C2=A0

    Still there's th= e question of the common model we want to present to the outside world and = supported by the protocol itself (which client libraries all build upon).= =C2=A0

    =C2=A0<= /u>

    But beneath the polyphormism quest= ion, the HN debate seems on the surface a lot like the original xyz (polyph= ormism goes along with the reduced endpoint model) vs xauth (a bit closer t= o OAuth2 in spirit, and where the client design has more latitude). Just ex= plained differently, by outside people with different agendas.=C2=A0=

    =C2=A0

    =

    Which is a bit weird because many of the critic= s on HN (who criticize polyphormism) also seem to really dislike OAuth in t= he first place (the inconsistencies are partially due to a bunch of differe= nt people commenting).=C2=A0

    =C2=A0

    Really to me= there's no fundamental truth behind that question. It's a matter o= f preference and priorities in the design. Whatever choices we make, we'= ;ll have to be prepared to explain and justify them in the open, even to so= me people that will dislike pretty much whatever we do (because it's fu= n to look smart and critize without proposing alternatives). And we owe the= se answers to people like Mika, who genuinely try to make the best of it.= =C2=A0

    =C2=A0<= /u>

    Fabien=C2=A0

    =C2=A0

    Le lun. 26 oct. 2020 =C3=A0 00:58, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

    =

    Hi Fabien<= /p>

    =C2=A0

    A library developer can provide whatever abstraction layer m= akes sense for the library's target=C2=A0audience and language.<= u>

    =C2=A0

    <= div>

    If the client library=C2=A0developer wants to us= e polymorphism=C2=A0in the interface presented to the user's of the lib= rary, the library developer can do that independent of polymorphism in the = protocol, and vice versa=C2=A0

    =C2=A0

    =3D> po= lymorphism in the protocol has no impact on client library developers

    =C2=A0

    =C2=A0

    <= img border=3D"0" width=3D"32" height=3D"32" style=3D"width: 0.3333in; heigh= t: 0.3333in;" id=3D"gmail-m_456060120045288885m_-3278588539485144854m_-5076= 011703106690355_x0000_i1028" alt=3D"Image removed by sender.">=E1=90= =A7

    =C2=A0

    On Sat, Oct 24, 2020 at 3:40 PM Fabi= en Imbault <fabien.imbault@gmail.com> wrote:<= /u>

    I= 9;m just realizing your "least to most important" might actually = say the same as what I was trying to say. So I'm not even sure what we&= #39;re arguing against :-)=C2=A0

    =C2=A0

    In brief my po= int if it wasn't clear is that we should be crystal clear on where we p= ut the cursor of simplicity, because this can mean different things for dif= ferent people and different roles.=C2=A0

    And as we see on HN we need to better explain our design c= hoices.=C2=A0

    =C2= =A0

    =C2=A0

    Le dim. 25 oct. 2020 =C3=A0 00:25, Fabien Im= bault <fabien.imbault@gmail.com> a =C3=A9crit=C2= =A0:

    Hi Dick,

    =C2=A0<= /u>

    Independantly from the debate on p= olyphormism, I beg to differ on your order preference.=C2=A0<= /p>

    =C2=A0

    Your assumption is that AS devs matter the most,=C2=A0because they're doing the i= mportant security implementation. But eating our own dogfood might help a l= ot to change that view. Most security issues occur because users of the spe= c are unable to deal with the complexity that is passed onto them.=C2=A0

    =C2=A0

    99% of the people that will actually= use the output of the work are application developers (client or RS) and t= heir own users.=C2=A0

    =C2=A0

    Our intent as well as the protocol drive the usag= e. Client libraries may help, but they're not a silver bullet, especial= ly because GNAP ultimately has no control about what people do there (for b= etter or worse). And everything we do here will help get to the better part= .=C2=A0

    = =C2=A0

    I'm not saying we do= n't intend to also care about AS developers (beginning with ourselves) = but it's a second order optimisation. And since it's a tendancy we&= #39;re leaning towards by default, I'm pretty sure we won't forget = that anyway.=C2=A0

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    =C2=A0

    Le sam. 24 oct. 2020 =C3=A0 23:50= , Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2= =A0:

    I'm confused by your logic Fabien.

    =C2=A0

    If= a client library developer wants to expose polymorphism, they can do that = independent of what is in the protocol.=C2=A0

    <= p class=3D"MsoNormal">=C2=A0

    I differ on who our stakeholders are.=C2=A0

    =C2=A0

    I think our stakeholders are in least to most important:<= /u>

    =C2=A0

    • AS developer
      • <= li class=3D"MsoNormal">RS developer
    • client developer
    • user

    =C2=A0

    A client library developer can expose whate= ver interface they want to simplify implementation.

    =

    =C2=A0

    I list the user so that we don't lose site of a critical rol= e.

    =C2=A0<= /p>

    /Dick

    =C2=A0

    =C2=A0

    =E1=90=A7

    =

    =C2=A0

    On Fri, Oct 23, 2020 at 6:27 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi there,=C2=A0

    =C2=A0

    Let me try to approach the issue under a different light.= More like a product manager would deal with feature selection to make it i= ntuitive for its users.=C2=A0

    = =C2=A0

    For most peo= ple, riding a bike is far easier than using a unicycle. Feels more stable. = And yet it's way easier to design for a single wheel than to build with= 2. Because then you'll need a lot more accessories (chain, chain ring,= etc.). Even so producing a bike doesn't have to be a brittle process, = it can be industrialized.=C2=A0

    =C2=A0

    Back to t= he GNAP topic.=C2=A0

    Ultimately we should strive to make the= spec as simple as can be. But we need to ask: simple for whom? For the bik= e owner or for the bike vendor?=C2=A0

    (short an= swer: the priority should be simplicity for spec users, not spec implemente= rs and even less spec designers).=C2=A0

    =

    =C2=A0

    The initial question that is asked is very interesting: isn't the= design flawed if GNAP is using json polyphormism? Or if the AS needs to ha= ndle the state of the request? Or if we must handle token revocation? Or if= we are looking for a global unique identifier? The argument stems of the f= act that is still arguably harder and more error prone to implement. Fair e= nough.=C2=A0

    =C2= =A0

    From a spec implementer'= ;s perspective, it may well be more complex. It mostly impacts the json lib= rary you'll end up using, plus a bit of input/output decoration around = it. Even golang provides utilities for this, despite not exactly being made= for this kind of purpose.

    My practical experience implementing it is that it's not that big a = deal. I mean, I wished it could be simpler, but it's manageable and the= re are other ways to reach levels of insurance that it does work as intende= d (json schema, test cases to validate the implementation, etc.). Arguably = it is still easier from an implementation perspective than say, json-ld, wh= ich is massively used in the SSI community.=C2=A0

    =C2=A0

    But ultimately who are we designing for? Are we striving to go eas= y on the spec implementer? Or are we trying to make sure end-developers usi= ng the client libraries won't shoot themselves in the foot?

    =C2=A0

    =

    The job to be done (JTBD), from the end-developer= 9;s perspective, is to efficiently ship an application. And provide authN/a= uthZ capabilities for end-users by relying on some well known implementatio= n.=C2=A0

    In turn, this s= pec implementer will rely on cryptographic utility libraries that deals int= ernally with the complexity of their own domain, so that we don't have = to. And here we could launch another HN flame war that starts with the titl= e "JWT sucks because". Which does have its set of very real issue= s but that's beyond the point.=C2=A0

    Note that any decent flamewar will be efficiently fueled b= y people hating medium. Is it outrageous for blog posts to be behind a payw= all? Maybe but it's even more outrageous to lack consistency, either by= not knowing how to get around a paywall if you're into a hacker punk m= ovement, or on the contrary by to not paying a subscription if you believe = that surveillance capitalism, to reuse Zuboff's terms, should be eradic= ated.=C2=A0

    What likely = seems an unnecessary sidenote tries to illustrate the point: for Justin it = was easier to publish on medium, because as a blog publisher, you might not= want to deal with hosting your own blog. But maybe as a reader you'll = find that annoying. Different audiences, different JTBD, different tradeoff= s.=C2=A0

    =C2=A0

    Polyphormism is a tool that enab= les the end-developer to have minimal knowledge of what it means to deal wi= th a GNAP client library. You prepare the request, send to the endpoint and= you're good to go. Massively simpler than OAuth2 or any similar protoc= ol by the way (as anyone with teaching experience on the subject might ackn= owledge). And=C2=A0 there's a lot more to be done to make sure we indee= d reduce the complexity for the end-developer and the end-user.=C2=A0

    =C2=A0

    If we find a better way to deal with that simp= licity balance, I'm all in. But the arguments need to be way more convi= ncing than just saying that it may be difficult to implement or validate.= =C2=A0

    =C2=A0<= /u>

    Cheers.

    Fabien

    =C2=A0

    = =C2=A0

    =C2=A0

    =

    =C2=A0

    =C2=A0

    Le ven. 23 oct. 2020 =C3=A0 22:35, Justin Richer <jr= icher@mit.edu> a =C3=A9crit=C2=A0:

    =C2=A0



    On Oct 23, 2020, at 3:5= 2 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    =C2=A0

    =

    Justin

    = =C2=A0

    I did note that I= was the one that argued for instance_id being in the object. Since it is i= n the object in the current draft, not including a pass by reference option= would be preferable.=C2=A0

    =C2=A0

    As for concre= te examples:

    - version o= f client

    - version of OS=

    - security attestation = of OS / device

    - locatio= n of client device

    - net= work client is operating on

    =C2=A0

    These are all= attributes of the client that an AS may require=C2=A0on the initial grant = request, and in future grant requests (which is when an instance_id) would = be used.

    =C2=A0

    = =C2=A0

    This is where our interp= retations differ: I don=E2=80=99t see these as =E2=80=9Cattributes of the c= lient=E2=80=9D in the same way that the key, display information, class ide= ntifiers, and other items currently represented by an instance_id are attri= butes of the client instance. The attestation components don=E2=80=99t modi= fy the instance so much as present additional information on top of the cli= ent instance itself. This is why I argue that they ought to be handled in a= separate object, so you=E2=80=99d have something like this strawman:

    =C2=A0

    {

    =C2=A0

    =C2=A0 pos= ture: {

    =C2=A0 =C2=A0 so= ftware_version: 1.2.3,

    = =C2=A0 =C2=A0 os_version: 14.3.2

    =C2=A0 =C2=A0 device_attestation: { =E2=80=A6 some structure or si= gned blob? =E2=80=A6 }

    = =C2=A0 =C2=A0 location: { lat: =E2=80=A6, lon: =E2=80=A6, alt: =E2=80=A6 }<= u>

    =C2=A0 },<= /p>

    =C2=A0

    =C2=A0 client: =E2=80=9Cclient-541-ab"

    =C2=A0

    =

    }

    =C2=A0

    This is a more f= undamental question about GNAP than whether the syntax uses polymorphism: t= his is about GNAP being very explicit about the data model of its elements.= OAuth 2=E2=80=99s incredibly loose and broad model of what the term =E2=80= =9Cclient=E2=80=9D is referring to, exactly, is deeply problematic in pract= ice. We=E2=80=99re even seeing that in the OAuth 2.1 work with having to de= fine a =E2=80=9Ccredentialed client=E2=80=9D, and even then that doesn=E2= =80=99t fully capture the different aspects that are out there. I think we= =E2=80=99re getting closer here in GNAP with explicit definition of =E2=80= =9Cclient instance=E2=80=9D, but we still need to be more precise about wha= t exactly a client instance includes, and what it does not.

    =C2=A0

    =C2=A0=E2=80=94 Justin

    =C2=A0


    =

    /Dick

    <= p class=3D"MsoNormal">=C2=A0

    3D"Image=E1=90=A7

    =C2=A0

    =

    On Fri, Oct 23, 2020 at 12:42 PM Justin Ri= cher <jricher@mit.edu> wrote:

    Dick,

    =

    =C2=A0

    As you=E2=80=99ll recall, I argued against including the client insta= nce identifier inside of the object as a mutually-exclusive field precisely= because of the principle violation that you are pointing out here, and so = it=E2=80=99s important to point out that the current text is a compromise t= hat needs to be examined in the wider experience of the working group. I am= on the side of removing the mutually-exclusive =E2=80=9Cinstance_id=E2=80= =9D option within an object, but this needs to be explored.

    =C2=A0

    The crux of my argument is that is exactly a case of pas= s-by-reference vs pass-by-value, and that runtime attestations are not part= of the =E2=80=9Cclient instance=E2=80=9D value itself but rather belong ou= tside of that object in a another part of the request. As stated in the edi= torial notes in this section, we need to look carefully at how these concep= ts fit within the model and where we would want to put them. Without concre= te examples of what these extensions look like and how they=E2=80=99re gene= rated, that is nearly impossible to do at this stage. I look forward to see= ing examples of this kind of data and how it can fit into the protocol.<= /u>

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct= 23, 2020, at 3:07 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

    =C2=A0<= /u>

    Hey Justin,

    <= div>

    =C2=A0

    As the draft has evolved, I question the continued use of polymor= phism. Note that I appreciate the elegance=C2=A0of using a string for pass-= by-reference, and an object for pass-by-value.

    =

    =C2=A0

    In the current draft, the=C2=A0

    =C2=A0

    Every time you create= or process a field it will mean only one thing, and there=E2=80=99s only o= ne field to look at to answer a question.=C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0 =C2= =A0instance_id =C2=A0An identifier string that the AS can use to identify t= he

    =C2=A0 =C2=A0 =C2=A0 = particular instance of this RC.=C2=A0 The content and structure of this<= /u>

    =C2=A0 =C2=A0 =C2=A0 identi= fier is opaque to the RC.

    =C2=A0

    =C2=A0 =C2=A0&q= uot;client": {

    =C2= =A0 =C2=A0 =C2=A0 =C2=A0"instance_id": "client-541-ab"<= u>

    =C2=A0 =C2=A0}=

    =C2=A0

    =C2=A0 =C2=A0If there are no additional fields to = send, the RC MAY send the

    =C2=A0 =C2=A0instance identifier as a direct reference value in lieu of t= he

    =C2=A0 =C2=A0object.<= u>

    =C2=A0

    =

    =C2=A0 =C2=A0"client": "cl= ient-541-ab"

    =C2=A0

    The instan= ce identifier can be sent two ways. Polymorphism is a convenience for the c= lient, but requires the server=C2=A0to have two code=C2=A0paths for "i= nstance_id".=C2=A0 We discussed this in the design team, and I argued = for having "instance_id" in the "client" object=C2=A0so= that any updates, such as new devices assertions, could be in the "cl= ient" object. As noted above, while I appreciate the elegance of using= a string (handle) to reference a previously provided object, it complicate= s how to update an existing object while providing the reference.=

    =C2=A0

    In your example of the "key" object belo= w, setting "proof" to bearer would avoid the issue you describe:<= u>

    =C2=A0

    =

    {=C2=A0
    =C2=A0"key": {=C2=A0=
    =C2=A0 =C2=A0 =C2=A0"proof": "bearer"
    =C2=A0 = =C2=A0 }
    }

    = =C2=A0

    In your example, when pr= ocessing the "key" object, code is having to check both the JSON = type of the property, as well as check the value of the "proof" p= roperty. In the example I provided, only the value of "proof" nee= ds to be checked. The "proof" property is acting as a type for th= e "key" object.

    =C2=A0

    Not being a Jav= a programmer, I don't know how this would work in a Java implementation= , but node.js, the processing would need to be done as above.=

    =C2=A0

    On a related note, there was significant negative feed= back on handles and polymorphism in the Hacker News article=C2=A0https://news.ycombinator.com/item?id=3D24855750= =C2=A0

    =C2=A0<= /u>

    /Dick

    =

    =C2=A0

    =C2=A0

    = On Fri, Oct 23, 2020 at 10:20 AM Justin Richer <jricher@mit.edu<= /a>> wrote:

    Hi Mika,

    Some background: I built out the XYZ p= rotocol (one of the predecessors to the initial GNAP Draft) in Java using s= trongly typed parsers and Java objects specifically to prove to myself that= it could be done in a way that made any sense in the code. (My own open so= urce implementation is at=C2=A0https://github.com/b= spk/oauth.xyz-java, but note that it=E2=80=99s not yet up to date with = the GNAP spec). It was important to me that I be able to use the system-wid= e configured parsers to implement this and not have to resort to stepping t= hrough elements completely by hand. Java doesn=E2=80=99t make it simple to = get the hooks into the right places (especially with the Jackson parser tha= t I used), but it is definitely possible to create a deterministic and stro= ngly-typed parser and serializer for this kind of data structure. Some of t= he rationale for using polymorphism is covered in the trailing appendix of = the draft document (https://www.ietf.org/archive/id/draft-ietf= -gnap-core-protocol-00.html#name-json-structures-and-polymor), but it= =E2=80=99s still good to discuss this here as the working group decides whi= ch approaches to take.=C2=A0

    =C2=A0

    The driving = reason for using polymorphism at the protocol level was to simplify the pro= tocol and make it :more: deterministic to create and process, not less. Eve= ry time you create or process a field it will mean only one thing, and ther= e=E2=80=99s only one field to look at to answer a question. Without polymor= phic field values, you usually need to rely on mutual exclusivity of fields= , which is prone to failure and requires additional error checking. Take fo= r example the key binding of access tokens. An access token could be bound = to the RC=E2=80=99s key used during the request, to a different key chosen = by the AS, or it could be a bearer token with no key at all. By making the = =E2=80=9Ckey=E2=80=9D field polymorphic, we can define it in terms of boole= an values and objects and express this set of mutually-exclusive options in= a non-ambiguous way. Without that, you=E2=80=99d need to have different fi= elds for the options and include additional checks in your parser to make s= ure they weren=E2=80=99t sent simultaneously, otherwise you could get hit w= ith this potential security vulnerability in an object:

    =C2=A0

    {=C2=A0

    = =C2=A0 =C2=A0 key: {

    =C2= =A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 }

    =C2=A0 =C2=A0 },

    =C2=A0 =C2=A0 bearer_token: true,=

    =C2=A0 =C2=A0 bind_to_rc_k= ey: true

    }=

    =C2=A0

    This would be an illegal object as per this alternate = proposal, but then you=E2=80=99d have to check each field and make sure it = wasn=E2=80=99t put next to others in the same object. I=E2=80=99ve done thi= s exercise with many other protocols and it=E2=80=99s both error prone and = easy to ignore since all the =E2=80=9Cgood=E2=80=9D examples would pass cod= e that doesn=E2=80=99t check this. With the polymorphic approach to this sa= me field, each of these three mutually-exclusive states is written in a way= that they cannot be sent together. It=E2=80=99s not just illegal, it=E2=80= =99s impossible and enforced by the syntax of JSON itself.

    =C2=A0

    =

    {=C2=A0

    =C2=A0 =C2=A0 key: {

    =C2=A0 =C2=A0 =C2=A0 proof: httpsig,

    =C2=A0 =C2=A0 =C2=A0 jwk: { =E2=80=A6 key value =E2=80=A6 = }

    =C2=A0 =C2=A0 }=

    }

    =

    =C2=A0

    // bearer token

    =C2=A0

    {

    =

    =C2=A0 =C2=A0 key: false

    }

    =C2=A0

    // bound to the RC=E2=80=99s presented key

    =C2=A0

    {

    =C2=A0 =C2=A0 key:= true

    }

    =C2=A0

    If someone sends a different type for this field, like an= array or number or a null, this doesn=E2=80=99t have a defined interpretat= ion in the protocol and would be a protocol level error.

    <= /div>

    =C2=A0

    While it might sound like polymorphism means that any field= could have any type or value, the opposite is true: each possible value is= explicitly typed, it=E2=80=99s just that there are potentially different t= ypes that express meaning for the field. This applies to all members of all= objects (dictionaries) as well as all members of an array (list). Every ti= me you process a field value or other element, you look at the type and the= n the value to determine what to do with that typed value.

    =C2=A0

    In your example below, each field within the dictionary w= ould also need to be typed, and each type would need to have a clear indica= tion of its meaning. To take your strawman key format below, the =E2=80=9Cm= odulus=E2=80=9D field could be defined polymorphically as either a =E2=80= =9Cbigint=E2=80=9D (a JSON number) or an =E2=80=9Cencoded string=E2=80=9D (= a JSON string). The definition would further say what exactly the encoding = of the string would be. That means that when you read the =E2=80=9Cmodulus= =E2=80=9D field there wouldn=E2=80=99t be any confusion on what the value w= as or how it was represented, regardless of the input format. Seeing a numb= er there means exactly one interpretation and seeing a string means exactly= one (different) interpretation =E2=80=94 but importantly, both of them are= a =E2=80=9Cmodulus=E2=80=9D, since that=E2=80=99s the field that determine= s the type. An implementation would likely use an internal BigInteger type = of object to represent the field value after parsing, so the question is ho= w to go from the JSON value (which is typed) into the BigInteger value.You = don=E2=80=99t just apply the type rules on the =E2=80=9Cpublic_key=E2=80=9D= field, you apply it to all sub-fields of that object.=C2=A0<= /p>

    =C2=A0

    So let=E2=80=99s dig into the specific bug you bring up= in the strawman, because it=E2=80=99s interesting: A JSON encoder that enc= odes numbers as strings, and not numbers, is not compliant with the JSON de= finitions of the field in question. For another example, the quoted string = value of =E2=80=9Ctrue=E2=80=9D is not equivalent to the boolean value true= in JSON, and they shouldn=E2=80=99t be treated the same by a parser implem= entation when mapping to a concrete object. It=E2=80=99s in this kind of au= tomated guessing that this class of bugs occur, and that=E2=80=99s going to= be the case whether or not you take =C2=A0advantage of JSON=E2=80=99s poly= morphic nature. I=E2=80=99ve run into cases where a parser library was tryi= ng to be overly =E2=80=9Chelpful=E2=80=9D in doing this kind of mapping, bu= t ended up introducing errors in more strict components downstream. This is= something that protocol designers need to be aware of and guard against in= the design of the protocol to reduce possible ambiguities. Within GNAP tod= ay, we generally have things that branch whether they=E2=80=99re an object = (for a rich description of something) or some non-structured special value = (for a reference or other item).=C2=A0

    =C2=A0

    Th= e design team created some simple JSON Schemas for parts of the protocol du= ring our discussion, but we didn=E2=80=99t include them in the design docum= ent due to both lack of time to keep it updated with the rapid changes to t= he protocol during the design team discussion, and not knowing if there wou= ld be interest in such material. I personally think it would be helpful to = include as an informative reference in the final document, but that=E2=80= =99s something for the working group to take up eventually.

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Oct 23, 2020, at 10:= 18 AM, Mika Bostr=C3=B6m <mika.bost= rom=3D40smarkets.com@dmarc.ietf.org> wrote:

    <= p class=3D"MsoNormal">=C2=A0

    Hello, everyone.

    =C2=A0

    For background:= GNAP/TxAuth/XYZ/Oauth3 came up on a discussion forum and when I made note = about certain concerns, I was requested to send my comments to this working= group.

    =C2=A0=

    In short, I believe that the use = of polymorphic JSON in the protocol invites subtle and confusing implementa= tion problems. I also searched through the WG archives, and noticed that si= milar concerns were noted, briefly, in a thread in July.

    =

    =C2=A0

    The problem with polymorphic values, as I see it, is that = implementations will need to branch on the (inferred) type of a given field= . This isn't quite as bad if the types are strictly different, but allo= ws for subtle bugs when the value in question is a dictionary. What makes t= his unappealing is that "subtle bugs" in security protocols have = a habit of turning into vulnerabilities.

    =C2=A0

    = Let's say we have these imaginary payloads, both possible and valid in = the same protocol step:

    = =C2=A0

    # payload 1

    {

    =C2=A0 ...,

    =C2=A0 "public_key": {

    =C2=A0=C2=A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "= modulus": <BIGINT>

    =C2=A0 }

    }<= u>

    =C2=A0

    <= div>

    # payload 2

    {

    =C2=A0 = ...,

    =C2=A0 "public= _key": {

    =C2=A0=C2= =A0=C2=A0 "alg": "rsa",

    =C2=A0=C2=A0=C2=A0 "modulus": "<encod= ed string>"

    =C2= =A0 }

    }

    =C2=A0

    In both cases, the type of "public_key" field i= s a dictionary. In both cases, they even have the same keys. However, the v= alues in the dictionaries are entirely different, and an implementation wil= l have to branch to at least two possible decoding mechanisms. To make thin= gs worse, some JSON implementations may choose to encode non-dictionary val= ues as strings, so it is possible for an originator to transmit what they e= xpect and believe to be payload 1 format, but which the receiver will inter= pret to be in payload 2 format. And if the encoded string contains only dig= its, it will even parse correctly as a bignum.

    =

    =C2=A0

    While the above is clearly a manufactured scenario, it nonetheless de= monstrates the potential for logic bugs with polymorphic JSON. With richer = types and more complex dictionaries, there will surely be more room for err= ors.

    =C2=A0

    Ambiguity in protocols is always a s= ource of implementation complexity and interoperability snags, but in an Au= thN/AuthZ protocol it is worse: it's terrifying. If GNAP/Oauth3 is inte= nded to supersede Oauth1/2, wouldn't it be in everyone's interest t= o keep implementation complexity and mistake potential to a minimum?=

    =C2=A0

    =

    Best regards,

    Mika

    <= u>=C2=A0

    --

    Mika Bostr=C3=B6m

    Smarkets

    --
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    <= /blockquote>

    =C2=A0

    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/tx= auth

    3D"Image=E1=90=A7

    = =C2=A0

    =C2=A0

    -= -
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth


    Yaron: would you elaborate on why you sugge= sted the file name be draft-ietf-gnap-core-protocol rather than just draft-= ietf-gnap-core?

    As GNAP is Grant Negotiation and Authori= zation Protocol, we have protocol in the file name twice.

    =3D""=E1=90=A7

    On Sat, Oct 17, 2020 at 5:27 AM Yaron S= heffer <yaronf.ietf@gmail.com> wrote:

    We have clear WG = consensus to adopt the draft, thank you all for your support.=

    =C2=A0

    J= ustin, can you please resubmit the draft as-is (no textual changes) as a wo= rking group draft. I would suggest the name draft-ietf-gnap-core-protocol. = We will ask that the document source will be managed on GitHub [1].<= u>

    =C2=A0

    The chairs will shortly announce additional draft editor(s). If you ar= e interested, please drop us a note. Note that this is a serious commitment= : this is a large and complex document and will take some time and likely q= uite a few revisions before it is published.

    =C2=A0

    This is a good tim= e to review the document and submit comments to the mailing list!=

    =C2=A0

    Thanks,

    =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

    =C2=A0

    [1] https://github.com/ietf-wg-gnap